DMA with 40-pin cable

zenlord · 2008-08-22 14:43:53

Hi,

I have already commented on the fact that pacman runs slowly over here, while both CPU and RAM-usage are very moderate, so there has to be another culprit. Someone already suggested filesystem-problems, but as this installation is fairly young, and I have formatted my hard drive during installation, I wouldn't suspect this.

It has come to my attention that my HD is connected to the mainboard using a 40-pin cable, which limits my HD to UDMA/33, whereas my controller can handle UDMA/100:

dmesg | grep DMA:
ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
ata1.00: ATA-6: FUJITSU MHT2080AT, 0022, max UDMA/100
ata1.00: limited to UDMA/33 due to 40-wire cable
ata1.00: configured for UDMA/33
ata2.00: ATAPI: _NEC DVD+/-RW ND-6500A, 2.40, max UDMA/33
ata2.00: configured for UDMA/33

hdparm -i /dev/sda:
 Model=FUJITSU MHT2080AT                       , FwRev=0022    , SerialNo=        NN7CT4B16R1G
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488
 IORDY=yes, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma5 
 AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 3a:  ATA/ATAPI-2,3,4,5,6

Since it is a laptop, I have to ask:
- is there any peculiar reason why a laptop manufacturer like Fujitsu would use a 40-pin cable when both the mainboard and the hard drive support a higher speed with a 80-pin cable?
- do I risk something using a 80-pin cable should I be able to dig one up?
- will it be *much* faster?

THX!

Zl.
PS1: I know it's not really Arch related, but since I experience the sluggishness almost solely with pacman ...
PS2: If this would be a desktop, I would have tried it already, but I have no experience whatsoever with the insides of a laptop...

11010010110 · 2008-08-22 17:26:30

AFAIK the connection is 40 pin anyway - its just about the cable having 2 wires in parallel for each bit instead of single wire

So it must sense the number of wires by the noise or crosstalk level on the cable etc. which means that a low noise cable may behav good enough to count as 80 wire one even if it isnt

If you dont mind to risk stability you may try to manually experiment with hdparm (read more before you do)

Most laptops dont have any cable - the drive plugs directly into the header on the mainboard (it is inverted - holes and not pins)

some have kinda orange plastic cable made for the specific laptop and often the connection of this cable to the mainboard is not standard but some proprietary connector. There are no replacement cables in this case

.:B:. · 2008-08-22 21:25:48

Are you sure it is a cable and no ZIF socket?

I had this problem a while ago too, I applied a patch to force the the UDMA speed to my HD's max (it's an SSD that does UDMA66 max).

This is how it looks:

diff -Naur linux-2.6.24-old/drivers/ata/libata-core.c linux-2.6.24/drivers/ata/libata-core.c
--- linux-2.6.24-old/drivers/ata/libata-core.c 2008-04-08 23:28:46.000000000 +0200
+++ linux-2.6.24/drivers/ata/libata-core.c 2008-04-09 00:21:54.000000000 +0200
@@ -119,6 +119,10 @@
module_param_named(noacpi, libata_noacpi, int, 0444);
MODULE_PARM_DESC(noacpi, "Disables the use of ACPI in probe/suspend/resume when set");
+int libata_force_cbl = 0;
+module_param_named(force_cbl, libata_force_cbl, int, 0644);
+MODULE_PARM_DESC(force_cbl, "force PATA cable type (0=keep, 40=40c, 80=80c)");
+
MODULE_AUTHOR("Jeff Garzik");
MODULE_DESCRIPTION("Library module for ATA devices");
MODULE_LICENSE("GPL");
@@ -4318,17 +4322,30 @@
   * drive side as well. Cases where we know a 40wire cable
   * is used safely for 80 are not checked here.
   */
