Disk wakes up every 30 minutes and produces errors on dmesg

[Ricardo Teixeira]

Hi.

I'm trying to make a hard disk drive that's only used for backups stay in standby but there is something that is spinning the drive up every 30 minutes (exactly) or whenever I login to Gnome.

The drive stays awake for a few seconds and then gets spun down again (even though I set hdparm -S 12 (1 minute)).
I can hear this perfectly because it's a pretty noisy drive: Maxtor 6L300R0

Further more, every time the drive is spun up I get the following messages in dmesg:

[189046.000060] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[189046.000075] ata1.00: cmd b0/d1:01:00:4f:c2/00:00:00:00:00/00 tag 0 pio 512 in
[189046.000077] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[189046.000082] ata1.00: status: { DRDY }
[189046.448025] ata1: soft resetting link
[189046.629893] ata1.00: configured for UDMA/100
[189046.629927] ata1: EH complete
[190844.988581] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[190844.988595] ata1.00: cmd b0/d1:01:00:4f:c2/00:00:00:00:00/00 tag 0 pio 512 in
[190844.988597] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[190844.988603] ata1.00: status: { DRDY }
[190846.444029] ata1: soft resetting link
[190846.625872] ata1.00: configured for UDMA/100
[190846.625904] ata1: EH complete

As you can see, this shows two occurrences of the problem, and they're ~ 1800 seconds (30 minutes) apart: 190844.988581-189046.000060 = 1798.988521
I thought it could be smartd but I disabled smartd and the problem persists.

System details:
Ubuntu karmic (development branch) 9.10 fully updated today.

[Mace (mace-redhat-bugs)]

Created attachment 336227
"sysctl -w vm.block_dump=1" activity for sdb

Description of problem:

I have an internal SATA drive (sdb) that I only use for backups; it is otherwise unmounted. I have it set to spin down when idle.

Recently, I noticed taht the drive is not spinning down. I checked to see what was accessing it using "sysctl -w vm.block_dump=1" (see the attached who-io.log). It appeared to be devkit-disks-part-id.

I ran "devkit-disks --monitor-detail" (see attached devkit.log), and it appears that deviceKit is polling smart data, which keeps the drive from spinning down.

The device is not removable, and it's not in the list of polled drives:

# ps -Afl | grep devkit-disks-daemon | grep -v grep
4 S root 4326 1 0 80 0 - 0 poll_s 17:23 ? 00:00:02 /usr/libexec/devkit-disks-daemon
1 S root 4382 4326 0 80 0 - 0 poll_s 17:23 ? 00:00:03 devkit-disks-daemon: polling /dev/sdg /dev/sdf /dev/sr0 /dev/sde /dev/sr1 /dev/sdd

Version-Release number of selected component (if applicable):

DeviceKit-disks-003-7.fc11.x86_64
DeviceKit-003-1.x86_64
DeviceKit-power-006-3.fc11.x86_64

How reproducible:

Always

Steps to Reproduce:
1.Unmount a drive
2.Set the spin down time
3.Watch nothing happen

Actual results:

Drives stay spun up, even when unmounted

Expected results:

Drives should spin down

Additional info:

[Mace (mace-redhat-bugs)]

Created attachment 336228
devkit-disks --monitor-detail

[Eric (eric-redhat-bugs)]

Mace, feel free to add it to the tracker bug if you like; it's a slightly different issue, but the same net result, sounds like.

-Eric

[David (david-redhat-bugs)]

FWIW, this is fixed with the smartmontools->libatasmart port that I committed upstream yesterday. I'll keep this bug open until it's in Rawhide.

[Mace (mace-redhat-bugs)]

