* Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive
@ 2006-08-28 23:01 Derek Taubert
2006-08-29 2:39 ` Tejun Heo
0 siblings, 1 reply; 16+ messages in thread
From: Derek Taubert @ 2006-08-28 23:01 UTC (permalink / raw)
To: htejun, linux-ide; +Cc: taubert
Greetings!
I'm using a 2.6.17.4 kernel (straight from kernel.org) patched with
libata-tj-stable-2.6.17.4-20060710 in an effort to make use of an external
drive bay with a Silicon Image port multipler and a bunch of SATA/PATA
drives. For the most part, it's a success (more below) but the write
performance that I'm seeing to a new Seagate 750GB drive (with NCQ) is
terrible (on the order of 1.2MBytes/sec).
The host is an old Toshiba laptop (PIIX4 based) with a 550MHz Celeron
processor. The SATA host interface is a PCMCIA based Silicon Image 3124
chip plugged into the Yenta PCMCIA controller. A tulip based Linksys
10/100 card takes up the other slot. From dmesg:
ACPI: PCI Interrupt 0000:00:04.1[B] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10
Yenta: CardBus bridge found at 0000:00:04.1 [1179:ff00]
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:00:04.1, mfunc 0x000c1722, devctl 0x66
usb 1-1: configuration #1 chosen from 1 choice
Yenta: ISA IRQ mask 0x0838, PCI irq 10
Socket status: 30000020
pccard: CardBus card inserted into slot 0
pccard: CardBus card inserted into slot 1
st: Version 20050830, fixed bufsize 32768, s/g segs 256
Adding 248996k swap on /dev/hda2. Priority:42 extents:1 across:248996k
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Linux Tulip driver version 1.1.13-NAPI (May 11, 2002)
PCI: Enabling device 0000:02:00.0 (0000 -> 0003)
ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKA] -> GSI 10 (level, low) -> IRQ 10
PCI: Setting latency timer of device 0000:02:00.0 to 64
tulip0: EEPROM default media type Autosense.
tulip0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
tulip0: MII transceiver #0 config 3000 status 7829 advertising 01e1.
eth0: Digital DS21143 Tulip rev 65 at 00011400, 00:E0:98:04:21:54, IRQ 10.
libata version 2.00 loaded.
sata_sil24 0000:06:00.0: version 0.3
PCI: Enabling device 0000:06:00.0 (0080 -> 0083)
ACPI: PCI Interrupt 0000:06:00.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10
PCI: Setting latency timer of device 0000:06:00.0 to 64
ata1: SATA max UDMA/100 cmd 0xC8CB0000 ctl 0x0 bmdma 0x0 irq 10
ata2: SATA max UDMA/100 cmd 0xC8CB2000 ctl 0x0 bmdma 0x0 irq 10
ata3: SATA max UDMA/100 cmd 0xC8CB4000 ctl 0x0 bmdma 0x0 irq 10
ata4: SATA max UDMA/100 cmd 0xC8CB6000 ctl 0x0 bmdma 0x0 irq 10
scsi0 : sata_sil24
ata1: SATA link down (SStatus 0 SControl 300)
scsi1 : sata_sil24
ata2: SATA link down (SStatus 0 SControl 300)
scsi2 : sata_sil24
ata3: SATA link down (SStatus 0 SControl 300)
scsi3 : sata_sil24
ata4: SATA link down (SStatus 0 SControl 300)
The /var/log/messages output after hotplugging the multiplier. Note the
NCQ for ata1.00:
Aug 27 18:48:26 linux-srv kernel: ata1: soft resetting port
Aug 27 18:48:26 linux-srv kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Aug 27 18:48:26 linux-srv kernel: ata1.15: Port Multiplier 1.1, 0x1095:0x3726 r23, 5 ports, feat 0x9/0x9
Aug 27 18:48:27 linux-srv kernel: ata1.00: hard resetting port
Aug 27 18:48:29 linux-srv kernel: ata1.00: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Aug 27 18:48:29 linux-srv kernel: ata1.01: hard resetting port
Aug 27 18:48:30 linux-srv kernel: ata1.01: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Aug 27 18:48:30 linux-srv kernel: ata1.02: hard resetting port
Aug 27 18:48:31 linux-srv kernel: ata1.02: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Aug 27 18:48:31 linux-srv kernel: ata1.03: hard resetting port
Aug 27 18:48:31 linux-srv kernel: ata1.03: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Aug 27 18:48:31 linux-srv kernel: ata1.04: hard resetting port
Aug 27 18:48:32 linux-srv kernel: ata1.04: SATA link down (SStatus 0 SControl 300)
Aug 27 18:48:32 linux-srv kernel: ata1.00: ATA-7, max UDMA/133, 1465149168 sectors: LBA48 NCQ (depth 31/32)
Aug 27 18:48:32 linux-srv kernel: ata1.00: configured for UDMA/100
Aug 27 18:48:32 linux-srv kernel: ata1.01: ATA-7, max UDMA/133, 490234752 sectors: LBA48
Aug 27 18:48:32 linux-srv kernel: ata1.01: ata1: dev 0 multi count 0
Aug 27 18:48:32 linux-srv kernel: ata1.01: applying bridge limits
Aug 27 18:48:32 linux-srv kernel: ata1.01: configured for UDMA/100
Aug 27 18:48:32 linux-srv kernel: ata1.02: ATA-6, max UDMA/100, 488397168 sectors: LBA48
Aug 27 18:48:32 linux-srv kernel: ata1.02: ata1: dev 0 multi count 0
Aug 27 18:48:32 linux-srv kernel: ata1.02: applying bridge limits
Aug 27 18:48:32 linux-srv kernel: ata1.02: configured for UDMA/100
Aug 27 18:48:32 linux-srv kernel: ata1.03: ATA-6, max UDMA/100, 488397168 sectors: LBA48
Aug 27 18:48:32 linux-srv kernel: ata1.03: ata1: dev 0 multi count 0
Aug 27 18:48:32 linux-srv kernel: ata1.03: applying bridge limits
Aug 27 18:48:32 linux-srv kernel: ata1.03: configured for UDMA/100
Aug 27 18:48:32 linux-srv kernel: ata1: EH complete
Aug 27 18:48:32 linux-srv kernel: Vendor: ATA Model: ST3750640AS Rev: 3.AA
Aug 27 18:48:32 linux-srv kernel: Type: Direct-Access ANSI SCSI revision: 05
Aug 27 18:48:32 linux-srv kernel: SCSI device sda: 1465149168 512-byte hdwr sectors (750156 MB)
Aug 27 18:48:32 linux-srv kernel: sda: Write Protect is off
Aug 27 18:48:32 linux-srv kernel: sda: Mode Sense: 00 3a 00 00
Aug 27 18:48:32 linux-srv kernel: SCSI device sda: drive cache: write back
Aug 27 18:48:32 linux-srv kernel: SCSI device sda: 1465149168 512-byte hdwr sectors (750156 MB)
Aug 27 18:48:32 linux-srv kernel: sda: Write Protect is off
Aug 27 18:48:32 linux-srv kernel: sda: Mode Sense: 00 3a 00 00
Aug 27 18:48:32 linux-srv kernel: SCSI device sda: drive cache: write back
Aug 27 18:48:32 linux-srv kernel: sda: sda1
Aug 27 18:48:32 linux-srv kernel: sd 0:0:0:0: Attached scsi disk sda
Aug 27 18:48:32 linux-srv kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
Aug 27 18:48:32 linux-srv kernel: Vendor: ATA Model: Maxtor 6Y250P0 Rev: YAR4
Aug 27 18:48:32 linux-srv kernel: Type: Direct-Access ANSI SCSI revision: 05
Aug 27 18:48:32 linux-srv kernel: SCSI device sdb: 490234752 512-byte hdwr sectors (251000 MB)
Aug 27 18:48:32 linux-srv kernel: sdb: Write Protect is off
Aug 27 18:48:32 linux-srv kernel: sdb: Mode Sense: 00 3a 00 00
Aug 27 18:48:32 linux-srv kernel: SCSI device sdb: drive cache: write back
Aug 27 18:48:32 linux-srv kernel: SCSI device sdb: 490234752 512-byte hdwr sectors (251000 MB)
Aug 27 18:48:32 linux-srv kernel: sdb: Write Protect is off
Aug 27 18:48:32 linux-srv kernel: sdb: Mode Sense: 00 3a 00 00
Aug 27 18:48:32 linux-srv kernel: SCSI device sdb: drive cache: write back
Aug 27 18:48:32 linux-srv kernel: sdb: sdb1
Aug 27 18:48:32 linux-srv kernel: sd 0:0:1:0: Attached scsi disk sdb
Aug 27 18:48:32 linux-srv kernel: sd 0:0:1:0: Attached scsi generic sg1 type 0
Aug 27 18:48:32 linux-srv kernel: Vendor: ATA Model: WDC WD2500BB-00G Rev: 08.0
Aug 27 18:48:32 linux-srv kernel: Type: Direct-Access ANSI SCSI revision: 05
Aug 27 18:48:32 linux-srv kernel: SCSI device sdc: 488397168 512-byte hdwr sectors (250059 MB)
Aug 27 18:48:32 linux-srv kernel: sdc: Write Protect is off
Aug 27 18:48:32 linux-srv kernel: sdc: Mode Sense: 00 3a 00 00
Aug 27 18:48:32 linux-srv kernel: SCSI device sdc: drive cache: write back
Aug 27 18:48:32 linux-srv kernel: SCSI device sdc: 488397168 512-byte hdwr sectors (250059 MB)
Aug 27 18:48:32 linux-srv kernel: sdc: Write Protect is off
Aug 27 18:48:32 linux-srv kernel: sdc: Mode Sense: 00 3a 00 00
Aug 27 18:48:32 linux-srv kernel: SCSI device sdc: drive cache: write back
Aug 27 18:48:32 linux-srv kernel: sdc: sdc1
Aug 27 18:48:32 linux-srv kernel: sd 0:0:2:0: Attached scsi disk sdc
Aug 27 18:48:32 linux-srv kernel: sd 0:0:2:0: Attached scsi generic sg2 type 0
Aug 27 18:48:32 linux-srv kernel: Vendor: ATA Model: WDC WD2500JB-00G Rev: 08.0
Aug 27 18:48:32 linux-srv kernel: Type: Direct-Access ANSI SCSI revision: 05
Aug 27 18:48:32 linux-srv kernel: SCSI device sdd: 488397168 512-byte hdwr sectors (250059 MB)
Aug 27 18:48:32 linux-srv kernel: sdd: Write Protect is off
Aug 27 18:48:32 linux-srv kernel: sdd: Mode Sense: 00 3a 00 00
Aug 27 18:48:32 linux-srv kernel: SCSI device sdd: drive cache: write back
Aug 27 18:48:32 linux-srv kernel: SCSI device sdd: 488397168 512-byte hdwr sectors (250059 MB)
Aug 27 18:48:32 linux-srv kernel: sdd: Write Protect is off
Aug 27 18:48:32 linux-srv kernel: sdd: Mode Sense: 00 3a 00 00
Aug 27 18:48:32 linux-srv kernel: SCSI device sdd: drive cache: write back
Aug 27 18:48:32 linux-srv kernel: sdd: sdd1
Aug 27 18:48:32 linux-srv kernel: sd 0:0:3:0: Attached scsi disk sdd
Aug 27 18:48:32 linux-srv kernel: sd 0:0:3:0: Attached scsi generic sg3 type 0
Aug 27 18:48:33 linux-srv /etc/hotplug.d/block/50-hwscan.hotplug[16227]: new block device /block/sda
Aug 27 18:48:35 linux-srv /etc/hotplug.d/block/50-hwscan.hotplug[16437]: new block device /block/sdb
Aug 27 18:48:35 linux-srv /etc/hotplug.d/block/50-hwscan.hotplug[16467]: new block device /block/sdd
Aug 27 18:48:35 linux-srv /etc/hotplug.d/block/50-hwscan.hotplug[16487]: new block device /block/sdc
Aug 27 18:48:35 linux-srv /etc/hotplug.d/block/50-hwscan.hotplug[16587]: new block device /block/sdc/sdc1
Aug 27 18:48:35 linux-srv /etc/hotplug.d/block/50-hwscan.hotplug[16599]: new block device /block/sdd/sdd1
Aug 27 18:48:37 linux-srv /etc/hotplug.d/block/50-hwscan.hotplug[16611]: new block device /block/sdb/sdb1
Aug 27 18:48:38 linux-srv /etc/hotplug.d/block/50-hwscan.hotplug[16603]: new block device /block/sda/sda1
Aug 27 18:49:01 linux-srv hald[9182]: Timed out waiting for hotplug event 1950. Rebasing to 1930
What works:
1) Read performance to all 4 drives is ok (40-50 MBytes/sec as reported
by iostat) and stable. I've hammered a read-only software RAID5 spread
across the last 3 drives with no problem.
2) "smartctl -d ata -a" works nicely to all 4 drives.
3) hdparm -S makes the drives spin down when idle as expected.
4) Hotplug seems to work quite well. I'm even able to power down and
remove a drive from the port multiplier while the other 3 are reading
data (during a "e2fsck -f -n /dev/md0").
What doesn't work so well:
1) Writing to sda1.
# dd if=/dev/zero of=/dev/sda1 count=4M
<ctrl-c, then wait 30 seconds>
264205+0 records in
264204+0 records out
135272448 bytes (135 MB) copied, 111.373 seconds, 1.2 MB/s
>From iostat -k 10:
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 2428.64 2422.46 667.66 24273 6690
sda 36.84 23.72 1667.87 237 16662
sda 2440.60 2434.90 616.00 24349 6160
The read rate is curious (should be 0)...
Top shows 1% user, 3% system, 93% wait.
If I "cat /proc/scsi/sg/devices" during this test, the next to last column
seems to indicate that the queue fills up and pretty much stays that way:
# cat /proc/scsi/sg/devices
0 0 0 0 0 1 31 0 1
0 0 1 0 0 1 1 0 1
0 0 2 0 0 1 1 0 1
0 0 3 0 0 1 1 0 1
# cat /proc/scsi/sg/devices
0 0 0 0 0 1 31 29 1
0 0 1 0 0 1 1 0 1
0 0 2 0 0 1 1 1 1
0 0 3 0 0 1 1 1 1
# cat /proc/scsi/sg/devices
0 0 0 0 0 1 31 31 1
0 0 1 0 0 1 1 0 1
0 0 2 0 0 1 1 0 1
0 0 3 0 0 1 1 0 1
# cat /proc/scsi/sg/devices
0 0 0 0 0 1 31 30 1
0 0 1 0 0 1 1 0 1
0 0 2 0 0 1 1 1 1
0 0 3 0 0 1 1 0 1
2) hdparm -C for all 4 drives always shows "drive state is: standby"
even when I'm certain that the drives are active.
I'd really like some assistance debugging the write performance issue.
The "hdparm -C" issue would be gravy...
Thanks,
Derek
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive
2006-08-28 23:01 Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive Derek Taubert
@ 2006-08-29 2:39 ` Tejun Heo
2006-08-29 4:58 ` Derek Taubert
2006-08-29 14:07 ` Greg Freemyer
0 siblings, 2 replies; 16+ messages in thread
From: Tejun Heo @ 2006-08-29 2:39 UTC (permalink / raw)
To: Derek Taubert; +Cc: linux-ide
Hello,
Derek Taubert wrote:
> Greetings!
>
> I'm using a 2.6.17.4 kernel (straight from kernel.org) patched with
> libata-tj-stable-2.6.17.4-20060710 in an effort to make use of an external
> drive bay with a Silicon Image port multipler and a bunch of SATA/PATA
> drives. For the most part, it's a success (more below) but the write
> performance that I'm seeing to a new Seagate 750GB drive (with NCQ) is
> terrible (on the order of 1.2MBytes/sec).
>
> The host is an old Toshiba laptop (PIIX4 based) with a 550MHz Celeron
> processor. The SATA host interface is a PCMCIA based Silicon Image 3124
> chip plugged into the Yenta PCMCIA controller. A tulip based Linksys
> 10/100 card takes up the other slot. From dmesg:
Hah... interesting setup.
(dmesg snipped, all look good)
> What works:
>
> 1) Read performance to all 4 drives is ok (40-50 MBytes/sec as reported
> by iostat) and stable. I've hammered a read-only software RAID5 spread
> across the last 3 drives with no problem.
> 2) "smartctl -d ata -a" works nicely to all 4 drives.
> 3) hdparm -S makes the drives spin down when idle as expected.
> 4) Hotplug seems to work quite well. I'm even able to power down and
> remove a drive from the port multiplier while the other 3 are reading
> data (during a "e2fsck -f -n /dev/md0").
Good.
> What doesn't work so well:
>
> 1) Writing to sda1.
>
> # dd if=/dev/zero of=/dev/sda1 count=4M
> <ctrl-c, then wait 30 seconds>
> 264205+0 records in
> 264204+0 records out
> 135272448 bytes (135 MB) copied, 111.373 seconds, 1.2 MB/s
>
> From iostat -k 10:
> Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
> sda 2428.64 2422.46 667.66 24273 6690
> sda 36.84 23.72 1667.87 237 16662
> sda 2440.60 2434.90 616.00 24349 6160
> The read rate is curious (should be 0)...
>
> Top shows 1% user, 3% system, 93% wait.
It seems some kind of read IO is in progress. Can you repeat the test
on an unused/idle (iostat -k 10 shows all zeros...) drive? The above
result actually looks good if you consider both read and write sides.
The result doesn't seem to indicate any problem in libata or any storage
related kernel subsystem. I would track down the reader first.
> If I "cat /proc/scsi/sg/devices" during this test, the next to last column
> seems to indicate that the queue fills up and pretty much stays that way:
>
> # cat /proc/scsi/sg/devices
> 0 0 0 0 0 1 31 0 1
> 0 0 1 0 0 1 1 0 1
> 0 0 2 0 0 1 1 0 1
> 0 0 3 0 0 1 1 0 1
> # cat /proc/scsi/sg/devices
> 0 0 0 0 0 1 31 29 1
> 0 0 1 0 0 1 1 0 1
> 0 0 2 0 0 1 1 1 1
> 0 0 3 0 0 1 1 1 1
> # cat /proc/scsi/sg/devices
> 0 0 0 0 0 1 31 31 1
> 0 0 1 0 0 1 1 0 1
> 0 0 2 0 0 1 1 0 1
> 0 0 3 0 0 1 1 0 1
> # cat /proc/scsi/sg/devices
> 0 0 0 0 0 1 31 30 1
> 0 0 1 0 0 1 1 0 1
> 0 0 2 0 0 1 1 1 1
> 0 0 3 0 0 1 1 0 1
This looks okay too considering the write queue is full.
> 2) hdparm -C for all 4 drives always shows "drive state is: standby"
> even when I'm certain that the drives are active.
hdparm -C says the same thing for my drive. I think it's safe to
ignore. Hmmm... it needs to be tracked down. Maybe some problem in
HDIO ioctl implementation in libata.
> I'd really like some assistance debugging the write performance issue.
> The "hdparm -C" issue would be gravy...
Please track down the reader.
--
tejun
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive
2006-08-29 2:39 ` Tejun Heo
@ 2006-08-29 4:58 ` Derek Taubert
2006-08-29 7:54 ` Derek Taubert
2006-08-29 13:27 ` Tejun Heo
2006-08-29 14:07 ` Greg Freemyer
1 sibling, 2 replies; 16+ messages in thread
From: Derek Taubert @ 2006-08-29 4:58 UTC (permalink / raw)
To: Tejun Heo; +Cc: Derek Taubert, linux-ide
On Tue, Aug 29, 2006 at 11:39:57AM +0900, Tejun Heo wrote:
> Derek Taubert wrote:
> ># dd if=/dev/zero of=/dev/sda1 count=4M
> ><ctrl-c, then wait 30 seconds>
> >264205+0 records in
> >264204+0 records out
> >135272448 bytes (135 MB) copied, 111.373 seconds, 1.2 MB/s
> >
> >From iostat -k 10:
> >Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
> >sda 2428.64 2422.46 667.66 24273 6690
> >sda 36.84 23.72 1667.87 237 16662
> >sda 2440.60 2434.90 616.00 24349 6160
> >The read rate is curious (should be 0)...
> >
> >Top shows 1% user, 3% system, 93% wait.
>
> It seems some kind of read IO is in progress. Can you repeat the test
> on an unused/idle (iostat -k 10 shows all zeros...) drive? The above
> result actually looks good if you consider both read and write sides.
I think that 3MBytes/sec total for a drive that can read at 50MBytes/sec
on the same system is quite bad, especially since we're talking about
a linear write test.
> The result doesn't seem to indicate any problem in libata or any storage
> related kernel subsystem. I would track down the reader first.
This drive has only been partitioned; there is no filesystem on it. So,
it certainly isn't mounted anywhere. There honestly isn't _anything_
other than the dd going on to sda1, and that's the only partition on
sda.
> >2) hdparm -C for all 4 drives always shows "drive state is: standby"
> > even when I'm certain that the drives are active.
>
> hdparm -C says the same thing for my drive. I think it's safe to
> ignore. Hmmm... it needs to be tracked down. Maybe some problem in
> HDIO ioctl implementation in libata.
It's a "nice to have" for using smartd. ie: don't spin the drives up to
poll the failure attributes, but they should be checked if the drive's
already active.
> >I'd really like some assistance debugging the write performance issue.
> >The "hdparm -C" issue would be gravy...
>
> Please track down the reader.
Before running dd (fuser -v /dev/sda1 shows nothing):
avg-cpu: %user %nice %sys %iowait %idle
0.50 0.00 0.20 0.00 99.30
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
fd0 0.00 0.00 0.00 0 0
hda 0.00 0.00 0.00 0 0
md0 0.00 0.00 0.00 0 0
md1 0.00 0.00 0.00 0 0
sda 0.00 0.00 0.00 0 0
sdb 0.00 0.00 0.00 0 0
sdc 0.00 0.00 0.00 0 0
sdd 0.00 0.00 0.00 0 0
After starting dd:
# fuser -v /dev/sda1
USER PID ACCESS COMMAND
/dev/sda1 root 21753 f.... dd
avg-cpu: %user %nice %sys %iowait %idle
0.90 0.00 11.01 88.09 0.00
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
fd0 0.00 0.00 0.00 0 0
hda 0.10 0.00 0.40 0 4
md0 0.00 0.00 0.00 0 0
md1 0.00 0.00 0.00 0 0
sda 1306.61 1295.60 1310.11 12943 13088
sdb 0.00 0.00 0.00 0 0
sdc 0.00 0.00 0.00 0 0
sdd 0.00 0.00 0.00 0 0
After stopping dd (fuser -v /dev/sda1 again shows nothing):
avg-cpu: %user %nice %sys %iowait %idle
0.80 0.00 0.30 0.00 98.90
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
fd0 0.00 0.00 0.00 0 0
hda 1.00 0.00 5.21 0 52
md0 0.00 0.00 0.00 0 0
md1 0.00 0.00 0.00 0 0
sda 0.00 0.00 0.00 0 0
sdb 0.00 0.00 0.00 0 0
sdc 0.00 0.00 0.00 0 0
sdd 0.00 0.00 0.00 0 0
I'm honestly not sure what else to check...
Thanks for your response,
Derek
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive
2006-08-29 4:58 ` Derek Taubert
@ 2006-08-29 7:54 ` Derek Taubert
2006-08-29 13:35 ` Tejun Heo
2006-08-29 13:27 ` Tejun Heo
1 sibling, 1 reply; 16+ messages in thread
From: Derek Taubert @ 2006-08-29 7:54 UTC (permalink / raw)
To: Tejun Heo; +Cc: Derek Taubert, linux-ide
On Mon, Aug 28, 2006 at 09:58:16PM -0700, Derek Taubert wrote:
> On Tue, Aug 29, 2006 at 11:39:57AM +0900, Tejun Heo wrote:
> > The result doesn't seem to indicate any problem in libata or any storage
> > related kernel subsystem. I would track down the reader first.
>
> This drive has only been partitioned; there is no filesystem on it. So,
> it certainly isn't mounted anywhere. There honestly isn't _anything_
> other than the dd going on to sda1, and that's the only partition on
> sda.
>
> After starting dd:
>
> # fuser -v /dev/sda1
>
> USER PID ACCESS COMMAND
> /dev/sda1 root 21753 f.... dd
>
> avg-cpu: %user %nice %sys %iowait %idle
> 0.90 0.00 11.01 88.09 0.00
>
> Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
> sda 1306.61 1295.60 1310.11 12943 13088
Another thought about this...
The sd cache_type is set to "write back" for this drive. I suspect that
the reads are coming from the block driver attempting to fill lines.
# cat /sys/bus/scsi/devices/0:0:0:0/scsi_disk:0:0:0:0/cache_type
write back
Also, a problem here:
# echo "none" > /sys/bus/scsi/devices/0:0:0:0/scsi_disk:0:0:0:0/cache_type
echo: write error: invalid argument
dmesg says:
sda: Current: sense key: Illegal Request
Additional sense: Invalid field in cdb
Derek
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive
2006-08-29 4:58 ` Derek Taubert
2006-08-29 7:54 ` Derek Taubert
@ 2006-08-29 13:27 ` Tejun Heo
2006-08-29 16:44 ` Derek Taubert
1 sibling, 1 reply; 16+ messages in thread
From: Tejun Heo @ 2006-08-29 13:27 UTC (permalink / raw)
To: Derek Taubert; +Cc: linux-ide
Derek Taubert wrote:
>> >From iostat -k 10:
>>> Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
>>> sda 2428.64 2422.46 667.66 24273 6690
>>> sda 36.84 23.72 1667.87 237 16662
>>> sda 2440.60 2434.90 616.00 24349 6160
>>> The read rate is curious (should be 0)...
>>>
>>> Top shows 1% user, 3% system, 93% wait.
>> It seems some kind of read IO is in progress. Can you repeat the test
>> on an unused/idle (iostat -k 10 shows all zeros...) drive? The above
>> result actually looks good if you consider both read and write sides.
>
> I think that 3MBytes/sec total for a drive that can read at 50MBytes/sec
> on the same system is quite bad, especially since we're talking about
> a linear write test.
True, I was referring to both reads and writes. If both are in progress
and they're apart on disk, the result looks normal.
>> The result doesn't seem to indicate any problem in libata or any storage
>> related kernel subsystem. I would track down the reader first.
>
> This drive has only been partitioned; there is no filesystem on it. So,
> it certainly isn't mounted anywhere. There honestly isn't _anything_
> other than the dd going on to sda1, and that's the only partition on
> sda.
Hmmm...
>>> 2) hdparm -C for all 4 drives always shows "drive state is: standby"
>>> even when I'm certain that the drives are active.
>> hdparm -C says the same thing for my drive. I think it's safe to
>> ignore. Hmmm... it needs to be tracked down. Maybe some problem in
>> HDIO ioctl implementation in libata.
>
> It's a "nice to have" for using smartd. ie: don't spin the drives up to
> poll the failure attributes, but they should be checked if the drive's
> already active.
I don't really understand what you mean. Can you elaborate?
>>> I'd really like some assistance debugging the write performance issue.
>>> The "hdparm -C" issue would be gravy...
>> Please track down the reader.
>
> Before running dd (fuser -v /dev/sda1 shows nothing):
[--snip--]
Can you try 'dd if=/dev/zero of=/dev/sdX bs=4M count=1'?
--
tejun
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive
2006-08-29 7:54 ` Derek Taubert
@ 2006-08-29 13:35 ` Tejun Heo
0 siblings, 0 replies; 16+ messages in thread
From: Tejun Heo @ 2006-08-29 13:35 UTC (permalink / raw)
To: Derek Taubert; +Cc: linux-ide
Derek Taubert wrote:
> The sd cache_type is set to "write back" for this drive. I suspect that
> the reads are coming from the block driver attempting to fill lines.
>
> # cat /sys/bus/scsi/devices/0:0:0:0/scsi_disk:0:0:0:0/cache_type
> write back
That's the cache inside the harddrive. To libata and SCSI, it's
(almost) transparent and doesn't cause such problems.
> Also, a problem here:
>
> # echo "none" > /sys/bus/scsi/devices/0:0:0:0/scsi_disk:0:0:0:0/cache_type
> echo: write error: invalid argument
>
> dmesg says:
>
> sda: Current: sense key: Illegal Request
> Additional sense: Invalid field in cdb
libata doesn't support that sysfs node (yet).
--
tejun
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive
2006-08-29 2:39 ` Tejun Heo
2006-08-29 4:58 ` Derek Taubert
@ 2006-08-29 14:07 ` Greg Freemyer
1 sibling, 0 replies; 16+ messages in thread
From: Greg Freemyer @ 2006-08-29 14:07 UTC (permalink / raw)
To: Tejun Heo; +Cc: Derek Taubert, linux-ide
On 8/28/06, Tejun Heo <htejun@gmail.com> wrote:
> Hello,
>
> Derek Taubert wrote:
> > What doesn't work so well:
> >
> > 1) Writing to sda1.
> >
> > # dd if=/dev/zero of=/dev/sda1 count=4M
> > <ctrl-c, then wait 30 seconds>
> > 264205+0 records in
> > 264204+0 records out
> > 135272448 bytes (135 MB) copied, 111.373 seconds, 1.2 MB/s
> >
> > From iostat -k 10:
> > Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
> > sda 2428.64 2422.46 667.66 24273 6690
> > sda 36.84 23.72 1667.87 237 16662
> > sda 2440.60 2434.90 616.00 24349 6160
> > The read rate is curious (should be 0)...
Tejun already asked you to change the dd line, but I'm pretty sure it
is the culprit, not a kernel bug. I always use a bs=4k arg for dd on
x86 boxes. Not sure of the detais, but it often makes a huge
performance change and eliminates all those wasteful reads.
Greg
--
Greg Freemyer
The Norcross Group
Forensics for the 21st Century
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive
2006-08-29 13:27 ` Tejun Heo
@ 2006-08-29 16:44 ` Derek Taubert
2006-08-29 21:24 ` Jeff Garzik
2006-09-01 13:32 ` Tejun Heo
0 siblings, 2 replies; 16+ messages in thread
From: Derek Taubert @ 2006-08-29 16:44 UTC (permalink / raw)
To: Tejun Heo; +Cc: Derek Taubert, linux-ide
On Tue, Aug 29, 2006 at 10:27:26PM +0900, Tejun Heo wrote:
> >>>2) hdparm -C for all 4 drives always shows "drive state is: standby"
> >>> even when I'm certain that the drives are active.
> >>hdparm -C says the same thing for my drive. I think it's safe to
> >>ignore. Hmmm... it needs to be tracked down. Maybe some problem in
> >>HDIO ioctl implementation in libata.
> >
> >It's a "nice to have" for using smartd. ie: don't spin the drives up to
> >poll the failure attributes, but they should be checked if the drive's
> >already active.
>
> I don't really understand what you mean. Can you elaborate?
Sure. See the "-n standby" option here:
http://smartmontools.sourceforge.net/man/smartd.conf.5.html
If the driver always reports "standby", then smartd effectively won't
monitor the device if "-n standby" is configured.
Now I can certainly eliminate the -n option from smartd.conf, but
then smartd will cause the drive(s) to spin up when it polls (see the
-p, -u, -t options).
> >>>I'd really like some assistance debugging the write performance issue.
> >>>The "hdparm -C" issue would be gravy...
> >>Please track down the reader.
> >
> >Before running dd (fuser -v /dev/sda1 shows nothing):
> [--snip--]
>
> Can you try 'dd if=/dev/zero of=/dev/sdX bs=4M count=1'?
Increasing the block size eliminates the reads (presumably because the
block driver doesn't have to fetch lines to read/modify/write), but the
write throughput is still very slow:
# dd if=/dev/zero of=/dev/sda1 bs=4M count=512
avg-cpu: %user %nice %sys %iowait %idle
0.90 0.00 1.30 97.80 0.00
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
fd0 0.00 0.00 0.00 0 0
hda 0.20 0.80 0.00 8 0
md0 0.00 0.00 0.00 0 0
md1 0.00 0.00 0.00 0 0
sda 15.00 0.00 1920.00 0 19200
sdb 0.00 0.00 0.00 0 0
sdc 0.00 0.00 0.00 0 0
sdd 0.00 0.00 0.00 0 0
Compare that with:
# dd of=/dev/null if=/dev/sda1 bs=4M count=512
avg-cpu: %user %nice %sys %iowait %idle
0.50 0.00 78.10 21.40 0.00
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
fd0 0.00 0.00 0.00 0 0
hda 1.10 4.40 0.00 44 0
md0 0.00 0.00 0.00 0 0
md1 0.00 0.00 0.00 0 0
sda 426.70 51532.80 0.00 515328 0
sdb 0.00 0.00 0.00 0 0
sdc 0.00 0.00 0.00 0 0
sdd 0.00 0.00 0.00 0 0
Derek
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive
2006-08-29 16:44 ` Derek Taubert
@ 2006-08-29 21:24 ` Jeff Garzik
2006-09-01 13:32 ` Tejun Heo
1 sibling, 0 replies; 16+ messages in thread
From: Jeff Garzik @ 2006-08-29 21:24 UTC (permalink / raw)
To: Derek Taubert; +Cc: Tejun Heo, linux-ide
I wonder if writeback caching is disabled?
Jeff
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive
2006-08-29 16:44 ` Derek Taubert
2006-08-29 21:24 ` Jeff Garzik
@ 2006-09-01 13:32 ` Tejun Heo
2006-09-01 17:24 ` Derek Taubert
1 sibling, 1 reply; 16+ messages in thread
From: Tejun Heo @ 2006-09-01 13:32 UTC (permalink / raw)
To: Derek Taubert; +Cc: linux-ide
Derek Taubert wrote:
> On Tue, Aug 29, 2006 at 10:27:26PM +0900, Tejun Heo wrote:
>>>>> 2) hdparm -C for all 4 drives always shows "drive state is: standby"
>>>>> even when I'm certain that the drives are active.
>>>> hdparm -C says the same thing for my drive. I think it's safe to
>>>> ignore. Hmmm... it needs to be tracked down. Maybe some problem in
>>>> HDIO ioctl implementation in libata.
>>> It's a "nice to have" for using smartd. ie: don't spin the drives up to
>>> poll the failure attributes, but they should be checked if the drive's
>>> already active.
>> I don't really understand what you mean. Can you elaborate?
>
> Sure. See the "-n standby" option here:
>
> http://smartmontools.sourceforge.net/man/smartd.conf.5.html
>
> If the driver always reports "standby", then smartd effectively won't
> monitor the device if "-n standby" is configured.
>
> Now I can certainly eliminate the -n option from smartd.conf, but
> then smartd will cause the drive(s) to spin up when it polls (see the
> -p, -u, -t options).
Ah.. I see. I'll try to track down that ioctl problem.
>>>>> I'd really like some assistance debugging the write performance issue.
>>>>> The "hdparm -C" issue would be gravy...
>>>> Please track down the reader.
>>> Before running dd (fuser -v /dev/sda1 shows nothing):
>> [--snip--]
>>
>> Can you try 'dd if=/dev/zero of=/dev/sdX bs=4M count=1'?
>
> Increasing the block size eliminates the reads (presumably because the
> block driver doesn't have to fetch lines to read/modify/write),
That's actually page cache trying to fill the rest of the page.
> but the write throughput is still very slow:
> # dd if=/dev/zero of=/dev/sda1 bs=4M count=512
>
> avg-cpu: %user %nice %sys %iowait %idle
> 0.90 0.00 1.30 97.80 0.00
>
> Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
> sda 15.00 0.00 1920.00 0 19200
Hmm... this really is weird. FYI, you're the first to report such
problem. As Jeff said, turning off write-back caching can have adverse
effect on write performance, but, then again, you previously reported
that the command queue is full. Please update us on the write-back stuff.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive
2006-09-01 13:32 ` Tejun Heo
@ 2006-09-01 17:24 ` Derek Taubert
2006-09-02 5:34 ` Derek Taubert
0 siblings, 1 reply; 16+ messages in thread
From: Derek Taubert @ 2006-09-01 17:24 UTC (permalink / raw)
To: Tejun Heo; +Cc: Derek Taubert, linux-ide
On Fri, Sep 01, 2006 at 10:32:12PM +0900, Tejun Heo wrote:
> ># dd if=/dev/zero of=/dev/sda1 bs=4M count=512
> >
> >avg-cpu: %user %nice %sys %iowait %idle
> > 0.90 0.00 1.30 97.80 0.00
> >
> >Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
> >sda 15.00 0.00 1920.00 0 19200
>
> Hmm... this really is weird. FYI, you're the first to report such
> problem. As Jeff said, turning off write-back caching can have adverse
> effect on write performance, but, then again, you previously reported
> that the command queue is full. Please update us on the write-back stuff.
>From searching the list archive, I gather this is controlled by "hdparm
-W"?
root@linux-srv:~ # hdparm -W 1 /dev/sda1
/dev/sda1:
setting drive write-caching to 1 (on)
root@linux-srv:~ # dd if=/dev/zero of=/dev/sda1 bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 53.8702 seconds, 1.9 MB/s
root@linux-srv:~ # hdparm -W 0 /dev/sda1
/dev/sda1:
setting drive write-caching to 0 (off)
root@linux-srv:~ # dd if=/dev/zero of=/dev/sda1 bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 53.7884 seconds, 1.9 MB/s
I'm going to try narrowing the scope of the test next. Will purchase
an eSATA<->SATA cable today and try bypassing the port multiplier.
If that works, I'll try using one drive at a time on the PMP.
Thanks,
Derek
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive
2006-09-01 17:24 ` Derek Taubert
@ 2006-09-02 5:34 ` Derek Taubert
2006-09-03 6:26 ` Derek Taubert
0 siblings, 1 reply; 16+ messages in thread
From: Derek Taubert @ 2006-09-02 5:34 UTC (permalink / raw)
To: Tejun Heo; +Cc: Derek Taubert, linux-ide
On Fri, Sep 01, 2006 at 10:24:35AM -0700, Derek Taubert wrote:
> I'm going to try narrowing the scope of the test next. Will purchase
> an eSATA<->SATA cable today and try bypassing the port multiplier.
>
> If that works, I'll try using one drive at a time on the PMP.
Well, that didn't change the performance one bit:
ata2: hard resetting port
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: ATA-7, max UDMA/133, 1465149168 sectors: LBA48 NCQ (depth 31/32)
ata2.00: configured for UDMA/100
ata2: EH complete
Vendor: ATA Model: ST3750640AS Rev: 3.AA
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 1465149168 512-byte hdwr sectors (750156 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 1465149168 512-byte hdwr sectors (750156 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1
sd 1:0:0:0: Attached scsi disk sda
sd 1:0:0:0: Attached scsi generic sg0 type 0
root@linux-srv:~ # dd if=/dev/zero of=/dev/sda1 bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 54.1042 seconds, 1.9 MB/s
root@linux-srv:~ # dd of=/dev/zero if=/dev/sda1 bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 20.079 seconds, 52.2 MB/s
I'm now suspecting that the performance problems are due to bus issues
on the PCMCIA/PCI side. Will poke around there and maybe try this with
a different laptop...
Thanks,
Derek
--
VGER BF report: H 5.11438e-07
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive
2006-09-02 5:34 ` Derek Taubert
@ 2006-09-03 6:26 ` Derek Taubert
2006-09-03 19:03 ` Tejun Heo
0 siblings, 1 reply; 16+ messages in thread
From: Derek Taubert @ 2006-09-03 6:26 UTC (permalink / raw)
To: Tejun Heo; +Cc: Derek Taubert, linux-ide
On Fri, Sep 01, 2006 at 10:34:59PM -0700, Derek Taubert wrote:
> I'm now suspecting that the performance problems are due to bus issues
> on the PCMCIA/PCI side. Will poke around there and maybe try this with
> a different laptop...
Found the problem!!!!
The Cache Line Size field in the 3124 PCI Config Space needed to be
set properly. I suspect that this caused the 3124 DMA engine to issue
non-burst reads for all data going toward the disk. Since my old
laptop has two bridges between host memory and the 3124, it surely made
for some long read latencies (and thus very bad throughput).
Before:
root@linux-srv:~ # od -Ax -t x4 /sys/bus/pci/devices/0000:06:00.0/config
000000 31241095 02b00087 01800001 00004000
000010 16008004 00000000 16000004 00000000
000020 00001c01 00000000 00000000 31241095
000030 00000000 00000064 00000000 0000010a
000040 00525407 12c3fff8 00000000 00000000
000050 00000000 00800005 00000000 00000000
000060 00000000 06224001 19002000 00000000
000070 00000000 00000000 00000000 00000000
I copied /sys/bus/pci/devices/0000:06:00.0/config to a temp file, used
bvi to edit it, and then copied it back using dd:
dd if=/tmp/sil24_config of=/sys/bus/pci/devices/0000:06:00.0/config bs=4 skip=3 seek=3 count=1 conv=notrunc
After:
root@linux-srv:~ # od -Ax -t x4 /sys/bus/pci/devices/0000:06:00.0/config
000000 31241095 02b00087 01800001 00004008
000010 16008004 00000000 16000004 00000000
000020 00001c01 00000000 00000000 31241095
000030 00000000 00000064 00000000 0000010a
000040 00525407 12c3fff8 00000000 00000000
000050 00000000 00800005 00000000 00000000
000060 00000000 06224001 19002000 00000000
000070 00000000 00000000 00000000 00000000
root@linux-srv:~ # dd if=/dev/zero of=/dev/sda1 bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 16.7798 seconds, 62.5 MB/s
Phew! I was just about to spend a ridiculous amount of money on ebay for
a logic analyzer...
I'm not sure if this will affect PCI-X configurations, but it is
certainly worth trying.
Derek
--
VGER BF report: H 0.104804
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive
2006-09-03 6:26 ` Derek Taubert
@ 2006-09-03 19:03 ` Tejun Heo
2006-09-03 20:04 ` Derek Taubert
0 siblings, 1 reply; 16+ messages in thread
From: Tejun Heo @ 2006-09-03 19:03 UTC (permalink / raw)
To: Derek Taubert; +Cc: linux-ide
Derek Taubert wrote:
> On Fri, Sep 01, 2006 at 10:34:59PM -0700, Derek Taubert wrote:
>> I'm now suspecting that the performance problems are due to bus issues
>> on the PCMCIA/PCI side. Will poke around there and maybe try this with
>> a different laptop...
>
> Found the problem!!!!
Great.
> The Cache Line Size field in the 3124 PCI Config Space needed to be
> set properly. I suspect that this caused the 3124 DMA engine to issue
> non-burst reads for all data going toward the disk. Since my old
> laptop has two bridges between host memory and the 3124, it surely made
> for some long read latencies (and thus very bad throughput).
>
> Before:
> root@linux-srv:~ # od -Ax -t x4 /sys/bus/pci/devices/0000:06:00.0/config
> 000000 31241095 02b00087 01800001 00004000
> 000010 16008004 00000000 16000004 00000000
> 000020 00001c01 00000000 00000000 31241095
> 000030 00000000 00000064 00000000 0000010a
> 000040 00525407 12c3fff8 00000000 00000000
> 000050 00000000 00800005 00000000 00000000
> 000060 00000000 06224001 19002000 00000000
> 000070 00000000 00000000 00000000 00000000
>
> I copied /sys/bus/pci/devices/0000:06:00.0/config to a temp file, used
> bvi to edit it, and then copied it back using dd:
> dd if=/tmp/sil24_config of=/sys/bus/pci/devices/0000:06:00.0/config bs=4 skip=3 seek=3 count=1 conv=notrunc
>
> After:
> root@linux-srv:~ # od -Ax -t x4 /sys/bus/pci/devices/0000:06:00.0/config
> 000000 31241095 02b00087 01800001 00004008
> 000010 16008004 00000000 16000004 00000000
> 000020 00001c01 00000000 00000000 31241095
> 000030 00000000 00000064 00000000 0000010a
> 000040 00525407 12c3fff8 00000000 00000000
> 000050 00000000 00800005 00000000 00000000
> 000060 00000000 06224001 19002000 00000000
> 000070 00000000 00000000 00000000 00000000
>
> root@linux-srv:~ # dd if=/dev/zero of=/dev/sda1 bs=1M count=1000
> 1000+0 records in
> 1000+0 records out
> 1048576000 bytes (1.0 GB) copied, 16.7798 seconds, 62.5 MB/s
>
> Phew! I was just about to spend a ridiculous amount of money on ebay for
> a logic analyzer...
How much was the price?
> I'm not sure if this will affect PCI-X configurations, but it is
> certainly worth trying.
Can you post full result of "lspci -vvv -xxx"? I'm curious why things
ended up that way.
Thanks.
--
tejun
--
VGER BF report: U 0.5
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive
2006-09-03 19:03 ` Tejun Heo
@ 2006-09-03 20:04 ` Derek Taubert
2006-09-28 22:07 ` Derek Taubert
0 siblings, 1 reply; 16+ messages in thread
From: Derek Taubert @ 2006-09-03 20:04 UTC (permalink / raw)
To: Tejun Heo; +Cc: Derek Taubert, linux-ide
On Sun, Sep 03, 2006 at 09:03:22PM +0200, Tejun Heo wrote:
> >Phew! I was just about to spend a ridiculous amount of money on ebay for
> >a logic analyzer...
>
> How much was the price?
In the $500 range for a 16500A with the right cards, software, and pods.
Either that, or I was thinking of giving the Intronix Logicport a shot.
Would be handy for lots of "projects" (if only it had Linux support).
Only ridiculous compared to how cheap I'm being with the system that
would be under test...
> >I'm not sure if this will affect PCI-X configurations, but it is
> >certainly worth trying.
>
> Can you post full result of "lspci -vvv -xxx"? I'm curious why things
> ended up that way.
Below. This output shows the modified cache line config for the 3124,
btw.
Derek
0000:00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 64
Region 0: Memory at e0000000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 1.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x2
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>
00: 86 80 90 71 06 01 10 22 03 00 00 06 00 40 00 00
10: 08 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 0c 82 00 fe 00 00 00 09 03 10 11 01 00 00 30 11
60: 08 08 10 10 10 10 10 10 00 02 40 21 00 80 00 00
70: 20 1f 0a 38 11 00 04 01 26 05 9c 00 10 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 04 61 00 00 00 05 00 00 00 00 00 00
a0: 02 00 10 00 02 02 00 1f 00 00 00 00 00 00 00 00
b0: 80 20 00 00 30 00 00 00 00 00 7f 06 20 10 00 00
c0: 00 00 00 00 00 00 00 00 18 0c ff ff 61 00 00 00
d0: 00 00 00 00 00 00 00 00 0c 00 00 00 00 00 00 00
e0: 4c ad ff bb 8a 3e 00 80 2c d3 f7 cf 9d 3e 00 00
f0: 40 01 00 00 00 f8 00 60 20 0f 00 00 00 00 00 00
0000:00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: 00002000-00002fff
Memory behind bridge: fc100000-fdffffff
Prefetchable memory behind bridge: 18000000-180fffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B+
00: 86 80 91 71 1f 00 20 02 03 00 04 06 00 80 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 40 20 20 a0 22
20: 10 fc f0 fd 00 18 00 18 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8c 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000:00:04.0 CardBus bridge: Texas Instruments PCI1420
Subsystem: Toshiba America Info Systems: Unknown device ff00
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 168, cache line size 20
Interrupt: pin A routed to IRQ 10
Region 0: Memory at 18100000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
Memory window 0: 10000000-11fff000 (prefetchable)
Memory window 1: 12000000-13fff000
I/O window 0: 00001400-000014ff
I/O window 1: 00001800-000018ff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt- PostWrite+
16-bit legacy interface ports at 0001
00: 4c 10 51 ac 07 00 10 02 00 00 07 06 20 a8 82 00
10: 00 00 10 18 a0 00 00 22 00 02 05 b0 00 00 00 10
20: 00 f0 ff 11 00 00 00 12 00 f0 ff 13 00 14 00 00
30: fc 14 00 00 00 18 00 00 fc 18 00 00 ff 01 00 05
40: 79 11 00 ff 01 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 61 f0 c4 00 00 00 00 00 00 00 00 00 22 17 0c 00
90: e0 03 66 60 00 00 00 00 00 00 00 00 00 00 00 00
a0: 01 00 42 fe 00 80 c0 00 03 08 00 00 1f 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000:00:04.1 CardBus bridge: Texas Instruments PCI1420
Subsystem: Toshiba America Info Systems: Unknown device ff00
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 168, cache line size 20
Interrupt: pin B routed to IRQ 10
Region 0: Memory at 18101000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=06, subordinate=09, sec-latency=176
Memory window 0: 14000000-15fff000 (prefetchable)
Memory window 1: 16000000-17fff000
I/O window 0: 00001c00-00001cff
I/O window 1: 00003000-000030ff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt- PostWrite+
16-bit legacy interface ports at 0001
00: 4c 10 51 ac 07 00 10 02 00 00 07 06 20 a8 82 00
10: 00 10 10 18 a0 00 00 22 00 06 09 b0 00 00 00 14
20: 00 f0 ff 15 00 00 00 16 00 f0 ff 17 00 1c 00 00
30: fc 1c 00 00 00 30 00 00 fc 30 00 00 ff 02 00 05
40: 79 11 00 ff 01 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 61 f0 c4 00 00 00 00 00 00 00 00 00 22 17 0c 00
90: e0 03 66 60 00 00 00 00 00 00 00 00 00 00 00 00
a0: 01 00 42 fe 00 80 c0 00 03 08 00 00 1f 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000:00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
00: 86 80 10 71 0f 00 80 02 02 00 80 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 4d 00 f3 04
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 0a 0a 05 0a d0 00 00 00 00 f2 00 00 00 00 00 00
70: 00 00 00 00 00 00 0c 0c 00 00 00 00 00 00 00 00
80: 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 06 00 01 70 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 25 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 30 0f 00 00 00 00 00 00
0000:00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64
Region 4: I/O ports at 1050 [size=16]
00: 86 80 11 71 05 00 80 02 01 80 01 01 00 40 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 51 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 07 a3 07 a3 00 00 00 00 05 00 02 02 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 30 0f 00 00 00 00 00 00
0000:00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64
Interrupt: pin D routed to IRQ 10
Region 4: I/O ports at 1060 [size=32]
00: 86 80 12 71 05 00 80 02 01 00 03 0c 00 40 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 61 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 04 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 30 0f 00 00 00 00 00 00
0000:00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin ? routed to IRQ 9
00: 86 80 13 71 03 00 80 02 03 00 80 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 01 10 00 00 0f ff bf 1f c1 7f 00 00 00 00 00 00
50: 00 50 1c 00 f5 41 00 00 37 80 00 02 08 00 00 82
60: 00 00 10 62 00 fe 21 08 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 70 03 01 00
80: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 41 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 30 0f 00 00 00 00 00 00
0000:00:08.0 Multimedia audio controller: Cirrus Logic Crystal CS4281 PCI Audio (rev 01)
Subsystem: Toshiba America Info Systems: Unknown device ff00
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (1000ns min, 6000ns max)
Interrupt: pin A routed to IRQ 5
Region 0: Memory at fc010000 (32-bit, non-prefetchable) [size=4K]
Region 1: Memory at fc000000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 13 10 05 60 06 00 10 02 01 00 01 04 00 40 00 00
10: 00 00 01 fc 00 00 00 fc 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 00 ff
30: 00 00 00 00 40 00 00 00 00 00 00 00 05 01 04 18
40: 01 00 22 7e 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 81 42 00 00 00 00 00 00 04 00 00 00 05 00 00 00
f0: 01 00 00 00 00 00 00 00 00 00 00 00 79 11 00 ff
0000:00:10.0 Communication controller: Rockwell International HSF 56k Data/Fax Modem (rev 01)
Subsystem: Toshiba America Info Systems Modem
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 10
Region 0: Memory at fc020000 (32-bit, non-prefetchable) [disabled] [size=64K]
Region 1: I/O ports at 1080 [disabled] [size=8]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
00: 7a 12 13 20 00 00 90 02 01 00 80 07 00 40 00 00
10: 00 00 02 fc 81 10 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 00 ff
30: 00 00 00 00 40 00 00 00 00 00 00 00 0a 01 00 00
40: 01 00 32 c8 00 01 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000:01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage LT Pro AGP-133 (rev dc) (prog-if 00 [VGA])
Subsystem: Toshiba America Info Systems: Unknown device ff00
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 66 (2000ns min), cache line size 08
Interrupt: pin A routed to IRQ 10
Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
Region 1: I/O ports at 2000 [size=256]
Region 2: Memory at fc100000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at 18000000 [disabled] [size=128K]
Capabilities: [50] AGP version 1.0
Status: RQ=256 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>
Capabilities: [5c] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 02 10 42 4c 87 00 90 02 dc 00 00 03 08 42 00 00
10: 00 00 00 fd 01 20 00 00 00 00 10 fc 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 79 11 00 ff
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 08 00
40: 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 02 5c 10 00 03 02 00 ff 00 00 00 00 01 00 01 06
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000:02:00.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
Subsystem: Abocom Systems Inc EtherFast 10/100 Cardbus (PCMPC200)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (5000ns min, 10000ns max)
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at 1400 [size=128]
Region 1: Memory at 12000000 (32-bit, non-prefetchable) [size=1K]
Expansion ROM at 10000000 [disabled] [size=256K]
00: 11 10 19 00 07 00 80 02 41 00 00 02 00 40 00 00
10: 01 14 00 00 00 00 00 12 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 82 02 00 00 d1 13 01 ab
30: 00 00 0c 20 00 00 00 00 00 00 00 00 0a 01 14 28
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000:06:00.0 Unknown mass storage controller: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3124 PCI-X Serial ATA Controller (rev 01)
Subsystem: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3124 PCI-X Serial ATA Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64, cache line size 08
Interrupt: pin A routed to IRQ 10
Region 0: Memory at 16008000 (64-bit, non-prefetchable) [size=128]
Region 2: Memory at 16000000 (64-bit, non-prefetchable) [size=32K]
Region 4: I/O ports at 1c00 [size=16]
Expansion ROM at 14000000 [disabled] [size=512K]
Capabilities: [64] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [40] PCI-X non-bridge device.
Command: DPERE- ERO+ RBC=0 OST=5
Status: Bus=255 Dev=31 Func=0 64bit+ 133MHz+ SCD- USC-, DC=simple, DMMRBC=2, DMOST=5, DMCRS=4, RSCEM- Capabilities: [54] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
00: 95 10 24 31 87 00 b0 02 01 00 80 01 08 40 00 00
10: 04 80 00 16 00 00 00 00 04 00 00 16 00 00 00 00
20: 01 1c 00 00 00 00 00 00 00 00 00 00 95 10 24 31
30: 00 00 00 00 64 00 00 00 00 00 00 00 0a 01 00 00
40: 07 54 52 00 f8 ff c3 12 00 00 00 00 00 00 00 00
50: 00 00 00 00 05 00 80 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 01 40 22 06 00 20 00 19 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
--
VGER BF report: U 0.500908
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive
2006-09-03 20:04 ` Derek Taubert
@ 2006-09-28 22:07 ` Derek Taubert
0 siblings, 0 replies; 16+ messages in thread
From: Derek Taubert @ 2006-09-28 22:07 UTC (permalink / raw)
To: Tejun Heo; +Cc: Derek Taubert, linux-ide
> > >I'm not sure if this will affect PCI-X configurations, but it is
> > >certainly worth trying.
> >
> > Can you post full result of "lspci -vvv -xxx"? I'm curious why things
> > ended up that way.
>
> Below. This output shows the modified cache line config for the 3124,
> btw.
FWIW, I got ahold of a system with the same host bridge but with a 3124
on the primary PCI bus, and the cache line size was properly configured.
Something to do with the cardbus bridge, perhaps...
Derek
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2006-09-28 22:07 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-08-28 23:01 Bad write performance with libata-tj-stable-2.6.17.4-20060710, pcmcia based sata_sil24, PMP, and NCQ drive Derek Taubert
2006-08-29 2:39 ` Tejun Heo
2006-08-29 4:58 ` Derek Taubert
2006-08-29 7:54 ` Derek Taubert
2006-08-29 13:35 ` Tejun Heo
2006-08-29 13:27 ` Tejun Heo
2006-08-29 16:44 ` Derek Taubert
2006-08-29 21:24 ` Jeff Garzik
2006-09-01 13:32 ` Tejun Heo
2006-09-01 17:24 ` Derek Taubert
2006-09-02 5:34 ` Derek Taubert
2006-09-03 6:26 ` Derek Taubert
2006-09-03 19:03 ` Tejun Heo
2006-09-03 20:04 ` Derek Taubert
2006-09-28 22:07 ` Derek Taubert
2006-08-29 14:07 ` Greg Freemyer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).