Keywords: D33887, D33888, drm-kmod, graphics, LinuxKPI, radeonkms, resume, sleep, suspend, wake ---- At 23:58 yesterday, in bug 261166 comment 9: > … Up for four hours, panic-free, … Three hours and twelve minutes later (03:10:24), I put the computer to sleep with a script that gracefully exports OpenZFS devices on USB: * a mobile hard disk drive that comprises a non-essential pool * two small (thumb) flash drives that provide L2ARC to the boot pool – then switched off a display on DisplayPort on the HP dock in which this HP EliteBook 8570p rests. ---- At then after 06:23, to the best of my recollection, I: * woke the computer * switched on the display (a little late) * ran xrandr * disconnected then remade USB connections to the docked HP keyboard and docked Kensington trackball (one after the other, I can't recall which order, to work around the operating system not responding to one of the two devices) * maybe also disconnected both devices then reconnected both devices * rearranged windows – mostly dragging from the notebook display (left) to the Philips display (right). Screens on both displays suddenly went dark (blank/black/grey) with no cursor or pointer. I watched the front of the EliteBook for hard disk drive activity. None. I have this computer set to gracefully shut down (not sleep) in response to a press on the power button, which is separate from the keyboard. No response to normal presses. After a while, I forced off the computer, started, then shortly after the desktop environment (KDE Plasma) appeared I ran: hw-probe -all -upload Result: <https://bsd-hardware.info/?probe=5f106ee686> I see nothing in X.Org logs (probed, above) or /var/log/messages to indicate exactly what happened _immediately_ before the freeze occurred. This absence of information is unfortunate, but does make sense, in that the freeze was sudden and complete. Triage ====== Tentatively graphics/drm-devel-kmod because I'm testing this in combination with the patches for (bug 261166) these two reviews: ⚙ D33887 LinuxKPI: Allow spin_lock_irqsave to be called within a critical section <https://reviews.freebsd.org/D33887> ⚙ D33888 LinuxKPI: Allow wake_up to be executed within a critical section <https://reviews.freebsd.org/D33888> Cc: the author and reviewers. If this bug is irrelevant: my apologies, please remove yourselves. Thank you. Notes to self ============= Four USB ports on the side of the dock: * mobile hard disk drive (rear, upper) * trackball (front, lower) * keyboard (front, upper). Two USB ports at the rear of the dock: * the lower nearly always runs to the USB hub that's integral to the Philips display … yesterday, extraordinarily, I removed the cable (to rearrange things at the table) and did not replace it * L2ARC, 15G, Duracell-branded Alcor Micro Flash Drive USB 058f:6387 (upper). Two ports on the left of the EliteBook: * L2ARC, 29G, Kingston Technology DataTraveler 100 G3/G4/SE9 G2/50 USB 0951:1666 (front).
(In reply to Graham Perrin from comment #0) First attempt to reproduce the bug: not reproducible. % grep -e suspend -e BOOT /var/log/messages | tail -n 2 Jan 15 06:32:09 mowa219-gjp4-8570p-freebsd kernel: ---<<BOOT>>--- Jan 15 12:04:21 mowa219-gjp4-8570p-freebsd acpi[26301]: suspend at 20220115 12:04:21 % Sleep (with the script) at 12:04:21, switched off the Philips display. Woke the computer after around ninety seconds of sleep, waited for things to automatically rearrange themselves on the sole display. Switched on the Philips, xrandr, waited for things to automatically rearrange themselves across both displays, dragged most windows to the display on the right, continued working. Fine so far, touch wood. Feels rock solid. Notably: * no trouble with the USB keyboard or trackball on this occasion. Whilst it did take some time for the system to respond to USB keyboard input, I treat delays such as this, after wake from sleep, as normal with FreeBSD.