CF as IDE on ICH6M using libata

CF as IDE on ICH6M using libata

[Eddie Hung]

Hello everyone,

In the hope of making myself a cheap SSD, I decided to replace my IDE
HDD on my IBM Thinkpad X41 (non tablet) with a generic CF-IDE adaptor,
and a Sandisk Extreme IV 4Gb CF, for reasonable prices off ebay. This
was partly influenced by the report that one X41 Tablet user had it
working successfully: http://forum.thinkpads.com/viewtopic.php?t=41568
(last post on that page)

As some of you may know, the X41 uses a SATA controller, which goes
into a SATA-PATA bridge, and then connects to a PATA HDD. This is a
strange setup, and may go some distance as to explaining why it
doesn't work.

The first I tried was the Ubuntu Feisty LiveCD, which uses 2.6.20, and
libata picks the drive up correctly. A hdparm -I showed that the
device was currently running at mdma2 - which was not what I expected
- the Sandisk, as garnered from review websites, supports UDMA. A
quick hdparm -t also revealed that I was only getting about 6MB/s.

Nonetheless, I tried to partition the disk - at which point mkfs.ext3
froze. Looking at dmesg, I saw some timeout commands, looking
something like:
ata1: port is slow to respond, please be patient (Status 0xd0)
ata1: soft resetting port
ata1: ... exception ... res 40/00:00:00:00:00/00:00:00:00:00/a0 Emask
0x4 (timeout)

I have also tried the latest Gutsy LiveCD, using kernel 2.6.22, and
that exhibits the same problem too. Also, I've also tried booting the
LiveCD in expert mode, unloading the ata_generic, ata_piix and libata
drivers, and loading ide-generic - at which point my drive shows up as
/dev/hda rather than /dev/sda. However, the CF card is still
recognised as only supporting mdma2, and hdparm -X still does not
allow me to set the transfer mode to anything else (the command goes
through without any errors, but another -i shows that the mode is
still mdma2). However, using ide-generic allows me to access the drive
"succesfully" (no timeout errors), but at an even more measly 2MB/s.

These errors are very similar to those that this list has seen before:
ICH8 timeout regression: http://www.spinics.net/lists/linux-ide/msg13104.html
CF flash IDE failure to attach:
http://www.mail-archive.com/linux-ide@vger.kernel.org/msg07402.html
CompactFlash performance (this guy gets 30MB/s using UDMA on an ICH8 -
I'm very jealous!)
http://www.opensubscriber.com/message/linux-ide@vger.kernel.org/6818048.html
Another Sandisk CF user only seeing mdma too:
http://www.spinics.net/lists/linux-ide/msg00207.html

I have read through those threads, but I'm not sure how I can apply
what they've learnt to my situation, and this is where I would like to
ask all you experts out there for some help!

My thoughts are as follows;
- MDMA is not really supported, hence why it is so slow - if I can
disable mdma and tell it to use single word PIO4, then I might get a
reasonable 15Mb/s - however extensive searching has shown me that
libata doesn't allow a user to set the xfer mode?
- UDMA is not detected for some reason, even if it is supported by the
card and by the controller (is there any way to force that to be
enabled, regardless of whether it is detected or not?)
- Even more worryingly for me, is that Windows also resorts to using
Multiword DMA 2, and it is frightfully slow (which is a big
disappointment - seeing as another X41 user (who is undoubtedly using
windows!) has reported success!) - I am currently trying to get in
touch with this user
- I bought a card which is too fast for its own good - if only it
could only support PIO, then I might not be in this mess! =)

Has there been any fixes since 2.6.22 (such as those patches that have
been suggested/used in the previous discussions) which could possibly
solve my problem?

Sorry for the long e-mail, and any help would be very very gratefully
received and appreciated!

Thanks and best regards,

Eddie Hung

Re: CF as IDE on ICH6M using libata

[Tejun Heo]

Eddie Hung wrote:
> Hello everyone,
> 
> In the hope of making myself a cheap SSD, I decided to replace my IDE
> HDD on my IBM Thinkpad X41 (non tablet) with a generic CF-IDE adaptor,
> and a Sandisk Extreme IV 4Gb CF, for reasonable prices off ebay. This
> was partly influenced by the report that one X41 Tablet user had it
> working successfully: http://forum.thinkpads.com/viewtopic.php?t=41568
> (last post on that page)
> 
> As some of you may know, the X41 uses a SATA controller, which goes
> into a SATA-PATA bridge, and then connects to a PATA HDD. This is a
> strange setup, and may go some distance as to explaining why it
> doesn't work.
> 
> The first I tried was the Ubuntu Feisty LiveCD, which uses 2.6.20, and
> libata picks the drive up correctly. A hdparm -I showed that the
> device was currently running at mdma2 - which was not what I expected
> - the Sandisk, as garnered from review websites, supports UDMA. A
> quick hdparm -t also revealed that I was only getting about 6MB/s.
> 
> Nonetheless, I tried to partition the disk - at which point mkfs.ext3
> froze. Looking at dmesg, I saw some timeout commands, looking
> something like:
> ata1: port is slow to respond, please be patient (Status 0xd0)
> ata1: soft resetting port
> ata1: ... exception ... res 40/00:00:00:00:00/00:00:00:00:00/a0 Emask
> 0x4 (timeout)

>From 2.6.22, please post the boot log and full error log (dmesg result)
and the result of 'hdparm -I /dev/sda'.

I don't think the device supports UDMA.  Supported transfer modes are
indicated in the IDENTIFY page (hdparm -I) and libata/ide would use UDMA
if the device reports so.  There's no black magic there.

Regarding MWDMA2 not working, are you sure that windows uses mwdma2?
We've had quite some number of reports about broken mwdma2 and till now
we thought those devices were broken and black listed them but it's also
possible that mwdma2 mode programming or something else is broken in
ata_piix.  If so, it really needs fixing.

Thanks.

-- 
tejun

Re: CF as IDE on ICH6M using libata

[Alan Cox]

O> - MDMA is not really supported, hence why it is so slow - if I can
> disable mdma and tell it to use single word PIO4, then I might get a
> reasonable 15Mb/s - however extensive searching has shown me that
> libata doesn't allow a user to set the xfer mode?

libata automatically picks the best mode for the device. Right now it
doesn't allow hand hacking this. I've got some patches (which I think I
sent in for the latest -mm) which allow you to specify that pata dma
doesn't occur for certain classes of device.

> - UDMA is not detected for some reason, even if it is supported by the
> card and by the controller (is there any way to force that to be
> enabled, regardless of whether it is detected or not?)
> - Even more worryingly for me, is that Windows also resorts to using
> Multiword DMA 2, and it is frightfully slow (which is a big
> disappointment - seeing as another X41 user (who is undoubtedly using
> windows!) has reported success!) - I am currently trying to get in
> touch with this user
> - I bought a card which is too fast for its own good - if only it
> could only support PIO, then I might not be in this mess! =)

If MWDMA2 is also very slow that is suprising. Is Windows in fact
dropping back to PIO as well ? A lot of CF cards support MWDMA, very few
UDMA. To complicate things many CF convertors do not support MWDMA, quite
a few are electrically inadequate for UDMA (I guess being defined long
before anyone thought about UDMA and CF).

Finally to completely screw you most SATA/PATA convertors don't support
anything but a few UDMA modes and PIO.

Alan

Re: CF as IDE on ICH6M using libata

[Eddie Hung]

