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?
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?
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: DMA problem with kernel >2.6.10
andrea gelmini wrote:
Hardware: Toshiba Satellite P20 (P4-3200 MHz, 512MB RAM) [1]
Software: Debian Unstable
GCC: 3.4.5 [2]
Memtest86+: v.1.60 (stress tools, CPU/RAM and so on, are all happy)
Problem: with kernel <=2.6.10 everything is all right...
but with any kernel released after 2.6.10 (pre, rc, stable, mm, and
so on), I've got this:
hda: dma_timer_expiry: dma status == 0x21
hda: DMA timeout error
hda: dma timeout error: status=0xd0 { Busy }
[...]
It happen quickly if I do also something like this:
cd /proc/sys/vm
echo 100 > dirty_background_ratio
echo 100 > dirty_expire_centisecs
echo 100 > dirty_ratio
echo 100 > dirty_writeback_centisecs
I've had a report about this before, from someone who was using laptop
mode -- same error message. Funny thing is, the laptop mode tools
scripts also modify the above values, so it's probably the same problem.
Until now I thought it was a Thinkpad hardware problem, because I only
heard about these problems on Thinkpads, but apparently it's a kernel
problem after all. Don't know anything about the causes though.
--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: DMA problem with kernel 2.6.10
andrea gelmini wrote:
Hardware: Toshiba Satellite P20 (P4-3200 MHz, 512MB RAM) [1]
Software: Debian Unstable
GCC: 3.4.5 [2]
Memtest86+: v.1.60 (stress tools, CPU/RAM and so on, are all happy)
Problem: with kernel =2.6.10 everything is all right...
but with any kernel released after 2.6.10 (pre, rc, stable, mm, and
so on), I've got this:
hda: dma_timer_expiry: dma status == 0x21
hda: DMA timeout error
hda: dma timeout error: status=0xd0 { Busy }
[...]
It happen quickly if I do also something like this:
cd /proc/sys/vm
echo 100 dirty_background_ratio
echo 100 dirty_expire_centisecs
echo 100 dirty_ratio
echo 100 dirty_writeback_centisecs
I've had a report about this before, from someone who was using laptop
mode -- same error message. Funny thing is, the laptop mode tools
scripts also modify the above values, so it's probably the same problem.
Until now I thought it was a Thinkpad hardware problem, because I only
heard about these problems on Thinkpads, but apparently it's a kernel
problem after all. Don't know anything about the causes though.
--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/
