NOTE: AI generated text below
----
Correction to the workaround I suggested in my previous comment, and a better
hypothesis to replace it.
I had written that detaching the dock before suspend, and re-attaching it only
after the desktop is up, was what kept my sessions alive. Today I forgot to do
that: I plugged the dock in while the machine was suspended and then resumed
with it attached - the exact sequence that crashed on Sep 10. It did not crash.
The dock enumerated fully inside the resume window (a SuperSpeed device and a
hub on bus 2, plus a four-device hub tree on bus 3, all within one second of
"PM: suspend exit"), so the hotplug did land where I expected it to. But USBSTS
read 0x401 - no PCD - where the crashing resume had read 0x411. Same gnome-shell
process still running, now 119 hours old.
So the dock-handling ritual was probably never the reason for the clean streak.
The one thing that changed between the crash and every clean cycle since is
something I did on Sep 11 for an unrelated reason (a wireless receiver kept
waking the laptop seconds after suspend): I disabled every ACPI and USB wake
source except the power button and the RTC alarm. That includes XHCI, TXHC,
TDM0 and TRP0.
The mechanism this suggests: while armed for wake, the host controller keeps
port-change detection live across suspend, so a connect made during sleep is
latched and still pending at wake-up - and gets processed in the same window in
which mutter is re-probing outputs. With wake disabled the controller loses
power completely, nothing is latched, and the dock is discovered as a fresh
device after resume has finished, outside that window.
That is consistent with the PCD correlation in my previous comment, and it also
explains why the crash was never reproducible on demand: it needs the hotplug to
fall inside the probe window, not merely to happen.
Cheap to test for anyone else hitting this:
echo XHCI > /proc/acpi/wakeup # plus TXHC, TDM0, TRP0 on a Thunderbolt
# laptop; check the names in that file first
The write is a toggle, not a set, and /proc/acpi/wakeup is reinitialised from
firmware defaults on every boot, so making it stick needs a small unit at boot.
Note this also disables wake-on-USB (keyboard, mouse, dock), which may or may
not be acceptable; the power button and the RTC alarm still work, so
suspend-then-hibernate is unaffected.
Caveat: this is one observation, not a verified workaround. I am reporting it
because it points at when the race window opens, which may be more useful than
the workaround itself. I will report back if a later resume crashes under this
configuration.
One non-fatal artefact from today's resume, in case it is related: about ten
seconds after the dock enumerated, gnome-shell logged
Page flip failed: drmModeAtomicCommit: Invalid argument
Failed to post KMS update: drmModeAtomicCommit: Invalid argument
The session recovered on its own and the external output came up
normally.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to 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
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
