NOTE: AI generated text below ---- Thanks for triaging. Your connector_state==NULL hypothesis matches what I can now show from the hardware side: the crash only happens when a connector/port change is still pending at the moment of resume, which is exactly the mid-hotplug window you describe. Below is the evidence that isolates it.
Nine suspend/resume cycles on the same boot, same gnome-shell process throughout (PID unchanged, 96 hours of uptime - it survived all eight clean cycles plus one hibernation): resume duration USBSTS at resume new SS devs crash ------------- ------------ ---------------------- ----------- ----- Sep 9, 17:53 14 s 0x401 = CNR+HCH - no Sep 10, 09:07 14 h 59 min 0x411 = CNR+PCD+HCH 2 YES Sep 10, 18:20 14 s 0x401 = CNR+HCH - no Sep 10, 18:54 18 min 31 s 0x401 = CNR+HCH - no Sep 10, 20:41 6 s 0x401 = CNR+HCH - no Sep 11, 08:08 11 h 11 min 0x401 = CNR+HCH - no Sep 11, 17:55 20 s (no xHCI resume error) - no Sep 11, 18:45 50 min 18 s (no xHCI resume error) - no Sep 12, 10:50 16 h 00 min 0x401 = CNR+HCH - no "new SS devs" counts only SuperSpeed devices enumerating within 60 s of the resume, which is what distinguishes a dock present at wake-up from one plugged in later during normal use. This rules out two things I had suspected: * Suspend duration is not the variable. An 11-hour suspend without the dock survived intact, as did a 16-hour one. The crashing resume was a 15-hour suspend: same order of magnitude, opposite outcome. An 18-minute one also survived, while a 4-minute one had crashed earlier. * The xHCI resume error is not the variable. "xhci_hcd 0000:00:0d.0: xHC error in resume ... Reinit" and "root hub lost power or was reset" are logged on seven of these nine resumes, including six that did not crash. The one register bit that tracks the crash is USBSTS bit 4 (0x10), PCD - Port Change Detect, set on exactly one of the nine resumes: the one that crashed. In other words a port state change was already latched on the host controller at wake-up, and only then. That matches the behavioural difference exactly: the crashing resume is the one where the Thunderbolt dock (and with it the external DP-1 monitor) was connected around resume time - the only resume at which SuperSpeed devices enumerate. On every clean resume the dock was absent, and the only USB activity is the re-enumeration of the internal fingerprint reader (06cb:00bd on 3-3) plus resets of two internal devices. Two corrections to my original description, now that I have more data: * I wrote that the dock was not involved, because its devices enumerate after the crash. The enumeration does happen after - but the PCD flag shows the port change was already pending before. The dock is causally involved; it just is not the enumeration of its downstream devices that does the damage. * I wrote that the xHC resume error is logged on every resume. That was an overstatement from a smaller sample: it is logged on seven of these nine. The conclusion is unchanged - six of those seven did not crash, so it is not the discriminating factor - but the wording was too strong. Working hypothesis, consistent with the backtrace: a pending connector hotplug makes the KMS output state transient at resume, and a GetResources D-Bus call served in that window reads an output whose EDID lookup returns NULL, which meta_output_kms_read_edid() dereferences unchecked. Caveat on the last three rows. After the Sep 11 08:08 resume I disabled every ACPI and USB wake source on this machine except the power button and the RTC alarm, for an unrelated reason (a wireless receiver was waking the laptop seconds after suspend). That includes XHCI, TXHC, TDM0 and TRP0, so the USB and Thunderbolt controllers are now left in a different power state across suspend. Two of the three resumes since then log no xHCI resume error at all, where all six before it did - so the change did alter the controller's resume path. It does not affect the crash correlation (no dock was attached at any of those three resumes), but measurements taken after Sep 11 are not strictly comparable to the earlier ones, and I am flagging it rather than quietly mixing the two sets. A workaround that has held so far, for anyone hitting this: detach the dock before suspending, and after resume wait until the desktop is fully up before plugging it back in. Eight clean cycles since adopting it. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to mutter in Ubuntu. https://bugs.launchpad.net/bugs/2166959 Title: gnome-shell crashed with SIGSEGV in meta_output_kms_read_edid when GetResources is called during resume from suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2166959/+subscriptions -- desktop-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