(In reply to comment #3)
> FWIW, this is fixed with the smartmontools->libatasmart port that I committed
> upstream yesterday. I'll keep this bug open until it's in Rawhide.

I don't have libatasmart installed; how does it relate to the issue?

[David (david-redhat-bugs)]

(In reply to comment #4)
> (In reply to comment #3)
> > FWIW, this is fixed with the smartmontools->libatasmart port that I committed
> > upstream yesterday. I'll keep this bug open until it's in Rawhide.
>
> I don't have libatasmart installed; how does it relate to the issue?

As I said this is fixed upstream but the fix is not in Rawhide yet. Once the next version hits Rawhide libatasmart will be pulled in and then a drive will not be spun up for checking ATA SMART if the drive are sleeping.

[Matthias (matthias-redhat-bugs)]

Should be fixed in DeviceKit-disks-004

[Mace (mace-redhat-bugs)]

Created attachment 338456
devkit-disks monitor output

I updated to DeviceKit-disks-004 from Koji, rebooted, and still see the same issue. Sdb is unmounted, has 'hdparm -S2' set, but will not spin down. The 'devkit-disks --monitor-detail' still shows /dev/sdb being polled.

[David (david-redhat-bugs)]

Interesting. Please try to boot into runlevel 3 (to avoid the desktop starting devkit-disks-daemon), ensure that devkit-disks-daemon isn't running and then put the drive asleep (or wait until it is asleep). Then as root run this command

 # /usr/libexec/devkit-disks-helper-ata-smart-collect /dev/sdb 1

replacing /dev/sdb with whatever disk it is. If the drive is asleep we should print

 Disk /dev/sdb is asleep and nowakeup option was passed

and exit with exit code 2. Otherwise it will dump a base64 encoded blob of the smart data to stdout and exit with exit code 0.

If this wakes up the disk it's probably a libatasmart bug - we've already identified a few issues with detecting whether a disk is asleep/awake in libatasmart (which is why I'm adding the libatasmart author to the Cc).

[Mace (mace-redhat-bugs)]

I booted to runlevel 3, and devkit was still polling the drive (something else must be starting devkit).

So I booted to runlevel 1, and confirmed that nothing was polling the drive. However, I still could not spin it down. Every time it went to spin down, I heard it spin up again (confirmed with 'hdparm -C'). Even manually (hdparm -y), the drive immediately spun back up.

I booted a F10 liveCD, and the drive spins down no problem. At this point, it appears that the F11 kernel is preventing the drive from spinning down, so devkit polling it while it's active is not a surprise. I'll open a separate bug for the kernel.

[Lennart (lennart-redhat-bugs)]

libatasmart 0.7 should fix the bad parsing of the awake flag.

http://koji.fedoraproject.org/koji/taskinfo?taskID=1283923

[David (david-redhat-bugs)]

(In reply to comment #9)
> I booted to runlevel 3, and devkit was still polling the drive (something else
> must be starting devkit).

Just do killall devkit-disks-daemon from a root shell...

> So I booted to runlevel 1, and confirmed that nothing was polling the drive.
> However, I still could not spin it down. Every time it went to spin down, I
> heard it spin up again (confirmed with 'hdparm -C'). Even manually (hdparm
> -y), the drive immediately spun back up.

I've seen that too on a Rawhide box. So what you are running into is a bug with hdparm and/or the kernel, not DeviceKit-disks.

FWIW, I have a WD Passport USB enclosure that automatically spins down the disk (e.g. without host intervention). When that happens devkit-disks-daemon will avoid reading SMART data to spin up the disk. And with the latest libatasmart fixes this should work for all kinds of ATA compliant devices. So I'm going to close this bug as WORKSFORME.

> I booted a F10 liveCD, and the drive spins down no problem. At this point, it
> appears that the F11 kernel is preventing the drive from spinning down, so
> devkit polling it while it's active is not a surprise. I'll open a separate
> bug for the kernel.

Please paste the bug number here so others can follow it. Thanks.

[David (david-redhat-bugs)]

Btw, I think the bug with hdparm and/or the kernel *may* be caused by what I explained in bug 454582 comment 5.

So it's probably worthwhile to try and patch hdparm to use O_RDONLY instead of O_RDWR as it is doing today, e.g.

 [root@localhost ~]# strace -o out.txt hdparm -y /dev/sda

 /dev/sda:
  issuing standby command

 [root@localhost ~]# grep "open(\"/dev/sda" out.txt
 open("/dev/sda", O_RDWR|O_NONBLOCK) = 3

[Mace (mace-redhat-bugs)]

Bug #494711 added for F11/rawhide kernel issue. I'll add a link to the above comment as well.

[Alex (alex-redhat-bugs)]

(In reply to comment #8)
> Interesting. Please try to boot into runlevel 3 (to avoid the desktop starting
> devkit-disks-daemon), ensure that devkit-disks-daemon isn't running and then
> put the drive asleep (or wait until it is asleep). Then as root run this
> command

I killed devkit-disks-daemon, and used hdparm 9.15's -S option to set the timeout to 5 seconds, then waited at least that amount of time.

> # /usr/libexec/devkit-disks-helper-ata-smart-collect /dev/sdb 1
>
> replacing /dev/sdb with whatever disk it is. If the drive is asleep we should
> print
>
> Disk /dev/sdb is asleep and nowakeup option was passed
>
> and exit with exit code 2. Otherwise it will dump a base64 encoded blob of the
> smart data to stdout and exit with exit code 0.

I did this, and heard the drive spin up, and shortly afterwards I got the base64 blob.

> If this wakes up the disk it's probably a libatasmart bug - we've already
> identified a few issues with detecting whether a disk is asleep/awake in
> libatasmart (which is why I'm adding the libatasmart author to the Cc).

libatasmart 0.12-3.fc11 and DeviceKit-disks-004-3.fc11 here.

[Jim (jim-redhat-bugs)]

Hi, I have a similar problem. Is there a way to tell devkit-disks-daemon (via devkit-disks-helper-ata-smart-collect) not to spin-up my /dev/sda once an hour? This is happening on F11 (I've just installed DeviceKit-disks-005-2.fc12.x86_64 but haven't restarted anything yet).

[Ricardo Teixeira (ricardo-ctrler)]

Here is the dmesg output with echo 1 > /proc/sys/vm/block_dump.

Could it be kjournald2 that is causing the spin ups?

The disk in question is /dev/sda and apparently there is no write actions to the disk at the time of spin up.
I don't know how to check if there is any read actions.

[Ricardo Teixeira (ricardo-ctrler)]

I figure out what is spinning up the disks.
If I kill devkit-disks-daemon the spinning up stops.

I'm assigning this bug to devkit-disks.

[Ricardo Teixeira (ricardo-ctrler)]

To furthermore pinpoint the problem it seems that the spinning up is happening because devkit is pooling the disk for smart data.
I did the following:

root@jupiter:~# hdparm -y /dev/sdc

/dev/sdc:
 issuing standby command
root@jupiter:~# hdparm -C /dev/sdc

/dev/sdc:
 drive state is: standby
root@jupiter:~# devkit-disks --ata-smart-refresh /dev/sdc >dump.txt
root@jupiter:~# hdparm -C /dev/sdc

/dev/sdc:
 drive state is: active/idle

but according to the devicekit man page it should only wakeup the disk if I issued devkit-disks --ata-smart-refresh /dev/sdc --ata-smart-wakeup

[Martin Pitt (pitti)]

This is pretty much wontfix, though. However, this could be made configurable.

[Ricardo Teixeira (ricardo-ctrler)]

But is there a way (even if it is a hard one) to disable the spinning up?

[Radu Cornea (raduc)]

I noticed the same problem, any workarounds?

Thanks.

[Jim (jim-redhat-bugs)]

reopening. Please see comment #15, above.

[Antti Kaihola (akaihola)]

Same problem here.

Strangely, when I tried monitoring disk access, I got no indication of any process accessing /dev/sdb* when the disk spun up or at any other time. I used this script to monitor:
    echo 1 >/proc/sys/vm/block_dump
    while ( ! dmesg -c|grep sdb ); do sleep 1; done
    echo 0 >/proc/sys/vm/block_dump

A work-around would be greatly appreciated. This pretty much prevents me from using Mythbuntu with my current hardware as a HTPC. My motherboard can't boot from the silent 1TB disk connected to my SATA PCI card, so I need an old noisy IDE disk just for booting up. Can't sleep if it's spinning up every 30 minutes in the next room.

[Antti Kaihola (akaihola)]

I peeked at the source code. The ATA smart collect script is called by the daemon like this:

    /usr/lib/devicekit-disks/devkit-disks-helper-ata-smart-collect /dev/sdb 1

The "1" parameter is the "nowakeup" option. Executing the above call as root always spins up my disk (also when replacing "1" with "0"). The corresponding code is:

        nowakeup = atoi (argv[2]);

        if (sk_disk_open (device, &d) != 0) {
                g_printerr ("Failed to open disk %s: %m\n", device);
                goto out;
        }

        if (sk_disk_check_sleep_mode (d, &awake) != 0) {
                g_printerr ("Failed to check if disk %s is awake: %m\n", device);
                goto out;
        }

        /* don't wake up disk unless specically asked to */
        if (nowakeup && !awake) {
                g_printerr ("Disk %s is asleep and nowakeup option was passed\n", device);
                ret = 2;
                goto out;
        }

So either sk_disk_check_sleep_mode fails to detect that the disk is sleeping, or the nowakeup option is parsed incorrectly. I'll debug that later.

[Ricardo Teixeira (ricardo-ctrler)]

Hello.
I think I don't have the knowledge to help you in debugging this but I hope you succeed.
If you need any help please post.
Thanks.

[Antti Kaihola (akaihola)]

Ricardo,

You could check whether these commands spin up the disk on your system:

$ sudo /usr/lib/devicekit-disks/devkit-disks-helper-ata-smart-collect /dev/sdX 1
$ sudo /usr/lib/devicekit-disks/devkit-disks-helper-ata-smart-collect /dev/sdX 0

(replace sdX with your disk device)

[Antti Kaihola (akaihola)]

Here's a dirty work-around:

    ~$ cd /usr/lib/devicekit-disks
    /usr/lib/devicekit-disks$ sudo mv devkit-disks-helper-ata-smart-collect devkit-disks-helper-ata-smart-collect.real
    /usr/lib/devicekit-disks$ sudo sh -c "cat >devkit-disks-helper-ata-smart-collect <<EOF
    > #!/bin/sh
    > [ "$1" != "/dev/sdb" ] && /usr/lib/devicekit-disks/devkit-disks-helper-ata-smart-collect.real "$@"
    > EOF"
    /usr/lib/devicekit-disks$ sudo chmod a+x devkit-disks-helper-ata-smart-collect
    $ ls -l devkit-disks-helper-ata-smart-collect*
    -rwxr-xr-x 1 root root 99 2009-10-16 09:30 devkit-disks-helper-ata-smart-collect
    -rwxr-xr-x 1 root root 5608 2009-09-19 18:30 devkit-disks-helper-ata-smart-collect.real

Replace /dev/sdb with the device you don't want to spin up.

[Snorre Jensen (snorre-jens1)]

All my disks that are inactive (spun down with hdparm -S12 /dev/sd*), are each 30 minutes woken up for a SMART check.

when i run Palimpsest Disk Utility and update now on a disk, I can see this with "ps auxf", and finally found out what is wakening my disks

root 1886 0.0 0.1 4944 2956 ? S 16:37 0:02 /usr/lib/DeviceKit/devkit-disks-daemon
root 1887 0.0 0.0 4608 684 ? S 16:37 0:03 \_ devkit-disks-daemon: polling /dev/sdb /dev/hdc /dev/sde /dev/sdc /dev/sdd
root 2570 0.0 0.0 2664 604 ? D 22:34 0:00 \_ /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/sda 0

running devicekit-disks 007 on Archlinux (gnome 2.28)

[Zeuthen (zeuthen)]

We don't. We specifically use libatasmart API to check if the disk is asleep before attempting retrieving SMART data from it. This works fine for most disks but some disks are broken insofar that checking if they are asleep wakes up the disk. Yes, priceless isn't it?

So this is either a hardware bug (most likely) or a libatatasmart bug (less likely). I'm saying the more is more likely because of the 8 external disks that I own, only one exhibits the behavior your bug is about.

Anyway, not a DeviceKit-disks bug.

[David (david-redhat-bugs)]

This is likely just a hardware bug in your hard disk spinning up when libatasmart sends the IDENTIFY command. Most of my external hard disks works fine - only a single one exhibits this behavior. So there is little we can do about this. Closing (since I believe there is little we can do about this) and reassigning to libatasmart (since it is the component waking up the disk even when told not to).

[Ricardo Teixeira (ricardo-ctrler)]

Antti,

I've checked and both commands spin up the disk.

[Ricardo Teixeira (ricardo-ctrler)]

Just checked your workaround and it works for me.
Don't know if updates will break it...

[Jim (jim-redhat-bugs)]

Thanks for the reply.
In that case, is there a way to make devkit refrain from sending IDENTIFY?

[Antti Kaihola (akaihola)]

Ricardo,

Yes, any updates to devicekit-disks will break my work-around.

[Antti Kaihola (akaihola)]

I sprinkled some debug output into job-ata-smart-collect.c and it seems that the sk_disk_open() call spins up the disk even before the sleep mode gets checked.

sk_disk_open() is provided by libatasmart4, so should this bug be assigned there?

Strangely, hdparm -C manages to retrieve the sleep state correctly without spinning the disk up. Hdparm doesn't use libatasmart4, so it must use a more advanced method for getting smart data from a drive.

[Antti Kaihola (akaihola)]

I've traced the reason for the spin-up to the disk_smart_read_thresholds() call at the end of sk_disk_open() in atasmart.c.

Apparently the SMART "Read Thresholds" command implies spinning up the disk, at least on my and Ricardo's controllers. I wonder why libatasmart4 always executes that call already when opening the disk device.

[Antti Kaihola (akaihola)]

Adding libatasmart to the "Affects" list since that seems to be the root cause for the problem: libatasmart can't query the sleep state of a drive without opening it first, and opening a disk executes the "Read Thresholds" call which spins up the disk.

[David (david-redhat-bugs)]

Not at this point. It might be useful with a DKD_ATA_SMART variable you can set via an udev rule. I've filed a bug for this here

https://bugs.freedesktop.org/show_bug.cgi?id=24594

for this feature request.

[Jim (jim-redhat-bugs)]

Thanks.

Since this has been reassigned, I'm reopening against libatasmart. If hddtemp can determine that this disk is asleep without waking it, libatasmart should be able to do that, too.

[Rich Rauenzahn (rich-shroop)]

FYI: The RedHat folks are also tracking this, but they claim it is a harddrive bug -- that the request shouldn't wake up most drives.

https://bugzilla.redhat.com/show_bug.cgi?id=491552

Regardless I'd like to see this fixed somehow... I'd rather not have to replace the 5 drives in my RAID5 setup!

[Ricardo Teixeira (ricardo-ctrler)]

This affects my 3 hdds...:

/dev/sda: Maxtor 6L300R0
/dev/sdb: SAMSUNG HD154UI
/dev/sdc: ST9120822AS

I only use sda and sdc once a day so I would also like to see this fixed.

[David (david-redhat-bugs)]

Interesting. Lennart, this is how I call into libatasmart

http://cgit.freedesktop.org/DeviceKit/DeviceKit-disks/tree/src/job-ata-smart-collect.c?id=008#n57

it looks correct, doesn't it? Adjusting summary too.

[David (david-redhat-bugs)]

(In reply to comment #20)
> Since this has been reassigned, I'm reopening against libatasmart. If hddtemp
> can determine that this disk is asleep without waking it, libatasmart should be
> able to do that, too.

Please attach strace output when doing this with hddtemp. Thanks.

[Rich (rich-redhat-bugs)]

execve("/usr/sbin/hddtemp", ["hddtemp", "/dev/sdc"], [/* 33 vars */]) = 0
brk(0) = 0x81ce000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=122927, ...}) = 0
mmap2(NULL, 122927, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb800b000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300k\1\0004\0\0\0\f"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1800012, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb800a000
mmap2(NULL, 1509672, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x90b000
mmap2(0xa76000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x16b) = 0xa76000
mmap2(0xa79000, 10536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0xa79000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb8009000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb80096c0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
mprotect(0xa76000, 8192, PROT_READ) = 0
mprotect(0xb78000, 4096, PROT_READ) = 0
munmap(0xb800b000, 122927) = 0
rt_sigaction(SIGSEGV, {0x804c9c0, [ILL BUS], SA_RESETHAND|SA_SIGINFO}, NULL, 8) = 0
rt_sigaction(SIGILL, {0x804c9c0, [BUS SEGV], SA_RESETHAND|SA_SIGINFO}, NULL, 8) = 0
rt_sigaction(SIGBUS, {0x804c9c0, [ILL SEGV], SA_RESETHAND|SA_SIGINFO}, NULL, 8) = 0
brk(0) = 0x81ce000
brk(0x81ef000) = 0x81ef000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=84748720, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7e09000
close(3) = 0
open("/dev/sdc", O_RDONLY|O_NONBLOCK) = 3
ioctl(3, SCSI_IOCTL_GET_BUS_NUMBER, 0xbf9d4570) = 0
ioctl(3, SG_IO, {'S', SG_DXFER_FROM_DEV, cmd[6]=[12, 00, 00, 00, 24, 00],
mx_sb_len=0, iovec_count=0, dxfer_len=36, timeout=3000, flags=0,
data[36]=["\0\0\5\2[\0\0\0ATA Maxtor 7H500F0 H"...], status=00,
masked_status=00, sb[0]=[], host_status=0, driver_status=0, resid=0, duration=0,
info=0}) = 0
ioctl(3, SG_IO, {'S', SG_DXFER_FROM_DEV, cmd[16]=[85, 08, 2e, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, ec, 00], mx_sb_len=32, iovec_count=0, dxfer_len=512,
timeout=3000, flags=0,
data[512]=["@\0\377?7\310\20\0\0\0\0\0?\0\0\0\0\0\0\0008HA18XHT "...],
status=02, masked_status=01, sb[22]=[72, 00, 00, 00, 00, 00, 00, 0e, 09, 0c, 00, 00,
00, ff, 00, 00, 00, 00, 00, 00, 00, 50], host_status=0, driver_status=0x8, resid=0,
duration=1, info=0x1}) = 0
ioctl(3, SG_IO, {'S', SG_DXFER_FROM_DEV, cmd[16]=[85, 08, 2e, 00, 00, 00, 00, 00,
00, 00, 00, 00, 00, 00, ec, 00], mx_sb_len=32, iovec_count=0, dxfer_len=512,
timeout=3000, flags=0,
data[512]=["@\0\377?7\310\20\0\0\0\0\0?\0\0\0\0\0\0\0008HA18XHT "...],
status=02, masked_status=01, sb[22]=[72, 00, 00, 00, 00, 00, 00, 0e, 09, 0c...

[Nico (nico-rdo)]

wow wow wow !

Wishlist? Really?

Please help us!

The disk I am using for rsnapshot backups is perfectly fine, but it is noisy. Plus I have 2 disks in a small Shuttle enclosure, it gets hot in there, so spin-down is not part of a wishlist for me, it is a necessity!

Please help!

[Radu Cornea (raduc)]

Not to mention the wear in the hard drive's spindle motor from spin-up/spin-down every 30 minutes. This will result in bad drives and is not acceptable in a mature release!

[Libin (libin-redhat-bugs)]

I'd just like to report I am facing the exact same issue. This is definitely not a hardware problem.

Upgraded from Fedora 9 to 11. Before upgrading everything worked fine. Hard drives will spin down after idling for a while. But now. They don't do that any more.

I have 3 hard drives, 2 of which are for backup purpose, one ATA, one SATA. If I issue a "hdparm -y" command. Both drives would spin down, no problem. then after a while I could hear them suddenly start spinning up again. do a "hadparm -C", both are active now.

This happens every half an hour.

If I kill devkit-disks-daemon, the issue will be gone. Both drives would spin down as expected.

[Antti (antti-redhat-bugs)]

Ubuntu's Launchpad is tracking this bug as well:
https://bugs.launchpad.net/ubuntu/+source/libatasmart/+bug/435190

The issue exists on Ubuntu 9.10 Karmic Alpha 6 using libatasmart 0.16.

I've traced the reason for the spin-up to the disk_smart_read_thresholds() call at the end of sk_disk_open() in atasmart.c.

Apparently the SMART "Read Thresholds" command causes at least some disks to spin up. I wonder why libatasmart4 always executes that call already when opening the disk device.

In the Launchpad bug comments, I also posted a dirty work-around involving a wrapper shell script.

[Antti Kaihola (akaihola)]

Rich,

Thanks for the Fedora bug link. That bug is assigned to the author of libatasmart, so I posted my findings there as well (see comment #15 above), with a link back to this Launchpad bug.

[Antti Kaihola (akaihola)]

The source file atasmart.c in current head of libatasmart Git repository [1] is identical Karmic's current 0.16 version. Just checked that to make sure a fix isn't already on its way.

  [1]: git://git.0pointer.de/libatasmart.git

[Zeuthen (zeuthen)]

Actually this seems to be a libatasmart bug, see these downstream bug reports

https://bugzilla.redhat.com/show_bug.cgi?id=491552
https://bugs.launchpad.net/ubuntu/+source/libatasmart/+bug/435190

Unfortunately there's no bug tracker for libatasmart yet but I think Lenny wanted one on fd.o. I'll try to get that going, then I'll reassign this bug. Thanks.

[Zeuthen (zeuthen)]

Reassigning to libatasmart.

[Rich Rauenzahn (rich-shroop)]

I understand that some drives are behaving differently, but I run hddtemp every 2 hours and have smartd polling every 2 hours, and neither utility wakes up my drives. They both know when they are asleep and they skip their check and log a message saying as much.

[Jim Meyering (meyering)]

Hi Lenny,
I have one of these disks, too ;-)

[David (david-redhat-bugs)]

Here's the upstream bug report

 http://bugs.freedesktop.org/show_bug.cgi?id=24579

(libatasmart just gained a bugzilla product at bugs.fd.o)

[Rich (rich-redhat-bugs)]

I think many of us are using hddparm -S during boot to set the power down time. I have smartd and hddtemp configured to poll at 2 hours, and I set -S to 1 hour. Their polling frequencies need to be greater than the sleep timeout. When smartd and hddtemp poll a sleeping drive, they notice the drive is asleep and ignore it. They do not wake it up.

What is the polling frequency of devkit-disks? Once this other issue is fixed, is it still going to poll so frequently that the drive never sleeps? Is it configurable? I haven't found anything in google yet.

[Lennart-poettering (lennart-poettering)]

Not sure who this "Lenny" guy is, I only know a distribution by that name...

But anyway, some guy called Lennart now prepped this patch:

http://git.0pointer.de/?p=libatasmart.git;a=commit;h=a223a4f6277a9f006b722b13671d5292dc6339bb

And I could use someone to test this before I roll a new release tarball for this. Anyone up for this?

[Rich Rauenzahn (rich-shroop)]

I can test it --- what's the easiest way for me to get a build? Or build my own?

Fedora 11, 32bit

Rich

[Lennart-poettering (lennart-poettering)]

(In reply to comment #7)
> I can test it --- what's the easiest way for me to get a build? Or build my
> own?

If building your own would be OK're prefer that. It should be enough to build libatasmart from the git tree and run the dkdisks daemon with LD_LIBRARY_PATH=foobar/libatasmart/.libs/

> Fedora 11, 32bit

Uh, this should be tested with F12. We broke ABI and API of libatasmart between F11 and F12.

[Rich Rauenzahn (rich-shroop)]

Hmph -- then that takes me out of the test pool!

Rich

[Snorre Jensen (snorre-jens1)]

Good work Lennart! now its working :)

/home/snorre# /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/sda 1
Disk /dev/sda is asleep and nowakeup option was passed
/home/snorre# /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/hda 1
Disk /dev/hda is asleep and nowakeup option was passed
/home/snorre# /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/hdb 1
Disk /dev/hdb is asleep and nowakeup option was passed

[Lennart-poettering (lennart-poettering)]

(In reply to comment #10)
> Good work Lennart! now its working :)
>
> /home/snorre# /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/sda
> 1
> Disk /dev/sda is asleep and nowakeup option was passed
> /home/snorre# /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/hda
> 1
> Disk /dev/hda is asleep and nowakeup option was passed
> /home/snorre# /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/hdb
> 1
> Disk /dev/hdb is asleep and nowakeup option was passed
>

Now we know that the wakeup situatin got fixed. But does reading the SMART data work as well, i.e. are there any regressions? Could you verify that please?

[Snorre Jensen (snorre-jens1)]

I run:
# /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/sda 0
then the disk spins up and I get this error:
Failed to read smart data for /dev/sda: No such file or directory

[Snorre Jensen (snorre-jens1)]

On Fri, 23 Oct 2009 15:47:34 -0700 (PDT)
<email address hidden> wrote:

> http://bugs.freedesktop.org/show_bug.cgi?id=24579
>
>
>
>
>
> --- Comment #11 from Lennart Poettering <email address hidden>
> 2009-10-23 15:47:33 PST --- (In reply to comment #10)
> > Good work Lennart! now its working :)
> >
> > /home/snorre# /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/sda
> > 1
> > Disk /dev/sda is asleep and nowakeup option was passed
> > /home/snorre# /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/hda
> > 1
> > Disk /dev/hda is asleep and nowakeup option was passed
> > /home/snorre# /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/hdb
> > 1
> > Disk /dev/hdb is asleep and nowakeup option was passed
> >
>
> Now we know that the wakeup situatin got fixed. But does reading the
> SMART data work as well, i.e. are there any regressions? Could you
> verify that please?
>
>
I run:
# /usr/lib/DeviceKit/devkit-disks-helper-ata-smart-collect /dev/sda 0
then the disk spins up and I get this error:
Failed to read smart data for /dev/sda: No such file or directory

[Lennart (lennart-redhat-bugs)]

*** Bug 526025 has been marked as a duplicate of this bug. ***

[Lennart (lennart-redhat-bugs)]

There's now a patch for this:

http://git.0pointer.de/?p=libatasmart.git;a=commit;h=a223a4f6277a9f006b722b13671d5292dc6339bb

And I could use someone to test this before I roll a new release tarball for
this. Anyone up for this?

[Akaihol+freedesktop (akaihol+freedesktop)]

Created an attachment (id=30689)
devkit-disks-helper-ata-smart-collect output with patched libatasmart

Lennart,

The patch fixed the spin-up problem on my Ubuntu 9.10 Alpha 6 box. Here's the output from devkit-disks-helper-ata-smart-collect when the drive is spun down, first with nowakeup=1, then nowakeup=0.

I installed the patched libatasmart from Martin Pitt's Ubuntu PPA: https://launchpad.net/~ubuntu-desktop/+archive/ppa

[Akaihol+freedesktop (akaihol+freedesktop)]

Created an attachment (id=30690)
skdump output with patched libatasmart

Here's skdump output for my disk with the patched libatasmart. I haven't compared it to the output before installing the patch, but all values seem valid.

[Martin Pitt (pitti)]

For easier testing, I prepared a package with Lennart's patch and uploaded it to

  https://launchpad.net/~ubuntu-desktop/+archive/ppa

There's nothing else in this PPA, so it's safe for upgrading.

Can folks affected by this please upgrade to this and verify that it fixes the problem? Thanks!

[Lennart (lennart-redhat-bugs)]

Fixed package is now in koji. Will request tag as soon as it finished to build.

[Tim (tim-redhat-bugs)]

Works fine here. Thanks!

[Libin (libin-redhat-bugs)]

I am sorry, I don't have much experience with these things, but is there a upgrade through yum?
I tried to do:
yum update libatasmart.x86_64
But the system says I am up to date:

>yum update libatasmart.x86_64
Loaded plugins: refresh-packagekit
Setting up Update Process
No Packages marked for Update

Was I updating the wrong package?

[Rich (rich-redhat-bugs)]

Libin,

Are you testing on FC11 or 12? My understanding is this fix will be on 12 only.

Meanwhile (until I upgrade), I've added this to my cron:

@hourly /usr/bin/killall devkit-disks-daemon > /dev/null 2>&1

[Lennart (lennart-redhat-bugs)]

Yes, this is fixed in F12 only. We change ABI/API since F11 and I have no plans to update this in that release.

[Libin (libin-redhat-bugs)]

Oh, No. I am on F11.

Why can't this be fixed on F11? I just upgraded from F9 one month ago. Lots of problems after upgrading. Don't want to repeat the same pain again.

Is there a way to config it to check the disk less frequently? Say once a day rather than every half an hour?

What's the impact if I just kill it like Rich said? Am I going to miss any functions?

[Pasi (pasi-redhat-bugs)]

Oh come on, fix this in F11 too!
Upgrade as itself is a pain but for me FC12 freezes randomly on install, I have no way out from FC11. Or paste the change here and I'll but it into FC11 code myself.
Even a proper workaround would be enough.

[Pasi (pasi-redhat-bugs)]

Hi

I have applied the change to libatasmart-0.12-3.fc11.x86_64.rpm and at least I my x86_64 system things seems to run OK. If anybody is interested in to try this lib out, I can provide the patch to you, or even x86_64 lib if needed.

  - Pasi -

[Peter Petrakis (peter-petrakis)]

For those still affected by this issue please compile the attached test case and run
against the suspected disk. If it produces

[189046.000060] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[189046.000075] ata1.00: cmd b0/d1:01:00:4f:c2/00:00:00:00:00/00 tag 0 pio 512 in
[189046.000077] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

On demand then let us know so we can duplicate this issue to

https://bugs.launchpad.net/ubuntu/+source/libatasmart/+bug/1092622

TEST CASE:

# sudo apt-get install -y libatasmart-dev
# gcc -o read_thresh_test skreadthreshold.c -latasmart
# sudo ./read_thresh_test /dev/sdX, where X is suspect device

[Davide Baldini (baldiniebaldini)]

As of 2013, Martin's package is no more in the "PPA" cited in message #38.
I tried to install libatasmart4 from packages.ubuntu.com/saucy/libatasmart4, but it doesn't fix the problem for me.

I'm on Debian 6.0, which doesn't have the updated package in repos (not in "unstable" repo, apparently).
Where can I get the package, preferably the individual "raw" .deb file so to not cause repo conflicts?