Occasional suspend/sleep failures: race? USB, HP dock, ZFS, three L2ARC devices.

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.