Re: ide/dma not working from 2.6.19 to 2.6.21
Sergei Shtylyov wrote: > Hello. > > Bahadir Balban wrote: > >> I have a PCI Promise TX2 Ultra133 controller with a harddisk on an ARM >> platform (which is a barebone system with no BIOS). This setup used to >> work with the old linux-ide drivers on 2.6.19 > > >You were very lucky then bacause actually it usually failed on > anything non-x86. ;-) > >> but it does not work >> with 2.6.22-rc4, or 2.6.21. Here's the error output: > > >I guess this might be related to the driver update in 2.6.20-rc1 then > -- I made the driver calibrate the chip's PLL, so that it might work for > non-x86 case too (where Promise BIOS isn't available to do this). The > code is basically the same as in the libata's pata_2027x driver... > >> PDC20269: chipset revision 2 >> <6>PDC20269: ROM enabled at 0xa021 >> PDC20269: ROM enabled at 0xa021 > > >Hm, why all the messages are printed twice? :-O >(I'll cut out the dupes to save bandwidth). > >> PDC20269: PLL input clock is 37736 kHz > > >37.736 MHz is a pretty strange PLL clock... Basically, it's the > halved PCI clock, and that value signifies your PCI is probably running > at 75 MHz -- which is serious overclocking... :-/ >That could explain why the driver managed to work before -- the > default DPLL settings fit for 66 MHz PCI but made the UltraDMA fail with > CRC errors on the plain 33 MHz PCI, IIRC... >I may suggest replacing #undef DEBUG by #define DEBUG in this driver, > rebuilding the kernel and posting the driver's output... > I don't know whether this is related or not. Recently I noticed that the PLL clock being detected higher than expected as 20MHz on my box. (It used be 16.6 MHz since my PCI bus is running at 33MHz...) Reloading the pata_pdc2027x module then the problem goes away. I guess maybe somehow mdelay() is not as precise as before... -- albert (dmesg attached for reference) The PLL clock is wrongly detected as 20MHz on my box, kernel 2.6.22-rc3. [ 5545.255266] pata_pdc2027x :02:05.0: version 0.9 [ 5545.255489] ACPI: PCI Interrupt :02:05.0[A] -> Link [LNK1] -> GSI 10 (level, low) -> IRQ 10 [ 5545.374703] pata_pdc2027x :02:05.0: PLL input clock 20027 kHz [ 5545.404872] scsi2 : pata_pdc2027x [ 5545.430357] scsi3 : pata_pdc2027x [ 5545.48] ata3: PATA max UDMA/133 cmd 0xe09897c0 ctl 0xe0989fda bmdma 0xe0989000 irq 0 [ 5545.433671] ata4: PATA max UDMA/133 cmd 0xe09895c0 ctl 0xe0989dda bmdma 0xe0989008 irq 0 [ 5545.916581] ata3.00: ATAPI, max UDMA/33 [ 5545.916590] ata3.01: ATAPI, max UDMA/33 [ 5546.080361] ata3.00: configured for UDMA/33 [ 5546.244197] ata3.01: configured for UDMA/33 [ 5546.410493] scsi 2:0:0:0: CD-ROMLITE-ON CD-RW SOHR-5238S 4S07 PQ: 0 ANSI: 5 [ 5546.437658] scsi 2:0:1:0: CD-ROMHL-DT-ST DVDRAM GSA-4163B A105 PQ: 0 ANSI: 5 [ 5546.604481] sr0: scsi3-mmc drive: 52x/52x writer cd/rw xa/form2 cdda tray [ 5546.604808] Uniform CD-ROM driver Revision: 3.20 [ 5546.607596] sr 2:0:0:0: Attached scsi CD-ROM sr0 [ 5546.612168] sr1: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray [ 5546.614075] sr 2:0:1:0: Attached scsi CD-ROM sr1 [ 5640.334685] ata3.00: disabled [ 5640.334695] ata3.01: disabled [ 5640.403451] ACPI: PCI interrupt for device :02:05.0 disabled == The PLL clock clock is correct after rmmod and reload the module: [ 5644.153643] pata_pdc2027x :02:05.0: version 0.9 [ 5644.153723] ACPI: PCI Interrupt :02:05.0[A] -> Link [LNK1] -> GSI 10 (level, low) -> IRQ 10 [ 5644.252954] pata_pdc2027x :02:05.0: PLL input clock 16714 kHz [ 5644.303470] scsi4 : pata_pdc2027x [ 5644.319285] scsi5 : pata_pdc2027x [ 5644.321207] ata5: PATA max UDMA/133 cmd 0xe09897c0 ctl 0xe0989fda bmdma 0xe0989000 irq 0 [ 5644.321215] ata6: PATA max UDMA/133 cmd 0xe09895c0 ctl 0xe0989dda bmdma 0xe0989008 irq 0 [ 5644.803308] ata5.00: ATAPI, max UDMA/33 [ 5644.803629] ata5.01: ATAPI, max UDMA/33 [ 5644.967144] ata5.00: configured for UDMA/33 [ 5645.130975] ata5.01: configured for UDMA/33 [ 5645.287539] scsi 4:0:0:0: CD-ROMLITE-ON CD-RW SOHR-5238S 4S07 PQ: 0 ANSI: 5 [ 5645.291669] sr0: scsi3-mmc drive: 52x/52x writer cd/rw xa/form2 cdda tray [ 5645.294295] sr 4:0:0:0: Attached scsi CD-ROM sr0 [ 5645.300189] scsi 4:0:1:0: CD-ROMHL-DT-ST DVDRAM GSA-4163B A105 PQ: 0 ANSI: 5 [ 5645.305716] sr1: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray [ 5645.306736] sr 4:0:1:0: Attached scsi CD-ROM sr1 [EMAIL PROTECTED] june_2007]$ - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.22-rc5 libata/ata_piix failure with older CDROM
Mikael Pettersson wrote: > I tried (again) to convert an Intel i815EP-chipset > machine from IDE to libata, but libata still fails > to initialise the CDROM on the machine. > > With 2.6.22-rc5, IDE says: > > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > ICH2: IDE controller at PCI slot :00:1f.1 > ICH2: chipset revision 5 > ICH2: not 100% native mode: will probe irqs later > ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio > ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA > Probing IDE interface ide0... > hda: IC35L080AVVA07-0, ATA DISK drive > hda: selected mode 0x45 > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > Probing IDE interface ide1... > hdc: CRD-8320B, ATAPI CD/DVD-ROM drive > hdd: Hewlett-Packard CD-Writer Plus 9100, ATAPI CD/DVD-ROM drive > hdc: selected mode 0x22 > hdd: selected mode 0x42 > ide1 at 0x170-0x177,0x376 on irq 15 > hda: max request size: 128KiB > hda: 160836480 sectors (82348 MB) w/1863KiB Cache, CHS=65535/16/63, UDMA(100) > hda: cache flushes supported > hda: hda1 hda2 hda3 hda4 < hda5 hda6 > > > Switching to libata (ata_piix) results in: > > ata_piix :00:1f.1: version 2.11 > PCI: Setting latency timer of device :00:1f.1 to 64 > scsi0 : ata_piix > scsi1 : ata_piix > ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f000 irq 14 > ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f008 irq 15 > ata1.00: ata_hpa_resize 1: sectors = 160836480, hpa_sectors = 160836480 > ata1.00: ATA-5: IC35L080AVVA07-0, VA4OA52A, max UDMA/100 > ata1.00: 160836480 sectors, multi 16: LBA > ata1.00: ata_hpa_resize 1: sectors = 160836480, hpa_sectors = 160836480 > ata1.00: configured for UDMA/100 > ata2.00: ATAPI: CRD-8320B, 1.12, max MWDMA2 > ata2.01: ATAPI: Hewlett-Packard CD-Writer Plus 9100, 1.0c, max UDMA/33 > ata2.00: configured for MWDMA2 > ata2.01: configured for UDMA/33 > scsi 0:0:0:0: Direct-Access ATA IC35L080AVVA07-0 VA4O PQ: 0 ANSI: 5 > sd 0:0:0:0: [sda] 160836480 512-byte hardware sectors (82348 MB) > sd 0:0:0:0: [sda] Write Protect is off > sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 > sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support > DPO or FUA > sd 0:0:0:0: [sda] 160836480 512-byte hardware sectors (82348 MB) > sd 0:0:0:0: [sda] Write Protect is off > sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 > sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support > DPO or FUA > sda: sda1 sda2 sda3 sda4 < sda5 sda6 > > sd 0:0:0:0: [sda] Attached SCSI disk > ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in > res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) > ata2: port is slow to respond, please be patient (Status 0xd0) > ata2: device not ready (errno=-16), forcing hardreset > ata2: BUG: prereset() requested invalid reset type > ata2: soft resetting port > ATA: abnormal status 0x80 on port 0x00010177 > ATA: abnormal status 0x80 on port 0x00010177 > ATA: abnormal status 0x80 on port 0x00010177 The INQUIRY timeout looks like the ATAPI DMA problem that Tejun is working on. Could you please check if Tejun's patch that limits ATAPI DMA to multiple of 16-bytes works: https://bugzilla.novell.com/attachment.cgi?id=147389 (The original bug is: https://bugzilla.novell.com/show_bug.cgi?id=229260#c35) -- albert - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.22-rc5] libata: add HTS541616J9SA00 to NCQ blacklist
Petr Vandrovec wrote: >>> Hmmm... The last one (HTS541612J9SA00) is taken directly from hdparm >>> output, and I think I verified the patch with the reporter. Hmm... Can >>> anyone verify these module strings? >> >> Could well be that they've started attaching Hitachi to the ID strings >> now.. In the past it hasn't seemed to have been Hitachi's (and IBM's >> before that) practice to have it there, but maybe they see the >> advantage of being able to figure out who made the drive now :-) > > Perhaps ones sold directly by Hitachi are Hitachi, while ones sold > through OEMs are no-name? I dunno but I doubt they care that much about the model string but one way or the other we might have to do pattern matching on HTS541* anyway. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.22-rc5] libata: add HTS541616J9SA00 to NCQ blacklist
Robert Hancock wrote:
Tejun Heo wrote:
Petr Vandrovec wrote:
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adfae9d..fbca8d8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3803,6 +3803,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
/* Drives which do spurious command completion */
{ "HTS541680J9SA00","SB2IC7EP",ATA_HORKAGE_NONCQ, },
{ "HTS541612J9SA00","SBDIC7JP",ATA_HORKAGE_NONCQ, },
+{ "Hitachi HTS541616J9SA00", "SB4OC70P", ATA_HORKAGE_NONCQ, },
{ "WDC WD740ADFD-00NLR1", NULL,ATA_HORKAGE_NONCQ, },
/* Devices with NCQ limits */
Is that the right ID string? Strange that that one has Hitachi at the
front and the others don't..
Yeah, I realized that and asked Enrico about it. :-)
I think that "new" one is correct, while old ones are incorrect (unless
it uses strstr()) - all my Hitachis claim to be Hitachis - like this one
(which seems to work fine with NCQ):
gwy:~# hdparm -i /dev/sda
/dev/sda:
Model=Hitachi HDT725032VLA380 , FwRev=V54OA52A,
SerialNo= VFA200R208LH5J
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
Hmmm... The last one (HTS541612J9SA00) is taken directly from hdparm
output, and I think I verified the patch with the reporter. Hmm... Can
anyone verify these module strings?
Could well be that they've started attaching Hitachi to the ID strings
now.. In the past it hasn't seemed to have been Hitachi's (and IBM's
before that) practice to have it there, but maybe they see the advantage
of being able to figure out who made the drive now :-)
Perhaps ones sold directly by Hitachi are Hitachi, while ones sold
through OEMs are no-name?
Petr
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.22-rc5] libata: add HTS541616J9SA00 to NCQ blacklist
Tejun Heo wrote:
Robert Hancock wrote:
Tejun Heo wrote:
Another member of HTS5416* family doing spurious NCQ completion.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Enrico Sardi <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adfae9d..fbca8d8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3803,6 +3803,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
/* Drives which do spurious command completion */
{ "HTS541680J9SA00","SB2IC7EP",ATA_HORKAGE_NONCQ, },
{ "HTS541612J9SA00","SBDIC7JP",ATA_HORKAGE_NONCQ, },
+{ "Hitachi HTS541616J9SA00", "SB4OC70P", ATA_HORKAGE_NONCQ, },
{ "WDC WD740ADFD-00NLR1", NULL,ATA_HORKAGE_NONCQ, },
/* Devices with NCQ limits */
Is that the right ID string? Strange that that one has Hitachi at the
front and the others don't..
Yeah, I realized that and asked Enrico about it. :-)
I think that "new" one is correct, while old ones are incorrect (unless
it uses strstr()) - all my Hitachis claim to be Hitachis - like this one
(which seems to work fine with NCQ):
gwy:~# hdparm -i /dev/sda
/dev/sda:
Model=Hitachi HDT725032VLA380 , FwRev=V54OA52A,
SerialNo= VFA200R208LH5J
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
Petr
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.22-rc5] libata: add HTS541616J9SA00 to NCQ blacklist
Tejun Heo wrote:
Petr Vandrovec wrote:
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adfae9d..fbca8d8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3803,6 +3803,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
/* Drives which do spurious command completion */
{ "HTS541680J9SA00","SB2IC7EP",ATA_HORKAGE_NONCQ, },
{ "HTS541612J9SA00","SBDIC7JP",ATA_HORKAGE_NONCQ, },
+{ "Hitachi HTS541616J9SA00", "SB4OC70P", ATA_HORKAGE_NONCQ, },
{ "WDC WD740ADFD-00NLR1", NULL,ATA_HORKAGE_NONCQ, },
/* Devices with NCQ limits */
Is that the right ID string? Strange that that one has Hitachi at the
front and the others don't..
Yeah, I realized that and asked Enrico about it. :-)
I think that "new" one is correct, while old ones are incorrect (unless
it uses strstr()) - all my Hitachis claim to be Hitachis - like this one
(which seems to work fine with NCQ):
gwy:~# hdparm -i /dev/sda
/dev/sda:
Model=Hitachi HDT725032VLA380 , FwRev=V54OA52A,
SerialNo= VFA200R208LH5J
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
Hmmm... The last one (HTS541612J9SA00) is taken directly from hdparm
output, and I think I verified the patch with the reporter. Hmm... Can
anyone verify these module strings?
Could well be that they've started attaching Hitachi to the ID strings
now.. In the past it hasn't seemed to have been Hitachi's (and IBM's
before that) practice to have it there, but maybe they see the advantage
of being able to figure out who made the drive now :-)
--
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-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.22-rc5] libata: add HTS541616J9SA00 to NCQ blacklist
Petr Vandrovec wrote:
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adfae9d..fbca8d8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3803,6 +3803,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
/* Drives which do spurious command completion */
{ "HTS541680J9SA00","SB2IC7EP",ATA_HORKAGE_NONCQ, },
{ "HTS541612J9SA00","SBDIC7JP",ATA_HORKAGE_NONCQ, },
+{ "Hitachi HTS541616J9SA00", "SB4OC70P", ATA_HORKAGE_NONCQ, },
{ "WDC WD740ADFD-00NLR1", NULL,ATA_HORKAGE_NONCQ, },
/* Devices with NCQ limits */
>>> Is that the right ID string? Strange that that one has Hitachi at the
>>> front and the others don't..
>>
>> Yeah, I realized that and asked Enrico about it. :-)
>
> I think that "new" one is correct, while old ones are incorrect (unless
> it uses strstr()) - all my Hitachis claim to be Hitachis - like this one
> (which seems to work fine with NCQ):
>
> gwy:~# hdparm -i /dev/sda
>
> /dev/sda:
>
> Model=Hitachi HDT725032VLA380 , FwRev=V54OA52A,
> SerialNo= VFA200R208LH5J
> Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
Hmmm... The last one (HTS541612J9SA00) is taken directly from hdparm
output, and I think I verified the patch with the reporter. Hmm... Can
anyone verify these module strings?
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata and legacy ide pcmcia failure
Mark Lord wrote: > Robert de Rooy wrote: > >> >> I did another try with libata pcmcia support using 2.6.22-rc5 which >> already includes the nodata polling fix, in combination with >> disable-dev_init_param-and-setxfermode-for-CFA.patch and the >> timing-debug.patch > > ... > >> Jun 22 13:19:44 localhost kernel: ata3.00: issuing IDENTIFY >> Jun 22 13:19:45 localhost kernel: ata3.00: IDENTIFY complete >> Jun 22 13:19:45 localhost kernel: ata3.00: CFA: Memory Card Adapter, >> 20011212, max PIO1 >> Jun 22 13:19:45 localhost kernel: ata3.00: 253696 sectors, multi 0: LBA >> Jun 22 13:19:45 localhost kernel: ata3.00: issuing IDENTIFY >> Jun 22 13:19:45 localhost kernel: ata3.00: IDENTIFY complete >> Jun 22 13:19:45 localhost kernel: ata3.00: configured for PIO0 >> Jun 22 13:19:45 localhost kernel: ata3: EH complete >> Jun 22 13:19:45 localhost kernel: scsi 2:0:0:0: Direct-Access >> ATA Memory Card Adap 2001 PQ: 0 ANSI: 5 >> Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] 253696 512-byte >> hardware sectors (130 MB) >> Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] Write Protect is off >> Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] Write cache: >> disabled, read cache: enabled, doesn't support DPO or FUA >> Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] 253696 512-byte >> hardware sectors (130 MB) >> Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] Write Protect is off >> Jun 22 13:19:45 localhost kernel: sd 2:0:0:0: [sdb] Write cache: >> disabled, read cache: enabled, doesn't support DPO or FUA >> Jun 22 13:20:15 localhost kernel: sdb:<3>ata3.00: exception Emask 0x0 >> SAct 0x0 SErr 0x0 action 0x2 frozen >> Jun 22 13:20:15 localhost kernel: ata3.00: cmd >> 20/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in >> Jun 22 13:20:15 localhost kernel: res >> 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) >> Jun 22 13:20:15 localhost kernel: ata3: soft resetting port >> Jun 22 13:20:15 localhost kernel: ata3: reset complete >> Jun 22 13:20:15 localhost kernel: ATA: abnormal status 0x80 on port >> 0x00014107 >> Jun 22 13:20:15 localhost kernel: ATA: abnormal status 0x80 on port >> 0x00014107 >> Jun 22 13:20:15 localhost kernel: ATA: abnormal status 0x58 on port >> 0x00014107 >> Jun 22 13:20:15 localhost kernel: ata3.00: issuing IDENTIFY >> Jun 22 13:20:15 localhost kernel: ATA: abnormal status 0x58 on port >> 0x00014107 > > ... > > Mmm.. I don't know about the first failure there, > but after that it gets into the "stuck DRQ" state > which libata makes no attempt to handle at present. > It seems the pata_pcmcia driver is using IRQ driven PIO. Maybe Robert could try the following pio_polling patch first. -- albert --- --- libata-dev/drivers/ata/pata_pcmcia.c~ 2007-06-12 16:44:43.0 +0800 +++ libata-dev/drivers/ata/pata_pcmcia.c2007-06-25 11:53:37.0 +0800 @@ -299,7 +299,7 @@ next_entry: ap->ops = &pcmcia_port_ops; ap->pio_mask = 1; /* ISA so PIO 0 cycles */ - ap->flags |= ATA_FLAG_SLAVE_POSS; + ap->flags |= ATA_FLAG_SLAVE_POSS | ATA_FLAG_PIO_POLLING; ap->ioaddr.cmd_addr = io_addr; ap->ioaddr.altstatus_addr = ctl_addr; ap->ioaddr.ctl_addr = ctl_addr; - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.22-rc5] libata: add HTS541616J9SA00 to NCQ blacklist
Robert Hancock wrote:
> Tejun Heo wrote:
>> Another member of HTS5416* family doing spurious NCQ completion.
>>
>> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
>> Cc: Enrico Sardi <[EMAIL PROTECTED]>
>> ---
>> drivers/ata/libata-core.c |1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>> index adfae9d..fbca8d8 100644
>> --- a/drivers/ata/libata-core.c
>> +++ b/drivers/ata/libata-core.c
>> @@ -3803,6 +3803,7 @@ static const struct ata_blacklist_entry
>> ata_device_blacklist [] = {
>> /* Drives which do spurious command completion */
>> { "HTS541680J9SA00","SB2IC7EP",ATA_HORKAGE_NONCQ, },
>> { "HTS541612J9SA00","SBDIC7JP",ATA_HORKAGE_NONCQ, },
>> +{ "Hitachi HTS541616J9SA00", "SB4OC70P", ATA_HORKAGE_NONCQ, },
>> { "WDC WD740ADFD-00NLR1", NULL,ATA_HORKAGE_NONCQ, },
>>
>> /* Devices with NCQ limits */
>>
>
> Is that the right ID string? Strange that that one has Hitachi at the
> front and the others don't..
Yeah, I realized that and asked Enrico about it. :-)
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata interface fatal error
Florian Effenberger wrote: > sorry, it seems it was all a false alert and our mainboard was > defective. At the end, it turned on only sometimes. To test it, we > wanted to install Windows, which didn't work as well. > > Now the dealer changed the motherboard, and we are just fine with 3.0 > Gbps and Kernel 2.6.21.5. > > Sorry for the big confusion and for your great help! I didn't know the > board was defective in the first place, there have been no indications > like that... Yeah, things like these are tricky. SATA is usually the first one to suffer from hardware defect including power fluctuation due to input power, PSU or on-board voltage regulator problems because the link is relatively long and runs at very high speed. I also heard that SATA cables should have been made more resistant to interference but I'm no expert in that area. It's interesting to see how it got solved. Thanks for another data point to blame hardware when I don't have a clue. :-) -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.22-rc5] libata: add HTS541616J9SA00 to NCQ blacklist
Tejun Heo wrote:
Another member of HTS5416* family doing spurious NCQ completion.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Enrico Sardi <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adfae9d..fbca8d8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3803,6 +3803,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
/* Drives which do spurious command completion */
{ "HTS541680J9SA00", "SB2IC7EP", ATA_HORKAGE_NONCQ, },
{ "HTS541612J9SA00", "SBDIC7JP", ATA_HORKAGE_NONCQ, },
+ { "Hitachi HTS541616J9SA00", "SB4OC70P", ATA_HORKAGE_NONCQ, },
{ "WDC WD740ADFD-00NLR1", NULL, ATA_HORKAGE_NONCQ, },
/* Devices with NCQ limits */
Is that the right ID string? Strange that that one has Hitachi at the
front and the others don't..
--
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-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.22-rc5] libata: add HTS541616J9SA00 to NCQ blacklist
Another member of HTS5416* family doing spurious NCQ completion.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Enrico Sardi <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index adfae9d..fbca8d8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3803,6 +3803,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
/* Drives which do spurious command completion */
{ "HTS541680J9SA00","SB2IC7EP", ATA_HORKAGE_NONCQ, },
{ "HTS541612J9SA00","SBDIC7JP", ATA_HORKAGE_NONCQ, },
+ { "Hitachi HTS541616J9SA00", "SB4OC70P", ATA_HORKAGE_NONCQ, },
{ "WDC WD740ADFD-00NLR1", NULL, ATA_HORKAGE_NONCQ, },
/* Devices with NCQ limits */
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hsm violation
Andrew Morton wrote: > That great spew of "set_level status: 0" is fairly annoying and useless. I don't know where those are coming from. It's not from libata. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hsm violation
Robert Hancock wrote: > Andrew Morton wrote: >> On Sun, 24 Jun 2007 14:32:22 +0200 Enrico Sardi <[EMAIL PROTECTED]> >> wrote: >>> [ 61.176000] ata1.00: exception Emask 0x2 SAct 0x2 SErr 0x0 action >>> 0x2 frozen >>> [ 61.176000] ata1.00: (spurious completions during NCQ issue=0x0 >>> SAct=0x2 FIS=005040a1:0004) >> >> It's not obvious (to me) whether this is a driver bug, a hardware bug, >> expected-normal-behaviour or what - those diagnostics (which we get to >> see distressingly frequently) are pretty obscure. > > The spurious completions during NCQ error is indicating that the drive > has indicated it's completed NCQ command tags which weren't outstanding. > It's normally a result of a bad NCQ implementation on the drive. > Technically we can live with it, but it's rather dangerous (if it > indicates completions for non-outstanding commands, how do we know it > doesn't indicate completions for actually outstanding commands that > aren't actually completed yet..) There is a small race window there. Please consider the following sequence. 1. drive sends SDB FIS with spurious completion in it. 2. block layer issues new r/w command to the drive. SDB FIS is still in flight. 3. ata driver issues the command (the pending bit is set prior to transmitting command FIS). 4. controller completes receiving FIS from #1. Driver reads the mask and completes all indicated commands. If spurious completion in #1 happens to match the slot allocated in #3, the driver just completed a command which hasn't been issued to the drive yet. So, it actually is dangerous. We might even be seeing the real completion as spurious one (as the command is completed prematurely). It seems all those HTS541* drives share this problem. Four of them are already on the blacklist and the other OS reportedly blacklists three of them too. I'll submit a patch to add HTS541616J9SA00. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SATA RAID5 speed drop of 100 MB/s
On Mon, Jun 25, 2007 at 12:07:23AM +0200, Carlo Wood wrote: > On Sun, Jun 24, 2007 at 12:59:10PM -0400, Justin Piszcz wrote: > > Concerning NCQ/no NCQ, without NCQ I get an additional 15-50MB/s in speed > > per various bonnie++ tests. > > There is more going on than a bad NCQ implementation of the drive imho. > I did a long test over night (and still only got two schedulers done, > will do the other two tomorrow), and the difference between a queue depth > of 1 and 2 is DRAMATIC. > > See http://www.xs4all.nl/~carlo17/noop_queue_depth.png > and http://www.xs4all.nl/~carlo17/anticipatory_queue_depth.png Hi Carlo, Have you considered using "blktrace" ? It enables you to gather data of all seperate requests queues and will also show you the mapping of bio request from /dev/mdX to the individual physical disk. You can also identify SYNC and BARRIER flags for requests, that might show you why the md driver will sometimes wait for completion or even REQUEUE if the queue is full. Just compile your kernel with CONFIG_BLK_DEV_IO_TRACE and pull the "blktrace" (and "blockparse") utility with git. The git URL is in the Kconfig help text. You have to mount, debugfs (automatically selected by IO trace). I just want to mention, because I did not figure it at first ;) You should of course use a different location for the output files to avoid an endless flood of IO. Regards, Patrick PS: I know, I talked about blktrace twice already ;) - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SATA RAID5 speed drop of 100 MB/s
Carlo Wood wrote: The following can be observed: 1) There is hardly any difference between the two schedulers (noop is a little faster for the bonny test). 2) An NCQ depth of 1 is WAY faster on RAID5 (bonnie; around 125 MB/s), the NCQ depth of 2 is by far the slowest for the RAID5 (bonnie; around 40 MB/s). NCQ depths of 3 and higher show no difference, but are also slow (bonnie; around 75 MB/s). 3) There is no significant influence of the NCQ depth for non-RAID, either the /dev/sda (hdparm -t) or /dev/sdd disk (hdparm -t and bonnie). 4) With a NCQ depth > 1, the hdparm -t measurement of /dev/md7 is VERY unstable. Sometimes it gives the maximum (around 150 MB/s), and sometimes as low as 30 MB/s, seemingly independent of the NCQ depth. Note that those measurement were done on an otherwise unloaded machine in single user mode; and the measurements were all done one after an other. The strong fluctuation of the hdparm results for the RAID device (while the underlaying devices do not show this behaviour) are unexplainable. From the above I conclude that something must be wrong with the software RAID implementation - and not just with the harddisks, imho. At least, that's what it looks like to me. I am not an expert though ;) I'm late tuning in here, but: (1) hdparm issues only a single read at a time, so NCQ won't help it. (2) WD Raptor drives automatically turn off "read-ahead" when using NCQ, which totally kills any throughput measurements. They do this to speed up random access seeks; dunno if it pays off or not. Under Windows, the disk drivers don't use NCQ when performing large I/O operations, which avoids the performance loss. (3) Other drives from other brands may have similar issues, but I have not run into it on them yet. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SATA RAID5 speed drop of 100 MB/s
On Sun, Jun 24, 2007 at 12:59:10PM -0400, Justin Piszcz wrote: > Concerning NCQ/no NCQ, without NCQ I get an additional 15-50MB/s in speed > per various bonnie++ tests. There is more going on than a bad NCQ implementation of the drive imho. I did a long test over night (and still only got two schedulers done, will do the other two tomorrow), and the difference between a queue depth of 1 and 2 is DRAMATIC. See http://www.xs4all.nl/~carlo17/noop_queue_depth.png and http://www.xs4all.nl/~carlo17/anticipatory_queue_depth.png The bonnie++ tests are done in a directory on the /dev/md7 and /dev/ssd2 partitions respectively. Each bonnie test is performed four times. The hdparm -t tests (that show no difference with a -tT test) are each done five times, for /dev/sdd, /dev/md7 and /dev/sda (that is one of the RAID5 drives used for /dev/md7). Thus in total there are 2 * 4 + 3 * 5 = 23 data points per queue depth value in each graph. The following can be observed: 1) There is hardly any difference between the two schedulers (noop is a little faster for the bonny test). 2) An NCQ depth of 1 is WAY faster on RAID5 (bonnie; around 125 MB/s), the NCQ depth of 2 is by far the slowest for the RAID5 (bonnie; around 40 MB/s). NCQ depths of 3 and higher show no difference, but are also slow (bonnie; around 75 MB/s). 3) There is no significant influence of the NCQ depth for non-RAID, either the /dev/sda (hdparm -t) or /dev/sdd disk (hdparm -t and bonnie). 4) With a NCQ depth > 1, the hdparm -t measurement of /dev/md7 is VERY unstable. Sometimes it gives the maximum (around 150 MB/s), and sometimes as low as 30 MB/s, seemingly independent of the NCQ depth. Note that those measurement were done on an otherwise unloaded machine in single user mode; and the measurements were all done one after an other. The strong fluctuation of the hdparm results for the RAID device (while the underlaying devices do not show this behaviour) are unexplainable. >From the above I conclude that something must be wrong with the software RAID implementation - and not just with the harddisks, imho. At least, that's what it looks like to me. I am not an expert though ;) -- Carlo Wood <[EMAIL PROTECTED]> PS RAID5 (md7 = sda7 + sdb7 + sdc7): Three times a Western Digital Raptor 10k rpm (WDC WD740ADFD-00NLR1). non-RAID (sdd2): Seagate barracuda 7200 rpm (ST3320620AS). The reason that now I measure around 145 MB/s instead of 165 MB/s as reported in previous post (with hdparm -t /dev/md7) is because before I use hdparm -t /dev/md2, which is closer to the outside of the disk and therefore faster. /dev/md2 still is around 165 MB/s. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_promise disk error 2.6.22-rc5 with hrt1 patch
(cc: linux-ide added) On Sun, 24 Jun 2007 20:49:05 +0200, otto Meier wrote: > I got the following in my logs: > > Jun 24 19:06:40 gate2 kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr > 0x0 action 0x0 > Jun 24 19:06:40 gate2 kernel: ata4.00: (port_status 0x1000) > Jun 24 19:06:40 gate2 kernel: ata4.00: cmd > 35/00:00:c1:17:92/00:04:17:00:00/e0 tag 0 cdb 0x0 data 524288 out > Jun 24 19:06:40 gate2 kernel: res > 50/00:00:c0:1b:92/00:00:17:00:00/e0 Emask 0x20 (host bus error) > Jun 24 19:06:40 gate2 kernel: ata4.00: ata_hpa_resize 1: sectors = > 488397168, hpa_sectors = 488397168 > Jun 24 19:06:40 gate2 kernel: ata4.00: ata_hpa_resize 1: sectors = > 488397168, hpa_sectors = 488397168 > Jun 24 19:06:40 gate2 kernel: ata4.00: configured for UDMA/133 > Jun 24 19:06:40 gate2 kernel: ata4: EH complete > Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] 488397168 512-byte > hardware sectors (250059 MB) > Jun 24 19:06:40 gate2 kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr > 0x0 action 0x0 > Jun 24 19:06:40 gate2 kernel: ata4.00: (port_status 0x1000) > Jun 24 19:06:40 gate2 kernel: ata4.00: cmd > 25/00:00:c1:15:92/00:02:17:00:00/e0 tag 0 cdb 0x0 data 262144 in > Jun 24 19:06:40 gate2 kernel: res > 50/00:00:c0:17:92/00:00:17:00:00/e0 Emask 0x20 (host bus error) > Jun 24 19:06:40 gate2 kernel: ata4.00: ata_hpa_resize 1: sectors = > 488397168, hpa_sectors = 488397168 > Jun 24 19:06:40 gate2 kernel: ata4.00: ata_hpa_resize 1: sectors = > 488397168, hpa_sectors = 488397168 > Jun 24 19:06:40 gate2 kernel: ata4.00: configured for UDMA/133 > Jun 24 19:06:40 gate2 kernel: ata4: EH complete > Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] Write Protect is off > Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 > Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] Write cache: enabled, > read cache: enabled, doesn't support DPO or FUA > Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] 488397168 512-byte > hardware sectors (250059 MB) > Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] Write Protect is off > Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 > Jun 24 19:06:40 gate2 kernel: sd 3:0:0:0: [sdd] Write cache: enabled, > read cache: enabled, doesn't support DPO or FUA > > The system continued without seeing other effects. > > It is runnuning a 2.6.22-rc5 kernel with hrt1 patch. > The drive ist part of a raid5 with 4 identical drives > > lspci -vvv gives: > > 02:06.0 Mass storage controller: Promise Technology, Inc. PDC40718 (SATA > 300 TX4) (rev 02) The 300 TX4 model is causing transient errors for several people, and we don't yet know why. In your case, port_status 0x1000 means that "host bus is busy more than 256 clock cycles for every ATA I/O transfer" (quoting the docs). Basically it's a timeout. As long as it's transient, don't worry. You may want to try without hrt1 to see if hrt1 is causing the issue. /Mikael - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Frequent SATA resets with sata_nv (fwd)
(ccing linux-ide) Matthew "Cheetah" Gabeler-Lee wrote: (Please cc me on replies) I have three samsung hdds (/sys/block/sda/device/model says SAMSUNG SP2504C) in a raid configuration. My system frequently (2-3x/day) experiences temporary lockups, which produce messages as below in my dmesg/syslog. The system recovers, but the hang is annoying to say the least. All three drives are connected to sata_nv ports. Oddly, it almost always happens on ata6 or ata7 (the second and third ports of that 4 port setup on my motherboard). There is an identical drive connected at ata5, but I've only once or twice seen it hit that drive. Googling around lkml.org, I found a few threads investigating what look like very similar problems, some of which never seemed to find the solution, but one of which came up with a fairly quick answer it seemed, namely that the drive's NCQ implementation was horked: http://lkml.org/lkml/2007/4/18/32 While I don't have older logs to verify exactly when this started, it was fairly recent, perhaps around my 2.6.20.1 to 2.6.21.1 kernel upgrade. Any other info or tests I can provide/run to help? Syslog snippet: Jun 21 10:35:23 cheetah kernel: ata6: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000 status 0x400 next cpb count 0x0 next cpb idx 0x0 Jun 21 10:35:24 cheetah kernel: ata6: CPB 0: ctl_flags 0x9, resp_flags 0x0 Jun 21 10:35:24 cheetah kernel: ata6: timeout waiting for ADMA IDLE, stat=0x400 Jun 21 10:35:24 cheetah kernel: ata6: timeout waiting for ADMA LEGACY, stat=0x400 Jun 21 10:35:24 cheetah kernel: ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Jun 21 10:35:24 cheetah kernel: ata6.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 Jun 21 10:35:24 cheetah kernel: res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) Jun 21 10:35:24 cheetah kernel: ata6: soft resetting port Jun 21 10:35:24 cheetah kernel: ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Jun 21 10:35:24 cheetah kernel: ata6.00: configured for UDMA/133 Jun 21 10:35:24 cheetah kernel: ata6: EH complete Jun 21 10:35:24 cheetah kernel: SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB) Jun 21 10:35:24 cheetah kernel: sdb: Write Protect is off Jun 21 10:35:24 cheetah kernel: sdb: Mode Sense: 00 3a 00 00 Jun 21 10:35:24 cheetah kernel: SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA Unfortunately, this kind of problem is rather difficult to diagnose. Essentially what's happened is that we've sent a command (in this case a cache flush) to the controller but it's given no indication that it's done anything with it (somewhat different from the case in the link you mentioned above, where the controller indicates it's sent the command and is waiting for completion). This could be some kind of drive issue or drive/controller incompatibility, a controller bug, the driver doing something the controller doesn't expect.. Does this drive actually support NCQ? I can't tell from this part of the log. -- 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-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hsm violation
Andrew Morton wrote: On Sun, 24 Jun 2007 14:32:22 +0200 Enrico Sardi <[EMAIL PROTECTED]> wrote: [ 61.176000] ata1.00: exception Emask 0x2 SAct 0x2 SErr 0x0 action 0x2 frozen [ 61.176000] ata1.00: (spurious completions during NCQ issue=0x0 SAct=0x2 FIS=005040a1:0004) .. It's not obvious (to me) whether this is a driver bug, a hardware bug, expected-normal-behaviour or what - those diagnostics (which we get to see distressingly frequently) are pretty obscure. The spurious completions during NCQ error is indicating that the drive has indicated it's completed NCQ command tags which weren't outstanding. It's normally a result of a bad NCQ implementation on the drive. Technically we can live with it, but it's rather dangerous (if it indicates completions for non-outstanding commands, how do we know it doesn't indicate completions for actually outstanding commands that aren't actually completed yet..) -- 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-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hsm violation
On Sun, 24 Jun 2007 14:32:22 +0200 Enrico Sardi <[EMAIL PROTECTED]> wrote: > Hi all! > > I found the following messages in the kernel log: > - > > [ 45.288000] set_level status: 0 > [ 45.572000] set_level status: 0 > [ 45.74] set_level status: 0 > [ 46.82] set_level status: 0 > [ 47.092000] set_level status: 0 > [ 61.176000] ata1.00: exception Emask 0x2 SAct 0x2 SErr 0x0 action 0x2 > frozen > [ 61.176000] ata1.00: (spurious completions during NCQ issue=0x0 > SAct=0x2 FIS=005040a1:0004) > [ 61.176000] ata1.00: cmd 60/08:08:37:cc:00/00:00:0c:00:00/40 tag 1 > cdb 0x0 data 4096 in > [ 61.176000] res 50/00:08:27:3c:ed/00:00:0b:00:00/40 Emask > 0x2 (HSM violation) > [ 61.488000] ata1: soft resetting port > [ 61.66] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) > [ 61.66] ata1.00: ata_hpa_resize 1: sectors = 312581808, > hpa_sectors = 312581808 > [ 61.66] ata1.00: ata_hpa_resize 1: sectors = 312581808, > hpa_sectors = 312581808 > [ 61.66] ata1.00: configured for UDMA/100 > [ 61.66] ata1: EH complete > [ 61.66] SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) > [ 61.66] sda: Write Protect is off > [ 61.66] sda: Mode Sense: 00 3a 00 00 > [ 61.66] SCSI device sda: write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [ 101.972000] set_level status: 0 > [ 102.20] set_level status: 0 > [ 102.404000] set_level status: 0 > [ 103.284000] set_level status: 0 > [ 103.476000] set_level status: 0 > [ 103.912000] set_level status: 0 > [ 104.284000] set_level status: 0 > [ 104.66] set_level status: 0 > [ 113.576000] set_level status: 0 > [ 559.02] set_level status: 0 > [ 559.476000] set_level status: 0 > [ 559.632000] set_level status: 0 > [ 561.744000] set_level status: 0 > [ 563.56] set_level status: 0 > [ 564.224000] set_level status: 0 > [ 564.688000] set_level status: 0 > [ 567.096000] set_level status: 0 > [ 567.712000] set_level status: 0 > [ 569.06] set_level status: 0 > [ 569.524000] set_level status: 0 > [ 569.828000] set_level status: 0 > [ 570.204000] set_level status: 0 > [ 570.504000] set_level status: 0 > [ 571.724000] set_level status: 0 > [ 572.012000] set_level status: 0 > [ 572.36] set_level status: 0 > [ 572.696000] set_level status: 0 > [ 573.016000] set_level status: 0 > [ 574.092000] set_level status: 0 > [ 574.348000] set_level status: 0 > [ 604.476000] set_level status: 0 > [ 604.764000] set_level status: 0 > [ 605.048000] set_level status: 0 > [ 605.244000] set_level status: 0 > [ 605.40] set_level status: 0 > [ 605.54] set_level status: 0 > [ 605.688000] set_level status: 0 > [ 606.528000] set_level status: 0 > [ 606.82] set_level status: 0 > [ 608.336000] set_level status: 0 > It's not obvious (to me) whether this is a driver bug, a hardware bug, expected-normal-behaviour or what - those diagnostics (which we get to see distressingly frequently) are pretty obscure. That great spew of "set_level status: 0" is fairly annoying and useless. Quite a lot has changed since 2.6.20. Are you able to test, say, 2.6.22-rc5? > > This is the result of hdparm -I /dev/sda: > > > /dev/sda: > > ATA device, with non-removable media > Model Number: Hitachi HTS541616J9SA00 > Serial Number: SB2461***V3AWE > Firmware Revision: SB4OC70P > Standards: > Used: ATA/ATAPI-7 T13 1532D revision 1 > Supported: 7 6 5 4 > Configuration: > Logicalmaxcurrent > cylinders1638316383 > heads1616 > sectors/track6363 > -- > CHS current addressable sectors: 16514064 > LBAuser addressable sectors: 268435455 > LBA48 user addressable sectors: 312581808 > device size with M = 1024*1024: 152627 MBytes > device size with M = 1000*1000: 160041 MBytes (160 GB) > Capabilities: > LBA, IORDY(can be disabled) > Queue depth: 32 > Standby timer values: spec'd by Vendor, no device specific minimum > R/W multiple sector transfer: Max = 16Current = 16 > Advanced power management level: 128 (0x80) > Recommended acoustic management value: 128, current value: 254 > DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 > Cycle time: min=120ns recommended=120ns > PIO: pio0 pio1 pio2 pio3 pio4 > Cycle time: no flow control=120ns IORDY flow control=120ns > Commands/features: > EnabledSupported: >*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 >*NOP cmd >*DOWNLOAD_MICROCODE >*Advanced Power Management feature set > Power-Up In Standby
Re: [PROBLEM]: hdparm strange behaviour for 2.6.21 and later
On Saturday 23 June 2007, Bartlomiej Zolnierkiewicz wrote: > Hi, Hello, thanks for answering :-D > Also could you try running UP kernel without PREEMPT and see > if it makes difference? Yes, it did make a difference. I've just tried both UP and SMP kernels (22-rc5) *without* PREEMPT. Neither of these locked! I also tried UP with PREEMPT and it locks. > Adding a couple of printk-s to ide.c::set_using_dma() and > ide.c::ide_spin_wait_hwgroup() will for sure help in debugging > it further. I just tried that as well. I placed printk-s when entering and exiting these 2 functions and when they use spin_lock_irq() and spin_unlock_irq(), and then watched the output: I didn't see something odd. For every hdparm execution, set_using_dma() is called, it successfully calls ide_spin_wait_hwgroup(), then set_using_dma() finishes. After set_using_dma() finishes, one more ide_spin_wait_hwgroup() is called and finishes. This pattern happens always, no matter if the kernel will eventually lock (preempt) or not lock (no preempt), with absolutely no differences. entering ide.c::set_using_dma() | entering ide.c::ide_spin_wait_hwgroup() ide.c::ide_spin_wait_hwgroup: LOCK exiting ide.c::ide_spin_wait_hwgroup() | ide.c::set_using_dma: set ->busy flag, unlock and let it ride ide.c::set_using_dma: UNLOCK ide.c::set_using_dma: lock, clear ->busy flag and unlock before leaving ide.c::set_using_dma: LOCK ide.c::set_using_dma: UNLOCK | exiting ide.c::set_using_dma() entering ide.c::ide_spin_wait_hwgroup() ide.c::ide_spin_wait_hwgroup: LOCK exiting ide.c::ide_spin_wait_hwgroup() The above gets printed twice (one for the hda hdparm and one for hdb). But I noticed something extra. Sometimes, the ide_spin_wait_hwgroup() that runs either before the 1st set_using_dma() or between the 1st and the 2nd (1st for hda, 2nd for hdb) (*but never the one called last*) is waiting A LOT inside the busy loop (while (hwgroup->busy)). I think PREEMPT kernels always produce a lot of this while loop output, and then print the above pattern, then lock. Non-PREEMPT kernels don't always produce the huge while loop output, only sometimes, but they never have locking problem. I don't know if this is at all relevant to the problem. Perhaps it's normal that during some of the bootups the IDE device group is busy while during other bootups it's not busy, right ? However, since all functions exit properly, should I try to place printk-s in other functions as well ? (I kind of need and appreciate guideance in order to help you, because I've never been in the kernel hacking business before :) ) > Thanks, > Bart -- Thanos Kyritsis - What's your ONE purpose in life ? - To explode, of course! ;-) - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] ide: add ide_pci_device_t.host_flags
Hello. Bartlomiej Zolnierkiewicz wrote: Index: b/drivers/ide/pci/serverworks.c === --- a/drivers/ide/pci/serverworks.c +++ b/drivers/ide/pci/serverworks.c @@ -448,9 +448,12 @@ static int __devinit init_setup_csb6 (st d->bootable = ON_BOARD; } - d->channels = ((dev->device == PCI_DEVICE_ID_SERVERWORKS_CSB6IDE || - dev->device == PCI_DEVICE_ID_SERVERWORKS_CSB6IDE2) && - (!(PCI_FUNC(dev->devfn) & 1))) ? 1 : 2; + if ((dev->device == PCI_DEVICE_ID_SERVERWORKS_CSB6IDE || + dev->device == PCI_DEVICE_ID_SERVERWORKS_CSB6IDE2) && I'd have left that aligning space alone. :-) + (!(PCI_FUNC(dev->devfn) & 1))) + d->host_flags |= IDE_HFLAG_SINGLE; + else > + d->host_flags &= IDE_HFLAG_SINGLE; Here's the offending code! Should've been: d->host_flags &= ~IDE_HFLAG_SINGLE; Thanks for catching this. Such things usually just spring into the eye. :-) Fixed, new patch below. [PATCH] ide: add ide_pci_device_t.host_flags (take 2) * Rename ide_pci_device_t.flags to ide_pci_device_t.host_flags and IDEPCI_FLAG_ISA_PORTS flag to IDE_HFLAG_ISA_PORTS. * Add IDE_HFLAG_SINGLE flag for single channel devices. * Convert core code and all IDE PCI drivers to use IDE_HFLAG_SINGLE and remove no longer needed ide_pci_device_t.channels field. v2: * Fix issues noticed by Sergei: - correct code alignment in scc_pata.c - s/IDE_HFLAG_SINGLE/~IDE_HFLAG_SINGLE/ in serverworks.c Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SATA RAID5 speed drop of 100 MB/s
On Sun, 24 Jun 2007, Michael Tokarev wrote: Justin Piszcz wrote: Don't forget about max_sectors_kb either (for all drives in the SW RAID5 array) max_sectors_kb = 8 $ dd if=/dev/zero of=file.out6 bs=1M count=10240 10737418240 bytes (11 GB) copied, 55.4848 seconds, 194 MB/s max_sectors_kb = 128 10737418240 bytes (11 GB) copied, 22.6298 seconds, 474 MB/s Well. You're comparing something different. Yes, this thread is about linux software raid5 in the first place, but I were commenting about [NT]CQ within a single drive. Overall, yes, the larger your reads/writes to the drive becomes, the faster its linear performance is. Yet you have to consider real workload instead of very synthetic dd test. It may be good approcsimation of a streaming video workload (when you feed a large video file over network or something like that), but even with this, you probably want to feed several files at once (different files to different clients), so single-threaded test here isn't very useful. IMHO anyway, and good for a personal computer test. /mjt - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Concerning NCQ/no NCQ, without NCQ I get an additional 15-50MB/s in speed per various bonnie++ tests. # Average of 3 runs with NCQ on for Quad Raptor 150 RAID 5 Software RAID: p34-ncq-on,7952M,43916.3,96.6667,151943,28.6667,75794.3,18.6667,48991.3,99,181687,24,558.033,0.33,16:10:16/64,867.667,9,29972.7,98.,2801.67,16,890.667,9.3,27743,94.,2115.33,15.6667 # Average of 3 runs with NCQ off for Quad Raptor 150 RAID 5 Software RAID: p34-ncq-off,7952M,42470,97.,200409,36.,90240.3,22.6667,48656,99,198853,27,546.467,0,16:10:16/64,972.333,10,21833,72.,3697,21,995,10.6667,27901.7,95.6667,2681,20.6667 - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ide: add ata_dev_has_iordy() helper
Bartlomiej Zolnierkiewicz wrote:
* Use it in sl82c105 host driver so it always gets the correct info
(use_iordy was incorrectly set for "pio" != 255 cases).
Hm, why incorrectly? ATA specs say PIO3/4 *must* use IORDY flow control,
IIRC... :-/
Moreover, it was me who added that! :-)
use_iordy = (pio_mode > 2);
Index: b/drivers/ide/pci/sl82c105.c
===
--- a/drivers/ide/pci/sl82c105.c
+++ b/drivers/ide/pci/sl82c105.c
@@ -52,9 +52,10 @@
* Convert a PIO mode and cycle time to the required on/off times
* for the interface. This has protection against runaway timings.
*/
-static unsigned int get_pio_timings(ide_pio_data_t *p)
+static unsigned int get_pio_timings(ide_drive_t *drive, ide_pio_data_t *p)
{
unsigned int cmd_on, cmd_off;
+ u8 iordy = 0;
cmd_on = (ide_pio_timings[p->pio_mode].active_time + 29) / 30;
cmd_off = (p->cycle_time - 30 * cmd_on + 29) / 30;
@@ -65,7 +66,10 @@ static unsigned int get_pio_timings(ide_
if (cmd_off == 0)
cmd_off = 1;
- return (cmd_on - 1) << 8 | (cmd_off - 1) | (p->use_iordy ? 0x40 : 0x00);
+ if (p->pio_mode > 2 || ata_dev_has_iordy(drive->id))
+ iordy = 0x40;
This logic, although mimicking the old one from ide_get_best_pio_mode(),
is not quite correct. As have been noted before, when you set a PIO mode using
It was actully correct enough, just superfluous -- it was me who was
incorrect, mistaking || for &&. :-<
Set Transfer Mode subcode of the Set Features command, you're always selecting
the flow control mode, i.e. using IORDY. So, the last condition in this if
So, what actually would need fixing in *all* the drivers if one was aiming
at ATA-1 compatibility is *not* issuing that subcommand to such drives...
Oh yes, I keep forgetting about it - some nice FIXME comment
in would be of a great help. :-)
Well, some drivers (like pdc202xx_*) don't do the IORDY thing right for
PIO modes < 3 as well...
stmt should probably be the first, if not the sole one...
Fixed, new patch below.
[PATCH] ide: add ata_dev_has_iordy() helper (take 2)
* Add ata_dev_has_iordy() helper and use it sl82c105 host driver.
* Remove no longer needed ide_pio_data_t.use_iordy field.
v2:
* Fix issues noticed by Sergei:
- correct patch description
- remove stale comment from ide_get_best_pio_mode()
I meant something like changing use_iordy to IORDY but it's good as is now...
- use only ata_dev_has_iordy() in sl82c105 host driver
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]>
MBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SATA RAID5 speed drop of 100 MB/s
Justin Piszcz wrote: > Don't forget about max_sectors_kb either (for all drives in the SW RAID5 > array) > > max_sectors_kb = 8 > $ dd if=/dev/zero of=file.out6 bs=1M count=10240 > 10737418240 bytes (11 GB) copied, 55.4848 seconds, 194 MB/s > > max_sectors_kb = 128 > 10737418240 bytes (11 GB) copied, 22.6298 seconds, 474 MB/s Well. You're comparing something different. Yes, this thread is about linux software raid5 in the first place, but I were commenting about [NT]CQ within a single drive. Overall, yes, the larger your reads/writes to the drive becomes, the faster its linear performance is. Yet you have to consider real workload instead of very synthetic dd test. It may be good approcsimation of a streaming video workload (when you feed a large video file over network or something like that), but even with this, you probably want to feed several files at once (different files to different clients), so single-threaded test here isn't very useful. IMHO anyway, and good for a personal computer test. /mjt - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SATA RAID5 speed drop of 100 MB/s
Dr. David Alan Gilbert wrote:
> * Michael Tokarev ([EMAIL PROTECTED]) wrote:
>
>
>
>> By the way, I did some testing of various drives, and NCQ/TCQ indeed
>> shows some difference -- with multiple I/O processes (like "server"
>> workload), IF NCQ/TCQ is implemented properly, especially in the
>> drive.
>>
>> For example, this is a good one:
>>
>> Single Seagate 74Gb SCSI drive (10KRPM)
>>
>> BlkSz Trd linRd rndRd linWr rndWr linR/W rndR/W
>> 1024k 1 83.1 36.0 55.8 34.6 28.2/27.6 20.3/19.4
>> 245.244.1 36.4/ 9.9
>> 448.147.6 40.7/ 7.1
[]
>> The only thing I don't understand is why with larger I/O block
>> size we see write speed drop with multiple threads.
>
> My guess is that something is chopping them up into smaller writes.
At least it's not in the kernel. According to /proc/diskstats,
the requests goes in 1024kb into the drive.
>> And in contrast to the above, here's another test run, now
>> with Seagate SATA ST3250620AS ("desktop" class) 250GB
>> 7200RPM drive:
>>
>> BlkSz Trd linRd rndRd linWr rndWr linR/WrndR/W
>> 1024k 1 78.4 34.1 33.5 24.6 19.6/19.5 16.0/12.7
>> 233.324.6 15.4/13.8
>> 434.325.0 14.7/15.0
>
>> And second, so far I haven't seen a case where a drive
>> with NCQ/TCQ enabled works worse than without. I don't
>> want to say there aren't such drives/controllers, but
>> it just happen that I haven't seen any.)
>
> Yes you have - the random writes with large blocks and 2 or 4 threads
> is significantly better for your non-NCQ drive; and getting more
> significant as you add more threads - I'm curious what happens
> on 8 threads or more.
Both drives shown above are with [NT]CQ enabled. And the first drive
above (74Gb SCSI, where the speed increases with the amount of threads)
is the one which has "better" TCQ implementation. When I turn off TCQ
for that drive, there's almost no speed increase while increasing number
of threads.
(I can't test this drive now as it's in production. The results where
gathered before I installed the system on it).
/mjt
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SATA RAID5 speed drop of 100 MB/s
Don't forget about max_sectors_kb either (for all drives in the SW RAID5
array)
max_sectors_kb = 8
$ dd if=/dev/zero of=file.out6 bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 55.4848 seconds, 194 MB/s
max_sectors_kb = 16
$ dd if=/dev/zero of=file.out5 bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 37.6886 seconds, 285 MB/s
max_sectors_kb = 32
$ dd if=/dev/zero of=file.out4 bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 26.2875 seconds, 408 MB/s
max_sectors_kb = 64
$ dd if=/dev/zero of=file.out2 bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 24.8301 seconds, 432 MB/s
max_sectors_kb = 128
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 22.6298 seconds, 474 MB/s
On Sun, 24 Jun 2007, Dr. David Alan Gilbert wrote:
* Michael Tokarev ([EMAIL PROTECTED]) wrote:
By the way, I did some testing of various drives, and NCQ/TCQ indeed
shows some difference -- with multiple I/O processes (like "server"
workload), IF NCQ/TCQ is implemented properly, especially in the
drive.
For example, this is a good one:
Single Seagate 74Gb SCSI drive (10KRPM)
BlkSz Trd linRd rndRd linWr rndWr linR/W rndR/W
1024k 1 83.1 36.0 55.8 34.6 28.2/27.6 20.3/19.4
245.244.1 36.4/ 9.9
448.147.6 40.7/ 7.1
The tests are direct-I/O over whole drive (/dev/sdX), with
either 1, 2, or 4 threads doing sequential or random reads
or writes in blocks of a given size. For the R/W tests,
we've 2, 4 or 8 threads running in total (1, 2 or 4 readers
and the same amount of writers). Numbers are MB/sec, as
totals (summary) for all threads.
Especially interesting is the very last column - random R/W
in parallel. In almost all cases, more threads gives larger
total speed (I *guess* it's due to internal optimisations in
the drive -- with more threads the drive has more chances to
reorder commands to minimize seek time etc).
The only thing I don't understand is why with larger I/O block
size we see write speed drop with multiple threads.
My guess is that something is chopping them up into smaller writes.
And in contrast to the above, here's another test run, now
with Seagate SATA ST3250620AS ("desktop" class) 250GB
7200RPM drive:
BlkSz Trd linRd rndRd linWr rndWr linR/WrndR/W
1024k 1 78.4 34.1 33.5 24.6 19.6/19.5 16.0/12.7
233.324.6 15.4/13.8
434.325.0 14.7/15.0
And second, so far I haven't seen a case where a drive
with NCQ/TCQ enabled works worse than without. I don't
want to say there aren't such drives/controllers, but
it just happen that I haven't seen any.)
Yes you have - the random writes with large blocks and 2 or 4 threads
is significantly better for your non-NCQ drive; and getting more
significant as you add more threads - I'm curious what happens
on 8 threads or more.
Dave
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _|_ http://www.treblig.org |___/
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SATA RAID5 speed drop of 100 MB/s
* Michael Tokarev ([EMAIL PROTECTED]) wrote:
> By the way, I did some testing of various drives, and NCQ/TCQ indeed
> shows some difference -- with multiple I/O processes (like "server"
> workload), IF NCQ/TCQ is implemented properly, especially in the
> drive.
>
> For example, this is a good one:
>
> Single Seagate 74Gb SCSI drive (10KRPM)
>
> BlkSz Trd linRd rndRd linWr rndWr linR/W rndR/W
> 1024k 1 83.1 36.0 55.8 34.6 28.2/27.6 20.3/19.4
> 245.244.1 36.4/ 9.9
> 448.147.6 40.7/ 7.1
>
> The tests are direct-I/O over whole drive (/dev/sdX), with
> either 1, 2, or 4 threads doing sequential or random reads
> or writes in blocks of a given size. For the R/W tests,
> we've 2, 4 or 8 threads running in total (1, 2 or 4 readers
> and the same amount of writers). Numbers are MB/sec, as
> totals (summary) for all threads.
>
> Especially interesting is the very last column - random R/W
> in parallel. In almost all cases, more threads gives larger
> total speed (I *guess* it's due to internal optimisations in
> the drive -- with more threads the drive has more chances to
> reorder commands to minimize seek time etc).
>
> The only thing I don't understand is why with larger I/O block
> size we see write speed drop with multiple threads.
My guess is that something is chopping them up into smaller writes.
> And in contrast to the above, here's another test run, now
> with Seagate SATA ST3250620AS ("desktop" class) 250GB
> 7200RPM drive:
>
> BlkSz Trd linRd rndRd linWr rndWr linR/WrndR/W
> 1024k 1 78.4 34.1 33.5 24.6 19.6/19.5 16.0/12.7
> 233.324.6 15.4/13.8
> 434.325.0 14.7/15.0
>
> And second, so far I haven't seen a case where a drive
> with NCQ/TCQ enabled works worse than without. I don't
> want to say there aren't such drives/controllers, but
> it just happen that I haven't seen any.)
Yes you have - the random writes with large blocks and 2 or 4 threads
is significantly better for your non-NCQ drive; and getting more
significant as you add more threads - I'm curious what happens
on 8 threads or more.
Dave
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _|_ http://www.treblig.org |___/
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] libata: adding ICH8M PCIIDs to ATA_PIIX.
On Monday, 18. June 2007, Jeff Garzik wrote:
> Gaston, Jason D wrote:
> > I don't think we want to have the same DeviceID supported in more then one
> > driver. Would they not conflict with each other?
>
> In Fedora 7, CONFIG_IDE is disabled. ata_piix drives all hardware at
> that point.
>
> Jeff
Hmm, did I forgot anything important in the last mail, or is everyone just busy?
(please keep CC!)
---
This patch adds a necessary PCIID for Santa Rosa's PATA controller.
Signed-off-by: Christian Lamparter <[EMAIL PROTECTED]>
---
drivers/ata/ata_piix.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 9c07b88..b210726 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -200,6 +200,8 @@ static const struct pci_device_id piix_pci_tbl[] = {
/* ICH7/7-R (i945, i975) UDMA 100*/
{ 0x8086, 0x27DF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_133 },
{ 0x8086, 0x269E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_100 },
+ /* ICH8 Mobile PATA Controller */
+ { 0x8086, 0x2850, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich_pata_133 },
/* NOTE: The following PCI ids must be kept in sync with the
* list in drivers/pci/quirks.c.
Re: SATA RAID5 speed drop of 100 MB/s
Jeff Garzik wrote:
> IN THEORY, RAID performance should /increase/ due to additional queued
> commands available to be sent to the drive. NCQ == command queueing ==
> sending multiple commands to the drive, rather than one-at-a-time like
> normal.
>
> But hdparm isn't the best test for that theory, since it does not
> simulate the transactions like real-world MD device usage does.
>
> We have seen buggy NCQ firmwares where performance decreases, so it is
> possible that NCQ just isn't good on your drives.
By the way, I did some testing of various drives, and NCQ/TCQ indeed
shows some difference -- with multiple I/O processes (like "server"
workload), IF NCQ/TCQ is implemented properly, especially in the
drive.
For example, this is a good one:
Single Seagate 74Gb SCSI drive (10KRPM)
BlkSz Trd linRd rndRd linWr rndWr linR/W rndR/W
4k 1 66.4 0.5 0.6 0.5 0.6/ 0.6 0.4/ 0.2
2 0.6 0.6 0.5/ 0.1
4 0.7 0.6 0.6/ 0.2
16k 1 84.8 2.0 2.5 1.9 2.5/ 2.5 1.6/ 0.6
2 2.3 2.1 2.0/ 0.6
4 2.7 2.5 2.3/ 0.6
64k 1 84.8 7.4 9.3 7.2 9.4/ 9.3 5.8/ 2.2
2 8.6 7.9 7.3/ 2.1
4 9.9 9.1 8.1/ 2.2
128k 1 84.8 13.6 16.7 12.9 16.9/16.6 10.6/ 3.9
215.614.4 13.5/ 3.2
417.916.4 15.7/ 2.7
512k 1 84.9 34.0 41.9 33.3 29.0/27.1 22.4/13.2
236.934.5 30.7/ 8.1
440.538.1 33.2/ 8.3
1024k 1 83.1 36.0 55.8 34.6 28.2/27.6 20.3/19.4
245.244.1 36.4/ 9.9
448.147.6 40.7/ 7.1
The tests are direct-I/O over whole drive (/dev/sdX), with
either 1, 2, or 4 threads doing sequential or random reads
or writes in blocks of a given size. For the R/W tests,
we've 2, 4 or 8 threads running in total (1, 2 or 4 readers
and the same amount of writers). Numbers are MB/sec, as
totals (summary) for all threads.
Especially interesting is the very last column - random R/W
in parallel. In almost all cases, more threads gives larger
total speed (I *guess* it's due to internal optimisations in
the drive -- with more threads the drive has more chances to
reorder commands to minimize seek time etc).
The only thing I don't understand is why with larger I/O block
size we see write speed drop with multiple threads.
And in contrast to the above, here's another test run, now
with Seagate SATA ST3250620AS ("desktop" class) 250GB
7200RPM drive:
BlkSz Trd linRd rndRd linWr rndWr linR/WrndR/W
4k 1 47.5 0.3 0.5 0.3 0.3/ 0.3 0.1/ 0.1
2 0.3 0.3 0.2/ 0.1
4 0.3 0.3 0.2/ 0.2
16k 1 78.4 1.1 1.8 1.1 0.9/ 0.9 0.6/ 0.6
2 1.2 1.1 0.6/ 0.6
4 1.3 1.2 0.6/ 0.6
64k 1 78.4 4.3 6.7 4.0 3.5/ 3.5 2.1/ 2.2
2 4.5 4.1 2.2/ 2.3
4 4.7 4.2 2.3/ 2.4
128k 1 78.4 8.0 12.6 7.2 6.2/ 6.2 3.9/ 3.8
2 8.2 7.3 4.1/ 4.0
4 8.7 7.7 4.3/ 4.3
512k 1 78.5 23.1 34.0 20.3 17.1/17.1 11.3/10.7
223.520.6 11.3/11.4
424.721.3 11.6/11.8
1024k 1 78.4 34.1 33.5 24.6 19.6/19.5 16.0/12.7
233.324.6 15.4/13.8
434.325.0 14.7/15.0
Here, the (total) I/O speed does not depend on the number
of threads. From which I conclude that the drive does
not reorder/optimize commands internally, even if NCQ is
enabled (queue depth is 32).
(And two notes. First of all, for some, those tables may
look.. strange, showing too low speed. Note the block
size, and note I'm doing *direct* *random* I/O, without
buffering in the kernel. Yes, even the most advanced
modern drives are very slow in this workload, due to
seek times and rotation latency -- the disk is maxing
out at the theoretical requests/secound -- take average
seek time plus rotation latency (usually given in the
drive specs), and divide one secound to the calculated
value -- you'll see about 200..250 - that's requests/sec.
And the numbers - like 0.3Mb/sec write - are very close
to those 200..250. In any way, this is not a typical
workload - file server for example is not like this.
But it's more or less resembles database workload.
And second, so far I haven't seen a case where a drive
with NCQ/TCQ enabled works worse than without. I don't
want to say there aren't such drives/controllers, but
it just happen that I haven't seen any.)
/mjt
-
To unsubscribe from this list:
Re: libata interface fatal error
Hi there, sorry, it seems it was all a false alert and our mainboard was defective. At the end, it turned on only sometimes. To test it, we wanted to install Windows, which didn't work as well. Now the dealer changed the motherboard, and we are just fine with 3.0 Gbps and Kernel 2.6.21.5. Sorry for the big confusion and for your great help! I didn't know the board was defective in the first place, there have been no indications like that... Florian - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SATA RAID5 speed drop of 100 MB/s
On Sun, 24 Jun 2007 10:54:56 +1000, Eyal Lebedinsky wrote: > Jeff Garzik wrote: > [trim] > > Given that some drives might be better tuned for benchmarks in > > non-queued mode, and that a major behavior difference is that your > > drives are now NCQ-enabled, the first thing I would suggest you try is > > disabling NCQ: > > http://linux-ata.org/faq.html#ncq > > I see in my bootup messages: > ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300) > ata6.00: ATA-7: WDC WD3200YS-01PGB0, 21.00M21, max UDMA/133 > ata6.00: 625142448 sectors, multi 0: LBA48 NCQ (depth 0/1) > ata6.00: configured for UDMA/133 > > and I wonder how to interpret "NCQ (depth 0/1)". Does this drive > support NCQ or not? > > Controller: Promise SATA-II-150-TX4. > Kernel: 2.6.21.5, x86 Your drive does, but the driver for your controller does not (yet). /Mikael - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
