Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #263744 > unrolled thread

screen lock shuts down attached HDDs, they don't start up again

Back to article view | Back to linux.debian.user

Contents

  screen lock shuts down attached HDDs, they don't start up again Zenaan Harkness <zenaan@gmail.com> - 2023-11-21 04:50 +0100
    Re: screen lock shuts down attached HDDs, they don't start up again Michael Kjörling <2695bd53d63c@ewoof.net> - 2023-11-21 09:10 +0100
      Re: screen lock shuts down attached HDDs, they don't start up again Zenaan Harkness <zenaan@gmail.com> - 2023-11-22 11:00 +0100
      Re: screen lock shuts down attached HDDs, they don't start up again Zenaan Harkness <zenaan@gmail.com> - 2023-11-22 11:00 +0100

#263744 — screen lock shuts down attached HDDs, they don't start up again

Every time the screen lock kicks in, and I return to my debian gnome
desktop, I press Enter, wait for 20 seconds, press Enter again,
eventually the monitor wakes up and I enter the password.

The desktop displays, but my external HDDs have been put to sleep, and
they do not wake up.

One of them is zfs. The zfs mounts list shows, but any attempt to
view/ls a zfs mount, just hangs permanently until a reboot.

The other drive is an ext4 filesystem, and it has been completely
un-mounted and the HDD spun down, and it does not spin up again -
until a reboot.

This seems rather drastic, and unexpected. Surely others have
forgotten to dismount external drives, or taken too long to return to
the computer and had the screen lock kick in, and the external drives
"permanently" shut down?

