Igor Mammedov wrote:
Actually applying patch1 is already creating the crash (why???), hence I have added also dmesg-6.5-0.txt which shows a working condition based on git e8afd0d9fccc level (acpiphp_glue in kernel 6.4)Changelog: * split out debug patch into a separate one with extra printk added * fixed inverte bus->self check (probably a reason why it didn't work before) 1/3 debug patch 2/3 offending patch 3/3 potential fixI added more files to trace, add following to kernel CLIdyndbg="file drivers/pci/access.c +p; file drivers/pci/hotplug/acpiphp_glue.c +p; file drivers/pci/bus.c +p; file drivers/pci/pci.c +p; file drivers/pci/setup-bus.c +p; file drivers/acpi/bus.c +p" ignore_loglevel should be applied on top of e8afd0d9fccc PCI: pciehp: Cancel bringup sequence if card is not present apply a patch one by one and run testcase + capture dmesg after each patch one shpould endup with 3 dmesg to ananlyse 1st - old behaviour - no crash 2nd - crash 3rd - no crash hopefully Igor Mammedov (3): acpiphp: extra debug hack PCI: acpiphp: Reassign resources on bridge if necessary acpipcihp: use __pci_bus_assign_resources() if bus doesn't have bridge drivers/pci/hotplug/acpiphp_glue.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-)
Patch3 did not fix the issue, it seems that the culprit is somewhere else triggered by "benign" patch1 :-(
Also note about the trigger description in patch3: the dmesg trace on Inspiron laptop is collected after the first wake from suspend to ram. The consecutive attempt to sleep results in a frozen system.
Thanks, Woody
Attachment:
rfc.tar.xz
Description: application/xz
