* Re: Bad behaviour after hdparm -M 128
[not found] <fa.DWgGSeKzniALToNSyX9W5NibA1w@ifi.uio.no>
@ 2007-06-06 14:29 ` Robert Hancock
2007-06-06 15:44 ` Henrique de Moraes Holschuh
0 siblings, 1 reply; 12+ messages in thread
From: Robert Hancock @ 2007-06-06 14:29 UTC (permalink / raw)
To: linux-kernel
Tino Keitel wrote:
> Hi,
>
> I tried to enable acoustic management on my SATA drive, because
> hdparm -I reported a recommended value of 128, and a current value
> of 0 (off).
>
> I did this:
>
> $ sudo hdparm -M 128 /dev/sda
> /dev/sda:
> setting acoustic management to 128
> HDIO_DRIVE_CMD:ACOUSTIC failed: Input/output error
> acoustic = not supported
>
> It apperently failed, no big deal.
>
> However, I had these messages in the kernel log, and they don't look
> really harmless to me:
>
> ata3.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
> ata3.01: cmd ef/42:80:00:00:00/00:00:00:00:00/50 tag 0 cdb 0x0 data 0
> res 51/04:80:00:00:00/00:00:00:00:00/50 Emask 0x1 (device error)
> ata3.01: configured for UDMA/133
> ata3: EH complete
> SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
> sda: Write Protect is off
> sda: Mode Sense: 00 3a 00 00
> SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
>
> Is this expected behaviour?
>
> I used kernel 2.6.21 with the libata PIIX SATA driver and a
> Seagate ST98823AS drive.
Yes, that's expected if the drive rejects the command.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bad behaviour after hdparm -M 128
2007-06-06 14:29 ` Bad behaviour after hdparm -M 128 Robert Hancock
@ 2007-06-06 15:44 ` Henrique de Moraes Holschuh
2007-06-06 16:24 ` Björn Steinbrink
0 siblings, 1 reply; 12+ messages in thread
From: Henrique de Moraes Holschuh @ 2007-06-06 15:44 UTC (permalink / raw)
To: Robert Hancock; +Cc: linux-kernel
On Wed, 06 Jun 2007, Robert Hancock wrote:
> >I used kernel 2.6.21 with the libata PIIX SATA driver and a
> >Seagate ST98823AS drive.
>
> Yes, that's expected if the drive rejects the command.
Are *all* SATA drives rejecting the command? Mine doesn't accept it,
either. And it should, AFAIK, unless IBM's HDAPS-enabled firmware started
ripping out accousting management from Hitachi drives, which I don't find
very likely...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bad behaviour after hdparm -M 128
2007-06-06 15:44 ` Henrique de Moraes Holschuh
@ 2007-06-06 16:24 ` Björn Steinbrink
2007-06-06 16:48 ` Henrique de Moraes Holschuh
0 siblings, 1 reply; 12+ messages in thread
From: Björn Steinbrink @ 2007-06-06 16:24 UTC (permalink / raw)
To: Henrique de Moraes Holschuh; +Cc: Robert Hancock, linux-kernel
On 2007.06.06 12:44:42 -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 06 Jun 2007, Robert Hancock wrote:
> > >I used kernel 2.6.21 with the libata PIIX SATA driver and a
> > >Seagate ST98823AS drive.
> >
> > Yes, that's expected if the drive rejects the command.
>
> Are *all* SATA drives rejecting the command? Mine doesn't accept it,
> either. And it should, AFAIK, unless IBM's HDAPS-enabled firmware started
> ripping out accousting management from Hitachi drives, which I don't find
> very likely...
Works here, using a WDC WD1600AAJS-00PSA0 and sata_nv.
Björn
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bad behaviour after hdparm -M 128
2007-06-06 16:24 ` Björn Steinbrink
@ 2007-06-06 16:48 ` Henrique de Moraes Holschuh
2007-06-06 17:51 ` Björn Steinbrink
0 siblings, 1 reply; 12+ messages in thread
From: Henrique de Moraes Holschuh @ 2007-06-06 16:48 UTC (permalink / raw)
To: Björn Steinbrink, Robert Hancock, linux-kernel
On Wed, 06 Jun 2007, Björn Steinbrink wrote:
> On 2007.06.06 12:44:42 -0300, Henrique de Moraes Holschuh wrote:
> > On Wed, 06 Jun 2007, Robert Hancock wrote:
> > > >I used kernel 2.6.21 with the libata PIIX SATA driver and a
> > > >Seagate ST98823AS drive.
> > >
> > > Yes, that's expected if the drive rejects the command.
> >
> > Are *all* SATA drives rejecting the command? Mine doesn't accept it,
> > either. And it should, AFAIK, unless IBM's HDAPS-enabled firmware started
> > ripping out accousting management from Hitachi drives, which I don't find
> > very likely...
>
> Works here, using a WDC WD1600AAJS-00PSA0 and sata_nv.
I am also using libata PIIX like the first person reporting the problem, but
it is a PATA drive behind a SATA-PATA bridge (it is a IBM T43 notebook).
Hmm...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bad behaviour after hdparm -M 128
2007-06-06 16:48 ` Henrique de Moraes Holschuh
@ 2007-06-06 17:51 ` Björn Steinbrink
2007-06-06 21:03 ` Henrique de Moraes Holschuh
0 siblings, 1 reply; 12+ messages in thread
From: Björn Steinbrink @ 2007-06-06 17:51 UTC (permalink / raw)
To: Henrique de Moraes Holschuh; +Cc: Robert Hancock, linux-kernel
On 2007.06.06 13:48:54 -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 06 Jun 2007, Björn Steinbrink wrote:
> > On 2007.06.06 12:44:42 -0300, Henrique de Moraes Holschuh wrote:
> > > On Wed, 06 Jun 2007, Robert Hancock wrote:
> > > > >I used kernel 2.6.21 with the libata PIIX SATA driver and a
> > > > >Seagate ST98823AS drive.
> > > >
> > > > Yes, that's expected if the drive rejects the command.
> > >
> > > Are *all* SATA drives rejecting the command? Mine doesn't accept it,
> > > either. And it should, AFAIK, unless IBM's HDAPS-enabled firmware started
> > > ripping out accousting management from Hitachi drives, which I don't find
> > > very likely...
> >
> > Works here, using a WDC WD1600AAJS-00PSA0 and sata_nv.
>
> I am also using libata PIIX like the first person reporting the problem, but
> it is a PATA drive behind a SATA-PATA bridge (it is a IBM T43 notebook).
> Hmm...
Also works fine on my T43 using ata_piix and a HTS541040G9AT00. Kernel
2.6.22-rc1.
Björn
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bad behaviour after hdparm -M 128
2007-06-06 17:51 ` Björn Steinbrink
@ 2007-06-06 21:03 ` Henrique de Moraes Holschuh
2007-06-06 21:36 ` Björn Steinbrink
0 siblings, 1 reply; 12+ messages in thread
From: Henrique de Moraes Holschuh @ 2007-06-06 21:03 UTC (permalink / raw)
To: Björn Steinbrink, Robert Hancock, linux-kernel
On Wed, 06 Jun 2007, Björn Steinbrink wrote:
> On 2007.06.06 13:48:54 -0300, Henrique de Moraes Holschuh wrote:
> > On Wed, 06 Jun 2007, Björn Steinbrink wrote:
> > > On 2007.06.06 12:44:42 -0300, Henrique de Moraes Holschuh wrote:
> > > > On Wed, 06 Jun 2007, Robert Hancock wrote:
> > > > > >I used kernel 2.6.21 with the libata PIIX SATA driver and a
> > > > > >Seagate ST98823AS drive.
> > > > >
> > > > > Yes, that's expected if the drive rejects the command.
> > > >
> > > > Are *all* SATA drives rejecting the command? Mine doesn't accept it,
> > > > either. And it should, AFAIK, unless IBM's HDAPS-enabled firmware started
> > > > ripping out accousting management from Hitachi drives, which I don't find
> > > > very likely...
> > >
> > > Works here, using a WDC WD1600AAJS-00PSA0 and sata_nv.
> >
> > I am also using libata PIIX like the first person reporting the problem, but
> > it is a PATA drive behind a SATA-PATA bridge (it is a IBM T43 notebook).
> > Hmm...
>
> Also works fine on my T43 using ata_piix and a HTS541040G9AT00. Kernel
> 2.6.22-rc1.
Which firmware in the HD? I need the fourth letter. If it is "I", it is
HDAPS firmware. If it is "O", it is regular OEM firmware (no Unload
Immediate support).
hdparm, and even /proc/scsi/scsi will tell you enough of the firmware
revision to get to the fourth letter.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bad behaviour after hdparm -M 128
2007-06-06 21:03 ` Henrique de Moraes Holschuh
@ 2007-06-06 21:36 ` Björn Steinbrink
2007-06-06 21:52 ` Henrique de Moraes Holschuh
0 siblings, 1 reply; 12+ messages in thread
From: Björn Steinbrink @ 2007-06-06 21:36 UTC (permalink / raw)
To: Henrique de Moraes Holschuh; +Cc: Robert Hancock, linux-kernel
On 2007.06.06 18:03:37 -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 06 Jun 2007, Björn Steinbrink wrote:
> > On 2007.06.06 13:48:54 -0300, Henrique de Moraes Holschuh wrote:
> > > I am also using libata PIIX like the first person reporting the problem, but
> > > it is a PATA drive behind a SATA-PATA bridge (it is a IBM T43 notebook).
> > > Hmm...
> >
> > Also works fine on my T43 using ata_piix and a HTS541040G9AT00. Kernel
> > 2.6.22-rc1.
>
> Which firmware in the HD? I need the fourth letter. If it is "I", it is
> HDAPS firmware. If it is "O", it is regular OEM firmware (no Unload
> Immediate support).
>
> hdparm, and even /proc/scsi/scsi will tell you enough of the firmware
> revision to get to the fourth letter.
HDAPS support is available, revision is MB2IA60A.
Björn
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bad behaviour after hdparm -M 128
2007-06-06 21:36 ` Björn Steinbrink
@ 2007-06-06 21:52 ` Henrique de Moraes Holschuh
2007-06-07 15:45 ` Mark Lord
0 siblings, 1 reply; 12+ messages in thread
From: Henrique de Moraes Holschuh @ 2007-06-06 21:52 UTC (permalink / raw)
To: Björn Steinbrink, Robert Hancock, linux-kernel
On Wed, 06 Jun 2007, Björn Steinbrink wrote:
> HDAPS support is available, revision is MB2IA60A.
That would usually rule out the possibility of it being the firmware, but we
have different disks, so different firmware.
It looks like I will have to try 2.6.22 to know for sure.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bad behaviour after hdparm -M 128
2007-06-06 21:52 ` Henrique de Moraes Holschuh
@ 2007-06-07 15:45 ` Mark Lord
2007-06-08 1:50 ` Henrique de Moraes Holschuh
0 siblings, 1 reply; 12+ messages in thread
From: Mark Lord @ 2007-06-07 15:45 UTC (permalink / raw)
To: Henrique de Moraes Holschuh
Cc: Björn Steinbrink, Robert Hancock, linux-kernel
Henrique de Moraes Holschuh wrote:
> On Wed, 06 Jun 2007, Björn Steinbrink wrote:
>> HDAPS support is available, revision is MB2IA60A.
>
> That would usually rule out the possibility of it being the firmware, but we
> have different disks, so different firmware.
>
> It looks like I will have to try 2.6.22 to know for sure.
>
"hdparm -I" should list "Automatic Acoustic Management feature set"
(near the bottom) for any drive that *does* support the -M feature.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bad behaviour after hdparm -M 128
2007-06-07 15:45 ` Mark Lord
@ 2007-06-08 1:50 ` Henrique de Moraes Holschuh
2007-06-11 9:22 ` Tino Keitel
0 siblings, 1 reply; 12+ messages in thread
From: Henrique de Moraes Holschuh @ 2007-06-08 1:50 UTC (permalink / raw)
To: Mark Lord; +Cc: Björn Steinbrink, Robert Hancock, linux-kernel
On Thu, 07 Jun 2007, Mark Lord wrote:
> Henrique de Moraes Holschuh wrote:
> >On Wed, 06 Jun 2007, Björn Steinbrink wrote:
> >>HDAPS support is available, revision is MB2IA60A.
> >
> >That would usually rule out the possibility of it being the firmware, but
> >we
> >have different disks, so different firmware.
> >
> >It looks like I will have to try 2.6.22 to know for sure.
>
> "hdparm -I" should list "Automatic Acoustic Management feature set"
> (near the bottom) for any drive that *does* support the -M feature.
I just tracked it down to hdparm. Version 6.9 (the one in Debian stable)
doesn't work right with libata. Version 7.5 (the one in Debian unstable)
works fine.
So, at least in my side, there are *no* kernel bugs. Maybe this is also the
case for the poster that reported the problem?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bad behaviour after hdparm -M 128
2007-06-08 1:50 ` Henrique de Moraes Holschuh
@ 2007-06-11 9:22 ` Tino Keitel
0 siblings, 0 replies; 12+ messages in thread
From: Tino Keitel @ 2007-06-11 9:22 UTC (permalink / raw)
To: linux-kernel
On Thu, Jun 07, 2007 at 22:50:04 -0300, Henrique de Moraes Holschuh wrote:
[...]
> I just tracked it down to hdparm. Version 6.9 (the one in Debian stable)
> doesn't work right with libata. Version 7.5 (the one in Debian unstable)
> works fine.
>
> So, at least in my side, there are *no* kernel bugs. Maybe this is also the
> case for the poster that reported the problem?
I also use Debian unstable.
Here is the relevant part of the hdparm -I output:
/dev/sda:
ATA device, with non-removable media
Model Number: ST98823AS
Serial Number: 5PK0GTK8
Firmware Revision: 7.01
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
LBA user addressable sectors: 156301488
LBA48 user addressable sectors: 156301488
device size with M = 1024*1024: 76319 MBytes
device size with M = 1000*1000: 80026 MBytes (80 GB)
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific
minimum
R/W multiple sector transfer: Max = 16 Current = ?
Advanced power management level: unknown setting (0x8080)
Recommended acoustic management value: 128, current value: 0
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=240ns IORDY flow control=120ns
Commands/features:
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
* DOWNLOAD_MICROCODE
* Advanced Power Management feature set
SET_MAX security extension
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* WRITE_{DMA|MULTIPLE}_FUA_EXT
* IDLE_IMMEDIATE with UNLOAD
* SATA-I signaling speed (1.5Gb/s)
* Native Command Queueing (NCQ)
* Phy event counters
Device-initiated interface power management
* Software settings preservation
* SMART Command Transport (SCT) feature set
Regards,
Tino
^ permalink raw reply [flat|nested] 12+ messages in thread
* Bad behaviour after hdparm -M 128
@ 2007-06-06 6:47 Tino Keitel
0 siblings, 0 replies; 12+ messages in thread
From: Tino Keitel @ 2007-06-06 6:47 UTC (permalink / raw)
To: linux-kernel
Hi,
I tried to enable acoustic management on my SATA drive, because
hdparm -I reported a recommended value of 128, and a current value
of 0 (off).
I did this:
$ sudo hdparm -M 128 /dev/sda
/dev/sda:
setting acoustic management to 128
HDIO_DRIVE_CMD:ACOUSTIC failed: Input/output error
acoustic = not supported
It apperently failed, no big deal.
However, I had these messages in the kernel log, and they don't look
really harmless to me:
ata3.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata3.01: cmd ef/42:80:00:00:00/00:00:00:00:00/50 tag 0 cdb 0x0 data 0
res 51/04:80:00:00:00/00:00:00:00:00/50 Emask 0x1 (device error)
ata3.01: configured for UDMA/133
ata3: EH complete
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Is this expected behaviour?
I used kernel 2.6.21 with the libata PIIX SATA driver and a
Seagate ST98823AS drive.
Regards,
Tino
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2007-06-11 9:22 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <fa.DWgGSeKzniALToNSyX9W5NibA1w@ifi.uio.no>
2007-06-06 14:29 ` Bad behaviour after hdparm -M 128 Robert Hancock
2007-06-06 15:44 ` Henrique de Moraes Holschuh
2007-06-06 16:24 ` Björn Steinbrink
2007-06-06 16:48 ` Henrique de Moraes Holschuh
2007-06-06 17:51 ` Björn Steinbrink
2007-06-06 21:03 ` Henrique de Moraes Holschuh
2007-06-06 21:36 ` Björn Steinbrink
2007-06-06 21:52 ` Henrique de Moraes Holschuh
2007-06-07 15:45 ` Mark Lord
2007-06-08 1:50 ` Henrique de Moraes Holschuh
2007-06-11 9:22 ` Tino Keitel
2007-06-06 6:47 Tino Keitel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).