2006-12-20 13:39:06

by Rene Herman

[permalink] [raw]
Subject: PATA -- pata_amd on 2.6.19 fails to IDENTIFY my DVD-ROM

Good day.

I just tried the PATA driver for my AMD756 chip. During boot, it hangs
for 3 minutes failing to identify my DVD-ROM (secondary slave) and does
not give me access to it after it timed out.

Situation is AMD756 (a UDMA66 chipset), both channels 80w cables:

1. Primary Master : UDMA133 disk, works fine
2. Primary Slave : Empty
3. Secondary Master : Plextor Premium CD-RW (UDMA33), works fine
4. Secondary Slave : Plextor PX-116A DVD-ROM (UDMA66), does not

All are using cable select and work fine with the old IDE driver and
also with an earlier version of the PATA code; I used 2.6.17-rc4-ide1
(which I see is still the latest standalone patch) without problems before.

The 2.6.17-rc4-ide pata_amd version was 0.1.7 and current is 0.2.4. Did
try a quick diff between them, but it seems the difference is mostly
infrastructural, so the problem is probably further on up.

Excerpt from boot-log (this takes 3 minutes):

===
pata_amd 0000:00:07.1: version 0.2.4
ata1: PATA max UDMA/66 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
ata2: PATA max UDMA/66 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
scsi0 : pata_amd
ata1.00: ATA-7, max UDMA/133, 240121728 sectors: LBA
ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/66
scsi1 : pata_amd
ata2.00: ATAPI, max UDMA/33
ata2.01: qc timeout (cmd 0xa1)
ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: failed to recover some devices, retrying in 5 secs
ata2: port is slow to respond, please be patient (Status 0xd8)
ata2: port failed to respond (30 secs, Status 0xd8)
ata2.01: qc timeout (cmd 0xa1)
ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: failed to recover some devices, retrying in 5 secs
ata2: port is slow to respond, please be patient (Status 0xd8)
ata2: port failed to respond (30 secs, Status 0xd8)
ata2.01: qc timeout (cmd 0xa1)
ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: failed to recover some devices, retrying in 5 secs
ata2: port is slow to respond, please be patient (Status 0xd8)
ata2: port failed to respond (30 secs, Status 0xd8)
ata2.00: configured for UDMA/33
scsi 0:0:0:0: Direct-Access ATA Maxtor 6Y120P0 YAR4 PQ: 0 ANSI: 5
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1 < sda5 sda6 sda7 sda8 > sda2 sda3 sda4
sda2: <minix: sda9 sda10 >
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0
scsi 1:0:0:0: CD-ROM PLEXTOR CD-R PREMIUM 1.07 PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 1:0:0:0: Attached scsi CD-ROM sr0
sr 1:0:0:0: Attached scsi generic sg1 type 5
===

By the way -- PATA interfaces (ata1, ata2) start counting at 1 while
their devices (.00, .01) start counting at 0 which sort of sucks. While
looking at "ata2.01" during boot (with the rest scrolled away) I thought
I was looking at secondary master initially. If they can still be named
ata0 and ata1, I'd consider that better.

Anyways, as said, all worked fine on 2.6.17-rc4-ide1 including I believe
with secondary master tuned to UDMA33 and slave to UDMA66 according to
their device capabilities.

Happy to provide more or other information if needed.

Rene.


2006-12-27 07:19:32

by Tejun Heo

[permalink] [raw]
Subject: Re: PATA -- pata_amd on 2.6.19 fails to IDENTIFY my DVD-ROM

Rene Herman wrote:
> Good day.
>
> I just tried the PATA driver for my AMD756 chip. During boot, it hangs
> for 3 minutes failing to identify my DVD-ROM (secondary slave) and does
> not give me access to it after it timed out.

Please give a shot at v2.6.20-rc2 and report what the kernel says.

Thanks.

--
tejun

2006-12-27 17:51:41

by Rene Herman

[permalink] [raw]
Subject: Re: PATA -- pata_amd on 2.6.19 fails to IDENTIFY my DVD-ROM

Tejun Heo wrote:

> Rene Herman wrote:

>> I just tried the PATA driver for my AMD756 chip. During boot, it hangs
>> for 3 minutes failing to identify my DVD-ROM (secondary slave) and does
>> not give me access to it after it timed out.
>
> Please give a shot at v2.6.20-rc2 and report what the kernel says.

This IDENTIFY issue seems already fixed in -rc2. No more pause, and my
DVD-ROM works fine again. Unfortunately, another issue seems to have
cropped up. On 2.6.20-rc2, hdparm -t /dev/sda gets me ~ 24 M/s while
both the old IDE driver and the 2.6.19 PATA driver do ~ 50 M/s

2.6.20-rc2-ata:

# hdparm -t /dev/sda

/dev/sda:
Timing buffered disk reads: 72 MB in 3.03 seconds = 23.75 MB/sec

2.6.19-ata:

# hdparm -t /dev/sda

/dev/sda:
Timing buffered disk reads: 150 MB in 3.00 seconds = 49.94 MB/sec

Here's the ata part of the 2.6.20-rc2 dmesg:

