On Fri, Dec 15, 2023 at 02:36:38PM +0100, Igor Mammedov wrote: > On Fri, 15 Dec 2023 21:57:43 +1030 > Jonathan Woithe <jwoithe@xxxxxxxxxx> wrote: > > > On Fri, Dec 15, 2023 at 08:43:29AM +1030, Jonathan Woithe wrote: > > > On Thu, Dec 14, 2023 at 02:32:05PM +0100, Igor Mammedov wrote: > > > > On Thu, 14 Dec 2023 11:58:20 +1030 Jonathan Woithe wrote: > > > > > > > > > > Following an update from 5.15.72 to 5.15.139 on one of my machines, the > > > > > > > > looks like you are running downstream kernel, can you file bug report > > > > with distro that you use (with a link posed here as well). > > > > > > I am running Slackware64 15.0. The kernels supplied by that distribution > > > are unmodified kernel.org kernels. > > > > > > > For now offending patches are being reverted, so downstream bug will help > > > > with tracking it and reverting it there. > > > > > > The patches will be reverted in Slackware as a matter of course when a > > > kernel.org "-stable" kernel with the fix is adopted. Slackware does not > > > apply any patches to kernel.org kernels. Nevertheless, I will raise a post > > > in the forum, hopefully later today. > > > > This has now been done: > > > > https://www.linuxquestions.org/questions/slackware-14/heads-up-pci-regression-introduced-in-or-around-5-15-129-commit-40613da52b13-4175731828/#post6470559 > > > > > > > The output of lspci is given at the end of this post[1]. The CPU is an > > > > > "Intel(R) Core(TM) i7-5930K CPU @ 3.50GHz" which is not overclocked. Please > > > > > let me know if you'd like more information about the affected machine. I > > > > > can also perform additional tests if required, although for various reasons > > > > > these can only be done on Thursdays at present. > > > > > > > > > > The kernel configuration file can easily be supplied if that would be > > > > > useful. > > > > > > > > full dmesg log and used config might help down the road (preferably with current > > > > upstream kernel), as I will be looking into fixing related issues. > > > > > > > > Perhaps a better way for taking this issue and collecting logs, will be > > > > opening a separate bug at https://bugzilla.kernel.org (pls CC me as well) > > > > > > Sure, will do. I'll be able to get the dmesg log from my earlier tests and > > > config easily enough. Testing with another kernel will have to wait until > > > next Thursday as that is when I'll next have physical access to the machine. > > > > A bug has been opened at bugzilla.kernel.org as requested. The logs, kernel > > configuration and the "lspci -tv" output (requested in a subsequent email) > > have been added. The logs and kernel configuration are from the kernel.org > > 5.15.139 kernel. You have been added to the bug's CC. The bug number is > > 218268: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=218268 > > > > As mentioned, testing another kernel can only happen next Thursday. If > > you would like other tests done let me know and I'll do them at the same > > time. I have remote access to the machine, so it's possible to retrieve > > information from it at any time. > > lets wait till you can get logs with dyndbg='...' (I've asked for earlier) > and one more test with "pci=realloc" on kernel CLI to see if that helps. Okay. > > Let me know if there's anything else I can do to assist. > > It looks like pci_assign_unassigned_bridge_resources() messed up BIOS configured > resources. And then didn't manage to reconfigure bridges correctly, which led to > unassigned BARs => thunderbolt/VGA issues. > > Something in ACPI tables must be triggering acpiphp hotplug path during boot. > Can you dump DSDT + SSDT tables and attach them to BZ. > PS: > to dump tables you can use command from acpica-tools (not sure how it's called in Slackware) > acpidump -b > which will dump all tables in binary format (so attach those or 'iasl -d' de-compiled ones) Slackware doesn't provide acpidump AFAIK but it was easy enough to compile from tools/power/acpi/tools/acpidump within the 5.15.72 tree I'd used previously to build 5.15.72 (the kernel that's currently running). However, running acpidump -b resulted in a segmentation fault. The root cause is line 339 in vsnprintf() in utprint.c. With a workaround in place a functional acpidump was obtained. I can provide further information from my analysis if it's appropriate and you're interested. For completeness I then tried the acpica source from Intel (version 20230628). The acpidump from this worked fine, and the files produced were identical to those from my fixed kernel-tree acpidump. A tarball of these is now attached to the Bugzilla report. Curiously enough, the corresponding vsnprintf() line in the Intel acpica source distribution matches that in the 5.15.72 source. Perhaps the compiler flags in the Intel package happen to prevent the segfault condition occurring at runtime for me. Regards jonathan
