diff options
| -rw-r--r-- | todo.org | 54 |
1 files changed, 20 insertions, 34 deletions
@@ -3220,6 +3220,18 @@ claims it does and needs correcting). The reload's one-second settle should make this hook's unblock land after =tlp resume=, and the re-check step is what shows it if the race goes the other way. +*** 2026-10-05 Mon @ 23:08:31 -0600 Real-cycle check passed: the hook fires from /usr/lib +One suspend-then-hibernate cycle on AC, RTC-woken after thirty seconds +(suspend entry 23:07:01, exit 23:07:32, s2idle). The kernel logged btusb +deregistered at 23:07:32 and registered again at 23:07:34, which is the hook's +unload, settle and load, and rfkill logged "unblock set for type bluetooth" +at 23:07:34, the hook's last command. No system-sleep line named the hook, +and afterwards rfkill read "Soft blocked: no" with the controller "Powered: +yes". The manual check under Manual testing is retired. Not proven by this +cycle: the plain-suspend race with =tlp resume='s replay (it entered with +bluetooth unblocked), and a true hibernate-class wake, which the entry-freeze +test now checks after each of its cycles. + *** TODO Hibernate entry freeze — confirm under observation, then mitigate :bug:velox:hibernate: Interim rule until this closes: do not hibernate unattended on battery. Shut down, or suspend on AC. @@ -4170,9 +4182,17 @@ date; systemctl hibernate #+begin_src sh :results output journalctl -b -o short-iso | grep -E "systemd-sleep|hibernation (entry|exit)|Image allocation|Failed to put" | tail -6 #+end_src +- Check bluetooth came back. A hibernate re-probes the controller, and the + resume hook's btusb reload is what un-wedges it: +#+begin_src sh :results output +rfkill list bluetooth | grep Soft; bluetoothctl show | grep Powered; journalctl -b -o short-iso | grep -E "btusb|unblock set for type bluetooth|Failed to set mode" | tail -6 +#+end_src - Repeat until five cycles are logged. Expected: all five cycles power off within two minutes and resume into the same session, with "hibernation exit" and no "Image allocation … short" line. +After each cycle bluetooth reads "Soft blocked: no" and "Powered: yes", the +journal shows a btusb reload and "unblock set for type bluetooth", and no +"Failed to set mode" line. A cycle where the screen stays black with the power LED on for more than five minutes is the entry freeze: hold power for 10 s, and write down the cycle number and whether the keyboard backlight was lit. A cycle that instead comes @@ -5206,40 +5226,6 @@ Expected: =zfs holds= showed the =upgrade-guarded= tag on the snapshot step -Qkk= over the reconciled names reports no mismatch, including the package cut off mid-extraction. -*** Bluetooth resume hook fires on a real sleep cycle -What we're verifying: that =/usr/lib/systemd/system-sleep/zz-bluetooth-resume= -runs at resume now that it lives in the one directory systemd-sleep scans. Its -old home under =/etc/= was never scanned, so the proof is a btusb reload in the -kernel log at the moment of resume, which about fifteen cycles never showed. -Do it on AC. A twenty-second cycle only suspends, so the hibernate entry -freeze does not come into it. -- Confirm the starting state and note the time: -#+begin_src sh :results output -rfkill list bluetooth | grep Soft; bluetoothctl show | grep Powered; date +%H:%M:%S -#+end_src -- Start a suspend-then-hibernate cycle (the hook reloads btusb for that class - whether or not the hibernate stage was reached): -#+begin_src sh :results output -systemctl suspend-then-hibernate -#+end_src -- Wait about twenty seconds. -- Wake it with a key press. -- After the wake, read the kernel log. The hook itself logs nothing, and - systemd-sleep logs a hook only when it fails, so the system-sleep and - zz-bluetooth terms should match nothing on a pass: -#+begin_src sh :results output -journalctl -b -o short-iso --since "-5 min" | grep -E 'btusb|system-sleep|zz-bluetooth|Failed to set mode' | tail -12 -#+end_src -- Re-check the radio state: -#+begin_src sh :results output -rfkill list bluetooth | grep Soft; bluetoothctl show | grep Powered -#+end_src -Expected: a "deregistering interface driver btusb" line and a fresh btusb -registration, both stamped within seconds of the resume; no system-sleep line -naming the hook; and the re-check still reads "Soft blocked: no" and -"Powered: yes". If the log shows no btusb deregistration at all, the hook -still is not running and the directory is not the cause. - ** DOING [#B] Prepare for GitHub open-source release :PROPERTIES: :LAST_REVIEWED: 2026-08-17 |