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 LBAuser 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 - 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: 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 LBAuser 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 - 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: 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 - 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: 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. - 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: 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 - 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: 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. - 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: 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 - 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: 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 - 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: 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 - 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: 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 - 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: 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 - 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: 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 - 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: 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 - 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: 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/ - 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: 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/ - 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: 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 - 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: 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 - 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: 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 - 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: 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 - 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: 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 - 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: 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 - 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: 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 - 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/