===
ata1: PATA max UDMA/66 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
ata2: PATA max UDMA/66 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
scsi0 : pata_amd
ata1.00: ATA-7, max UDMA/133, 240121728 sectors: LBA
ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/66
scsi1 : pata_amd
ata2.00: ATAPI, max UDMA/33
ata2.01: ATAPI, max UDMA/66
ata2.00: configured for UDMA/33
ata2.01: configured for UDMA/66
scsi 0:0:0:0: Direct-Access ATA Maxtor 6Y120P0 YAR4 PQ: 0 ANSI: 5
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sda: sda1 < sda5 sda6 sda7 sda8 > sda2 sda3 sda4
sda2: <minix: sda9 sda10 >
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0
scsi 1:0:0:0: CD-ROM PLEXTOR CD-R PREMIUM 1.07 PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 1:0:0:0: Attached scsi CD-ROM sr0
sr 1:0:0:0: Attached scsi generic sg1 type 5
scsi 1:0:1:0: CD-ROM PLEXTOR DVD-ROM PX-116A 1.00 PQ: 0 ANSI: 5
sr1: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray
sr 1:0:1:0: Attached scsi CD-ROM sr1
sr 1:0:1:0: Attached scsi generic sg2 type 5
===

There's some difference with respect to caching versus 2.6.19 it seems?
The same bit for 2.6.19:

===
pata_amd 0000:00:07.1: version 0.2.4
ata1: PATA max UDMA/66 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
ata2: PATA max UDMA/66 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
scsi0 : pata_amd
ata1.00: ATA-7, max UDMA/133, 240121728 sectors: LBA
ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/66
scsi1 : pata_amd
ata2.00: ATAPI, max UDMA/33
ata2.01: qc timeout (cmd 0xa1)
ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: failed to recover some devices, retrying in 5 secs
ata2: port is slow to respond, please be patient (Status 0xd8)
ata2: port failed to respond (30 secs, Status 0xd8)
ata2.01: qc timeout (cmd 0xa1)
ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: failed to recover some devices, retrying in 5 secs
ata2: port is slow to respond, please be patient (Status 0xd8)
ata2: port failed to respond (30 secs, Status 0xd8)
ata2.01: qc timeout (cmd 0xa1)
ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: failed to recover some devices, retrying in 5 secs
ata2: port is slow to respond, please be patient (Status 0xd8)
ata2: port failed to respond (30 secs, Status 0xd8)
ata2.00: configured for UDMA/33
scsi 0:0:0:0: Direct-Access ATA Maxtor 6Y120P0 YAR4 PQ: 0 ANSI: 5
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 240121728 512-byte hdwr sectors (122942 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1 < sda5 sda6 sda7 sda8 > sda2 sda3 sda4
sda2: <minix: sda9 sda10 >
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0
scsi 1:0:0:0: CD-ROM PLEXTOR CD-R PREMIUM 1.07 PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 1:0:0:0: Attached scsi CD-ROM sr0
sr 1:0:0:0: Attached scsi generic sg1 type 5
===

Rene.

2006-12-28 02:25:06

by Tejun Heo

[permalink] [raw]
Subject: Re: PATA -- pata_amd on 2.6.19 fails to IDENTIFY my DVD-ROM

Rene Herman wrote:
> Tejun Heo wrote:
>
>> Rene Herman wrote:
>
>>> I just tried the PATA driver for my AMD756 chip. During boot, it hangs
>>> for 3 minutes failing to identify my DVD-ROM (secondary slave) and does
>>> not give me access to it after it timed out.
>>
>> Please give a shot at v2.6.20-rc2 and report what the kernel says.
>
> This IDENTIFY issue seems already fixed in -rc2. No more pause, and my
> DVD-ROM works fine again.

Great.

> Unfortunately, another issue seems to have
> cropped up. On 2.6.20-rc2, hdparm -t /dev/sda gets me ~ 24 M/s while
> both the old IDE driver and the 2.6.19 PATA driver do ~ 50 M/s
>
> 2.6.20-rc2-ata:
>
> # hdparm -t /dev/sda
>
> /dev/sda:
> Timing buffered disk reads: 72 MB in 3.03 seconds = 23.75 MB/sec
>
> 2.6.19-ata:
>
> # hdparm -t /dev/sda
>
> /dev/sda:
> Timing buffered disk reads: 150 MB in 3.00 seconds = 49.94 MB/sec

Everything seems fine in the dmesg. Performance degradation is probably
some other issue in -rc kernel. I'm suspecting recently fixed block
layer bug. If it's still the same in the next -rc, please report.

Thanks.

--
tejun

2007-01-01 22:48:33

by Rene Herman

[permalink] [raw]
Subject: 2.6.20-rc2+: CFQ halving disk throughput.

Linux version 2.6.20-rc3-local (rene@7ixe4) (gcc version 4.1.1) #15 PREEMPT Mon Jan 1 23:12:31 CET 2007
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start: 0000000000000000 size: 000000000009fc00 end: 000000000009fc00 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000000009fc00 size: 0000000000000400 end: 00000000000a0000 type: 2
copy_e820_map() start: 00000000000f0000 size: 0000000000010000 end: 0000000000100000 type: 2
copy_e820_map() start: 0000000000100000 size: 000000002fef0000 end: 000000002fff0000 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000002fff0000 size: 0000000000008000 end: 000000002fff8000 type: 3
copy_e820_map() start: 000000002fff8000 size: 0000000000008000 end: 0000000030000000 type: 4
copy_e820_map() start: 00000000ffff0000 size: 0000000000010000 end: 0000000100000000 type: 2
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000002fff0000 (usable)
BIOS-e820: 000000002fff0000 - 000000002fff8000 (ACPI data)
BIOS-e820: 000000002fff8000 - 0000000030000000 (ACPI NVS)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
767MB LOWMEM available.
Entering add_active_range(0, 0, 196592) 0 entries of 256 used
Zone PFN ranges:
DMA 0 -> 4096
Normal 4096 -> 196592
early_node_map[1] active PFN ranges
0: 0 -> 196592
On node 0 totalpages: 196592
DMA zone: 32 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 4064 pages, LIFO batch:0
Normal zone: 1503 pages used for memmap
Normal zone: 190993 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP (v000 AMI ) @ 0x000fabb0
ACPI: RSDT (v001 AMIINT 0x00000010 MSFT 0x00000097) @ 0x2fff0000
ACPI: FADT (v001 AMIINT 0x00000011 MSFT 0x00000097) @ 0x2fff0030
ACPI: DSDT (v001 AMD75X IRONGATE 0x00001000 MSFT 0x0100000b) @ 0x00000000
ACPI: PM-Timer IO Port: 0x5008
Allocating PCI resources starting at 40000000 (gap: 30000000:cfff0000)
Detected 1312.969 MHz processor.
Built 1 zonelists. Total pages: 195057
Kernel command line: auto BOOT_IMAGE=rc ro root=306 reboot=w
Enabling fast FPU save and restore... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c039e000 soft=c039d000
PID hash table entries: 4096 (order: 12, 16384 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 776036k/786368k available (1673k kernel code, 9792k reserved, 833k data, 144k init, 0k highmem)
virtual kernel memory layout:
fixmap : 0xffff8000 - 0xfffff000 ( 28 kB)
vmalloc : 0xf0800000 - 0xffff6000 ( 247 MB)
lowmem : 0xc0000000 - 0xefff0000 ( 767 MB)
.init : 0xc0374000 - 0xc0398000 ( 144 kB)
.data : 0xc02a2449 - 0xc0372a4c ( 833 kB)
.text : 0xc0100000 - 0xc02a2449 (1673 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 2627.56 BogoMIPS (lpj=1313783)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0183f9ff c1c3f9ff 00000000 00000000 00000000 00000000 00000000
Enabling disabled K7/SSE Support.
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 64K (64 bytes/line)
CPU: After all inits, caps: 0383f9ff c1c3f9ff 00000000 00000420 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Duron(tm) Processor stepping 01
Checking 'hlt' instruction... OK.
ACPI: Core revision 20060707
ACPI: setting ELCR to 0800 (from 1c08)
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfdb71, last bus=1
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
Boot video device is 0000:01:05.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: Power Resource [URP1] (off)
ACPI: Power Resource [URP2] (off)
ACPI: Power Resource [FDDP] (off)
ACPI: Power Resource [LPTP] (off)
ACPI: PCI Interrupt Link [LNKA] (IRQs *3 4 5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 11 *12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: ACPI device : hid PNP0A03
pnp: ACPI device : hid PNP0C02
pnp: ACPI device : hid PNP0200
pnp: ACPI device : hid PNP0B00
pnp: ACPI device : hid PNP0800
pnp: ACPI device : hid PNP0C04
pnp: ACPI device : hid PNP0303
pnp: ACPI device : hid PNP0700
pnp: ACPI device : hid PNP0501
pnp: ACPI device : hid PNP0401
pnp: PnP ACPI: found 10 devices
SCSI subsystem initialized
libata version 2.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
pnp: the driver 'system' has been registered
pnp: match found with the PnP device '00:01' and the driver 'system'
pnp: 00:01: ioport range 0xde00-0xde03 has been reserved
PCI: Bridge: 0000:00:01.0
IO window: b000-bfff
MEM window: eee00000-efefffff
PREFETCH window: e2c00000-e6cfffff
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 7, 524288 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
Machine check exception polling timer started.
io scheduler noop registered
io scheduler cfq registered (default)
input: Power Button (FF) as /class/input/input0
ACPI: Power Button (FF) [PWRF]
input: Sleep Button (FF) as /class/input/input1
ACPI: Sleep Button (FF) [SLPF]
input: Power Button (CM) as /class/input/input2
ACPI: Power Button (CM) [PWRB]
ACPI: Thermal Zone [THRM] (30 C)
isapnp: Scanning for PnP cards...
isapnp: checksum for device 2 is not valid (0x52)
isapnp: Card 'AudioSystem EWS64'
isapnp: Card 'TerraTec ActiveRadio'
isapnp: 2 Plug & Play cards detected total
Real Time Clock Driver v1.12ac
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected AMD Irongate chipset
agpgart: AGP aperture is 64M @ 0xe8000000
[drm] Initialized drm 1.1.0 20060810
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:01:05.0[A] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
[drm] Initialized mga 3.2.1 20051102 on minor 0
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10
3c59x: Donald Becker and others. http://www.scyld.com/network/vortex.html
0000:00:0a.0: 3Com PCI 3c905C Tornado at f0838f80.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
AMD7409: IDE controller at PCI slot 0000:00:07.1
AMD7409: chipset revision 7
AMD7409: not 100% native mode: will probe irqs later
AMD7409: 0000:00:07.1 (rev 07) UDMA66 controller
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
hda: Maxtor 6Y120P0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: PLEXTOR CD-R PREMIUM, ATAPI CD/DVD-ROM drive
hdd: PLEXTOR DVD-ROM PX-116A, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 240121728 sectors (122942 MB) w/7936KiB Cache, CHS=65535/16/63, UDMA(66)
hda: cache flushes supported
hda: hda1 < hda5 hda6 hda7 hda8 > hda2 hda3 hda4
hda2: <minix: hda9 hda10 >
hdc: ATAPI 40X CD-ROM CD-R/RW drive, 8192kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hdd: ATAPI 48X DVD-ROM drive, 256kB Cache, UDMA(66)
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
uhci_hcd 0000:00:09.0: UHCI Host Controller
uhci_hcd 0000:00:09.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:09.0: irq 11, io base 0x0000da00
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:09.1[B] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10
uhci_hcd 0000:00:09.1: UHCI Host Controller
uhci_hcd 0000:00:09.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:09.1: irq 10, io base 0x0000dc00
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usb 1-1: new full speed USB device using uhci_hcd and address 2
usb 1-1: configuration #1 chosen from 1 choice
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
usb 1-1.4: new low speed USB device using uhci_hcd and address 3
usb 1-1.4: configuration #1 chosen from 1 choice
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
input: Logitech N48 as /class/input/input3
input: USB HID v1.00 Mouse [Logitech N48] on usb-0000:00:09.0-1.4
usbcore: registered new interface driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
pnp: the driver 'i8042 kbd' has been registered
pnp: match found with the PnP device '00:06' and the driver 'i8042 kbd'
pnp: the driver 'i8042 aux' has been registered
PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
PNP: PS/2 controller doesn't have AUX irq; using default 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
input: PC Speaker as /class/input/input4
input: AT Translated Set 2 keyboard as /class/input/input5
i2c /dev entries driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI Shortcut mode
ACPI: (supports S0 S1 S4 S5)
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Time: tsc clocksource has been installed.
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 144k freed
Adding 1048568k swap on /dev/hda5. Priority:-1 extents:1 across:1048568k
EXT3 FS on hda6, internal journal
kjournald starting. Commit interval 5 seconds
EXT3 FS on hda7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on hda8, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
eth0: setting full-duplex.
Installing knfsd (copyright (C) 1996 [email protected]).
agpgart: Found an AGP 1.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 2x mode
agpgart: Putting AGP V2 device at 0000:01:05.0 into 2x mode
[drm] Initialized card for AGP DMA.

Attachments:
config-2.6.20-rc3 (42.64 kB)
 dmesg-2.6.20-rc3 (11.17 kB)
 Download all attachments

2007-01-01 22:57:46

by Rene Herman

[permalink] [raw]
Subject: Re: 2.6.20-rc2+: CFQ halving disk throughput.

Rene Herman wrote:

> In fact, it's CFQ. The PATA thing was a red herring. 2.6.20-rc2 and 3
> give me ~ 24 MB/s from "hdparm t /dev/hda" while 2.6.20-rc1 and below
> give me ~ 50 MB/s.
>
> Jens: this is due to "[PATCH] cfq-iosched: tighten allow merge
> criteria", 719d34027e1a186e46a3952e8a24bf91ecc33837:

[email protected] bounces for me. Could one of the other recipients of
parent message try to forward?

Rene.

2007-01-01 23:31:07

by Linus Torvalds

[permalink] [raw]
Subject: Re: 2.6.20-rc2+: CFQ halving disk throughput.



On Mon, 1 Jan 2007, Rene Herman wrote:

> Rene Herman wrote:
>
> > In fact, it's CFQ. The PATA thing was a red herring. 2.6.20-rc2 and 3 give
> > me ~ 24 MB/s from "hdparm t /dev/hda" while 2.6.20-rc1 and below give me ~
> > 50 MB/s.
> >
> > Jens: this is due to "[PATCH] cfq-iosched: tighten allow merge criteria",
> > 719d34027e1a186e46a3952e8a24bf91ecc33837:
>
> [email protected] bounces for me. Could one of the other recipients of parent
> message try to forward?

It should be "Jens Axboe <[email protected]>".

Jens was away over the holidays, hopefully he'll be back today or
tomorrow.

Linus

2007-01-01 23:53:09

by Mark Lord

[permalink] [raw]
Subject: Re: 2.6.20-rc2+: CFQ halving disk throughput.

Rene Herman wrote:
> Tejun Heo wrote:
>
>> Everything seems fine in the dmesg. Performance degradation is
>> probably some other issue in -rc kernel. I'm suspecting recently
>> fixed block layer bug. If it's still the same in the next -rc,
>> please report.
>
> In fact, it's CFQ. The PATA thing was a red herring. 2.6.20-rc2 and 3
> give me ~ 24 MB/s from "hdparm t /dev/hda" while 2.6.20-rc1 and below
> give me ~ 50 MB/s.
>
> Jens: this is due to "[PATCH] cfq-iosched: tighten allow merge
> criteria", 719d34027e1a186e46a3952e8a24bf91ecc33837:
>
> http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=719d34027e1a186e46a3952e8a24bf91ecc33837
>
>
> If I revert that one, I have my 50 M/s back. config and dmesg attached
> in case they're useful.

Wow.. same deal here -- sequential throughput drops from 40MB/sec to 28MB/sec
with CFQ -- whereas the anticipatory scheduler maintains the 40MB/sec.

Jens.. I wonder if the new merging test is a bit too strict?

There are four possible combinations, and the new code
allows merging for two of them: sync+sync and async+async.

But surely one of (not sure which) sync+async or async+sync may also be okay?
Or would it?

This is a huge performance hit.

Cheers

2007-01-02 05:36:12

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.20-rc2+: CFQ halving disk throughput.

On Mon, 01 Jan 2007 23:46:58 +0100
Rene Herman <[email protected]> wrote:

> > Everything seems fine in the dmesg. Performance degradation is
> > probably some other issue in -rc kernel. I'm suspecting recently
> > fixed block layer bug. If it's still the same in the next -rc,
> > please report.
>
> In fact, it's CFQ. The PATA thing was a red herring. 2.6.20-rc2 and 3
> give me ~ 24 MB/s from "hdparm t /dev/hda" while 2.6.20-rc1 and below
> give me ~ 50 MB/s.
>
> Jens: this is due to "[PATCH] cfq-iosched: tighten allow merge
> criteria", 719d34027e1a186e46a3952e8a24bf91ecc33837:
>
> http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=719d34027e1a186e46a3952e8a24bf91ecc33837
>
> If I revert that one, I have my 50 M/s back. config and dmesg attached
> in case they're useful.

The patch would appear to need this fix:

--- a/block/cfq-iosched.c~a
+++ a/block/cfq-iosched.c
@@ -592,7 +592,7 @@ static int cfq_allow_merge(request_queue
if (cfqq == RQ_CFQQ(rq))
return 1;

- return 1;
+ return 0;
}

static inline void
_

But that might not fix things...

2007-01-02 08:34:18

by Jens Axboe

[permalink] [raw]
Subject: Re: 2.6.20-rc2+: CFQ halving disk throughput.

On Mon, Jan 01 2007, Mark Lord wrote:
> Rene Herman wrote:
> >Tejun Heo wrote:
> >
> >>Everything seems fine in the dmesg. Performance degradation is
> >>probably some other issue in -rc kernel. I'm suspecting recently
> >>fixed block layer bug. If it's still the same in the next -rc,
> >>please report.
> >
> >In fact, it's CFQ. The PATA thing was a red herring. 2.6.20-rc2 and 3
> >give me ~ 24 MB/s from "hdparm t /dev/hda" while 2.6.20-rc1 and below
> >give me ~ 50 MB/s.
> >
> >Jens: this is due to "[PATCH] cfq-iosched: tighten allow merge
> >criteria", 719d34027e1a186e46a3952e8a24bf91ecc33837:
> >
> >http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=719d34027e1a186e46a3952e8a24bf91ecc33837
> >
> >
> >If I revert that one, I have my 50 M/s back. config and dmesg attached
> >in case they're useful.
>
> Wow.. same deal here -- sequential throughput drops from 40MB/sec to
> 28MB/sec
> with CFQ -- whereas the anticipatory scheduler maintains the 40MB/sec.
>
> Jens.. I wonder if the new merging test is a bit too strict?
>
> There are four possible combinations, and the new code
> allows merging for two of them: sync+sync and async+async.
>
> But surely one of (not sure which) sync+async or async+sync may also be
> okay?
> Or would it?

Async merge to sync request should be ok. But I wonder what happens with
hdparm, since it seems to trigger one of these tests. Very puzzling.
I'll dive in and take a look.

> This is a huge performance hit.

Indeed, not acceptable of course. And not intentional :-)

--
Jens Axboe

2007-01-02 08:44:51

by Jens Axboe

[permalink] [raw]
Subject: Re: 2.6.20-rc2+: CFQ halving disk throughput.

On Mon, Jan 01 2007, Andrew Morton wrote:
> On Mon, 01 Jan 2007 23:46:58 +0100
> Rene Herman <[email protected]> wrote:
>
> > > Everything seems fine in the dmesg. Performance degradation is
> > > probably some other issue in -rc kernel. I'm suspecting recently
> > > fixed block layer bug. If it's still the same in the next -rc,
> > > please report.
> >
> > In fact, it's CFQ. The PATA thing was a red herring. 2.6.20-rc2 and 3
> > give me ~ 24 MB/s from "hdparm t /dev/hda" while 2.6.20-rc1 and below
> > give me ~ 50 MB/s.
> >
> > Jens: this is due to "[PATCH] cfq-iosched: tighten allow merge
> > criteria", 719d34027e1a186e46a3952e8a24bf91ecc33837:
> >
> > http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=719d34027e1a186e46a3952e8a24bf91ecc33837
> >
> > If I revert that one, I have my 50 M/s back. config and dmesg attached
> > in case they're useful.
>
> The patch would appear to need this fix:
>
> --- a/block/cfq-iosched.c~a
> +++ a/block/cfq-iosched.c
> @@ -592,7 +592,7 @@ static int cfq_allow_merge(request_queue
> if (cfqq == RQ_CFQQ(rq))
> return 1;
>
> - return 1;
> + return 0;
> }
>
> static inline void
> _
>
> But that might not fix things...

Yeah it is, but I don't think it'll fix it (if anything, it'll be more
conservative).

--
Jens Axboe

2007-01-02 10:26:13

by Rene Herman

[permalink] [raw]
Subject: Re: 2.6.20-rc2+: CFQ halving disk throughput.

Jens Axboe wrote:

> On Mon, Jan 01 2007, Andrew Morton wrote:

>> The patch would appear to need this fix:
>>
>> --- a/block/cfq-iosched.c~a
>> +++ a/block/cfq-iosched.c
>> @@ -592,7 +592,7 @@ static int cfq_allow_merge(request_queue
>> if (cfqq == RQ_CFQQ(rq))
>> return 1;
>>
>> - return 1;
>> + return 0;
>> }
>>
>> static inline void
>> _
>>
>> But that might not fix things...
>
> Yeah it is, but I don't think it'll fix it (if anything, it'll be more
> conservative).

(to possibly save others from trying -- no, doesn't fix any)

Rene.

2007-01-02 11:58:03

by Jens Axboe

[permalink] [raw]
Subject: Re: 2.6.20-rc2+: CFQ halving disk throughput.

On Tue, Jan 02 2007, Rene Herman wrote:
> Jens Axboe wrote:
>
> >On Mon, Jan 01 2007, Andrew Morton wrote:
>
> >>The patch would appear to need this fix:
> >>
> >>--- a/block/cfq-iosched.c~a
> >>+++ a/block/cfq-iosched.c
> >>@@ -592,7 +592,7 @@ static int cfq_allow_merge(request_queue
> >> if (cfqq == RQ_CFQQ(rq))
> >> return 1;
> >>
> >>- return 1;
> >>+ return 0;
> >> }
> >>
> >> static inline void
> >>_
> >>
> >>But that might not fix things...
> >
> >Yeah it is, but I don't think it'll fix it (if anything, it'll be more
> >conservative).
>
> (to possibly save others from trying -- no, doesn't fix any)

As expected. The issue is rq_is_sync(rq) takes the data direction into
account as well, while bio_sync() only checks the sync bit. This should
fix it.

diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index 4b4217d..26fb40f 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -574,12 +574,14 @@ static int cfq_allow_merge(request_queue
struct cfq_data *cfqd = q->elevator->elevator_data;
const int rw = bio_data_dir(bio);
struct cfq_queue *cfqq;
+ int bio_is_sync;
pid_t key;

/*
* Disallow merge, if bio and rq aren't both sync or async
*/
- if (!!bio_sync(bio) != !!rq_is_sync(rq))
+ bio_is_sync = bio_data_dir(bio) == READ || bio_sync(bio);
+ if (bio_is_sync != !!rq_is_sync(rq))
return 0;

/*
@@ -592,7 +594,7 @@ static int cfq_allow_merge(request_queue
if (cfqq == RQ_CFQQ(rq))
return 1;

- return 1;
+ return 0;
}


--
Jens Axboe

2007-01-02 12:10:53

by Jens Axboe

[permalink] [raw]
Subject: Re: 2.6.20-rc2+: CFQ halving disk throughput.

On Tue, Jan 02 2007, Jens Axboe wrote:
> On Tue, Jan 02 2007, Rene Herman wrote:
> > Jens Axboe wrote:
> >
> > >On Mon, Jan 01 2007, Andrew Morton wrote:
> >
> > >>The patch would appear to need this fix:
> > >>
> > >>--- a/block/cfq-iosched.c~a
> > >>+++ a/block/cfq-iosched.c
> > >>@@ -592,7 +592,7 @@ static int cfq_allow_merge(request_queue
> > >> if (cfqq == RQ_CFQQ(rq))
> > >> return 1;
> > >>
> > >>- return 1;
> > >>+ return 0;
> > >> }
> > >>
> > >> static inline void
> > >>_
> > >>
> > >>But that might not fix things...
> > >
> > >Yeah it is, but I don't think it'll fix it (if anything, it'll be more
> > >conservative).
> >
> > (to possibly save others from trying -- no, doesn't fix any)
>
> As expected. The issue is rq_is_sync(rq) takes the data direction into
> account as well, while bio_sync() only checks the sync bit. This should
> fix it.

And here a little more relaxed version, as Mark Lord suggested. We allow
merge of async bio into a sync request, but not vice versa.

Both patches pending testing, will do so now.

diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index 4b4217d..07b7062 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -577,9 +577,9 @@ static int cfq_allow_merge(request_queue
pid_t key;

/*
- * Disallow merge, if bio and rq aren't both sync or async
+ * Disallow merge of a sync bio into an async request.
*/
- if (!!bio_sync(bio) != !!rq_is_sync(rq))
+ if ((bio_data_dir(bio) == READ || bio_sync(bio)) && !rq_is_sync(rq))
return 0;

/*
@@ -592,7 +592,7 @@ static int cfq_allow_merge(request_queue
if (cfqq == RQ_CFQQ(rq))
return 1;

- return 1;
+ return 0;
}

static inline void

--
Jens Axboe

2007-01-02 15:01:32

by Mark Lord

[permalink] [raw]
Subject: Re: 2.6.20-rc2+: CFQ halving disk throughput.

Jens Axboe wrote:
>
>> But surely one of (not sure which) sync+async or async+sync may also be
>> okay?
>> Or would it?
>
> Async merge to sync request should be ok. But I wonder what happens with
> hdparm, since it seems to trigger one of these tests. Very puzzling.
> I'll dive in and take a look.

The code (written 10 years ago) isn't the best in the world,
and will be redone entirely for hdparm-7.0 this year.

But right now, it essentially does this:

loop:
seek( to sector zero );
read( 2MBytes );
repeat loop for 3 seconds

Cheers

2007-01-02 15:12:09

by Mark Lord

[permalink] [raw]
Subject: Re: 2.6.20-rc2+: CFQ halving disk throughput.

Jens Axboe wrote:
> On Tue, Jan 02 2007, Jens Axboe wrote:
>> On Tue, Jan 02 2007, Rene Herman wrote:
>>> Jens Axboe wrote:
>>>
>>>> On Mon, Jan 01 2007, Andrew Morton wrote:
>>>>> The patch would appear to need this fix:
>>>>>
>>>>> --- a/block/cfq-iosched.c~a
>>>>> +++ a/block/cfq-iosched.c
>>>>> @@ -592,7 +592,7 @@ static int cfq_allow_merge(request_queue
>>>>> if (cfqq == RQ_CFQQ(rq))
>>>>> return 1;
>>>>>
>>>>> - return 1;
>>>>> + return 0;
>>>>> }
>>>>>
>>>>> static inline void
>>>>> _
>>>>>
>>>>> But that might not fix things...
>>>> Yeah it is, but I don't think it'll fix it (if anything, it'll be more
>>>> conservative).
>>> (to possibly save others from trying -- no, doesn't fix any)
>> As expected. The issue is rq_is_sync(rq) takes the data direction into
>> account as well, while bio_sync() only checks the sync bit. This should
>> fix it.
>
> And here a little more relaxed version, as Mark Lord suggested. We allow
> merge of async bio into a sync request, but not vice versa.
>
> Both patches pending testing, will do so now.

Performance is right back where it should be now, thanks!

I did have to massage the second patch to get it to apply cleanly
after the first patch. You may want to regenerate it against -rc3.

Cheers

2007-01-02 15:14:07

by Jens Axboe

[permalink] [raw]
Subject: Re: 2.6.20-rc2+: CFQ halving disk throughput.

On Tue, Jan 02 2007, Mark Lord wrote:
> Jens Axboe wrote:
> >On Tue, Jan 02 2007, Jens Axboe wrote:
> >>On Tue, Jan 02 2007, Rene Herman wrote:
> >>>Jens Axboe wrote:
> >>>
> >>>>On Mon, Jan 01 2007, Andrew Morton wrote:
> >>>>>The patch would appear to need this fix:
> >>>>>
> >>>>>--- a/block/cfq-iosched.c~a
> >>>>>+++ a/block/cfq-iosched.c
> >>>>>@@ -592,7 +592,7 @@ static int cfq_allow_merge(request_queue
> >>>>> if (cfqq == RQ_CFQQ(rq))
> >>>>> return 1;
> >>>>>
> >>>>>- return 1;
> >>>>>+ return 0;
> >>>>>}
> >>>>>
> >>>>>static inline void
> >>>>>_
> >>>>>
> >>>>>But that might not fix things...
> >>>>Yeah it is, but I don't think it'll fix it (if anything, it'll be more
> >>>>conservative).
> >>>(to possibly save others from trying -- no, doesn't fix any)
> >>As expected. The issue is rq_is_sync(rq) takes the data direction into
> >>account as well, while bio_sync() only checks the sync bit. This should
> >>fix it.
> >
> >And here a little more relaxed version, as Mark Lord suggested. We allow
> >merge of async bio into a sync request, but not vice versa.
> >
> >Both patches pending testing, will do so now.
>
> Performance is right back where it should be now, thanks!

Good, thanks!

> I did have to massage the second patch to get it to apply cleanly
> after the first patch. You may want to regenerate it against -rc3.

Hmm odd, I thought I did. Will double check.

--
Jens Axboe

2007-01-02 15:40:36

by Mark Lord

[permalink] [raw]
Subject: Re: 2.6.20-rc2+: CFQ halving disk throughput.

Jens Axboe wrote:
>
>> I did have to massage the second patch to get it to apply cleanly
>> after the first patch. You may want to regenerate it against -rc3.
>
> Hmm odd, I thought I did. Will double check.

Ahh.. I get it now.

I tried to apply the second patch *on top* of the first patch,
whereas it was supposed to be a full replacement instead.

Cheers

2007-01-02 15:45:28

by Jens Axboe

[permalink] [raw]
Subject: Re: 2.6.20-rc2+: CFQ halving disk throughput.

On Tue, Jan 02 2007, Mark Lord wrote:
> Jens Axboe wrote:
> >
> >>I did have to massage the second patch to get it to apply cleanly
> >>after the first patch. You may want to regenerate it against -rc3.
> >
> >Hmm odd, I thought I did. Will double check.
>
> Ahh.. I get it now.
>
> I tried to apply the second patch *on top* of the first patch,
> whereas it was supposed to be a full replacement instead.

Ah, then I can see you would have problems :-)

--
Jens Axboe

2007-01-02 16:53:54

by Tejun Heo

[permalink] [raw]
Subject: Re: 2.6.20-rc2+: CFQ halving disk throughput.

Mark Lord wrote:
> The code (written 10 years ago) isn't the best in the world,
> and will be redone entirely for hdparm-7.0 this year.

OT but care to make -i and -I work equivalently? Such that -i reports
more detailed info and user can dump stored id block. Support for
IDENTIFY PACKET DEVICE would be nice too.

Thanks.

--
tejun

2007-01-02 17:14:45

by Jan Engelhardt

[permalink] [raw]
Subject: Re: 2.6.20-rc2+: CFQ halving disk throughput.


On Jan 2 2007 10:01, Mark Lord wrote:
> Jens Axboe wrote:
>>
>> > But surely one of (not sure which) sync+async or async+sync may also
>> > be okay?
>> > Or would it?
>>
>> Async merge to sync request should be ok. But I wonder what happens with
>> hdparm, since it seems to trigger one of these tests. Very puzzling.
>> I'll dive in and take a look.
>
> The code (written 10 years ago) isn't the best in the world,
> and will be redone entirely for hdparm-7.0 this year.
>
> But right now, it essentially does this:
>
> loop:
> seek( to sector zero );
> read( 2MBytes );
> repeat loop for 3 seconds

Well for pure reading speed, I already use dd_rescue -d /dev/hda /dev/null
Gives the same as hdparm -t when acting on uncached data.


-`J'
--

2007-01-02 17:35:44

by Mark Lord

[permalink] [raw]
Subject: Re: 2.6.20-rc2+: CFQ halving disk throughput.

Tejun Heo wrote:
>
> OT but care to make -i and -I work equivalently? Such that -i reports
> more detailed info and user can dump stored id block.

hdparm -I works just fine now.

hdparm -i requires the HDIO_GET_IDENTITY ioctl() from drivers/ide,
to retrieve the "boot time" copy of the identify block, before any
mods are made by the driver. But in recent years, drivers/ide has
broken it, in that it tries to maintain the "boot time" copy in sync
with the on-drive copy. Kinda makes -i pointless.

Is there a way to retrieve the libata cached copy of the ID block?
How?

>Support for IDENTIFY PACKET DEVICE would be nice too.

It already does that, using HDIO_DRIVE_CMD to retrieve it
in the same way as for regular IDENTIFY DEVICE commands.

In hdparm-7.0, I'll have it use ATA passthrough when possible
for most/all commands.

Cheers

2007-01-02 17:54:00

by Tejun Heo

[permalink] [raw]
Subject: Re: 2.6.20-rc2+: CFQ halving disk throughput.

Mark Lord wrote:
> Tejun Heo wrote:
>>
>> OT but care to make -i and -I work equivalently? Such that -i reports
>> more detailed info and user can dump stored id block.
>
> hdparm -I works just fine now.

No objection there.

> hdparm -i requires the HDIO_GET_IDENTITY ioctl() from drivers/ide,
> to retrieve the "boot time" copy of the identify block, before any
> mods are made by the driver. But in recent years, drivers/ide has
> broken it, in that it tries to maintain the "boot time" copy in sync
> with the on-drive copy. Kinda makes -i pointless.
>
> Is there a way to retrieve the libata cached copy of the ID block?
> How?

Just implemented and posted patch for HDIO_GET_IDENTITY in an attempt to
access ATAPI IDENTIFY block using hdparm.

>> Support for IDENTIFY PACKET DEVICE would be nice too.
>
> It already does that, using HDIO_DRIVE_CMD to retrieve it
> in the same way as for regular IDENTIFY DEVICE commands.

Hmmm... My hdparm doesn't seem to do that.

# hdparm -V
hdparm v6.9
# hdparm -I /dev/sr0

/dev/sr0:
HDIO_DRIVE_CMD(identify) failed: Input/output error

Am I missing something?

> In hdparm-7.0, I'll have it use ATA passthrough when possible
> for most/all commands.

Glad to hear.

Happy new year.

--
tejun

2007-01-02 18:10:39

by Mark Lord

[permalink] [raw]
Subject: Re: 2.6.20-rc2+: CFQ halving disk throughput.

Tejun Heo wrote:
> Mark Lord wrote:
>
>>> Support for IDENTIFY PACKET DEVICE would be nice too.
>> It already does that, using HDIO_DRIVE_CMD to retrieve it
>> in the same way as for regular IDENTIFY DEVICE commands.
>
> Hmmm... My hdparm doesn't seem to do that.

Sure it does.
Try "strace hdparm -I /dev/sr0" and notice the two ioctl() calls.

The problem is that libata/SCSI always fail it for some reason.
Ditto for me right now when I tried it with an SG_IO passthru command.

Contrary to my other posting, I actually *do* have a libata-controlled
DVD/RW drive in my box here. So I'll try and see what's happening.

Still digging..