- if (xfer_mask & (0xF8 << ATA_SHIFT_UDMA))
- /* UDMA/44 or higher would be available */
- if ((ap->cbl == ATA_CBL_PATA40) ||
-    (ata_is_40wire(dev) &&
-    (ap->cbl == ATA_CBL_PATA_UNK ||
-    ap->cbl == ATA_CBL_PATA80))) {
- ata_dev_printk(dev, KERN_WARNING,
-    "limited to UDMA/33 due to 40-wire cable\n");
- xfer_mask &= ~(0xF8 << ATA_SHIFT_UDMA);
+ if (xfer_mask & (0xF8 << ATA_SHIFT_UDMA)) {
+ switch (libata_force_cbl) {
+ case 40:
+ /* limit to UDMA/33 */
+ ata_dev_printk(dev, KERN_INFO, "forcing 40c\n");
+ xfer_mask &= ~(0xF8 << ATA_SHIFT_UDMA);
+ break;
+ case 80:
+ /* ignore cable checks */
+ ata_dev_printk(dev, KERN_INFO, "forcing 80c\n");
+ break;
+ default:
+ /* UDMA/44 or higher would be available */
+ if ((ap->cbl == ATA_CBL_PATA40) ||
+ (ata_is_40wire(dev) &&
+ (ap->cbl == ATA_CBL_PATA_UNK ||
+ ap->cbl == ATA_CBL_PATA80))) {
+ ata_dev_printk(dev, KERN_WARNING,
+ "limited to UDMA/33 due to 40-wire cable\n");
+ xfer_mask &= ~(0xF8 << ATA_SHIFT_UDMA);
+ }
}
-
+ }
+
ata_unpack_xfermask(xfer_mask, &dev->pio_mask,
   &dev->mwdma_mask, &dev->udma_mask);
}
diff -Naur linux-2.6.24-old/drivers/ata/libata-eh.c linux-2.6.24/drivers/ata/libata-eh.c
--- linux-2.6.24-old/drivers/ata/libata-eh.c 2008-04-08 23:28:46.000000000 +0200
+++ linux-2.6.24/drivers/ata/libata-eh.c 2008-04-09 00:26:39.000000000 +0200
@@ -2296,8 +2296,26 @@
/* PDIAG- should have been released, ask cable type if post-reset */
if (ata_is_host_link(link) && ap->ops->cable_detect &&
-    (ehc->i.flags & ATA_EHI_DID_RESET))
+ (ehc->i.flags & ATA_EHI_DID_RESET)) {
ap->cbl = ap->ops->cable_detect(ap);
+
+ if (!(ap->flags & ATA_FLAG_SATA) && libata_force_cbl) {
+ switch (libata_force_cbl) {
+ case 40:
+ ata_port_printk(ap, KERN_INFO, "forcing 40c\n");
+ ap->cbl = ATA_CBL_PATA40;
+ break;
+ case 80:
+ ata_port_printk(ap, KERN_INFO, "forcing 80c\n");
+ ap->cbl = ATA_CBL_PATA80;
+ break;
+ default:
+ ata_port_printk(ap, KERN_WARNING,
+ "invalid force_cbl value %d\n",
+ libata_force_cbl);
+ }
+ }
+ }
/* Configure new devices forward such that user doesn't see
   * device detection messages backwards.
diff -Naur linux-2.6.24-old/drivers/ata/libata.h linux-2.6.24/drivers/ata/libata.h
--- linux-2.6.24-old/drivers/ata/libata.h 2008-04-08 23:28:46.000000000 +0200
+++ linux-2.6.24/drivers/ata/libata.h 2008-04-08 23:31:53.000000000 +0200
@@ -60,6 +60,7 @@
extern int atapi_passthru16;
extern int libata_fua;
extern int libata_noacpi;
+extern int libata_force_cbl;
extern struct ata_queued_cmd *ata_qc_new_init(struct ata_device *dev);
extern int ata_build_rw_tf(struct ata_taskfile *tf, struct ata_device *dev,
   u64 block, u32 n_block, unsigned int tf_flags,

From 2.6.26 on I don't have any detection problems anymore so I can just use the vanilla kernel. You might want to try this to force it - at your own risk of course . Be sure to add a

libata.force_cbl=80

as a boot parameter on the kernel line of your GRUB config.

Last edited by B (2008-08-22 21:26:59)

zenlord · 2008-08-23 01:03:12

OK - apparently the first thing to do is to check the cable and count the wires

I'll get back on this!

Zl.

rooloo · 2008-08-23 02:24:41

zenlord wrote:

OK - apparently the first thing to do is to check the cable and count the wires
I'll get back on this!
Zl.

you ain't gotta count shit, there is a clear difference between a 40 and 80 wire cable. But as others have said and like you already admitted too. It's a fijitsu(sp). I'd bet my paycheck the connector is proprietary and you won't be able to tell anyway.

Arch Linux

#1 2008-08-22 14:43:53

DMA with 40-pin cable

#2 2008-08-22 17:26:30

Re: DMA with 40-pin cable

#3 2008-08-22 21:25:48

Re: DMA with 40-pin cable

#4 2008-08-23 01:03:12

Re: DMA with 40-pin cable

#5 2008-08-23 02:24:41

Re: DMA with 40-pin cable

Board footer