On 02/09/07, Tejun Heo <htejun@gmail.com> wrote:
> Eddie Hung wrote:
> > Hello everyone,
> >
> > In the hope of making myself a cheap SSD, I decided to replace my IDE
> > HDD on my IBM Thinkpad X41 (non tablet) with a generic CF-IDE adaptor,
> > and a Sandisk Extreme IV 4Gb CF, for reasonable prices off ebay. This
> > was partly influenced by the report that one X41 Tablet user had it
> > working successfully: http://forum.thinkpads.com/viewtopic.php?t=41568
> > (last post on that page)
> >
> > As some of you may know, the X41 uses a SATA controller, which goes
> > into a SATA-PATA bridge, and then connects to a PATA HDD. This is a
> > strange setup, and may go some distance as to explaining why it
> > doesn't work.
> >
> > The first I tried was the Ubuntu Feisty LiveCD, which uses 2.6.20, and
> > libata picks the drive up correctly. A hdparm -I showed that the
> > device was currently running at mdma2 - which was not what I expected
> > - the Sandisk, as garnered from review websites, supports UDMA. A
> > quick hdparm -t also revealed that I was only getting about 6MB/s.
> >
> > Nonetheless, I tried to partition the disk - at which point mkfs.ext3
> > froze. Looking at dmesg, I saw some timeout commands, looking
> > something like:
> > ata1: port is slow to respond, please be patient (Status 0xd0)
> > ata1: soft resetting port
> > ata1: ... exception ... res 40/00:00:00:00:00/00:00:00:00:00/a0 Emask
> > 0x4 (timeout)
>
> From 2.6.22, please post the boot log and full error log (dmesg result)
> and the result of 'hdparm -I /dev/sda'.
>
> I don't think the device supports UDMA.  Supported transfer modes are
> indicated in the IDENTIFY page (hdparm -I) and libata/ide would use UDMA
> if the device reports so.  There's no black magic there.
>
> Regarding MWDMA2 not working, are you sure that windows uses mwdma2?
> We've had quite some number of reports about broken mwdma2 and till now
> we thought those devices were broken and black listed them but it's also
> possible that mwdma2 mode programming or something else is broken in
> ata_piix.  If so, it really needs fixing.
>
> Thanks.
>
> --
> tejun
>

Hello tejun,

Thanks for replying so quickly.

Here's the information you requested:

*** uname -r ***
2.6.22-10-generic

*** hdparm -I ***

/dev/sda:

ATA device, with non-removable media
	Model Number:       SMI MODEL
	Serial Number:      SZAUSWIN    000006E5
	Firmware Revision:  20070709
Standards:
	Likely used: 5
Configuration:
	Logical		max	current
	cylinders	7866	7866
	heads		16	16
	sectors/track	63	63
	--
	CHS current addressable sectors:    7928928
	LBA    user addressable sectors:    7928928
	device size with M = 1024*1024:        3871 MBytes
	device size with M = 1000*1000:        4059 MBytes (4 GB)
Capabilities:
	LBA, IORDY(may be)(cannot be disabled)
	bytes avail on r/w long: 4
	Standby timer values: spec'd by Vendor
	R/W multiple sector transfer: Max = 1	Current = 0
	DMA: mdma0 mdma1 *mdma2
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4
	     Cycle time: no flow control=120ns  IORDY flow control=120ns
HW reset results:
	CBLID- below Vih
	Device num = 0
Integrity word not set (found 0x0000, expected 0x14a5)

*** hdparm -i ***

/dev/sda:

 Model=SMI MODEL                               , FwRev=20070709,
SerialNo=SZAUSWIN    000006E5
 Config={ HardSect NotMFM Fixed DTR>10Mbs }
 RawCHS=7866/16/63, TrkSize=0, SectSize=576, ECCbytes=4
 BuffType=DualPort, BuffSize=1kB, MaxMultSect=1, MultSect=?0?
 CurCHS=7866/16/63, CurSects=7928928, LBA=yes, LBAsects=7928928
 IORDY=no, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 *mdma2
 AdvancedPM=no

 * signifies the current active mode

*** hdparm -t ***

/dev/sda:
 Timing buffered disk reads:   26 MB in  3.01 seconds =   8.64 MB/sec

*** dmesg (relevant only) ***

[    0.000000] Linux version 2.6.22-10-generic (buildd@palmer) (gcc
version 4.1.3 20070812 (prerelease) (Ubuntu 4.1.2-15ubuntu2)) #1 SMP
Wed Aug 22 08:11:52 GMT 2007 (Ubuntu 2.6.22-10.30-generic)
...snip...
[    4.328000] ahci 0000:00:1f.2: version 2.2
[    4.328000] ahci: probe of 0000:00:1f.2 failed with error -22
[    4.332000] ata_piix 0000:00:1f.2: version 2.11
[    4.332000] ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ]
[    4.332000] PCI: Setting latency timer of device 0000:00:1f.2 to 64
[    4.332000] scsi0 : ata_piix
[    4.332000] scsi1 : ata_piix
[    4.332000] ata1: SATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6
bmdma 0x00011810 irq 14
[    4.332000] ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376
bmdma 0x00011818 irq 15
[    4.504000] ata1.00: ATA-0: SMI MODEL, 20070709, max MWDMA2
[    4.504000] ata1.00: 7928928 sectors, multi 0: LBA
[    4.504000] ata1.00: applying bridge limits
[    4.520000] ata1.00: configured for MWDMA2
[    4.660000] usb 1-1: device not accepting address 2, error -71
[    4.840000] ata2.00: ATAPI: DVD/CDRW UJDA775, CB03, max UDMA/33
[    5.012000] ata2.00: configured for UDMA/33
[    5.012000] scsi 0:0:0:0: Direct-Access     ATA      SMI MODEL
  2007 PQ: 0 ANSI: 5
