USB powerseving and HDD sleep state

Aquinox · June 19, 2013, 12:21am

Hi.

I’ve recently acquired a new laptop:
Schenker Technologies A522 i5 3260, GTX 660M, 8GB RAM, HDD Seagate ST9500423AS (500GB)
After I got it I’ve installed a second hdd Hitachi HTS543232L9A300 320GB.

On the second one my main system - OS 12.3 64bit is installed (KDE 4)

I am experiencing the following inconvenience when working on battery:

If I plug my USB drive into any of the 3 USB3.0 slots - nothing happens.
If I do that with the only USB 2.0 port, I can mount the drive.

Similar yet more annoying problem is with a usb mouse.
Whatever I do, the mouse will go to sleep after a few seconds of inactivity (e.g. when loading a webpage on a slow connection).
I had the same problem on my old laptop running 12.1 - but there I could at least circumvent it by plugging the mouse in after I logged on rather than before. That does not work anymore.

Secondary and a bit not explicitly a laptop problem:

When working in linux I’d like to keep the Seagate HDD in sleep mode (due power, noise, lifetime etc.).

However when I spin it down using “hdparam -Y /dev/sda” after some minutes (approx 4) it is being started up again.
I have experienced a similar problem with HDDs on my normal PC ( https://forums.opensuse.org/english/get-technical-help-here/applications/467466-disabling-smart-hdds.html )
That time it was a SMART issue - so I have made similar entries to smartd.conf as written in that thread.
That however did not help.

Therefore my question: does anybody know what could be causing this?
I have tried to get the relevant process using “iotop” but I do not see anything directly from the logs.

Thanks in advance

Aquinox · January 2, 2014, 12:24am

There is one thing I have probably figured out. That is, that the udisks2 daemon is accessing the drive unnecessarily.
If I deactivate it and spin the drive down, it remains spun-down.

The info comes from: Bug #638765 “udisks wakes up unmounted drives from standby with …” : Bugs : “udisks” package : Ubuntu
As described on that page I have created a file 80-udisks.conf under /etc/udev/rules.d and added the following lines:

KERNEL=="sd*!0-9]", ATTR{removable}=="0", ENV{ID_BUS}=="ata", ENV{DEVTYPE}=="disk", ENV{UDISKS_DISABLE_POLLING}="1"
KERNEL=="sda!0-9]", ATTR{removable}=="0", ENV{ID_BUS}=="scsi", ENV{DEVTYPE}=="disk", ENV{ID_VENDOR}=="ATA", ENV{UDISKS_DISABLE_POLLING}="1"
KERNELS=="0:0:0:0", ENV{UDISKS_DISABLE_POLLING}="1"
KERNELS=="1:0:0:0", ENV{UDISKS_DISABLE_POLLING}="1"
KERNEL=="0:0:0:0", ENV{UDISKS_DISABLE_POLLING}="1"
KERNEL=="sda!0-9]", ENV{UDISKS_DISABLE_POLLING}="1"

to no avail.
Even if I stop udisks2.service by hand it still comes back to life rather quickly and a status check gives:

Jan 02 00:09:12 MobileUnit.QNet udisksd[6855]: Error performing housekeeping for drive /org/freedesktop/UDisks2/drives/ST9500423AS_6WR2V7KR: Error updating SMART data: sk_disk_smart_read_data: Operation not support...-error-quark, 0)

