On 31/08/2023 19:42, Graham Perrin wrote (to freebsd-current alone,
<https://lists.freebsd.org/archives/freebsd-current/2023-August/004509.html>):
I have a suspend.sh script that aims to take three cache devices
offline before sleep of the computer:
% grep -v -e '# ' /etc/rc.suspend | uniq | grep -B 3 -A 2 suspend.sh
#!/bin/sh
#
/usr/local/sbin/suspend.sh
echo "Usage: $0 [apm|acpi] [standby,suspend|1-4]"
% grep -v -e '# ' /usr/local/sbin/suspend.sh | uniq
#!/bin/sh
while mount | grep Transcend 2>&1; do
zpool export Transcend
sleep 5
done
zpool offline august gpt/cache1-august
zpool offline august gpt/cache2-august
zpool offline august gpt/cache3-august
sync
killall pulseaudio
while fstat | grep -e dsp -e mixer 2>&1; do
fstat | grep -e dsp -e mixer | cut -w -f 3 | while read pid;
do kill -15 "$pid"
done
done
sysctl hw.snd.default_unit=1
%
…
On the morning of Tuesday 26th September, I predicted a failure
(internal HDD ada1 was busy with a buildworld), so I took a screenshot
before attempting to sleep the notebook (HP ZBook 17 G2).
The album at <https://photos.app.goo.gl/wg2Ab5Huod1ToEMn8> begins with
cropped and non-cropped versions of this shot (08:07:51).
08:10: the failure to suspend, photographed. L2ARC device
gpt/cache1-august at the foot of the screen.
08:11: the HP dock. Two of four USB ports at the side occupied by flash
drives, both Kingston DataTraveler 3.0. gpt/cache1-august above,
gpt/cache2-august below.
08:12: the screen, after physically disconnecting various peripherals
but not the dock. At the foot of the screen: a Kingston DataTraveler
2.0, which provides gpt/cache3-august. This drive was at the side of the
notebook (was not docked).
08:13: the screen, after removing the HP ZBook from the HP dock.
REMARKABLE: neither of the DataTraveler 3.0 devices (in the side of the
dock) appears in any photograph.
Is this a race condition? As if the OS, or ZFS, prematurely lost the
ability to handle the docked storage devices on USB.
Can I do anything to make the sleep-related script (above) stronger, to
reduce the risk of failure?
Might things be more reliable _without_ acpi_hp(4)?
FreeBSD 15.0-CURRENT on the morning of 26th September would have been
n265350-72d97e1dd9cc:
% bectl list -c creation | tail -n 5
n265350-72d97e1dd9cc-c - - 882M 2023-09-19 12:45
n265350-72d97e1dd9cc-d - - 775M 2023-09-23 12:09
n265538-915af883221a-a - - 256M 2023-09-26 16:30
n265538-915af883221a-b - - 257M 2023-09-28 09:05
n265538-915af883221a-c NR / 503G 2023-09-29 23:34
%
% grep acpi_hp /boot/loader.conf
acpi_hp_load="YES"
# dev.acpi_hp.0.verbose=1
% man 4 acpi_hp
%
<https://man.freebsd.org/cgi/man.cgi?query=acpi_hp&sektion=4&manpath=freebsd-release#BUGS>
experimental, etc.