[    5.012000] scsi 1:0:0:0: CD-ROM            MATSHITA DVD/CDRW
UJDA775 CB03 PQ: 0 ANSI: 5
[    5.028000] sd 0:0:0:0: [sda] 7928928 512-byte hardware sectors (4060 MB)
[    5.028000] sd 0:0:0:0: [sda] Write Protect is off
[    5.028000] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    5.028000] sd 0:0:0:0: [sda] Write cache: disabled, read cache:
enabled, doesn't support DPO or FUA
[    5.028000] sd 0:0:0:0: [sda] 7928928 512-byte hardware sectors (4060 MB)
[    5.028000] sd 0:0:0:0: [sda] Write Protect is off
[    5.028000] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    5.028000] sd 0:0:0:0: [sda] Write cache: disabled, read cache:
enabled, doesn't support DPO or FUA
[    5.028000]  sda: sda1
[    5.028000] sd 0:0:0:0: [sda] Attached SCSI disk
[    5.032000] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    5.032000] scsi 1:0:0:0: Attached scsi generic sg1 type 5
[    5.044000] sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
[    5.044000] Uniform CD-ROM driver Revision: 3.20
[    5.044000] sr 1:0:0:0: Attached scsi CD-ROM sr0
...snip...
[ 1148.368000] program gparted is using a deprecated SCSI ioctl,
please convert it to SG_IO
[ 1159.200000] program gparted is using a deprecated SCSI ioctl,
please convert it to SG_IO
[ 1238.644000] program gparted is using a deprecated SCSI ioctl,
please convert it to SG_IO
[ 1301.836000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[ 1301.836000] ata1.00: cmd ca/00:80:50:55:1f/00:00:00:00:00/e0 tag 0
cdb 0x0 data 65536 out
[ 1301.836000]          res 40/00:00:00:00:00/00:00:00:00:00/e0 Emask
0x4 (timeout)
[ 1306.876000] ata1: port is slow to respond, please be patient (Status 0xd0)
[ 1311.860000] ata1: device not ready (errno=-16), forcing hardreset
[ 1311.860000] ata1: soft resetting port
[ 1312.048000] ata1.00: configured for MWDMA2
[ 1312.048000] ata1: EH complete
[ 1342.048000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[ 1342.048000] ata1.00: cmd ca/00:80:50:55:1f/00:00:00:00:00/e0 tag 0
cdb 0x0 data 65536 out
[ 1342.048000]          res 40/00:00:00:00:00/00:00:00:00:00/e0 Emask
0x4 (timeout)
[ 1347.088000] ata1: port is slow to respond, please be patient (Status 0xd0)
[ 1352.072000] ata1: device not ready (errno=-16), forcing hardreset
[ 1352.072000] ata1: soft resetting port
[ 1352.260000] ata1.00: configured for MWDMA2
[ 1352.260000] ata1: EH complete
[ 1382.260000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[ 1382.260000] ata1.00: cmd ca/00:80:50:55:1f/00:00:00:00:00/e0 tag 0
cdb 0x0 data 65536 out
[ 1382.260000]          res 40/00:00:00:00:00/00:00:00:00:00/e0 Emask
0x4 (timeout)
[ 1387.300000] ata1: port is slow to respond, please be patient (Status 0xd0)
[ 1392.284000] ata1: device not ready (errno=-16), forcing hardreset
[ 1392.284000] ata1: soft resetting port
[ 1392.472000] ata1.00: configured for MWDMA2
[ 1392.472000] ata1: EH complete
[ 1422.472000] ata1.00: limiting speed to MWDMA1:PIO4
[ 1422.472000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[ 1422.472000] ata1.00: cmd ca/00:80:50:55:1f/00:00:00:00:00/e0 tag 0
cdb 0x0 data 65536 out
[ 1422.472000]          res 40/00:00:00:00:00/00:00:00:00:00/e0 Emask
0x4 (timeout)
[ 1427.512000] ata1: port is slow to respond, please be patient (Status 0xd0)
[ 1432.496000] ata1: device not ready (errno=-16), forcing hardreset
[ 1432.496000] ata1: soft resetting port
[ 1432.684000] ata1.00: configured for MWDMA1
[ 1432.684000] ata1: EH complete
[ 1462.684000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[ 1462.684000] ata1.00: cmd ca/00:80:50:55:1f/00:00:00:00:00/e0 tag 0
cdb 0x0 data 65536 out
[ 1462.684000]          res 40/00:00:00:00:00/00:00:00:00:00/e0 Emask
0x4 (timeout)
[ 1467.724000] ata1: port is slow to respond, please be patient (Status 0xd0)
[ 1472.708000] ata1: device not ready (errno=-16), forcing hardreset
[ 1472.708000] ata1: soft resetting port
[ 1472.896000] ata1.00: configured for MWDMA1
[ 1472.896000] ata1: EH complete
[ 1502.896000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[ 1502.896000] ata1.00: cmd ca/00:80:50:55:1f/00:00:00:00:00/e0 tag 0
cdb 0x0 data 65536 out
[ 1502.896000]          res 40/00:00:00:00:00/00:00:00:00:00/e0 Emask
0x4 (timeout)
[ 1507.936000] ata1: port is slow to respond, please be patient (Status 0xd0)
[ 1512.920000] ata1: device not ready (errno=-16), forcing hardreset
[ 1512.920000] ata1: soft resetting port
[ 1513.108000] ata1.00: configured for MWDMA1
[ 1513.108000] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE,SUGGEST_OK
[ 1513.108000] sd 0:0:0:0: [sda] Sense Key : Aborted Command [current]
[descriptor]
[ 1513.108000] Descriptor sense data with sense descriptors (in hex):
[ 1513.108000]         72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
[ 1513.108000]         00 00 00 00
[ 1513.108000] sd 0:0:0:0: [sda] Add. Sense: No additional sense information
[ 1513.108000] end_request: I/O error, dev sda, sector 2053456
[ 1513.108000] Buffer I/O error on device sda1, logical block 2053393
[ 1513.108000] lost page write due to I/O error on sda1
[ 1513.108000] Buffer I/O error on device sda1, logical block 2053394
[ 1513.108000] lost page write due to I/O error on sda1
[ 1513.108000] Buffer I/O error on device sda1, logical block 2053395
[ 1513.108000] lost page write due to I/O error on sda1
[ 1513.108000] Buffer I/O error on device sda1, logical block 2053396
[ 1513.108000] lost page write due to I/O error on sda1
[ 1513.108000] Buffer I/O error on device sda1, logical block 2053397
[ 1513.108000] lost page write due to I/O error on sda1
[ 1513.108000] Buffer I/O error on device sda1, logical block 2053398
[ 1513.108000] lost page write due to I/O error on sda1
[ 1513.108000] Buffer I/O error on device sda1, logical block 2053399
[ 1513.108000] lost page write due to I/O error on sda1
[ 1513.108000] Buffer I/O error on device sda1, logical block 2053400
[ 1513.108000] lost page write due to I/O error on sda1
[ 1513.108000] Buffer I/O error on device sda1, logical block 2053401
[ 1513.108000] lost page write due to I/O error on sda1
[ 1513.108000] Buffer I/O error on device sda1, logical block 2053402
[ 1513.108000] lost page write due to I/O error on sda1
[ 1513.108000] ata1: EH complete
[ 1543.108000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[ 1543.108000] ata1.00: cmd ca/00:80:d0:55:1f/00:00:00:00:00/e0 tag 0
cdb 0x0 data 65536 out
[ 1543.108000]          res 40/00:00:00:00:00/00:00:00:00:00/e0 Emask
0x4 (timeout)
[ 1548.148000] ata1: port is slow to respond, please be patient (Status 0xd0)
[ 1553.132000] ata1: device not ready (errno=-16), forcing hardreset
[ 1553.132000] ata1: soft resetting port
[ 1553.320000] ata1.00: configured for MWDMA1
[ 1553.320000] ata1: EH complete
[ 1583.320000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[ 1583.320000] ata1.00: cmd ca/00:80:d0:55:1f/00:00:00:00:00/e0 tag 0
cdb 0x0 data 65536 out
[ 1583.320000]          res 40/00:00:00:00:00/00:00:00:00:00/e0 Emask
0x4 (timeout)
[ 1588.360000] ata1: port is slow to respond, please be patient (Status 0xd0)
[ 1593.344000] ata1: device not ready (errno=-16), forcing hardreset
[ 1593.344000] ata1: soft resetting port
[ 1593.532000] ata1.00: configured for MWDMA1
[ 1593.532000] ata1: EH complete
[ 1623.532000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[ 1623.532000] ata1.00: cmd ca/00:80:d0:55:1f/00:00:00:00:00/e0 tag 0
cdb 0x0 data 65536 out
[ 1623.532000]          res 40/00:00:00:00:00/00:00:00:00:00/e0 Emask
0x4 (timeout)
[ 1628.572000] ata1: port is slow to respond, please be patient (Status 0xd0)
[ 1633.556000] ata1: device not ready (errno=-16), forcing hardreset
[ 1633.556000] ata1: soft resetting port
[ 1633.744000] ata1.00: configured for MWDMA1
[ 1633.744000] ata1: EH complete
[ 1663.744000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[ 1663.744000] ata1.00: cmd ca/00:80:d0:55:1f/00:00:00:00:00/e0 tag 0
cdb 0x0 data 65536 out
[ 1663.744000]          res 40/00:00:00:00:00/00:00:00:00:00/e0 Emask
0x4 (timeout)
[ 1668.784000] ata1: port is slow to respond, please be patient (Status 0xd0)
[ 1673.768000] ata1: device not ready (errno=-16), forcing hardreset
[ 1673.768000] ata1: soft resetting port
[ 1673.956000] ata1.00: configured for MWDMA1
[ 1673.956000] ata1: EH complete
[ 1703.956000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[ 1703.956000] ata1.00: cmd ca/00:80:d0:55:1f/00:00:00:00:00/e0 tag 0
cdb 0x0 data 65536 out
[ 1703.956000]          res 40/00:00:00:00:00/00:00:00:00:00/e0 Emask
0x4 (timeout)
[ 1708.996000] ata1: port is slow to respond, please be patient (Status 0xd0)
[ 1713.980000] ata1: device not ready (errno=-16), forcing hardreset
[ 1713.980000] ata1: soft resetting port
[ 1714.168000] ata1.00: configured for MWDMA1
[ 1714.168000] ata1: EH complete

** End ***

I can see that it falls back from MWDMA2 to MWDMA1, but it doesn't
fall back again to Single Word DMA?

What is very strange also is that I can mount the NTFS drive just
fine, and copy 70Mb of files off it (pretty nippily, I might add =D) -
without any timeouts, but as soon as I tried to do something
"lowlevel" to the disk (i.e. as you may have spotted, I used gparted
to try and resize the NTFS partition, so I could try and run mkfs.ext3
again - which was what caused the timeouts when I originally tried to
install.

I can confirm that my chipset does indeed support UDMA, here is the
hdparm -I report on my original disk:

/dev/sda:

ATA device, with non-removable media
        Model Number:       HITACHI_DK13FA-40B
        Serial Number:      D09466
        Firmware Revision:  00MCA0B7
Standards:
        Used: ATA/ATAPI-5 T13 1321D revision 3
        Supported: 5 4 3 & some of 6
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:   16514064
        LBA    user addressable sectors:   78140160
        device size with M = 1024*1024:       38154 MBytes
        device size with M = 1000*1000:       40007 MBytes (40 GB)
Capabilities:
        LBA, IORDY(cannot be disabled)
        bytes avail on r/w long: 4
        Standby timer values: spec'd by Vendor, no device specific minimum
        R/W multiple sector transfer: Max = 16  Current = 16
        Advanced power management level: 128 (0x80)
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=240ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
           *    Host Protected Area feature set
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    NOP cmd
           *    Advanced Power Management feature set
                Address Offset Reserved Area Boot
                SET_MAX security extension
           *    Device Configuration Overlay feature set
           *    Mandatory FLUSH_CACHE
           *    SMART error logging
           *    SMART self-test
Security:
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
                frozen
        not     expired: security count
                supported: enhanced erase
        52min for SECURITY ERASE UNIT. 52min for ENHANCED SECURITY ERASE UNIT.
HW reset results:
        CBLID- above Vih
        Device num = 0 determined by the jumper
Checksum: correct

*** End ***

In regards to Windows performance: I have been using the tool HDTune
to see which mode the device is in - and it reports Multiword DMA 2.
Also, the benchmark facility with HDTune reveals that the burst speed
of the drive is 2MB - consistent with the hdparm -t speed when
ide-generic is used.

Strangely enough, I've gone into Device Manager, and the transfer mode
Windows claims it is using is PIO, which seems to be contradictory to
what HDTune is telling me (and leads me to ask another question, I've
included in my reply to Alan) I've also tried to various registry
settings to try and force the device into UDMA or PIO, to no success -
as far as I can tell MWDMA may well be the lowest speed Windows XP
supports operating devices at?

Eddie

Re: CF as IDE on ICH6M using libata

[Eddie Hung]

On 02/09/07, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> O> - MDMA is not really supported, hence why it is so slow - if I can
> > disable mdma and tell it to use single word PIO4, then I might get a
> > reasonable 15Mb/s - however extensive searching has shown me that
> > libata doesn't allow a user to set the xfer mode?
>
> libata automatically picks the best mode for the device. Right now it
> doesn't allow hand hacking this. I've got some patches (which I think I
> sent in for the latest -mm) which allow you to specify that pata dma
> doesn't occur for certain classes of device.
>
> > - UDMA is not detected for some reason, even if it is supported by the
> > card and by the controller (is there any way to force that to be
> > enabled, regardless of whether it is detected or not?)
> > - Even more worryingly for me, is that Windows also resorts to using
> > Multiword DMA 2, and it is frightfully slow (which is a big
> > disappointment - seeing as another X41 user (who is undoubtedly using
> > windows!) has reported success!) - I am currently trying to get in
> > touch with this user
> > - I bought a card which is too fast for its own good - if only it
> > could only support PIO, then I might not be in this mess! =)
>
> If MWDMA2 is also very slow that is suprising. Is Windows in fact
> dropping back to PIO as well ? A lot of CF cards support MWDMA, very few
> UDMA. To complicate things many CF convertors do not support MWDMA, quite
> a few are electrically inadequate for UDMA (I guess being defined long
> before anyone thought about UDMA and CF).
>
> Finally to completely screw you most SATA/PATA convertors don't support
> anything but a few UDMA modes and PIO.
>
> Alan
>

Hello Alan,

Thank you for helping.

In my research on this issue, I do remember coming across an
announcement you made not so long ago regarding the libata.pata_dma
command - however because of my revelations with Windows detailed at
the end of my reply to tejun, I am curious as to whether MWDMA is
really DMA at all? I also believe it runs at about the same speed as
the top PIO speeds too?

In which case, the setting may not be of any help to this scenario.

I'm not sure what Windows is doing - it doesn't like to tell me
anywhere near as much information as Linux does!!

I have one of the new Sandisk Extreme IV cards - which support 40Mb/s
- and it has been reported my various websites that it supports UDMA -
which is only utilised thus far in conjuction with the Sandisk reader.
One such review is here:
http://www.trustedreviews.com/storage/review/2006/09/26/SanDisk-Extreme-IV-2GB-CF-Card-Reader-Bundle/p1
From where I quote:
"Before we find out how fast the card is, let's have a look at what
you get for your £165. First of all there's the actual card – in this
case a 2GB one (the Extreme IV is also available in capacities of 4
and 8GB). The card design is typical of SanDisk but internally, it's
one of the only CF cards that uses a controller compliant with the
UDMA 4 transfer protocol. It also has an extended operating
temperature of -25 to 85C."

Whilst I can accept that 40Mb/s might be an exaggerated
lab-environment-only claim - I certainly would love to see 30Mb/s
which another user claims to have gotten!

I also know that my SATA-PATA arrangement is hardly ideal - but the
controller, using the original HDD, supports udma5 - so I am wondering
why it does not detect, and use, that with the CF card - this brings
me back to the question I originally posed and tejun answered - is
there any way to force it to use UDMA4 - because I know it is
supported by the card?

Also, the CF-IDE bridge is a cheap one (not that there were much
choices) from ebay - and the documentation that comes with it states
that it supports DMA - in which case is there any way I can verify
that? What are the prerequisites for DMA support? (Do certain pins
need to be connected, for example?)

Many, many thanks for your help,

Eddie

Re: CF as IDE on ICH6M using libata

[Alan Cox]

> In my research on this issue, I do remember coming across an
> announcement you made not so long ago regarding the libata.pata_dma
> command - however because of my revelations with Windows detailed at
> the end of my reply to tejun, I am curious as to whether MWDMA is
> really DMA at all? I also believe it runs at about the same speed as
> the top PIO speeds too?

MWDMA is DMA but MWDMA2 and PIO4 use the same data transfer rates - the
DMA modes make it easier to offload the processing. In fact MWDMA isn't
really needed - the Cyrix CS5520 and some other chipsets can do DMA in
the chipset up to MWDMA while talking PIO4 to the device.

But to answer the question - there is a real difference electrically
between MWDMA2 and PIO4

> I also know that my SATA-PATA arrangement is hardly ideal - but the
> controller, using the original HDD, supports udma5 - so I am wondering
> why it does not detect, and use, that with the CF card - this brings
> me back to the question I originally posed and tejun answered - is
> there any way to force it to use UDMA4 - because I know it is
> supported by the card?

If it is offered by the card it should be automatically selected. Can you
mail me the hdparm identify data for the drive ?
> 
> Also, the CF-IDE bridge is a cheap one (not that there were much
> choices) from ebay - and the documentation that comes with it states
> that it supports DMA - in which case is there any way I can verify
> that? What are the prerequisites for DMA support? (Do certain pins
> need to be connected, for example?)

For DMA certain pins must be connected correctly. For UDMA the entire
cable assembly including adapter must also meet very strict capacitance
and other loading requirements - few do, especially hung off the end of
cables.

Re: CF as IDE on ICH6M using libata

[Eddie Hung]

On 02/09/07, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > In my research on this issue, I do remember coming across an
> > announcement you made not so long ago regarding the libata.pata_dma
> > command - however because of my revelations with Windows detailed at
> > the end of my reply to tejun, I am curious as to whether MWDMA is
> > really DMA at all? I also believe it runs at about the same speed as
> > the top PIO speeds too?
>
> MWDMA is DMA but MWDMA2 and PIO4 use the same data transfer rates - the
> DMA modes make it easier to offload the processing. In fact MWDMA isn't
> really needed - the Cyrix CS5520 and some other chipsets can do DMA in
> the chipset up to MWDMA while talking PIO4 to the device.
>
> But to answer the question - there is a real difference electrically
> between MWDMA2 and PIO4
>
> > I also know that my SATA-PATA arrangement is hardly ideal - but the
> > controller, using the original HDD, supports udma5 - so I am wondering
> > why it does not detect, and use, that with the CF card - this brings
> > me back to the question I originally posed and tejun answered - is
> > there any way to force it to use UDMA4 - because I know it is
> > supported by the card?
>
> If it is offered by the card it should be automatically selected. Can you
> mail me the hdparm identify data for the drive ?
> >
> > Also, the CF-IDE bridge is a cheap one (not that there were much
> > choices) from ebay - and the documentation that comes with it states
> > that it supports DMA - in which case is there any way I can verify
> > that? What are the prerequisites for DMA support? (Do certain pins
> > need to be connected, for example?)
>
> For DMA certain pins must be connected correctly. For UDMA the entire
> cable assembly including adapter must also meet very strict capacitance
> and other loading requirements - few do, especially hung off the end of
> cables.
>
>

Hello Alan,

I sent a reply to the list with the data that tejun asked for before I
replied to you - I guess you haven't got it (yet?). I'll forward it to
you once I finish this e-mail.

The CF-IDE adaptor is plugged straight into the header - and as far as
I can tell it doesn't do anything fancy (e.g. there are no ICs on
there) - but simply maps the pins from the CF slot to the IDE
connector. As such, its effect should be minimal...

Eddie

Re: CF as IDE on ICH6M using libata

[Tejun Heo]

drivers/ata/Eddie Hung wrote:
> ATA device, with non-removable media
> 	Model Number:       SMI MODEL
> 	Serial Number:      SZAUSWIN    000006E5
> 	Firmware Revision:  20070709
> Standards:
> 	Likely used: 5
> Configuration:
> 	Logical		max	current
> 	cylinders	7866	7866
> 	heads		16	16
> 	sectors/track	63	63
> 	--
> 	CHS current addressable sectors:    7928928
> 	LBA    user addressable sectors:    7928928
> 	device size with M = 1024*1024:        3871 MBytes
> 	device size with M = 1000*1000:        4059 MBytes (4 GB)
> Capabilities:
> 	LBA, IORDY(may be)(cannot be disabled)
> 	bytes avail on r/w long: 4
> 	Standby timer values: spec'd by Vendor
> 	R/W multiple sector transfer: Max = 1	Current = 0
> 	DMA: mdma0 mdma1 *mdma2

Yeap, your device's best mode is mwdma2.

> [    4.504000] ata1.00: ATA-0: SMI MODEL, 20070709, max MWDMA2
> [    4.504000] ata1.00: 7928928 sectors, multi 0: LBA
> [    4.504000] ata1.00: applying bridge limits
> [    4.520000] ata1.00: configured for MWDMA2
[--snip--]
> [ 1301.836000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> [ 1301.836000] ata1.00: cmd ca/00:80:50:55:1f/00:00:00:00:00/e0 tag 0
> cdb 0x0 data 65536 out
> [ 1301.836000]          res 40/00:00:00:00:00/00:00:00:00:00/e0 Emask
> 0x4 (timeout)
> ** End ***
> 
> I can see that it falls back from MWDMA2 to MWDMA1, but it doesn't
> fall back again to Single Word DMA?

libata doesn't use SWDMA.  SWDMA is pointless to support.  It buys
almost nothing over PIO modes.  The condition to fall back to PIO is
very strict to prevent premature fall back.  I think it needs some
relaxation and special handling for cases where DMA transfer has never
succeeded after configuration so that it can fall back more easily.

> What is very strange also is that I can mount the NTFS drive just
> fine, and copy 70Mb of files off it (pretty nippily, I might add =D) -
> without any timeouts, but as soon as I tried to do something
> "lowlevel" to the disk (i.e. as you may have spotted, I used gparted
> to try and resize the NTFS partition, so I could try and run mkfs.ext3
> again - which was what caused the timeouts when I originally tried to
> install.

Hmmm.. it could be that the timeouts occur only on write or are
dependent on transfer size.  You should be able to find out what causes
the timeouts by playing with dd with 'direct' added to iflag and oflag.

> I can confirm that my chipset does indeed support UDMA, here is the
> hdparm -I report on my original disk:

Yeah, it's really difficult to come by a controller which doesn't
support UDMA these days.

> In regards to Windows performance: I have been using the tool HDTune
> to see which mode the device is in - and it reports Multiword DMA 2.
> Also, the benchmark facility with HDTune reveals that the burst speed
> of the drive is 2MB - consistent with the hdparm -t speed when
> ide-generic is used.
> 
> Strangely enough, I've gone into Device Manager, and the transfer mode
> Windows claims it is using is PIO, which seems to be contradictory to
> what HDTune is telling me (and leads me to ask another question, I've
> included in my reply to Alan) I've also tried to various registry
> settings to try and force the device into UDMA or PIO, to no success -
> as far as I can tell MWDMA may well be the lowest speed Windows XP
> supports operating devices at?

WXP uses PIO modes just fine.  I dunno how HDTune determines the current
transfer mode but if it uses IDENTIFY to query the device setting, it's
possible that the device reports MWDMA while the OS drives it in PIO
mode.  The best way to tell is watching cpu usage while transferring
data from the device.  If you're using mwdma, you won't see too high cpu
usage; otherwise, you'll notice high spikes during data transfer.  Can
you please try that and report?

Thanks.

-- 
tejun

Re: CF as IDE on ICH6M using libata

[Eddie Hung]

On 03/09/07, Tejun Heo <htejun@gmail.com> wrote:
> > [    4.504000] ata1.00: ATA-0: SMI MODEL, 20070709, max MWDMA2
> > [    4.504000] ata1.00: 7928928 sectors, multi 0: LBA
> > [    4.504000] ata1.00: applying bridge limits
> > [    4.520000] ata1.00: configured for MWDMA2
> [--snip--]
> > [ 1301.836000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> > [ 1301.836000] ata1.00: cmd ca/00:80:50:55:1f/00:00:00:00:00/e0 tag 0
> > cdb 0x0 data 65536 out
> > [ 1301.836000]          res 40/00:00:00:00:00/00:00:00:00:00/e0 Emask
> > 0x4 (timeout)
> > ** End ***
> >
> > I can see that it falls back from MWDMA2 to MWDMA1, but it doesn't
> > fall back again to Single Word DMA?
>
> libata doesn't use SWDMA.  SWDMA is pointless to support.  It buys
> almost nothing over PIO modes.  The condition to fall back to PIO is
> very strict to prevent premature fall back.  I think it needs some
> relaxation and special handling for cases where DMA transfer has never
> succeeded after configuration so that it can fall back more easily.

Sorry, by SWDMA I meant PIO4 - and as the log shows - it does not seem
to drop from MWDMA1 to the PIO modes - even after about 15 minutes.

> > What is very strange also is that I can mount the NTFS drive just
> > fine, and copy 70Mb of files off it (pretty nippily, I might add =D) -
> > without any timeouts, but as soon as I tried to do something
> > "lowlevel" to the disk (i.e. as you may have spotted, I used gparted
> > to try and resize the NTFS partition, so I could try and run mkfs.ext3
> > again - which was what caused the timeouts when I originally tried to
> > install.
>
> Hmmm.. it could be that the timeouts occur only on write or are
> dependent on transfer size.  You should be able to find out what causes
> the timeouts by playing with dd with 'direct' added to iflag and oflag.

I'll look into that when I get home from work.

> > I can confirm that my chipset does indeed support UDMA, here is the
> > hdparm -I report on my original disk:
>
> Yeah, it's really difficult to come by a controller which doesn't
> support UDMA these days.

So from that, we can determine that the CF card doesn't support UDMA
(or if you're being optimistic like I am - it doesn't report it, or it
doesn't report it in a way which the controller recognises)

> > In regards to Windows performance: I have been using the tool HDTune
> > to see which mode the device is in - and it reports Multiword DMA 2.
> > Also, the benchmark facility with HDTune reveals that the burst speed
> > of the drive is 2MB - consistent with the hdparm -t speed when
> > ide-generic is used.
> >
> > Strangely enough, I've gone into Device Manager, and the transfer mode
> > Windows claims it is using is PIO, which seems to be contradictory to
> > what HDTune is telling me (and leads me to ask another question, I've
> > included in my reply to Alan) I've also tried to various registry
> > settings to try and force the device into UDMA or PIO, to no success -
> > as far as I can tell MWDMA may well be the lowest speed Windows XP
> > supports operating devices at?
>
> WXP uses PIO modes just fine.  I dunno how HDTune determines the current
> transfer mode but if it uses IDENTIFY to query the device setting, it's
> possible that the device reports MWDMA while the OS drives it in PIO
> mode.  The best way to tell is watching cpu usage while transferring
> data from the device.  If you're using mwdma, you won't see too high cpu
> usage; otherwise, you'll notice high spikes during data transfer.  Can
> you please try that and report?

Like I said before, the CF card is operating extremely slowly: HDTune
shows that I'm getting 2MB/s burst which often drops to about 0.1MB/s
- and the qualitative observation is the same as what I get when I'm
using ide-generic.

My X41 has a 1.5Ghz P4M, and a 0.1MB/s hit (if it is using PIO) is
hardly going to make a dent - I'm fairly sure that it is spending most
of its time waiting for IO, but I shall take a deeper look tonight.

I believe the transfer mode is set in the registry - though I've not
been able to find any documentation that explains their values. I've
tried guessing and setting some lower values/bits, but not had any
success.

What's confusing me is that my 40MB/s card only supporting MWDMA2 -
which offers only a max transfer rate of 16.7MB/s - how have other
people achieved 30MB/s then!?! (I'm referring to an ICH8 user who
claims he has here, with a very similar CF card:
http://www.opensubscriber.com/message/linux-ide@vger.kernel.org/6818048.html

Also, does libATA support the PIO5 and PIO6 modes, which according to
Wikipedia are not part of the ATA standard, but the CF 2.0 standard?
(source: http://en.wikipedia.org/wiki/Programmed_input/output )

Many thanks,

Eddie

Re: CF as IDE on ICH6M using libata

[Tejun Heo]

Eddie Hung wrote:
>> libata doesn't use SWDMA.  SWDMA is pointless to support.  It buys
>> almost nothing over PIO modes.  The condition to fall back to PIO is
>> very strict to prevent premature fall back.  I think it needs some
>> relaxation and special handling for cases where DMA transfer has never
>> succeeded after configuration so that it can fall back more easily.
> 
> Sorry, by SWDMA I meant PIO4 - and as the log shows - it does not seem
> to drop from MWDMA1 to the PIO modes - even after about 15 minutes.

Yeah, it seems the logic can't speed down to PIO only with timeouts.
The condition is more than 10 Cat-1 + Cat-2 + Cat-3 errors in 5 mins.
The timeout is 30secs so you can't do 10 of them within 5 mins.  It
needs fixing.

>>> I can confirm that my chipset does indeed support UDMA, here is the
>>> hdparm -I report on my original disk:
>> Yeah, it's really difficult to come by a controller which doesn't
>> support UDMA these days.
> 
> So from that, we can determine that the CF card doesn't support UDMA
> (or if you're being optimistic like I am - it doesn't report it, or it
> doesn't report it in a way which the controller recognises)

The report mechanism is simple and the controller doesn't have much to
do with it.  Bridge chip may affect it but I'm doubtful.

>> WXP uses PIO modes just fine.  I dunno how HDTune determines the current
>> transfer mode but if it uses IDENTIFY to query the device setting, it's
>> possible that the device reports MWDMA while the OS drives it in PIO
>> mode.  The best way to tell is watching cpu usage while transferring
>> data from the device.  If you're using mwdma, you won't see too high cpu
>> usage; otherwise, you'll notice high spikes during data transfer.  Can
>> you please try that and report?
> 
> Like I said before, the CF card is operating extremely slowly: HDTune
> shows that I'm getting 2MB/s burst which often drops to about 0.1MB/s
> - and the qualitative observation is the same as what I get when I'm
> using ide-generic.
> 
> My X41 has a 1.5Ghz P4M, and a 0.1MB/s hit (if it is using PIO) is
> hardly going to make a dent - I'm fairly sure that it is spending most
> of its time waiting for IO, but I shall take a deeper look tonight.

The beautiful thing about PIO is that it doesn't matter how fast your
cpu is.  Faster CPUs will just burn more cycles while transferring data
at the same measly speed. :-)

> What's confusing me is that my 40MB/s card only supporting MWDMA2 -
> which offers only a max transfer rate of 16.7MB/s - how have other
> people achieved 30MB/s then!?! (I'm referring to an ICH8 user who
> claims he has here, with a very similar CF card:
> http://www.opensubscriber.com/message/linux-ide@vger.kernel.org/6818048.html

Whatever the device is, it should support UDMA to do 30MB/s.  MWDMA2
just can't reach that speed electronically.

> Also, does libATA support the PIO5 and PIO6 modes, which according to
> Wikipedia are not part of the ATA standard, but the CF 2.0 standard?
> (source: http://en.wikipedia.org/wiki/Programmed_input/output )

I dunno much about those fancy PIO modes.  Maybe Alan knows?

Thanks.

-- 
tejun

Re: CF as IDE on ICH6M using libata

[Eddie Hung]

On 03/09/07, Tejun Heo <htejun@gmail.com> wrote:
> The report mechanism is simple and the controller doesn't have much to
> do with it.  Bridge chip may affect it but I'm doubtful.

> >
> > My X41 has a 1.5Ghz P4M, and a 0.1MB/s hit (if it is using PIO) is
> > hardly going to make a dent - I'm fairly sure that it is spending most
> > of its time waiting for IO, but I shall take a deeper look tonight.
>
> The beautiful thing about PIO is that it doesn't matter how fast your
> cpu is.  Faster CPUs will just burn more cycles while transferring data
> at the same measly speed. :-)

Ahh yes, that makes sense - it's more about the time it takes rather
than the cycles consumed...

> > What's confusing me is that my 40MB/s card only supporting MWDMA2 -
> > which offers only a max transfer rate of 16.7MB/s - how have other
> > people achieved 30MB/s then!?! (I'm referring to an ICH8 user who
> > claims he has here, with a very similar CF card:
> > http://www.opensubscriber.com/message/linux-ide@vger.kernel.org/6818048.html
>
> Whatever the device is, it should support UDMA to do 30MB/s.  MWDMA2
> just can't reach that speed electronically.

Sorry, I was implying that he mustn't be using MWDMA to achieve them
sort of speeds, and indeed from his hdparm -I he is not. I'm currently
in touch with an X41 user who has reported success with a different CF
card, who is getting 35MB/s and 0.2ms access time under Windows
*drool*

> > Also, does libATA support the PIO5 and PIO6 modes, which according to
> > Wikipedia are not part of the ATA standard, but the CF 2.0 standard?
> > (source: http://en.wikipedia.org/wiki/Programmed_input/output )
>
> I dunno much about those fancy PIO modes.  Maybe Alan knows?

>From the wiki article, I get the impression that the faster PIO modes
are simply lower cycle times, with everything else more or less the
same - so that shouldn't be too hard to add if it's not already there?
More importantly I guess, I wonder if hdparm -I supports the detection
of pio5 or pio6? I'll dig into the sources later.

Thanks,

Eddie

Re: CF as IDE on ICH6M using libata

[Eddie Hung]

On 03/09/07, Eddie Hung <eddie.hung@gmail.com> wrote:
> On 03/09/07, Tejun Heo <htejun@gmail.com> wrote:
> > The report mechanism is simple and the controller doesn't have much to
> > do with it.  Bridge chip may affect it but I'm doubtful.
>
> > >
> > > My X41 has a 1.5Ghz P4M, and a 0.1MB/s hit (if it is using PIO) is
> > > hardly going to make a dent - I'm fairly sure that it is spending most
> > > of its time waiting for IO, but I shall take a deeper look tonight.
> >
> > The beautiful thing about PIO is that it doesn't matter how fast your
> > cpu is.  Faster CPUs will just burn more cycles while transferring data
> > at the same measly speed. :-)
>
> Ahh yes, that makes sense - it's more about the time it takes rather
> than the cycles consumed...
>
> > > What's confusing me is that my 40MB/s card only supporting MWDMA2 -
> > > which offers only a max transfer rate of 16.7MB/s - how have other
> > > people achieved 30MB/s then!?! (I'm referring to an ICH8 user who
> > > claims he has here, with a very similar CF card:
> > > http://www.opensubscriber.com/message/linux-ide@vger.kernel.org/6818048.html
> >
> > Whatever the device is, it should support UDMA to do 30MB/s.  MWDMA2
> > just can't reach that speed electronically.
>
> Sorry, I was implying that he mustn't be using MWDMA to achieve them
> sort of speeds, and indeed from his hdparm -I he is not. I'm currently
> in touch with an X41 user who has reported success with a different CF
> card, who is getting 35MB/s and 0.2ms access time under Windows
> *drool*
>
> > > Also, does libATA support the PIO5 and PIO6 modes, which according to
> > > Wikipedia are not part of the ATA standard, but the CF 2.0 standard?
> > > (source: http://en.wikipedia.org/wiki/Programmed_input/output )
> >
> > I dunno much about those fancy PIO modes.  Maybe Alan knows?
>
> From the wiki article, I get the impression that the faster PIO modes
> are simply lower cycle times, with everything else more or less the
> same - so that shouldn't be too hard to add if it's not already there?
> More importantly I guess, I wonder if hdparm -I supports the detection
> of pio5 or pio6? I'll dig into the sources later.
>
> Thanks,
>
> Eddie
>

I am pursuing another possibility: the CF card is not a genuine
Sandisk one at all, especially as it was off eBay! I compared my
hdparm -I with the one in the thread above (which as I've found out is
a Sandisk Extreme II 4GB) and there are big differences, namely the
model number, serial number and firmware version.

This might explain everything!

Eddie

Re: CF as IDE on ICH6M using libata

[Tejun Heo]

Eddie Hung wrote:
> I am pursuing another possibility: the CF card is not a genuine
> Sandisk one at all, especially as it was off eBay! I compared my
> hdparm -I with the one in the thread above (which as I've found out is
> a Sandisk Extreme II 4GB) and there are big differences, namely the
> model number, serial number and firmware version.
> 
> This might explain everything!

We still need to fix your device.  :-)

-- 
tejun

Re: CF as IDE on ICH6M using libata

[Eddie Hung]

On 03/09/07, Tejun Heo <htejun@gmail.com> wrote:
> Eddie Hung wrote:
> > I am pursuing another possibility: the CF card is not a genuine
> > Sandisk one at all, especially as it was off eBay! I compared my
> > hdparm -I with the one in the thread above (which as I've found out is
> > a Sandisk Extreme II 4GB) and there are big differences, namely the
> > model number, serial number and firmware version.
> >
> > This might explain everything!
>
> We still need to fix your device.  :-)
>

Haha.. well if the CF card is cheap knockoff which doesn't support
MDMA (or does it extremely, extremely badly) then we have our culprit!

I am beginning to be more and more inclined to think that it's a fake
(the packaging and presentation was the genuine deal, though!) - and
I'm in touch with Sandisk to confirm. I've not found that much
information on the Internet - but one particularly interesting post is
that another user had bought a Kingston card off ebay, and his -I is
very similar to mine. For the record:

Kingston Elite Pro 45x (possibly fake):
ATA device, with non-removable media
Model Number: SMI MODEL
Serial Number: AS 0055FA00
Firmware Revision: 20070131

Source; http://1src.com/forums/showpost.php?p=993663&postcount=655

Don't forget my device works just fine with the original HDD, though!

Eddie

Re: CF as IDE on ICH6M using libata

[Eddie Hung]

On 03/09/07, Tejun Heo <htejun@gmail.com> wrote:
> Eddie Hung wrote:
> > I am pursuing another possibility: the CF card is not a genuine
> > Sandisk one at all, especially as it was off eBay! I compared my
> > hdparm -I with the one in the thread above (which as I've found out is
> > a Sandisk Extreme II 4GB) and there are big differences, namely the
> > model number, serial number and firmware version.
> >
> > This might explain everything!
>
> We still need to fix your device.  :-)
>
> --
> tejun
>

Uhm.. it seems like I spoke too soon!

I have now acquired a Sandisk Extreme III 8GB CF card, from a
reputable source, but it doesn't support UDMA as the Extreme IV card
was supposed to... and this means I'm getting MWDMA again - and the
same timeout problems!

I had previously blamed the timeout problems on it being a completely
naff card which wasn't standards compliant, but now I know this can't
be the case.

Here is the hdparm:

/dev/sda:

CompactFlash ATA device, with removable media
	Model Number:       SanDisk SDCFX3-8192
	Serial Number:      019324G2207I5851
	Firmware Revision:  HDX 4.03
Standards:
	Supported: 4
	Likely used: 4
Configuration:
	Logical		max	current
	cylinders	15880	15880
	heads		16	16
	sectors/track	63	63
	--
	CHS current addressable sectors:   16007040
	LBA    user addressable sectors:   16007040
	device size with M = 1024*1024:        7815 MBytes
	device size with M = 1000*1000:        8195 MBytes (8 GB)
Capabilities:
	LBA, IORDY(may be)(cannot be disabled)
	Standby timer values: spec'd by Vendor
	R/W multiple sector transfer: Max = 4	Current = 0
	DMA: mdma0 mdma1 *mdma2
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4
	     Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
	Enabled	Supported:
	    	Write cache
	   *	CFA feature set
	   *	CFA advanced modes: pio5 *pio6

Note that it does identify PIO5 and PIO6 (answering my previous
question), with PIO6 even starred. I got about 9MB/s under hdparm,
too.

However, the timeouts remain, I triggered it again by doing a mkfs.ext3.

Any ideas?

Thanks,

Eddie

Re: CF as IDE on ICH6M using libata

[Mark Lord]

Tejun Heo wrote:
> ..
> I don't think the device supports UDMA.  Supported transfer modes are
> indicated in the IDENTIFY page (hdparm -I) and libata/ide would use UDMA
> if the device reports so.  There's no black magic there.
> 
>

Some newer CF Cards have a funky way of reporting UDMA.
Get a copy of hdparm-7.7 (sourceforge) and try "hdparm -I"
using it, and post the output here.

We may (or not) need to update libata to recognize UDMA on CF cards.

Cheers

Re: CF as IDE on ICH6M using libata

[Eddie Hung]

Hello all,

After trying a fake Extreme IV, then an Extreme III (which doesn't
support UDMA) and then back onto another Extreme IV - I can finally
report success!

I am now using UDMA4 and enjoying speeds of 30+MB/s which is all very
nice!!! (The other X41 user who reported success was also using a UDMA
capable card)

However, I think we can conclude that ICH6M (which on the X41, has a
SATA-PATA bridge to connect a PATA drive) does not seem to support
MWDMA (especially as it is not completely supported under Windows
either - it is *incredibly* slow but does not give the same timeout
problems as with libata), nor does libata it drop down gracefully to
PIO4 when it detects these timeouts.

Thanks everybody,

Eddie

On 05/09/07, Mark Lord <liml@rtr.ca> wrote:
> Tejun Heo wrote:
> > ..
> > I don't think the device supports UDMA.  Supported transfer modes are
> > indicated in the IDENTIFY page (hdparm -I) and libata/ide would use UDMA
> > if the device reports so.  There's no black magic there.
> >
> >
>
> Some newer CF Cards have a funky way of reporting UDMA.
> Get a copy of hdparm-7.7 (sourceforge) and try "hdparm -I"
> using it, and post the output here.
>
> We may (or not) need to update libata to recognize UDMA on CF cards.
>
> Cheers
>

Re: CF as IDE on ICH6M using libata

[Tejun Heo]

Eddie Hung wrote:
> However, I think we can conclude that ICH6M (which on the X41, has a
> SATA-PATA bridge to connect a PATA drive) does not seem to support
> MWDMA

It isn't clear whether the fault is at the driver or the CF device.

> (especially as it is not completely supported under Windows
> either - it is *incredibly* slow but does not give the same timeout
> problems as with libata),

Please verify which mode is in use in Windows.  Just watching cpu usage
in the task manager while transferring data should give you a pretty
good idea.

> nor does libata it drop down gracefully to
> PIO4 when it detects these timeouts.

Yeah, this is a bug to fix.

Thanks.

-- 
tejun

Re: CF as IDE on ICH6M using libata

[Tejun Heo]

[adding-back linux-ide, please don't drop cc's]

Eddie Hung wrote:
> On 06/09/07, Tejun Heo <htejun@gmail.com> wrote:
>> Eddie Hung wrote:
>>> However, I think we can conclude that ICH6M (which on the X41, has a
>>> SATA-PATA bridge to connect a PATA drive) does not seem to support
>>> MWDMA
>> It isn't clear whether the fault is at the driver or the CF device.
> 
> I have tried two separate CF cards which support MWDMA, and they both
> exhibit the same problems. You're right in that it could potentially
> be the CF-IDE adapter - but the adapter works with UDMA, so I'm
> guessing it should also work with MWDMA?

Not really.  MWDMA support seems especially wonky on CF devices.  I'm
not completely sure whether MWDMA support is broken on ata_piix or there
are just a lot of broken CF devices because windows doesn't use MWDMA.

>>> (especially as it is not completely supported under Windows
>>> either - it is *incredibly* slow but does not give the same timeout
>>> problems as with libata),
>> Please verify which mode is in use in Windows.  Just watching cpu usage
>> in the task manager while transferring data should give you a pretty
>> good idea.
> 
> I no longer have Windows installed (it is frustratingly, frustratingly
> slow regardless - which in my books means something definitely isn't
> right).

Aieeee... We need confirmation.

> There also seems to be some ambiguity (at least in libata) where MWDMA
> is associated with PIO (i.e. one of my error messages was something
> along the lines of: "dropping down to MWDMA1:PIO4" - which is maybe
> what Windows is doing as well?

PIO mode is always configured no matter which DMA mode is used.
Significant part of ATA depends on PIO (e.g. transferring commands to
the device, IDENTIFY, ...)

So that we can blacklist them, please post 'hdparm -I' results of both
devices with MWDMA.

Alan, Jeff, if windows doesn't use MWMDA on CF devices, I think we
probably shouldn't either.  I don't think supporting MWDMA is worth the
trouble considering only small fraction of this type of problems would
make it to linux-ide or bugzilla.

Thanks.

-- 
tejun

Re: CF as IDE on ICH6M using libata

[Mark Lord]

Tejun Heo wrote:
> Eddie Hung wrote:
>> However, I think we can conclude that ICH6M (which on the X41, has a
>> SATA-PATA bridge to connect a PATA drive) does not seem to support
>> MWDMA
> 
> It isn't clear whether the fault is at the driver or the CF device.

It's probably the bridge chip --> we've run through that one before
just recently (early summer?) on this list.  A particular bridge that
doesn't work at all with MWDMA.

Cheers

Re: CF as IDE on ICH6M using libata

[Tejun Heo]

Mark Lord wrote:
> Tejun Heo wrote:
>> Eddie Hung wrote:
>>> However, I think we can conclude that ICH6M (which on the X41, has a
>>> SATA-PATA bridge to connect a PATA drive) does not seem to support
>>> MWDMA
>>
>> It isn't clear whether the fault is at the driver or the CF device.
> 
> It's probably the bridge chip --> we've run through that one before
> just recently (early summer?) on this list.  A particular bridge that
> doesn't work at all with MWDMA.

Hmmm... How do we solve this situation?  Till now, we've been
blacklisting the device IDs but it doesn't work for broken bridges.
Maybe we should default to not using MWDMA by default?

-- 
tejun

Re: CF as IDE on ICH6M using libata

[Mark Lord]

Tejun Heo wrote:
> Mark Lord wrote:
>> Tejun Heo wrote:
>>> Eddie Hung wrote:
>>>> However, I think we can conclude that ICH6M (which on the X41, has a
>>>> SATA-PATA bridge to connect a PATA drive) does not seem to support
>>>> MWDMA
>>> It isn't clear whether the fault is at the driver or the CF device.
>> It's probably the bridge chip --> we've run through that one before
>> just recently (early summer?) on this list.  A particular bridge that
>> doesn't work at all with MWDMA.
> 
> Hmmm... How do we solve this situation?  Till now, we've been
> blacklisting the device IDs but it doesn't work for broken bridges.
> Maybe we should default to not using MWDMA by default?

Alan has observed that we really need to have a way to identify the bridge chip.
But those seem to be mostly invisible to ordinary commands.  Perhaps somebody
at Marvell might give us the vendor-specific commands required to do this.

Failing that, we cannot do it automatically, so we really do need some kind
of boot/module/sysfs method for overriding libata's chosen transfer method.

Blacklisting doesn't work here, because we really need to blacklist
the invisible bridge chip, not the main chipset or the device.

Cheers

Re: CF as IDE on ICH6M using libata

[Alan Cox]

On Wed, 05 Sep 2007 13:28:11 -0400
Mark Lord <liml@rtr.ca> wrote:

> Tejun Heo wrote:
> > ..
> > I don't think the device supports UDMA.  Supported transfer modes are
> > indicated in the IDENTIFY page (hdparm -I) and libata/ide would use UDMA
> > if the device reports so.  There's no black magic there.
> > 
> >
> 
> Some newer CF Cards have a funky way of reporting UDMA.
> Get a copy of hdparm-7.7 (sourceforge) and try "hdparm -I"
> using it, and post the output here.
> 
> We may (or not) need to update libata to recognize UDMA on CF cards.

Is there any more (standards type) information on this and what is
needed ?

Re: CF as IDE on ICH6M using libata

[Mark Lord]

Alan Cox wrote:
> On Wed, 05 Sep 2007 13:28:11 -0400
> Mark Lord <liml@rtr.ca> wrote:

>> We may (or not) need to update libata to recognize UDMA on CF cards.
> 
> Is there any more (standards type) information on this and what is
> needed ?

No update required, as CF cards mimic regular drives well enough for this.
The weird stuff I was thinking of is only applicable to non "True IDE" modes.

Cheers