Re: hdparm standby timeout not working for WD raptors?
On 10/14/07, Mark Lord <[EMAIL PROTECTED]> wrote: > 1. How are you forcing the drives into standby? hdparm -y > 2. Have you reproduced this with a stock kernel.org kernel yet? No; maybe later this week. > One possibility is that these drives may be the kind that > generate a "spurious" interrupt when they spin-down via the timer, > and perhaps libata is "processing" that interrupt and sending > additional command(s) that then wake the drive up again immediately. > > To rule this out, you could try using drivers/ide for a moment or two, > and see if the same problem persists with those drives. > > You could also try dumping /proc/interrupts in conjunction with "hdparm -S1", > and we can compare that with a "known good" system. > > Something like this: > > hdparm -B255 /dev/sda > hdparm -S1 /dev/sda > cat /proc/interrupts > sleep 6 > cat /proc/interrupts Here's the log for the second suggestion: narf ~ # hdparm -B255 /dev/sda /dev/sda: setting Advanced Power Management level to disabled HDIO_DRIVE_CMD failed: Input/output error narf ~ # hdparm -S1 /dev/sda /dev/sda: setting standby to 1 (5 seconds) narf ~ # cat /proc/interrupts CPU0 0: 2268 IO-APIC-edge timer 1: 2 IO-APIC-edge i8042 8: 5 IO-APIC-edge rtc 9: 0 IO-APIC-fasteoi acpi 12: 4 IO-APIC-edge i8042 14: 206827 IO-APIC-edge ide0 16: 350813 IO-APIC-fasteoi sata_promise, uhci_hcd:usb5 17: 39596029 IO-APIC-fasteoi eth0 18: 0 IO-APIC-fasteoi uhci_hcd:usb4 19: 728947 IO-APIC-fasteoi libata, uhci_hcd:usb3 20: 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2 NMI: 0 LOC:2736793 ERR: 0 MIS: 0 narf ~ # sleep 6 narf ~ # cat /proc/interrupts CPU0 0: 2268 IO-APIC-edge timer 1: 2 IO-APIC-edge i8042 8: 5 IO-APIC-edge rtc 9: 0 IO-APIC-fasteoi acpi 12: 4 IO-APIC-edge i8042 14: 206828 IO-APIC-edge ide0 16: 350813 IO-APIC-fasteoi sata_promise, uhci_hcd:usb5 17: 39596069 IO-APIC-fasteoi eth0 18: 0 IO-APIC-fasteoi uhci_hcd:usb4 19: 728947 IO-APIC-fasteoi libata, uhci_hcd:usb3 20: 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2 NMI: 0 LOC:2736881 ERR: 0 MIS: 0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
1. How are you forcing the drives into standby? 2. Have you reproduced this with a stock kernel.org kernel yet? One possibility is that these drives may be the kind that generate a "spurious" interrupt when they spin-down via the timer, and perhaps libata is "processing" that interrupt and sending additional command(s) that then wake the drive up again immediately. To rule this out, you could try using drivers/ide for a moment or two, and see if the same problem persists with those drives. You could also try dumping /proc/interrupts in conjunction with "hdparm -S1", and we can compare that with a "known good" system. Something like this: hdparm -B255 /dev/sda hdparm -S1 /dev/sda cat /proc/interrupts sleep 6 cat /proc/interrupts Cheers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
On 10/14/07, Bart Samwel <[EMAIL PROTECTED]> wrote: > > Just to be sure: you did use -S 60 to get 5 minutes, right? Yes. And hdparm is kind enough to print: /dev/sda: setting standby to 60 (5 minutes) Here's a bizarre sequence which I just noticed: [extraneous blank lines removed for clarity] >> hdparm -C /dev/sd[abcde] /dev/sda: drive state is: standby /dev/sdb: drive state is: standby /dev/sdc: drive state is: standby /dev/sdd: drive state is: standby /dev/sde: drive state is: standby >> hdparm -S 60 /dev/sda /dev/sda: setting standby to 60 (5 minutes) >> hdparm -C /dev/sd[abcde] /dev/sda: drive state is: active/idle /dev/sdb: drive state is: active/idle /dev/sdc: drive state is: standby /dev/sdd: drive state is: standby /dev/sde: drive state is: standby Note that the -S 60 on /dev/sda affected /dev/sdb too! This is repeatable. I have these drives as RAID5 (software RAID). I don't know if that has anything to do with the failure of -S or not. Don't know if hdparm bypasses the RAID or not. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
Mark Weber wrote: On 10/14/07, Bart Samwel <[EMAIL PROTECTED]> wrote: Some things to check: * Run "hdparm -I" on your drive. In the "Capabilities" section there is a line "Standby timer values", for some drives this mentions a device specific minimum. I know some drives that ignore any setting below 60 seconds. * I also know of quite a number of drives where hdparm -B settings override the -S settings, even if you set the -S settings after the hdparm -B settings. You could try combinations with various values of hdparm -B, especially 1 and 255. Thanks for the suggestions. The -I command prints out a bunch of stuff including: Standby timer values: spec'd by Standard, with device specific minimum Ahhh. Spec'd by standard means that each -S unit is worth 5 seconds (for values up to 240 = 20 minutes), and the second part means that there is a minimum (which is not specified in this report, unfortunately). Perhaps you can get a hold of the full drive manual, the exact minimum value is probably specified there. I tried setting -B to 1 and and then set -S to 5 minutes. Also, -B 255 and then set -S to 5 minutes. No luck with either. These drives want to keep running. Just to be sure: you did use -S 60 to get 5 minutes, right? One thing of possible interest: The -B command printed the following message: /dev/sda: setting Advanced Power Management level to 0x01 (1) HDIO_DRIVE_CMD failed: Input/output error I would guess that the first line came out just before hdparm tried to do the set, and the second line indicates that the set failed. Yes, that seems correct. Nothing too weird there: it simply seems that the drive doesn't support the power management knob. (AFAIK you should be able to confirm this using the feature sets listed in the output of hdparm -I.) Perhaps -S is failing too, just without the diagnostic? Perhaps, but I'd expect it to print a diagnostic if it fails. I do seem to remember that (at least for some drives that I've seen) there isn't a diagnostic if you go below the device specific minimum, the value is simply ignored. Cheers, Bart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
On 10/14/07, Bart Samwel <[EMAIL PROTECTED]> wrote: > > Some things to check: > > * Run "hdparm -I" on your drive. In the "Capabilities" section there is > a line "Standby timer values", for some drives this mentions a device > specific minimum. I know some drives that ignore any setting below 60 > seconds. > > * I also know of quite a number of drives where hdparm -B settings > override the -S settings, even if you set the -S settings after the > hdparm -B settings. You could try combinations with various values of > hdparm -B, especially 1 and 255. Thanks for the suggestions. The -I command prints out a bunch of stuff including: Standby timer values: spec'd by Standard, with device specific minimum I tried setting -B to 1 and and then set -S to 5 minutes. Also, -B 255 and then set -S to 5 minutes. No luck with either. These drives want to keep running. One thing of possible interest: The -B command printed the following message: /dev/sda: setting Advanced Power Management level to 0x01 (1) HDIO_DRIVE_CMD failed: Input/output error I would guess that the first line came out just before hdparm tried to do the set, and the second line indicates that the set failed. Perhaps -S is failing too, just without the diagnostic? All of the above using 2.6.22-gentoo-r5 I have not yet tried 2.6.23 as suggested by Mark Lord. --- "And he puzzled three hours, `till his puzzler was sore." from "How the Grinch Stole Christmas" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
Mark Weber wrote: On 10/12/07, Mark Lord <[EMAIL PROTECTED]> wrote: That's interesting. So, either something is regularly accessing/polling the drive, or it just doesn't work with the standby timer. Are there any interesting kernel messages being generated during execution of those commands? No messages to /var/log/messages as a result of those commands; I ran several times and did a sync too, just in case. I very much doubt that something is regularly accessing the drives because I have a script that runs every 1/2 hour to check and log status. The drives stay "standby" for hours (even days) at a time unless I specifically access something on the RAID array. Then, they stay "active/idle" until I manually set them to "standby". Anything else you'd like me to try? Some things to check: * Run "hdparm -I" on your drive. In the "Capabilities" section there is a line "Standby timer values", for some drives this mentions a device specific minimum. I know some drives that ignore any setting below 60 seconds. * I also know of quite a number of drives where hdparm -B settings override the -S settings, even if you set the -S settings after the hdparm -B settings. You could try combinations with various values of hdparm -B, especially 1 and 255. Cheers, Bart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
Mark Weber wrote: On 10/12/07, Mark Lord [EMAIL PROTECTED] wrote: That's interesting. So, either something is regularly accessing/polling the drive, or it just doesn't work with the standby timer. Are there any interesting kernel messages being generated during execution of those commands? No messages to /var/log/messages as a result of those commands; I ran several times and did a sync too, just in case. I very much doubt that something is regularly accessing the drives because I have a script that runs every 1/2 hour to check and log status. The drives stay standby for hours (even days) at a time unless I specifically access something on the RAID array. Then, they stay active/idle until I manually set them to standby. Anything else you'd like me to try? Some things to check: * Run hdparm -I on your drive. In the Capabilities section there is a line Standby timer values, for some drives this mentions a device specific minimum. I know some drives that ignore any setting below 60 seconds. * I also know of quite a number of drives where hdparm -B settings override the -S settings, even if you set the -S settings after the hdparm -B settings. You could try combinations with various values of hdparm -B, especially 1 and 255. Cheers, Bart - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
On 10/14/07, Bart Samwel [EMAIL PROTECTED] wrote: Some things to check: * Run hdparm -I on your drive. In the Capabilities section there is a line Standby timer values, for some drives this mentions a device specific minimum. I know some drives that ignore any setting below 60 seconds. * I also know of quite a number of drives where hdparm -B settings override the -S settings, even if you set the -S settings after the hdparm -B settings. You could try combinations with various values of hdparm -B, especially 1 and 255. Thanks for the suggestions. The -I command prints out a bunch of stuff including: Standby timer values: spec'd by Standard, with device specific minimum I tried setting -B to 1 and and then set -S to 5 minutes. Also, -B 255 and then set -S to 5 minutes. No luck with either. These drives want to keep running. One thing of possible interest: The -B command printed the following message: /dev/sda: setting Advanced Power Management level to 0x01 (1) HDIO_DRIVE_CMD failed: Input/output error I would guess that the first line came out just before hdparm tried to do the set, and the second line indicates that the set failed. Perhaps -S is failing too, just without the diagnostic? All of the above using 2.6.22-gentoo-r5 I have not yet tried 2.6.23 as suggested by Mark Lord. --- And he puzzled three hours, `till his puzzler was sore. from How the Grinch Stole Christmas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
Mark Weber wrote: On 10/14/07, Bart Samwel [EMAIL PROTECTED] wrote: Some things to check: * Run hdparm -I on your drive. In the Capabilities section there is a line Standby timer values, for some drives this mentions a device specific minimum. I know some drives that ignore any setting below 60 seconds. * I also know of quite a number of drives where hdparm -B settings override the -S settings, even if you set the -S settings after the hdparm -B settings. You could try combinations with various values of hdparm -B, especially 1 and 255. Thanks for the suggestions. The -I command prints out a bunch of stuff including: Standby timer values: spec'd by Standard, with device specific minimum Ahhh. Spec'd by standard means that each -S unit is worth 5 seconds (for values up to 240 = 20 minutes), and the second part means that there is a minimum (which is not specified in this report, unfortunately). Perhaps you can get a hold of the full drive manual, the exact minimum value is probably specified there. I tried setting -B to 1 and and then set -S to 5 minutes. Also, -B 255 and then set -S to 5 minutes. No luck with either. These drives want to keep running. Just to be sure: you did use -S 60 to get 5 minutes, right? One thing of possible interest: The -B command printed the following message: /dev/sda: setting Advanced Power Management level to 0x01 (1) HDIO_DRIVE_CMD failed: Input/output error I would guess that the first line came out just before hdparm tried to do the set, and the second line indicates that the set failed. Yes, that seems correct. Nothing too weird there: it simply seems that the drive doesn't support the power management knob. (AFAIK you should be able to confirm this using the feature sets listed in the output of hdparm -I.) Perhaps -S is failing too, just without the diagnostic? Perhaps, but I'd expect it to print a diagnostic if it fails. I do seem to remember that (at least for some drives that I've seen) there isn't a diagnostic if you go below the device specific minimum, the value is simply ignored. Cheers, Bart - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
On 10/14/07, Bart Samwel [EMAIL PROTECTED] wrote: Just to be sure: you did use -S 60 to get 5 minutes, right? Yes. And hdparm is kind enough to print: /dev/sda: setting standby to 60 (5 minutes) Here's a bizarre sequence which I just noticed: [extraneous blank lines removed for clarity] hdparm -C /dev/sd[abcde] /dev/sda: drive state is: standby /dev/sdb: drive state is: standby /dev/sdc: drive state is: standby /dev/sdd: drive state is: standby /dev/sde: drive state is: standby hdparm -S 60 /dev/sda /dev/sda: setting standby to 60 (5 minutes) hdparm -C /dev/sd[abcde] /dev/sda: drive state is: active/idle /dev/sdb: drive state is: active/idle /dev/sdc: drive state is: standby /dev/sdd: drive state is: standby /dev/sde: drive state is: standby Note that the -S 60 on /dev/sda affected /dev/sdb too! This is repeatable. I have these drives as RAID5 (software RAID). I don't know if that has anything to do with the failure of -S or not. Don't know if hdparm bypasses the RAID or not. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
1. How are you forcing the drives into standby? 2. Have you reproduced this with a stock kernel.org kernel yet? One possibility is that these drives may be the kind that generate a spurious interrupt when they spin-down via the timer, and perhaps libata is processing that interrupt and sending additional command(s) that then wake the drive up again immediately. To rule this out, you could try using drivers/ide for a moment or two, and see if the same problem persists with those drives. You could also try dumping /proc/interrupts in conjunction with hdparm -S1, and we can compare that with a known good system. Something like this: hdparm -B255 /dev/sda hdparm -S1 /dev/sda cat /proc/interrupts sleep 6 cat /proc/interrupts Cheers - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
On 10/14/07, Mark Lord [EMAIL PROTECTED] wrote: 1. How are you forcing the drives into standby? hdparm -y 2. Have you reproduced this with a stock kernel.org kernel yet? No; maybe later this week. One possibility is that these drives may be the kind that generate a spurious interrupt when they spin-down via the timer, and perhaps libata is processing that interrupt and sending additional command(s) that then wake the drive up again immediately. To rule this out, you could try using drivers/ide for a moment or two, and see if the same problem persists with those drives. You could also try dumping /proc/interrupts in conjunction with hdparm -S1, and we can compare that with a known good system. Something like this: hdparm -B255 /dev/sda hdparm -S1 /dev/sda cat /proc/interrupts sleep 6 cat /proc/interrupts Here's the log for the second suggestion: narf ~ # hdparm -B255 /dev/sda /dev/sda: setting Advanced Power Management level to disabled HDIO_DRIVE_CMD failed: Input/output error narf ~ # hdparm -S1 /dev/sda /dev/sda: setting standby to 1 (5 seconds) narf ~ # cat /proc/interrupts CPU0 0: 2268 IO-APIC-edge timer 1: 2 IO-APIC-edge i8042 8: 5 IO-APIC-edge rtc 9: 0 IO-APIC-fasteoi acpi 12: 4 IO-APIC-edge i8042 14: 206827 IO-APIC-edge ide0 16: 350813 IO-APIC-fasteoi sata_promise, uhci_hcd:usb5 17: 39596029 IO-APIC-fasteoi eth0 18: 0 IO-APIC-fasteoi uhci_hcd:usb4 19: 728947 IO-APIC-fasteoi libata, uhci_hcd:usb3 20: 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2 NMI: 0 LOC:2736793 ERR: 0 MIS: 0 narf ~ # sleep 6 narf ~ # cat /proc/interrupts CPU0 0: 2268 IO-APIC-edge timer 1: 2 IO-APIC-edge i8042 8: 5 IO-APIC-edge rtc 9: 0 IO-APIC-fasteoi acpi 12: 4 IO-APIC-edge i8042 14: 206828 IO-APIC-edge ide0 16: 350813 IO-APIC-fasteoi sata_promise, uhci_hcd:usb5 17: 39596069 IO-APIC-fasteoi eth0 18: 0 IO-APIC-fasteoi uhci_hcd:usb4 19: 728947 IO-APIC-fasteoi libata, uhci_hcd:usb3 20: 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2 NMI: 0 LOC:2736881 ERR: 0 MIS: 0 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
Mark Weber wrote: Anything else you'd like me to try? Yes: a stock kernel, please. Preferably 2.6.23. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
Mark Weber wrote: Anything else you'd like me to try? Yes: a stock kernel, please. Preferably 2.6.23. Thanks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
On 10/12/07, Mark Lord <[EMAIL PROTECTED]> wrote: > > That's interesting. > > So, either something is regularly accessing/polling the drive, > or it just doesn't work with the standby timer. > > Are there any interesting kernel messages being generated > during execution of those commands? No messages to /var/log/messages as a result of those commands; I ran several times and did a sync too, just in case. I very much doubt that something is regularly accessing the drives because I have a script that runs every 1/2 hour to check and log status. The drives stay "standby" for hours (even days) at a time unless I specifically access something on the RAID array. Then, they stay "active/idle" until I manually set them to "standby". Anything else you'd like me to try? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
Mark Weber wrote: # hdparm -S1 -C /dev/sda; sleep 6; hdparm -C /dev/sda /dev/sda: setting standby to 1 (5 seconds) drive state is: active/idle /dev/sda: drive state is: active/idle That's interesting. So, either something is regularly accessing/polling the drive, or it just doesn't work with the standby timer. Are there any interesting kernel messages being generated during execution of those commands? -ml - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
Mark Weber wrote: # hdparm -S1 -C /dev/sda; sleep 6; hdparm -C /dev/sda /dev/sda: setting standby to 1 (5 seconds) drive state is: active/idle /dev/sda: drive state is: active/idle That's interesting. So, either something is regularly accessing/polling the drive, or it just doesn't work with the standby timer. Are there any interesting kernel messages being generated during execution of those commands? -ml - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
On 10/12/07, Mark Lord [EMAIL PROTECTED] wrote: That's interesting. So, either something is regularly accessing/polling the drive, or it just doesn't work with the standby timer. Are there any interesting kernel messages being generated during execution of those commands? No messages to /var/log/messages as a result of those commands; I ran several times and did a sync too, just in case. I very much doubt that something is regularly accessing the drives because I have a script that runs every 1/2 hour to check and log status. The drives stay standby for hours (even days) at a time unless I specifically access something on the RAID array. Then, they stay active/idle until I manually set them to standby. Anything else you'd like me to try? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
On 10/11/07, Mark Lord <[EMAIL PROTECTED]> wrote: > > What do you get when you try this: > hdparm -S1 -C /dev/sda;sleep 6; hdparm -C /dev/sda > ?? Thanks for taking an interest. I ran the commands and got the result shown below. Anything else you want me to try? # hdparm -S1 -C /dev/sda; sleep 6; hdparm -C /dev/sda /dev/sda: setting standby to 1 (5 seconds) drive state is: active/idle /dev/sda: drive state is: active/idle Should I give sdparm a shot? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
Mark Weber wrote: I can't get "hdparm -S" to work at all. Using "hdparm -S 1" should set the timeout to 5 seconds, but the drives stay active/idle all the time. When I set to standby manually, the drives stay on standby for days, and start up fine when they are used. I know this because I logged status every 30 minutes using crontab. They just don't standby automatically. I'm using 5 identical drives (see below for drive info), with software RAID. I don't have Raptors here anymore to try it with, but "hdparm -S1 /dev/sd?" did work fine with them when last tried. What do you get when you try this: hdparm -S1 -C /dev/sda;sleep 6; hdparm -C /dev/sda ?? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
Mark Weber wrote: I can't get hdparm -S to work at all. Using hdparm -S 1 should set the timeout to 5 seconds, but the drives stay active/idle all the time. When I set to standby manually, the drives stay on standby for days, and start up fine when they are used. I know this because I logged status every 30 minutes using crontab. They just don't standby automatically. I'm using 5 identical drives (see below for drive info), with software RAID. I don't have Raptors here anymore to try it with, but hdparm -S1 /dev/sd? did work fine with them when last tried. What do you get when you try this: hdparm -S1 -C /dev/sda;sleep 6; hdparm -C /dev/sda ?? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm standby timeout not working for WD raptors?
On 10/11/07, Mark Lord [EMAIL PROTECTED] wrote: What do you get when you try this: hdparm -S1 -C /dev/sda;sleep 6; hdparm -C /dev/sda ?? Thanks for taking an interest. I ran the commands and got the result shown below. Anything else you want me to try? # hdparm -S1 -C /dev/sda; sleep 6; hdparm -C /dev/sda /dev/sda: setting standby to 1 (5 seconds) drive state is: active/idle /dev/sda: drive state is: active/idle Should I give sdparm a shot? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
hdparm standby timeout not working for WD raptors?
I can't get "hdparm -S" to work at all. Using "hdparm -S 1" should set the timeout to 5 seconds, but the drives stay active/idle all the time. When I set to standby manually, the drives stay on standby for days, and start up fine when they are used. I know this because I logged status every 30 minutes using crontab. They just don't standby automatically. I'm using 5 identical drives (see below for drive info), with software RAID. Any suggestions? System details follow. # uname -a Linux narf 2.6.22-gentoo-r5 #1 Sat Sep 1 13:35:06 CDT 2007 i686 Intel(R) Celeron(R) D CPU 420 @ 1.60GHz GenuineIntel GNU/Linux # hdparm -S 1 /dev/sda setting standby to 1 (5 seconds) # hdparm -I /dev/sda /dev/sda: ATA device, with non-removable media Model Number: WDC WD5000ABYS-01TNA0 Serial Number: WD-WCAPW2171884 Firmware Revision: 12.01C01 Standards: Supported: 7 6 5 4 Likely used: 7 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBAuser addressable sectors: 268435455 LBA48 user addressable sectors: 976773168 device size with M = 1024*1024: 476940 MBytes device size with M = 1000*1000: 500107 MBytes (500 GB) Capabilities: LBA, IORDY(can be disabled) Queue depth: 32 Standby timer values: spec'd by Standard, with device specific minimum R/W multiple sector transfer: Max = 16 Current = 16 Recommended acoustic management value: 128, current value: 254 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: *SMART feature set Security Mode feature set *Power Management feature set *Write cache *Look-ahead *Host Protected Area feature set *WRITE_BUFFER command *READ_BUFFER command *NOP cmd *DOWNLOAD_MICROCODE Power-Up In Standby feature set *SET_FEATURES required to spinup after power up SET_MAX security extension *Automatic Acoustic Management feature set *48-bit Address feature set *Device Configuration Overlay feature set *Mandatory FLUSH_CACHE *FLUSH_CACHE_EXT *SMART error logging *SMART self-test *General Purpose Logging feature set *WRITE_{DMA|MULTIPLE}_FUA_EXT *64-bit World wide name *Segmented DOWNLOAD_MICROCODE *SATA-I signaling speed (1.5Gb/s) *SATA-II signaling speed (3.0Gb/s) *Native Command Queueing (NCQ) *Phy event counters DMA Setup Auto-Activate optimization *Software settings preservation *SMART Command Transport (SCT) feature set *SCT Long Sector Access (AC1) *SCT LBA Segment Access (AC2) *SCT Error Recovery Control (AC3) *SCT Features Control (AC4) *SCT Data Tables (AC5) unknown 206[12] unknown 206[13] Security: Master password revision code = 65534 supported not enabled not locked frozen not expired: security count not supported: enhanced erase 134min for SECURITY ERASE UNIT. Checksum: correct - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
hdparm standby timeout not working for WD raptors?
I can't get hdparm -S to work at all. Using hdparm -S 1 should set the timeout to 5 seconds, but the drives stay active/idle all the time. When I set to standby manually, the drives stay on standby for days, and start up fine when they are used. I know this because I logged status every 30 minutes using crontab. They just don't standby automatically. I'm using 5 identical drives (see below for drive info), with software RAID. Any suggestions? System details follow. # uname -a Linux narf 2.6.22-gentoo-r5 #1 Sat Sep 1 13:35:06 CDT 2007 i686 Intel(R) Celeron(R) D CPU 420 @ 1.60GHz GenuineIntel GNU/Linux # hdparm -S 1 /dev/sda setting standby to 1 (5 seconds) # hdparm -I /dev/sda /dev/sda: ATA device, with non-removable media Model Number: WDC WD5000ABYS-01TNA0 Serial Number: WD-WCAPW2171884 Firmware Revision: 12.01C01 Standards: Supported: 7 6 5 4 Likely used: 7 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBAuser addressable sectors: 268435455 LBA48 user addressable sectors: 976773168 device size with M = 1024*1024: 476940 MBytes device size with M = 1000*1000: 500107 MBytes (500 GB) Capabilities: LBA, IORDY(can be disabled) Queue depth: 32 Standby timer values: spec'd by Standard, with device specific minimum R/W multiple sector transfer: Max = 16 Current = 16 Recommended acoustic management value: 128, current value: 254 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: *SMART feature set Security Mode feature set *Power Management feature set *Write cache *Look-ahead *Host Protected Area feature set *WRITE_BUFFER command *READ_BUFFER command *NOP cmd *DOWNLOAD_MICROCODE Power-Up In Standby feature set *SET_FEATURES required to spinup after power up SET_MAX security extension *Automatic Acoustic Management feature set *48-bit Address feature set *Device Configuration Overlay feature set *Mandatory FLUSH_CACHE *FLUSH_CACHE_EXT *SMART error logging *SMART self-test *General Purpose Logging feature set *WRITE_{DMA|MULTIPLE}_FUA_EXT *64-bit World wide name *Segmented DOWNLOAD_MICROCODE *SATA-I signaling speed (1.5Gb/s) *SATA-II signaling speed (3.0Gb/s) *Native Command Queueing (NCQ) *Phy event counters DMA Setup Auto-Activate optimization *Software settings preservation *SMART Command Transport (SCT) feature set *SCT Long Sector Access (AC1) *SCT LBA Segment Access (AC2) *SCT Error Recovery Control (AC3) *SCT Features Control (AC4) *SCT Data Tables (AC5) unknown 206[12] unknown 206[13] Security: Master password revision code = 65534 supported not enabled not locked frozen not expired: security count not supported: enhanced erase 134min for SECURITY ERASE UNIT. Checksum: correct - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/