After stopping udisks2.service and starting btrace on /dev/sda I sent the drive to sleep by hdparm -Y /dev/sda
After that I waited a bit and then tried to save one file to /home, which is on /dev/sdb. Just opening the save-dialogue started sda again.
The btrace result for this chain of events is below:

  8,0    3        0     0.000000000     0  m   N cfq6840S / alloced
  8,0    3        1     0.000001437  6840  G   N [hdparm]
  8,0    3        2     0.000003732  6840  I   N 0 (85 06 20 00 00 00 00 00 00 00 00 00 00 40 e6 00 ..) [hdparm]
  8,0    3        3     0.000005172  6840  D   N 0 (85 06 20 00 00 00 00 00 00 00 00 00 00 40 e6 00 ..) [hdparm]                                                             
  8,0    2        0     0.045284498     0  m   N cfq6840S / put_queue                                                                                                        
  8,0    2        1     0.045295359  3211  G   N [kworker/2:1]                                                                                                               
  8,0    2        2     0.045296333  3211  I   N 0 (00 ..) [kworker/2:1]                                                                                                     
  8,0    2        3     0.045297253  3211  D   N 0 (00 ..) [kworker/2:1]                                                                                                     
  8,0    1        0    56.006607692     0  m   N cfq6329S / put_queue                                                                                                        
  8,0    1        0   154.801089164     0  m   N cfq6857S / alloced                                                                                                          
  8,0    1        1   154.801091019  6857  G   N [pool]                                                                                                                      
  8,0    1        2   154.801098663  6857  I   R 512 (85 08 2e 00 00 00 01 00 00 00 00 00 00 00 ec 00 ..) [pool]                                                             
  8,0    1        3   154.801100751  6857  D   R 512 (85 08 2e 00 00 00 01 00 00 00 00 00 00 00 ec 00 ..) [pool]                                                             
  8,0    0        0   155.167415926     0  m   N cfq5882S / alloced                                                                                                          
  8,0    0        1   155.167417486  5882  G   N [kworker/0:0]
  8,0    0        2   155.167418873  5882  I   N 0 (00 ..) [kworker/0:0]
  8,0    0        3   155.167419974  5882  D   N 0 (00 ..) [kworker/0:0]
  8,0    0        4   155.167423884  5882  R   N [0]
  8,0    0        5   155.167424109  5882  I   N 0 (00 ..) [kworker/0:0]
  8,0    2        4   157.566446599    56  C   R (85 08 2e 00 00 00 01 00 00 00 00 00 00 00 ec 00 ..) [2]
  8,0    2        5   157.566457307    56  D   N 0 (00 ..) [scsi_eh_0]
  8,0    2        6   157.566458897    56  R   N [0]
  8,0    2        7   157.566459980    56  I   N 0 (00 ..) [scsi_eh_0]
  8,0    2        8   157.566468318    56  D   N 0 (00 ..) [scsi_eh_0]
  8,0    0        6   157.566502148  5882  G   N [kworker/0:0]
  8,0    0        7   157.566509782  5882  I   R 32 (9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 ..) [kworker/0:0]
  8,0    0        8   157.566510351  5882  D   R 32 (9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 ..) [kworker/0:0]
  8,0    0        9   157.566526317     3  C   R (9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 ..) [0]
  8,0    0       10   157.566538377  5882  G   N [kworker/0:0]
  8,0    0       11   157.566540459  5882  I   R 64 (12 01 00 00 40 00 ..) [kworker/0:0]
  8,0    0       12   157.566540692  5882  D   R 64 (12 01 00 00 40 00 ..) [kworker/0:0]
  8,0    0       13   157.566553354  5882  C   R (12 01 00 00 40 00 ..) [0]
  8,0    0       14   157.566559542  5882  G   N [kworker/0:0]
  8,0    0       15   157.566562342  5882  I   R 64 (12 01 b0 00 40 00 ..) [kworker/0:0]
  8,0    0       16   157.566562699  5882  D   R 64 (12 01 b0 00 40 00 ..) [kworker/0:0]
  8,0    0       17   157.566571626     3  C   R (12 01 b0 00 40 00 ..) [0]
  8,0    0       18   157.566582163  5882  G   N [kworker/0:0]
  8,0    0       19   157.566584555  5882  I   R 64 (12 01 00 00 40 00 ..) [kworker/0:0]
  8,0    0       20   157.566584953  5882  D   R 64 (12 01 00 00 40 00 ..) [kworker/0:0]
  8,0    0       21   157.566600368     3  C   R (12 01 00 00 40 00 ..) [0]
  8,0    0       22   157.566607955  5882  G   N [kworker/0:0]
  8,0    0       23   157.566610441  5882  I   R 64 (12 01 b1 00 40 00 ..) [kworker/0:0]
  8,0    0       24   157.566610761  5882  D   R 64 (12 01 b1 00 40 00 ..) [kworker/0:0]
  8,0    0       25   157.566618476     3  C   R (12 01 b1 00 40 00 ..) [0]
  8,0    0       26   157.566627740  5882  G   N [kworker/0:0]
  8,0    0       27   157.566630152  5882  I   R 8 (5a 00 3f 00 00 00 00 00 08 00 ..) [kworker/0:0]
  8,0    0       28   157.566630529  5882  D   R 8 (5a 00 3f 00 00 00 00 00 08 00 ..) [kworker/0:0]
  8,0    0       29   157.566638688     3  C   R (5a 00 3f 00 00 00 00 00 08 00 ..) [0]
  8,0    0       30   157.566646980  5882  G   N [kworker/0:0]
  8,0    0       31   157.566649456  5882  I   R 8 (5a 00 08 00 00 00 00 00 08 00 ..) [kworker/0:0]
  8,0    0       32   157.566649833  5882  D   R 8 (5a 00 08 00 00 00 00 00 08 00 ..) [kworker/0:0]
  8,0    0       33   157.566656635     3  C   R (5a 00 08 00 00 00 00 00 08 00 ..) [0]
  8,0    0       34   157.566663889  5882  G   N [kworker/0:0]
  8,0    0       35   157.566666006  5882  I   R 36 (5a 00 08 00 00 00 00 00 24 00 ..) [kworker/0:0]
  8,0    0       36   157.566666400  5882  D   R 36 (5a 00 08 00 00 00 00 00 24 00 ..) [kworker/0:0]
  8,0    0       37   157.566673634     3  C   R (5a 00 08 00 00 00 00 00 24 00 ..) [0]
  8,0    1        4   157.566518505  6857  G   N [pool]
  8,0    1        5   157.566520985  6857  I   N 0 (85 06 20 00 00 00 00 00 00 00 00 00 00 00 e5 00 ..) [pool]
  8,0    1        6   157.566522291  6857  D   N 0 (85 06 20 00 00 00 00 00 00 00 00 00 00 00 e5 00 ..) [pool]
  8,0    2        9   157.573354130  3211  G   N [kworker/2:1]
  8,0    2       10   157.573355045  3211  I   N 0 (00 ..) [kworker/2:1]
  8,0    2       11   157.573355840  3211  D   N 0 (00 ..) [kworker/2:1]
  8,0    0        0   173.513438935     0  m   N cfq6857S / put_queue

Any Ideas how I can prevent this stupid access to sda would be welcome.

On the matter of sleeping USB:
I have modified /etc/laptop-mode/conf.d/usb-autosuspend.conf to read:

# The list of USB IDs that should not use autosuspend. Use lsusb to find out the
# IDs of your USB devices.
# Example: AUTOSUSPEND_USBID_BLACKLIST="046d:c025 0123:abcd"
AUTOSUSPEND_USBID_BLACKLIST="8564:1000 046d:c05a 046a:0801"

# The list of USB driver types that should not use autosuspend.  The driver
# type is given by "DRIVER=..." in a USB device's uevent file.
# Example: AUTOSUSPEND_USBID_BLACKLIST="usbhid usb-storage"
AUTOSUSPEND_USBTYPE_BLACKLIST="usbhid usb-storage"

this does not help in any way, mouse and keyboard remain dead on the USB3.0 ports. Only disabling autosuspend on battery revives them.

robin_listas · January 2, 2014, 12:51am

On 2014-01-02 00:26, Aquinox wrote:
>
> There is one thing I have probably figured out. That is, that the
> udisks2 daemon is accessing the drive unnecessarily.
> If I deactivate it and spin the drive down, it remains spun-down.

You should report all this on Bugzilla.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))