Re: Bad behaviour after hdparm -M 128

Re: Bad behaviour after hdparm -M 128

[Robert Hancock]

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/

Re: Bad behaviour after hdparm -M 128

[Henrique de Moraes Holschuh]

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

Re: Bad behaviour after hdparm -M 128

[Björn Steinbrink]

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

Re: Bad behaviour after hdparm -M 128

[Henrique de Moraes Holschuh]

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

Re: Bad behaviour after hdparm -M 128

[Björn Steinbrink]

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

Re: Bad behaviour after hdparm -M 128

[Henrique de Moraes Holschuh]

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

Re: Bad behaviour after hdparm -M 128

[Björn Steinbrink]

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

Re: Bad behaviour after hdparm -M 128

[Henrique de Moraes Holschuh]

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

Re: Bad behaviour after hdparm -M 128

[Mark Lord]

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.

Re: Bad behaviour after hdparm -M 128

[Henrique de Moraes Holschuh]

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

Re: Bad behaviour after hdparm -M 128

[Tino Keitel]

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

Bad behaviour after hdparm -M 128

[Tino Keitel]

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