Any ideas on how to stop this, without disabling the Gnome screen
lock? (I do want the screen to lock if I forget to lock it, or if I
manually lock it, if I'm away from my pc for a while)

[toc] | [next] | [standalone]

#263748

On 21 Nov 2023 14:48 +1100, from zenaan@gmail.com (Zenaan Harkness):
> The desktop displays, but my external HDDs have been put to sleep, and
> they do not wake up.
> 
> One of them is zfs. The zfs mounts list shows, but any attempt to
> view/ls a zfs mount, just hangs permanently until a reboot.
> 
> The other drive is an ext4 filesystem, and it has been completely
> un-mounted and the HDD spun down, and it does not spin up again -
> until a reboot.

This doesn't sound right.

Can you run hdparm -C on the affected devices at the time? What is the
result of that?

Do the drives spin back up if you use hdparm -z?

What is the exact kernel version you are running? Please provide both
the package name and exact package version, and the full output from
uname -a.

Assuming that those drives are connected over USB, do they show up in
lsusb output while inaccessible?

Is there anything relevant in dmesg output?

Are you booting the kernel with any command-line parameters? Please
provide the exact contents of /proc/cmdline.

A spun-down drive can take a brief time to spin back up (typically on
the order of a few seconds), but that SHOULD be handled automatically;
clearly something odd is going on in your case if it doesn't.

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

[toc] | [prev] | [next] | [standalone]

#263769

On 11/22/23, Zenaan Harkness <zenaan@gmail.com> wrote:
> On 11/21/23, Michael Kjörling <2695bd53d63c@ewoof.net> wrote:
>> On 21 Nov 2023 14:48 +1100, from zenaan@gmail.com (Zenaan Harkness):
>>> The desktop displays, but my external HDDs have been put to sleep, and
>>> they do not wake up.
>>>
>>> One of them is zfs. The zfs mounts list shows, but any attempt to
>>> view/ls a zfs mount, just hangs permanently until a reboot.
>>>
>>> The other drive is an ext4 filesystem, and it has been completely
>>> un-mounted and the HDD spun down, and it does not spin up again -
>>> until a reboot.
>>
>> This doesn't sound right.
>>
>> Can you run hdparm -C on the affected devices at the time? What is the
>> result of that?
>
> So it seems I can test this quickly with a manual suspend, then do the
> various checks... it seems that the issue here is the
> auto-sleep/suspend.
>
> For starters, prior to suspend, I've removed the zfs drive, and just
> left the ext4 drive in the USB caddy (it holds up to 2 drives).
>
> Prior to suspend, I get, for the 2.5 inch hdd when it has not been
> accessed for a while and I can feel it is not spinning:
>
> # hdparm -C /dev/sda
> /dev/sda:
>  drive state is:  standby
>
> then, I ls'ed a dir in that drive that had not previously been
> accessed, and could feel it spin up and then give me the output, and
> then I ran hdparm again and interestingly, checking a few times on the
> now spun up drive, I get identical results as with the drive in the
> spun down state:
>
> # hdparm -C /dev/sda
> /dev/sda:
>  drive state is:  standby
>
> ----
> Now, after suspend (and wait for hdd to spin down, and wait for
> monitors to blank, and wait another 10s) and finally wake the computer
> up (which is really too slow - 20 or 30 seconds or so, so something
> odd or challenging seems to be happening inside the kernel somewhere):
>
> # ll /dev/sd*
> ls: cannot access '/dev/sd*': No such file or directory
>
> # hdparm -C /dev/sda
> /dev/sda: No such file or directory
>
>
>> Do the drives spin back up if you use hdparm -z?
>
> Prior to suspend and wake, I get this:
>
> # hdparm -z /dev/sda
> /dev/sda:
>  re-reading partition table
>  BLKRRPART failed: Device or resource busy
>
> And again, after suspend and wake there is no more /dev/sda, or any
> /dev/sd*, so I cannot run hdparm on any such device.
>
>
>> What is the exact kernel version you are running? Please provide both
>> the package name and exact package version, and the full output from
>> uname -a.
>
> # uname -a
> Linux zen-L7 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1
> (2023-09-29) x86_64 GNU/Linux
>
> The kernel package is exactly
> linux-image-6.1.0-13-amd64
>
>
>> Assuming that those drives are connected over USB, do they show up in
>> lsusb output while inaccessible?
>
> Prior to suspend and wake, lsusb shows me my hubs, dock, eth adaptors,
> trackball, and possibly the following is the HDD dock ? dunno:
>
> Bus 006 Device 015: ID 152d:0565 JMicron Technology Corp. / JMicron
> USA Technology Corp. JMS56x Series
>
> ... and sure enough after suspend and wake, Bus 006 Device 015 is
> gone, no longer exists, so it somehow has not woken up - but I CAN
> still see the blue light on the hdd caddy, but the hdd remains in a
> spun down/ sleep state, and no /dev/sd* device.


I apologize, the above para was inserted after I did the suspend and
wake cycle, and the following paras were done before that. I apologize
for the confusion, so just be aware the following paras are part of
the "Prior to suspend..." para above.

> I do get these though (alias ll='ls -l'):
>
> # find /dev/disk/|grep usb
> /dev/disk/by-id/usb-WDC_WD20_SPZX-22UA7T0_RANDOM__3F4917AD758C-0:0
> /dev/disk/by-path/pci-0000:3a:00.0-usb-0:2.3.1:1.0-scsi-0:0:0:0
>
> # ll /dev/disk/by-path/pci-0000:3a:00.0-usb-0:2.3.1:1.0-scsi-0:0:0:0
> 0 lrwxrwxrwx 1 root root 9 20231122 10:33.10
> /dev/disk/by-path/pci-0000:3a:00.0-usb-0:2.3.1:1.0-scsi-0:0:0:0 ->
> ../../sda
>
> # ll /dev/sd*
> 0 brw-rw---- 1 root disk 8, 0 20231122 10:33.10 /dev/sda
>
> ... interestingly, it seems when I formatted this drive with ext4, I
> formatted ext4 on the whole disk (/dev/sda) without using partitions,
> and so it's just /dev/sda and not /dev/sda1, which has the ext4
> filesystem.
>
>
>> Is there anything relevant in dmesg output?
>
> This looks quite suspicious (some error lines, not all of dmesg output):
>
> [42635.638996] usb 6-2.3.1: device not accepting address 15, error -62
> [42668.986050] usb 6-2.3.1: USB disconnect, device number 15
> [42668.986406] device offline error, dev sda, sector 0 op 0x1:(WRITE)
> flags 0x800 phys_seg 0 prio class 2
> [42668.988647] hub 6-2.3.2:1.0: hub_ext_port_status failed (err = -71)
> [42668.990867] hub 6-2.3.2.3:1.0: hub_ext_port_status failed (err = -71)
> [42668.990888] hub 6-2.3.2.1:1.0: hub_ext_port_status failed (err = -71)
> [42669.007554] usb 6-2.3.2.3.1: Failed to suspend device, error -71
> [42669.008775] hub 6-2.3.2:1.0: hub_ext_port_status failed (err = -71)
> 42713.495809] xhci_hcd 0000:3a:00.0: Timeout while waiting for setup
> device command
> [42713.703761] usb 6-2.3.1: device not accepting address 19, error -62
> [42713.704792] usb 6-2.3-port1: unable to enumerate USB device
> [42713.708332] usb 6-2.3.2: USB disconnect, device number 5
> [42713.708343] usb 6-2.3.2.1: USB disconnect, device number 7
>
>
> since "2.3.1" appears in the drive links above, and 6 could be "Bus
> 6". I'm not familiar with dmesg output though...
>
> I also see the following, but that was earlier in the dmesg output and
> may relate to "quitting mpv" causing my desktop/wayland (or it seems,
> gnome shell) hang (a different email thread of mine):
>
> [41107.248174] gnome-shell[45289]: segfault at 0 ip 00007f8bc835f1e0
> sp 00007ffd720f9028 error 4 in
> libmutter-11.so.0.0.0[7f8bc824f000+15a000] likely on CPU 10 (core 4,
> socket 0)
>
>
>> Are you booting the kernel with any command-line parameters? Please
>> provide the exact contents of /proc/cmdline.
>
> Fresh debian stable install, no customization by me at all:
>
> # cat /proc/cmdline
> BOOT_IMAGE=/boot/vmlinuz-6.1.0-13-amd64
> root=UUID=9ce1e519-9712-4616-aeeb-0f858e5ac00a ro quiet
>
>
>> A spun-down drive can take a brief time to spin back up (typically on
>> the order of a few seconds), but that SHOULD be handled automatically;
>> clearly something odd is going on in your case if it doesn't.
>
> Indeed, something odd is up.
>
> So this hdd has, through suspend, disappeared. It's mount is gone,
> it's /dev device is gone. There is a crypted mount which still shows,
> but of course any access gives io error, and umount and cryptsetup
> close cleans that up.
>
> In the past, and I suspect still, with the zfs drive, the problems
> above are impossible to clean up with zfs, e.g run any zfs command
> such as `zfs list` or `zpool list` and the command hangs until reboot,
> and the drive cannot be used again, until a reboot, so the
> suspend/wake cycle is very problematic in this instance, I have to
> permanently disable auto suspend, and remember to not manually
> suspend, if I am in the middle of work on a zfs drive. At least, an
> externally attached zfs drive, but I suspect the same problem is with
> internal drive zfs mounts - zfs is just not properly integrated in
> relation to the linux kernel's suspend and resume, and zfs is not
> currently designed to cope with that... though I DO suspect if some
> sort of loop mount zfs filesystem-in-a-file were mounted only inside a
> virtual machine, and exported back to the host via samba or nfs, and
> the zfs 'filesystem in a file' exists on the host in an ext4
> filesystem, that then zfs may "cope" with suspend and resume, due to
> the cleaner nature of virtual machine "suspend" environment. Something
> to test one day...
>
>
>> “Remember when, on the Internet, nobody cared that you were a dog?”
>
> Bugger! I've been so deluded all this time...
> Oh well, better awake than deluded!
>

