Some NCQ numbers...
[Offtopic notice: For the first time I demonstrated some speed testing results on linux-ide mailinglist, as a demonstration how [NT]CQ can help. But later, someone becomes curious and posted that email to lkml, asking for more details. Since that, I become more curious as well, and decided to look at it more closely. Here it goes...] A test drive is Seagate Barracuda ST3250620AS desktop drive, 250Gb, cache size is 16Mb, 7200RPM. The same results shows Seagate Barracuda ES drive, ST3250620NS. I guess pretty similar results will be fore larger Barracudas from Seagate. The only difference between 250Gb ones and larger ones is the amount of disk platters and heads. Test machine was using MPTSAS driver for the following card: SCSI storage controller: LSI Logic / Symbios Logic SAS1064E PCI-Express Fusion-MPT SAS (rev 02) Pretty similar results were obtained on an AHCI controller: SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) Serial ATA Storage Controller AHCI (rev 01) on another machines. The following tables shows data read/write speed in Megabytes/sec, with different parameters. All I/O performed directly on the whole drive, i.e. open(/dev/sda, O_RDWR|O_DIRECT). There are 5 kinds of tests were performed: linear read (linRd), random read (rndRd), linear write (linWr), random write (rndWr), and a combination of random read and write (rndR/W). Each test has been tried with 1 (2 in case of r/w), 4 and 32 threads doing I/O in parallel (Trd column). Linear read and writes were performed only for single thread. Two modes for each test -- with command queuing enabled (qena) and disabled (qdis), using /sys/block/sda/device/queue_depth, by setting queue depth to 31 (default) and 1 respectively. And finally, each set of tests were performed for different block sizes -- 4, 8, 16, 32, 128 and 1024 kb (1 kb = 1024 bytes). First, tests with write cache enabled (factory default settings for the drives in question): BlkSz Trd linRd rndRd linWr rndWr rndR/W qena qdis qena qdis qena qdis qena qdis qena qdis 4k 1 12.8 12.8 0.3 0.3 35.4 37.0 0.5 0.5 0.2/ 0.2 0.2/ 0.2 4 0.3 0.3 0.5 0.5 0.2/ 0.2 0.2/ 0.1 32 0.3 0.4 0.5 0.5 0.2/ 0.2 0.2/ 0.1 8k 1 23.4 23.4 0.6 0.6 51.5 51.2 1.0 1.0 0.4/ 0.4 0.4/ 0.4 4 0.6 0.6 1.0 1.0 0.4/ 0.4 0.4/ 0.2 32 0.6 0.8 1.0 1.0 0.4/ 0.4 0.4/ 0.2 16k 1 41.1 40.3 1.2 1.2 67.4 67.8 2.0 2.0 0.7/ 0.7 0.7/ 0.7 4 1.2 1.1 2.0 2.0 0.7/ 0.7 0.8/ 0.4 32 1.2 1.6 2.0 2.0 0.7/ 0.7 0.9/ 0.4 32k 1 58.6 57.6 2.2 2.2 79.1 70.9 3.8 3.7 1.4/ 1.4 1.4/ 1.4 4 2.3 2.2 3.8 3.7 1.4/ 1.4 1.6/ 0.8 32 2.3 3.0 3.7 3.8 1.4/ 1.4 1.7/ 0.9 128k 1 80.4 80.4 8.1 8.0 78.7 77.3 11.6 11.6 4.5/ 4.5 4.5/ 4.5 4 8.1 8.0 11.4 11.3 4.6/ 4.6 5.5/ 2.8 32 8.1 9.2 11.3 11.4 4.7/ 4.6 5.7/ 3.0 1024k 1 80.4 80.4 33.9 34.0 78.2 78.3 33.6 33.6 15.9/15.9 15.9/15.9 4 34.5 34.8 33.5 33.3 16.4/16.3 17.2/11.8 32 34.5 34.5 33.5 35.8 20.6/11.3 21.4/11.6 And second, the same drive with write caching disabled (WCE=0, hdparm -W0): BlkSz Trd linRd rndRd linWr rndWr rndR/W qena qdis qena qdis qena qdis qena qdis qena qdis 4k 1 12.8 12.8 0.3 0.3 0.4 0.5 0.3 0.3 0.2/ 0.2 0.2/ 0.2 4 0.3 0.3 0.3 0.3 0.2/ 0.2 0.2/ 0.1 32 0.3 0.4 0.3 0.4 0.2/ 0.1 0.2/ 0.1 8k 1 24.6 24.6 0.6 0.6 0.9 0.9 0.6 0.6 0.3/ 0.3 0.3/ 0.3 4 0.6 0.6 0.6 0.5 0.3/ 0.3 0.4/ 0.2 32 0.6 0.8 0.6 0.8 0.3/ 0.3 0.4/ 0.2 16k 1 41.8 41.7 1.2 1.1 1.8 1.8 1.1 1.1 0.6/ 0.6 0.6/ 0.6 4 1.2 1.1 1.1 1.0 0.6/ 0.6 0.8/ 0.4 32 1.2 1.5 1.1 1.6 0.6/ 0.6 0.8/ 0.4 32k 1 60.1 59.2 2.3 2.3 3.6 3.5 2.1 2.1 1.1/ 1.1 1.1/ 1.1 4 2.3 2.2 2.1 2.0 1.1/ 1.1 1.5/ 0.7 32 2.3 2.9 2.1 3.0 1.1/ 1.1 1.5/ 0.8 128k 1 79.4 79.4 8.1 8.1 12.4 12.6 7.2 7.1 3.8/ 3.8 3.8/ 3.8 4 8.1 7.9 7.2 7.1 3.8/ 3.8 5.2/ 2.6 32 8.1 9.0 7.2 7.8 3.9/ 3.8 5.2/ 2.7 1024k 1 79.0 79.4 33.8 33.8 34.2 34.1 24.6 24.6 14.3/14.2 14.3/14.2 4 33.9 34.3 24.7 24.8 14.4/14.2 15.9/11.1 32 34.0 34.3
Re: Some NCQ numbers...
Michael Tokarev wrote: [] I'm planning to test several models of SCSI drives. On SCSI front (or maybe with different drives - I don't know) things are WAY more interesting wrt TCQ. Difference in results between 1 and 32 threads goes up to 4 times sometimes!. But I'm a bit stuck with SCSI tests since I don't know how to turn off TCQ without rebooting a machine. A quick followup, to demonstrate the interesting part. Seagate SCSI ST3146854LC drive, 140Gb, 15KRPM, write cache disabled, queue depth = 32: BlkSz Trd linRd rndRd linWr rndWr rndR/W 4k 1 37.9 0.6 0.9 0.6 0.4/ 0.3 4 0.9 0.7 0.6/ 0.4 32 1.5 1.1 0.9/ 0.4 8k 1 75.2 1.2 1.9 1.1 0.8/ 0.6 4 1.7 1.5 1.1/ 0.7 32 2.9 2.2 1.7/ 0.9 16k 1 82.3 2.4 3.6 2.3 1.5/ 1.2 4 3.3 2.9 2.2/ 1.4 32 5.5 4.3 3.3/ 1.7 32k 1 86.3 4.7 6.9 4.4 2.9/ 2.3 4 6.4 5.6 4.2/ 2.7 3210.2 8.0 6.2/ 3.1 128k 1 86.5 15.8 26.6 14.9 9.5/ 7.7 420.618.2 13.5/ 8.5 3229.224.8 18.3/ 9.1 1024k 1 88.6 46.7 63.1 48.2 25.3/25.3 451.751.3 33.5/21.8 3255.957.3 37.6/19.0 Fujitsu SCSI MAX3147NC drive, same parameters: BlkSz Trd linRd rndRd linWr rndWr rndR/W 4k 1 37.4 0.7 1.0 0.6 0.4/ 0.3 4 0.9 0.8 0.6/ 0.4 32 1.5 1.2 0.9/ 0.4 8k 1 32.9 1.3 1.9 1.2 0.7/ 0.7 4 1.8 1.5 1.2/ 0.7 32 2.8 2.3 1.7/ 0.9 16k 1 89.6 2.6 3.7 2.4 1.4/ 1.3 4 3.5 3.0 2.4/ 1.4 32 5.4 4.4 3.3/ 1.7 32k 1 87.9 4.8 7.0 4.4 2.6/ 2.6 4 6.8 5.6 4.6/ 2.7 32 9.9 8.3 6.2/ 3.1 128k 1 90.7 16.2 22.5 15.3 8.6/ 8.6 421.818.6 15.0/ 8.1 3228.625.0 18.2/ 9.1 1024k 1 90.6 48.9 60.0 47.4 25.3/25.9 455.651.7 34.4/22.5 3259.856.2 38.6/19.7 /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
PROBLEM: ata_piix.c for the ICH5 SATA Controller.
Hi, I have a big problem with my SC1425 Dell Servers. I use Linux Software RAID on them and last days i make few tests on them to see the reaction of the server about different situations like : power failure, hard drive prower failure ... And the hard drive prower failure was the problem. When i unplug the electric alimentation (or the SATA port cable) of one of my two hard drives in RAID 1, the server stop responding and i get this messages : ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata4.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x0 data 0 res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata4: port is slow to respond, please be patient (Status 0xd0) ata4: port failed to respond (30sec, Status 0xd0) ata4: soft resetting port I have make the same test on a SC1435 (the next generation) with a broadcom chispset/driver and everything is fine when i unplug one hard drive. On SC1425 my bios is up-to-date from the dell website. You can contact me for more informations, or some tests. Thanks for your work My informations : # sh scripts/ver_linux Linux raid-test 2.6.21.5-grsec-ipvs #1 SMP Thu Jun 28 13:51:34 CEST 2007 x86_64 GNU/Linux Gnu C 4.1.2 Gnu make 3.81 binutils 2.17 util-linux 2.12r mount 2.12r module-init-tools 3.3-pre2 e2fsprogs 1.40-WIP Linux C Library2.3.6 Dynamic linker (ldd) 2.3.6 Procps 3.2.7 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.97 udev 105 # cat /proc/ioports -001f : dma1 0020-0021 : pic1 0040-0043 : timer0 0050-0053 : timer1 0060-006f : keyboard 0070-0077 : rtc 0080-008f : dma page reg 00a0-00a1 : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : :00:1f.1 0170-0177 : libata 01f0-01f7 : :00:1f.1 01f0-01f7 : libata 0376-0376 : :00:1f.1 0376-0376 : libata 03c0-03df : vga+ 03f6-03f6 : :00:1f.1 03f6-03f6 : libata 03f8-03ff : serial 0800-087f : :00:1f.0 0800-087f : pnp 00:07 0800-0803 : ACPI PM1a_EVT_BLK 0804-0805 : ACPI PM1a_CNT_BLK 0808-080b : ACPI PM_TMR 0828-082f : ACPI GPE0_BLK 0880-08bf : :00:1f.0 0880-08bf : pnp 00:07 08c0-08df : pnp 00:07 08e0-08e3 : pnp 00:07 0c00-0c0f : pnp 00:07 0c10-0c1f : pnp 00:07 0ca0-0ca7 : pnp 00:07 0ca9-0cab : pnp 00:07 0cf8-0cff : PCI conf1 cc80-cc8f : :00:1f.2 cc80-cc8f : libata cc98-cc9b : :00:1f.2 cc98-cc9b : libata cca0-cca7 : :00:1f.2 cca0-cca7 : libata ccb0-ccb3 : :00:1f.2 ccb0-ccb3 : libata ccb8-ccbf : :00:1f.2 ccb8-ccbf : libata ccc0-ccdf : :00:1d.1 ccc0-ccdf : uhci_hcd cce0-ccff : :00:1d.0 cce0-ccff : uhci_hcd d000-dfff : PCI Bus #04 d800-d8ff : :04:0d.0 dcc0-dcff : :04:03.0 dcc0-dcff : e1000 e000-efff : PCI Bus #01 e000-efff : PCI Bus #02 ecc0-ecff : :02:04.0 ecc0-ecff : e1000 fc00-fc0f : :00:1f.1 fc00-fc0f : libata # cat /proc/iomem -0009 : System RAM - : Crash kernel 0010-1ffb : System RAM 0020-004dcfb9 : Kernel code 004dcfba-0059c9ef : Kernel data 1ffc-1ffcfbff : ACPI Tables 1ffcfc00-1fffefff : reserved 2000-23ff : :00:1f.1 e000-efff : PCI MMCONFIG 0 e000-efff : reserved f000-f7ff : PCI Bus #04 f000-f7ff : :04:0d.0 fe50-fe6f : PCI Bus #04 fe50-fe51 : :04:0d.0 fe5d-fe5d : :04:0d.0 fe5e-fe5f : :04:03.0 fe5e-fe5f : e1000 fe70-feaf : PCI Bus #01 fe90-feaf : PCI Bus #02 fe9e-fe9f : :02:04.0 fe9e-fe9f : e1000 feb0-feb003ff : :00:1d.7 feb0-feb003ff : ehci_hcd fec0-fec8 : reserved fec0-fec00fff : IOAPIC 0 fec8-fec80fff : IOAPIC 1 fed0-fed003ff : HPET 0 fee0-fee00fff : Local APIC ffb0- : reserved # lspci -vvv 00:00.0 Host bridge: Intel Corporation E7520 Memory Controller Hub (rev 09) Subsystem: Dell PowerEdge SC1425 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Capabilities: [40] Vendor Specific Information 00:02.0 PCI bridge: Intel Corporation E7525/E7520/E7320 PCI Express Port A (rev 09) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=01, subordinate=03, sec-latency=0 I/O behind bridge: e000-efff Memory behind bridge: fe70-feaf Prefetchable memory behind bridge: fff0-000f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR-
Re: [git patches] libata fixes
On Wed, 27 Jun 2007 03:35:26 -0400, Jeff Garzik wrote: Tejun Heo (9): libata: kill the infamous abnormal status message libata: kill non-sense warning message libata: be less verbose about hpa libata: remove unused variable from ata_eh_reset() libata: fix ata_dev_disable() libata: fix infinite EH waiting bug libata: call ata_check_atapi_dma() with qc better prepared libata: use PIO for non-16 byte aligned ATAPI commands libata: kill ATA_HORKAGE_DMA_RW_ONLY These changes fixed the CDROM IDENTIFY failures one of my older test machines used to get with libata. I now get much nicer results on that machine: 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-5: IC35L080AVVA07-0, VA4OA52A, max UDMA/100 ata1.00: 160836480 sectors, multi 16: LBA 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 scsi 1:0:0:0: CD-ROMGoldStar CD-ROM CRD-8320B 1.12 PQ: 0 ANSI: 5 scsi 1:0:1:0: CD-ROMHP CD-Writer+ 9100 1.0c PQ: 0 ANSI: 5 It's the CRD-8320B that used to time out and fail IDENTIFY. Tested-by: Mikael Pettersson [EMAIL PROTECTED] - 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-rc6] sata_inic162x: add big fat warning about broken LBA48 support
sata_inic162x can't do LBA48 properly yet. Whine loudly about it to
reduce confusion.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/sata_inic162x.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: work/drivers/ata/sata_inic162x.c
===
--- work.orig/drivers/ata/sata_inic162x.c
+++ work/drivers/ata/sata_inic162x.c
@@ -664,8 +664,12 @@ static int inic_init_one(struct pci_dev
void __iomem * const *iomap;
int i, rc;
- if (!printed_version++)
+ if (!printed_version++) {
dev_printk(KERN_DEBUG, pdev-dev, version DRV_VERSION \n);
+ printk(KERN_WARNING WARNING: sata_inic162x doesn't support
+ LBA48 yet. Devices larger than\n
+ 2^28 - 1 sectors (~127GiB) won't work.\n);
+ }
/* alloc host */
host = ata_host_alloc_pinfo(pdev-dev, ppi, NR_PORTS);
-
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-rc6] sata_inic162x: add big fat warning about broken LBA48 support
On 6/28/07, Tejun Heo [EMAIL PROTECTED] wrote:
sata_inic162x can't do LBA48 properly yet. Whine loudly about it to
reduce confusion.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/sata_inic162x.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: work/drivers/ata/sata_inic162x.c
===
--- work.orig/drivers/ata/sata_inic162x.c
+++ work/drivers/ata/sata_inic162x.c
@@ -664,8 +664,12 @@ static int inic_init_one(struct pci_dev
void __iomem * const *iomap;
int i, rc;
- if (!printed_version++)
+ if (!printed_version++) {
dev_printk(KERN_DEBUG, pdev-dev, version DRV_VERSION \n);
+ printk(KERN_WARNING WARNING: sata_inic162x doesn't support
+ LBA48 yet. Devices larger than\n
+ 2^28 - 1 sectors (~127GiB) won't work.\n);
+ }
/* alloc host */
host = ata_host_alloc_pinfo(pdev-dev, ppi, NR_PORTS);
-
Does it simply fail? Or does it corrupt?
In my Windows experience, if you try to write data past ~128GiB and
you don't have LBA48 support you get a wraparound effect that causes
corruption of the data below ~128GiB. I've seen it happen several
times under Win2K in particular.
Greg
--
Greg Freemyer
The Norcross Group
Forensics for the 21st Century
-
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-rc6] sata_inic162x: add big fat warning about broken LBA48 support
Greg Freemyer wrote: Does it simply fail? Or does it corrupt? In my Windows experience, if you try to write data past ~128GiB and you don't have LBA48 support you get a wraparound effect that causes corruption of the data below ~128GiB. I've seen it happen several times under Win2K in particular. It will probably wrap and corrupt data. The driver is already marked HIGHLY EXPERIMENTAL. Do you think we need bigger hammer? -- 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-rc6] sata_inic162x: add big fat warning about broken LBA48 support
On Fri, 29 Jun 2007 01:27:29 +0900 Tejun Heo [EMAIL PROTECTED] wrote: Greg Freemyer wrote: Does it simply fail? Or does it corrupt? In my Windows experience, if you try to write data past ~128GiB and you don't have LBA48 support you get a wraparound effect that causes corruption of the data below ~128GiB. I've seen it happen several times under Win2K in particular. It will probably wrap and corrupt data. The driver is already marked HIGHLY EXPERIMENTAL. Do you think we need bigger hammer Probably if the driver has set the no lba48 flag and the drive is 128GB we need to clip the reported size of the volume and/or print a message and skip it - 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-rc6] sata_inic162x: add big fat warning about broken LBA48 support
On 6/28/07, Tejun Heo [EMAIL PROTECTED] wrote: Greg Freemyer wrote: Does it simply fail? Or does it corrupt? In my Windows experience, if you try to write data past ~128GiB and you don't have LBA48 support you get a wraparound effect that causes corruption of the data below ~128GiB. I've seen it happen several times under Win2K in particular. It will probably wrap and corrupt data. The driver is already marked HIGHLY EXPERIMENTAL. Do you think we need bigger hammer? -- tejun At a minimum the error msg should be much stronger than won't work. Something like will be horribly corrupted and all your valuable data will be lost. Even better from my perspective would be to simply cause a 128GiB drive to be ignored and totally unaccessible. Obviously it should have a message to that effect. ie. Assume you have a partition that spans the 128 GiB barrier. If you allow access to the first half of the partition and not the last, you have another major corruption possibility even though you don't have any wrap-around affects. Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century - 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: CF flash PATA on libata failure to attach
Andrew Hall wrote: Hi Mark, The device is a Nexcom NSA1083 appliance: http://www.nexcom.com/product/productshow.jsp?iid=13pid=878 It's an OEM appliance that uses the Intel 965 chipset. We use it as one of three platforms for our access control and compliance products as it has 8 built in Ethernet ports and a dual core processor - with built in compact flash. The older appliance that this new (1083) one is superseding also had built in CF although this one apparently had separate PATA and SATA controllers, whereas the 1083 has only one 4 channel ICH8 Intel SATA controller which interfaces to one CF connector and one IDE connector via a SATA to PATA bridge ( I don't know exactly what this bridge is or how it interfaces to the SATA bus - but I can probably find this out from the manufacturer). The CF is a standard 512MB Sandisk/Kingston chip that we boot from and write configuration data to. .. I'm betting that the SATA/PATA converter is getting confused with the ata_piix driver's attempt to use MDMA2 on it. PIO appears to be working fine -- the BIOS uses it to boot, and libata uses it to do the IDENTIFY operation. So, try this hack, which should force ata_piix to use only PIO for the ICH8 chipset. So long as you don't have any real SATA drives, this might do the trick. Cheers --- linux/drivers/ata/ata_piix.c.orig 2007-06-27 11:20:51.0 -0400 +++ linux/drivers/ata/ata_piix.c 2007-06-28 13:32:27.0 -0400 @@ -526,8 +526,8 @@ .flags = PIIX_SATA_FLAGS | PIIX_FLAG_SCR | PIIX_FLAG_AHCI, .pio_mask = 0x1f, /* pio0-4 */ - .mwdma_mask = 0x07, /* mwdma0-2 */ - .udma_mask = 0x7f, /* udma0-6 */ + .mwdma_mask = 0x00, /* mwdma0-2 */ + .udma_mask = 0x00, /* udma0-6 */ .port_ops = piix_sata_ops, }, @@ -537,8 +537,8 @@ .flags = PIIX_SATA_FLAGS | PIIX_FLAG_SCR | PIIX_FLAG_AHCI, .pio_mask = 0x1f, /* pio0-4 */ - .mwdma_mask = 0x07, /* mwdma0-2 */ - .udma_mask = 0x7f, /* udma0-6 */ + .mwdma_mask = 0x00, /* mwdma0-2 */ + .udma_mask = 0x00, /* udma0-6 */ .port_ops = piix_sata_ops, }, - 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-rc6] sata_inic162x: add big fat warning about broken LBA48 support
Tejun Heo wrote: sata_inic162x can't do LBA48 properly yet. Whine loudly about it to reduce confusion. Why not whine only when an affected device is actually present? Cheers from OLS. - 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-rc6] sata_inic162x: add big fat warning about broken LBA48 support
Mark Lord wrote: Tejun Heo wrote: sata_inic162x can't do LBA48 properly yet. Whine loudly about it to reduce confusion. Why not whine only when an affected device is actually present? That's sorta that I think... Jeff - 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-rc6] sata_inic162x: add big fat warning about broken LBA48 support
Jeff Garzik wrote: Mark Lord wrote: Tejun Heo wrote: sata_inic162x can't do LBA48 properly yet. Whine loudly about it to reduce confusion. Why not whine only when an affected device is actually present? That's sorta that I think... That was me being lazy. I'll just ban LBA28 disks on the controller. -- 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-rc6] sata_inic162x: add big fat warning about broken LBA48 support
Tejun Heo wrote: Jeff Garzik wrote: Mark Lord wrote: Tejun Heo wrote: sata_inic162x can't do LBA48 properly yet. Whine loudly about it to reduce confusion. Why not whine only when an affected device is actually present? That's sorta that I think... That was me being lazy. I'll just ban LBA28 disks on the controller. Sounds better to me... I certainly prefer that to clipping-to-1xxGB, especially given the shaky state of the overall driver. Jeff - 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
ATA: add a PCI ID for Intel Santa Rosa PATA controller
From: Christian Lamparter [EMAIL PROTECTED]
ATA: add a PCI ID for Intel Santa Rosa PATA controller.
Signed-off-by: Christian Lamparter [EMAIL PROTECTED]
---
[against 2.6.22-rc6; patch also attached, use the attachment]
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.
From: Christian Lamparter [EMAIL PROTECTED]
ATA: add a PCI ID for Intel Santa Rosa 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: [PATCH 2.6.22-rc4] libata: SiS180 pata support
Nevermind, I did it myself: This ensures that we can easily make changes specific to the PATA port on the newer SATA chips, and also does what I've been requesting -- use the standard ata_bmdma_error_handler(), rather than creating custom code that achieves the same effect. diff --git a/drivers/ata/pata_sis.c b/drivers/ata/pata_sis.c index ec3ae93..0752104 100644 --- a/drivers/ata/pata_sis.c +++ b/drivers/ata/pata_sis.c Jeff, Did you have added the patch you have mailed on 06.06. anywhere or is this patch an email only patch. And how to continue? Uwe - 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-rc4] libata: SiS180 pata support
Uwe Koziolek wrote: Nevermind, I did it myself: This ensures that we can easily make changes specific to the PATA port on the newer SATA chips, and also does what I've been requesting -- use the standard ata_bmdma_error_handler(), rather than creating custom code that achieves the same effect. diff --git a/drivers/ata/pata_sis.c b/drivers/ata/pata_sis.c index ec3ae93..0752104 100644 --- a/drivers/ata/pata_sis.c +++ b/drivers/ata/pata_sis.c Jeff, Did you have added the patch you have mailed on 06.06. anywhere or is this patch an email only patch. And how to continue? It's in my mbox queue, should be in my next run... :) Jeff - 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-rc4] libata: SiS180 pata support
Jeff Garzik wrote: Jeff, Did you have added the patch you have mailed on 06.06. anywhere or is this patch an email only patch. And how to continue? It's in my mbox queue, should be in my next run... :) Jeff I have 3 fixes that i want to add on top - a compilation fix for your fix - an additional PCI-ID - a changed handling for SATA-devices in IDE-emulation mode, this fixes issues for the SiS968 I have submitted these fixes 2 times in a single patch, but i can also split the three fixes in separate patches if wanted. Uwe - 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: CF flash PATA on libata failure to attach
I'm betting that the SATA/PATA converter is getting confused with the ata_piix driver's attempt to use MDMA2 on it. PIO appears to be working fine -- the BIOS uses it to boot, and libata uses it to do the IDENTIFY operation. So, try this hack, which should force ata_piix to use only PIO for the ICH8 chipset. So long as you don't have any real SATA drives, this might do the trick. Cheers --- linux/drivers/ata/ata_piix.c.orig 2007-06-27 11:20:51.0 - 0400 +++ linux/drivers/ata/ata_piix.c 2007-06-28 13:32:27.0 -0400 @@ -526,8 +526,8 @@ .flags = PIIX_SATA_FLAGS | PIIX_FLAG_SCR | PIIX_FLAG_AHCI, .pio_mask = 0x1f, /* pio0-4 */ - .mwdma_mask = 0x07, /* mwdma0-2 */ - .udma_mask = 0x7f, /* udma0-6 */ + .mwdma_mask = 0x00, /* mwdma0-2 */ + .udma_mask = 0x00, /* udma0-6 */ .port_ops = piix_sata_ops, }, @@ -537,8 +537,8 @@ .flags = PIIX_SATA_FLAGS | PIIX_FLAG_SCR | PIIX_FLAG_AHCI, .pio_mask = 0x1f, /* pio0-4 */ - .mwdma_mask = 0x07, /* mwdma0-2 */ - .udma_mask = 0x7f, /* udma0-6 */ + .mwdma_mask = 0x00, /* mwdma0-2 */ + .udma_mask = 0x00, /* udma0-6 */ .port_ops = piix_sata_ops, }, Yes!! It worked.. which means you were right - forcing the channel to PIO4 and the drive was happy. The problem I have now is that we do in fact also have a SATA HDD connected to the same controller used for database and logging data - this now also is forced to use PIO4. How can I force the first channel to only use PIO and the remainder to use MWDMA2? Thanks for your help.. - 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 -mm] sata_nv: allow changing queue depth
The sata_nv driver was missing the change_queue_depth hook in the SCSI host template which the other NCQ-capable libata drivers had. This made it impossible to change the queue depth by user request. Add this in. Signed-off-by: Robert Hancock [EMAIL PROTECTED] --- linux-2.6.22-rc6-mm1/drivers/ata/sata_nv.c 2007-06-28 17:30:28.0 -0600 +++ linux-2.6.22-rc6-mm1edit/drivers/ata/sata_nv.c 2007-06-28 17:39:30.0 -0600 @@ -398,6 +398,7 @@ static struct scsi_host_template nv_adma .name = DRV_NAME, .ioctl = ata_scsi_ioctl, .queuecommand = ata_scsi_queuecmd, + .change_queue_depth = ata_scsi_change_queue_depth, .can_queue = NV_ADMA_MAX_CPBS, .this_id= ATA_SHT_THIS_ID, .sg_tablesize = NV_ADMA_SGTBL_TOTAL_LEN, @@ -416,6 +417,7 @@ static struct scsi_host_template nv_swnc .name = DRV_NAME, .ioctl = ata_scsi_ioctl, .queuecommand = ata_scsi_queuecmd, + .change_queue_depth = ata_scsi_change_queue_depth, .can_queue = ATA_MAX_QUEUE, .this_id= ATA_SHT_THIS_ID, .sg_tablesize = LIBATA_MAX_PRD, - 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: CF flash PATA on libata failure to attach
Andrew Hall wrote: Yes!! It worked.. which means you were right - forcing the channel to PIO4 and the drive was happy. The problem I have now is that we do in fact also have a SATA HDD connected to the same controller used for database and logging data - this now also is forced to use PIO4. How can I force the first channel to only use PIO and the remainder to use MWDMA2? Thanks for your help.. You're welcome. Here's a slightly modified hack, which should leave your SATA drive working as well as the CF card. Tejun / Alan : do we really want to continue attempting mdma2 on a modern chipset such as ICH8 ??? The best mdma2 can do is the same throughput as pio4, and the bus occupancy is so high for mdma2 that it really probably isn't worthwhile -- only CF cards seem to use it in modern systems anyway. Signed-off-by: Mark Lord [EMAIL PROTECTED] --- --- linux/drivers/ata/ata_piix.c.orig 2007-06-10 18:58:27.0 -0400 +++ linux/drivers/ata/ata_piix.c2007-06-28 21:09:04.0 -0400 @@ -537,7 +537,7 @@ .flags = PIIX_SATA_FLAGS | PIIX_FLAG_SCR | PIIX_FLAG_AHCI, .pio_mask = 0x1f, /* pio0-4 */ - .mwdma_mask = 0x07, /* mwdma0-2 */ + .mwdma_mask = 0x00, /* mwdma0-2 */ .udma_mask = 0x7f, /* udma0-6 */ .port_ops = piix_sata_ops, }, - 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-rc6] sata_inic162x: add big fat warning about broken LBA48 support
Jeff Garzik wrote: Tejun Heo wrote: Jeff Garzik wrote: Mark Lord wrote: Tejun Heo wrote: sata_inic162x can't do LBA48 properly yet. Whine loudly about it to reduce confusion. Why not whine only when an affected device is actually present? That's sorta that I think... That was me being lazy. I'll just ban LBA28 disks on the controller. Sounds better to me... I certainly prefer that to clipping-to-1xxGB, especially given the shaky state of the overall driver. I wonder if PIO works for LBA48 on that chipset (very, *very* likely). Maybe just fall back to PIO for an LBA48 drive. Or even better, fall back to PIO only for sectors beyond 128GB. ??? Or wait for a more stable driver.. - 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-rc6] sata_inic162x: add big fat warning about broken LBA48 support
Mark Lord wrote: I wonder if PIO works for LBA48 on that chipset (very, *very* likely). HOB register access doesn't work (even get native max address is broken). Maybe just fall back to PIO for an LBA48 drive. Or even better, fall back to PIO only for sectors beyond 128GB. ??? Or wait for a more stable driver.. I don't really think the driver is useful in its current state. Maybe we should just mark it BROKEN. I don't think I'm gonna work on it without further information and initio is almost impossible to contact. -- 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: CF flash PATA on libata failure to attach
Hello, Mark Lord wrote: Here's a slightly modified hack, which should leave your SATA drive working as well as the CF card. Tejun / Alan : do we really want to continue attempting mdma2 on a modern chipset such as ICH8 ??? One thing that worries me is that we have reports where the IDE piix can do mwdma but ata_piix can't. I wonder whether Andrew is hitting the same problem. The best mdma2 can do is the same throughput as pio4, and the bus occupancy is so high for mdma2 that it really probably isn't worthwhile -- only CF cards seem to use it in modern systems anyway. There also seem to be devices which claim to support mwdma2 but pukes when actual commands are given. Do we know whether the other os uses mwdma mode? -- 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: CF flash PATA on libata failure to attach
Here's a slightly modified hack, which should leave your SATA drive working as well as the CF card. Tejun / Alan : do we really want to continue attempting mdma2 on a modern chipset such as ICH8 ??? The best mdma2 can do is the same throughput as pio4, and the bus occupancy is so high for mdma2 that it really probably isn't worthwhile -- only CF cards seem to use it in modern systems anyway. Signed-off-by: Mark Lord [EMAIL PROTECTED] --- --- linux/drivers/ata/ata_piix.c.orig 2007-06-10 18:58:27.0 -0400 +++ linux/drivers/ata/ata_piix.c 2007-06-28 21:09:04.0 -0400 @@ -537,7 +537,7 @@ .flags = PIIX_SATA_FLAGS | PIIX_FLAG_SCR | PIIX_FLAG_AHCI, .pio_mask = 0x1f, /* pio0-4 */ - .mwdma_mask = 0x07, /* mwdma0-2 */ + .mwdma_mask = 0x00, /* mwdma0-2 */ .udma_mask = 0x7f, /* udma0-6 */ .port_ops = piix_sata_ops, }, That worked a treat! CF is flagged as PIO4 and HDD is now UDMA. I can't tell you how grateful I am that you were able to point out the fix / modification but I can certainly now sleep a bit easier. Furthermore, if there is anything else I can do or would like me to test while we have this type of hardware, please let me know. Thanks again, Mark.. - 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: CF flash PATA on libata failure to attach
Tejun Heo wrote: Hello, Mark Lord wrote: Here's a slightly modified hack, which should leave your SATA drive working as well as the CF card. Tejun / Alan : do we really want to continue attempting mdma2 on a modern chipset such as ICH8 ??? One thing that worries me is that we have reports where the IDE piix can do mwdma but ata_piix can't. I wonder whether Andrew is hitting the same problem. I think Andrew said he had tried the old IDE driver, but perhaps it didn't match his PCI IDs ? Andrew? - 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: CF flash PATA on libata failure to attach
Andrew Hall wrote: .. Signed-off-by: Mark Lord [EMAIL PROTECTED] --- --- linux/drivers/ata/ata_piix.c.orig 2007-06-10 18:58:27.0 -0400 +++ linux/drivers/ata/ata_piix.c2007-06-28 21:09:04.0 -0400 @@ -537,7 +537,7 @@ .flags = PIIX_SATA_FLAGS | PIIX_FLAG_SCR | PIIX_FLAG_AHCI, .pio_mask = 0x1f, /* pio0-4 */ - .mwdma_mask = 0x07, /* mwdma0-2 */ + .mwdma_mask = 0x00, /* mwdma0-2 */ .udma_mask = 0x7f, /* udma0-6 */ .port_ops = piix_sata_ops, }, That worked a treat! CF is flagged as PIO4 and HDD is now UDMA. I can't tell you how grateful I am that you were able to point out the fix / modification but I can certainly now sleep a bit easier. Furthermore, if there is anything else I can do or would like me to test while we have this type of hardware, please let me know. Thanks again, Mark.. You can certainly also thank Tejun and Jeff, for making libata so easy to tune with a one-liner liner like this! Per my other email -- did you try the legacy IDE driver instead of libata? Can you provide a boot log from that for Tejun? 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
[PATCH] sata_inic162x: disable LBA48 devices
sata_inic162x can't do LBA48 properly yet and is likely to corrupt
data on drives larger than LBA28 limit. Disable LBA48 devices during
device configuration.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
---
drivers/ata/sata_inic162x.c |7 +++
1 file changed, 7 insertions(+)
Index: work/drivers/ata/sata_inic162x.c
===
--- work.orig/drivers/ata/sata_inic162x.c
+++ work/drivers/ata/sata_inic162x.c
@@ -496,6 +496,13 @@ static void inic_dev_config(struct ata_d
/* inic can only handle upto LBA28 max sectors */
if (dev-max_sectors ATA_MAX_SECTORS)
dev-max_sectors = ATA_MAX_SECTORS;
+
+ if (dev-n_sectors = 1 28) {
+ ata_dev_printk(dev, KERN_ERR,
+ ERROR: This driver doesn't support LBA48 yet and may cause\n
+ data corruption on such devices. Disabling.\n);
+ ata_dev_disable(dev);
+ }
}
static void init_port(struct ata_port *ap)
-
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: CF flash PATA on libata failure to attach
You can certainly also thank Tejun and Jeff, for making libata so easy to tune with a one-liner liner like this! Per my other email -- did you try the legacy IDE driver instead of libata? Can you provide a boot log from that for Tejun? Too true.. thanks Tejun, Jeff and Alan also.. much appreciated.. I did try the legacy driver but couldn't get it to be detected at all. I wasn't sure how to modify it (ide/pci/piix.c) to add the right PCI-ID but am happy to get Tejun the dmesg if you can tell me how I derive the PCI-ID for my hardware and where to add it. Also because this is IDE via SATA, when disabling the libata drivers do I need to enable the old Support for SATA compile option to get the device to be detected? - 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
