2007-06-06 06:48:17

by Tino Keitel

[permalink] [raw]
Subject: Bad behaviour after hdparm -M 128

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


2007-06-06 14:30:27

by Robert Hancock

[permalink] [raw]
Subject: Re: Bad behaviour after hdparm -M 128

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 [email protected]
Home Page: http://www.roberthancock.com/

Subject: Re: Bad behaviour after hdparm -M 128

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

2007-06-06 16:24:37

by Björn Steinbrink

[permalink] [raw]
Subject: Re: Bad behaviour after hdparm -M 128

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

Subject: Re: Bad behaviour after hdparm -M 128

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

2007-06-06 17:51:23

by Björn Steinbrink

[permalink] [raw]
Subject: Re: Bad behaviour after hdparm -M 128

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

Subject: Re: Bad behaviour after hdparm -M 128

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

2007-06-06 21:36:31

by Björn Steinbrink

[permalink] [raw]
Subject: Re: Bad behaviour after hdparm -M 128

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

Subject: Re: Bad behaviour after hdparm -M 128

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

2007-06-07 15:45:27

by Mark Lord

[permalink] [raw]
Subject: Re: Bad behaviour after hdparm -M 128

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.

Subject: Re: Bad behaviour after hdparm -M 128

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

2007-06-11 09:22:50

by Tino Keitel

[permalink] [raw]
Subject: Re: Bad behaviour after hdparm -M 128

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