[toc] | [prev] | [next] | [standalone]

#263770

On 11/21/23, Michael Kjörling <2695bd53d63c@ewoof.net> wrote:
> On 21 Nov 2023 14:48 +1100, from zenaan@gmail.com (Zenaan Harkness):
>> The desktop displays, but my external HDDs have been put to sleep, and
>> they do not wake up.
>>
>> One of them is zfs. The zfs mounts list shows, but any attempt to
>> view/ls a zfs mount, just hangs permanently until a reboot.
>>
>> The other drive is an ext4 filesystem, and it has been completely
>> un-mounted and the HDD spun down, and it does not spin up again -
>> until a reboot.
>
> This doesn't sound right.
>
> Can you run hdparm -C on the affected devices at the time? What is the
> result of that?

So it seems I can test this quickly with a manual suspend, then do the
various checks... it seems that the issue here is the
auto-sleep/suspend.

For starters, prior to suspend, I've removed the zfs drive, and just
left the ext4 drive in the USB caddy (it holds up to 2 drives).

Prior to suspend, I get, for the 2.5 inch hdd when it has not been
accessed for a while and I can feel it is not spinning:

# hdparm -C /dev/sda
/dev/sda:
 drive state is:  standby

then, I ls'ed a dir in that drive that had not previously been
accessed, and could feel it spin up and then give me the output, and
then I ran hdparm again and interestingly, checking a few times on the
now spun up drive, I get identical results as with the drive in the
spun down state:

