https://bugzilla.kernel.org/show_bug.cgi?id=203617
--- Comment #20 from Zhang Rui ([email protected]) --- (In reply to Rob from comment #16) > Someone else has identified the kernel commit that caused the change in ACPI > error reporting and has further narrowed down some of the causes for this > bug: > can you show me where the following information is got? I'm wondering which specific commit introduces the regression, pci? or the thunderbolt driver? But it does not seem to be an ACPI problem anyway. > > The issue appears to be related to trying to increase the io size allocated > > to > > a specific pci hotplug device on the thunderbolt 3 bridge. What I'm seeing > is > > consistent with the results of the git bisect I did earlier that added a > call > > to reallocate unassigned bridge resources; a change introduced in that > commit > > tries to optimize the layout of memory and io across a bridge, and > allocates > > more resources to hotplug buses that would otherwise go to waste. > > > > When the above is performed in combination with MMCONFIG/MCFG > (memory-mapped > > config space/table provided by motherboard (firmware, bios?), some kind of > > corruption occurs that immediately begins spamming the ACPI interrupt > handler > > with junk events; this may be due to memory corruption/offset errors, but > I'm > > not sure yet. They don't appear to be valid events; they seem to be > > randomized > > and each event has flags set on them that should make it impossible to > reach > > the code paths that are generating the errors due to guards on the dispatch > > side. ACPI errors have their event's dispatch type set to none, which > should > > never happen...it's not the GPE XX that's the problem, they're just bogus. > > From https://github.com/dhedlund/kernel-patch-lg-gram-17 -- You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ acpi-bugzilla mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