# hdparm -C /dev/sda
/dev/sda:
 drive state is:  standby

----
Now, after suspend (and wait for hdd to spin down, and wait for
monitors to blank, and wait another 10s) and finally wake the computer
up (which is really too slow - 20 or 30 seconds or so, so something
odd or challenging seems to be happening inside the kernel somewhere):

# ll /dev/sd*
ls: cannot access '/dev/sd*': No such file or directory

# hdparm -C /dev/sda
/dev/sda: No such file or directory


> Do the drives spin back up if you use hdparm -z?

Prior to suspend and wake, I get this:

# hdparm -z /dev/sda
/dev/sda:
 re-reading partition table
 BLKRRPART failed: Device or resource busy

And again, after suspend and wake there is no more /dev/sda, or any
/dev/sd*, so I cannot run hdparm on any such device.


> What is the exact kernel version you are running? Please provide both
> the package name and exact package version, and the full output from
> uname -a.

# uname -a
Linux zen-L7 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1
(2023-09-29) x86_64 GNU/Linux

The kernel package is exactly
linux-image-6.1.0-13-amd64


> Assuming that those drives are connected over USB, do they show up in
> lsusb output while inaccessible?

Prior to suspend and wake, lsusb shows me my hubs, dock, eth adaptors,
trackball, and possibly the following is the HDD dock ? dunno:

Bus 006 Device 015: ID 152d:0565 JMicron Technology Corp. / JMicron
USA Technology Corp. JMS56x Series

... and sure enough after suspend and wake, Bus 006 Device 015 is
gone, no longer exists, so it somehow has not woken up - but I CAN
still see the blue light on the hdd caddy, but the hdd remains in a
spun down/ sleep state, and no /dev/sd* device.

I do get these though (alias ll='ls -l'):

# find /dev/disk/|grep usb
/dev/disk/by-id/usb-WDC_WD20_SPZX-22UA7T0_RANDOM__3F4917AD758C-0:0
/dev/disk/by-path/pci-0000:3a:00.0-usb-0:2.3.1:1.0-scsi-0:0:0:0

# ll /dev/disk/by-path/pci-0000:3a:00.0-usb-0:2.3.1:1.0-scsi-0:0:0:0
0 lrwxrwxrwx 1 root root 9 20231122 10:33.10
/dev/disk/by-path/pci-0000:3a:00.0-usb-0:2.3.1:1.0-scsi-0:0:0:0 ->
../../sda

# ll /dev/sd*
0 brw-rw---- 1 root disk 8, 0 20231122 10:33.10 /dev/sda

... interestingly, it seems when I formatted this drive with ext4, I
formatted ext4 on the whole disk (/dev/sda) without using partitions,
and so it's just /dev/sda and not /dev/sda1, which has the ext4
filesystem.


> Is there anything relevant in dmesg output?

This looks quite suspicious (some error lines, not all of dmesg output):

[42635.638996] usb 6-2.3.1: device not accepting address 15, error -62
[42668.986050] usb 6-2.3.1: USB disconnect, device number 15
[42668.986406] device offline error, dev sda, sector 0 op 0x1:(WRITE)
flags 0x800 phys_seg 0 prio class 2
[42668.988647] hub 6-2.3.2:1.0: hub_ext_port_status failed (err = -71)
[42668.990867] hub 6-2.3.2.3:1.0: hub_ext_port_status failed (err = -71)
[42668.990888] hub 6-2.3.2.1:1.0: hub_ext_port_status failed (err = -71)
[42669.007554] usb 6-2.3.2.3.1: Failed to suspend device, error -71
[42669.008775] hub 6-2.3.2:1.0: hub_ext_port_status failed (err = -71)
42713.495809] xhci_hcd 0000:3a:00.0: Timeout while waiting for setup
device command
[42713.703761] usb 6-2.3.1: device not accepting address 19, error -62
[42713.704792] usb 6-2.3-port1: unable to enumerate USB device
[42713.708332] usb 6-2.3.2: USB disconnect, device number 5
[42713.708343] usb 6-2.3.2.1: USB disconnect, device number 7


since "2.3.1" appears in the drive links above, and 6 could be "Bus
6". I'm not familiar with dmesg output though...

I also see the following, but that was earlier in the dmesg output and
may relate to "quitting mpv" causing my desktop/wayland (or it seems,
gnome shell) hang (a different email thread of mine):

[41107.248174] gnome-shell[45289]: segfault at 0 ip 00007f8bc835f1e0
sp 00007ffd720f9028 error 4 in
libmutter-11.so.0.0.0[7f8bc824f000+15a000] likely on CPU 10 (core 4,
socket 0)


> Are you booting the kernel with any command-line parameters? Please
> provide the exact contents of /proc/cmdline.

Fresh debian stable install, no customization by me at all:

# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.1.0-13-amd64
root=UUID=9ce1e519-9712-4616-aeeb-0f858e5ac00a ro quiet


> A spun-down drive can take a brief time to spin back up (typically on
> the order of a few seconds), but that SHOULD be handled automatically;
> clearly something odd is going on in your case if it doesn't.

Indeed, something odd is up.

So this hdd has, through suspend, disappeared. It's mount is gone,
it's /dev device is gone. There is a crypted mount which still shows,
but of course any access gives io error, and umount and cryptsetup
close cleans that up.

In the past, and I suspect still, with the zfs drive, the problems
above are impossible to clean up with zfs, e.g run any zfs command
such as `zfs list` or `zpool list` and the command hangs until reboot,
and the drive cannot be used again, until a reboot, so the
suspend/wake cycle is very problematic in this instance, I have to
permanently disable auto suspend, and remember to not manually
suspend, if I am in the middle of work on a zfs drive. At least, an
externally attached zfs drive, but I suspect the same problem is with
internal drive zfs mounts - zfs is just not properly integrated in
relation to the linux kernel's suspend and resume, and zfs is not
currently designed to cope with that... though I DO suspect if some
sort of loop mount zfs filesystem-in-a-file were mounted only inside a
virtual machine, and exported back to the host via samba or nfs, and
the zfs 'filesystem in a file' exists on the host in an ext4
filesystem, that then zfs may "cope" with suspend and resume, due to
the cleaner nature of virtual machine "suspend" environment. Something
to test one day...


> “Remember when, on the Internet, nobody cared that you were a dog?”

Bugger! I've been so deluded all this time...
Oh well, better awake than deluded!

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web