confusion about libata.force=80c

[Tom Sylla]

I have a platform with a single CompactFlash socket connected to a
Broadcom HT1000's PATA port. With libata's pata_serverworks, it ends
up using drive-side 80-conductor cable detection (Broadcom provides no
cable bits for the BIOS to report what is attached). The
CompactFlashes I am using mis-report the cable type, and
pata_serverworks limits to UDMA2. I tried to use the recent addition
of libata.force, but it does not seem to work like I would expect it
to. An excerpt from dmesg:

scsi4 : pata_serverworks
scsi5 : pata_serverworks
ata5: PATA max UDMA/66 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
ata6: PATA max UDMA/66 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
ata5: FORCE: cable set to 80c
ata5.00: ATA-4: CF CARD, 20080308, max UDMA/66
ata5.00: 15662304 sectors, multi 0: LBA
ata5.00: limited to UDMA/33 due to 40-wire cable
ata5.00: configured for UDMA/33

The force parameter is certainly getting accepted, but then 3 lines
later, it believes it has a 40 conductor cable.

I have attached the full dmesg. This is vanilla 2.6.25.3 with "options
libata force=80c" added in the initrd.

Yes, I know I should just get a more well-behaved device, but both of
the high-speed (UDMA) CFs I am using mis-report the cable detection. I
would bet many other high-speed CFs do the same. I have already
contacted the CF manufacturer to look into it. For now, though, I'd
like to run UDMA4, and the force parameter seems like it would do what
I want.

Is force=80c what I want? Should it work?

Thanks

[Tom Sylla]

Anyone have a comment? All I am asking for now is if this *should*
work or not. Is force=80c supposed to do what I want?


---------- Forwarded message ----------
From: Tom Sylla <***@gmail.com>
Date: Wed, May 14, 2008 at 2:20 PM
Subject: confusion about libata.force=80c
To: linux-***@vger.kernel.org


I have a platform with a single CompactFlash socket connected to a
Broadcom HT1000's PATA port. With libata's pata_serverworks, it ends
up using drive-side 80-conductor cable detection (Broadcom provides no
cable bits for the BIOS to report what is attached). The
CompactFlashes I am using mis-report the cable type, and
pata_serverworks limits to UDMA2. I tried to use the recent addition
of libata.force, but it does not seem to work like I would expect it
to. An excerpt from dmesg:

scsi4 : pata_serverworks
scsi5 : pata_serverworks
ata5: PATA max UDMA/66 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
ata6: PATA max UDMA/66 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
ata5: FORCE: cable set to 80c
ata5.00: ATA-4: CF CARD, 20080308, max UDMA/66
ata5.00: 15662304 sectors, multi 0: LBA
ata5.00: limited to UDMA/33 due to 40-wire cable
ata5.00: configured for UDMA/33

The force parameter is certainly getting accepted, but then 3 lines
later, it believes it has a 40 conductor cable.

I have attached the full dmesg. This is vanilla 2.6.25.3 with "options
libata force=80c" added in the initrd.

Yes, I know I should just get a more well-behaved device, but both of
the high-speed (UDMA) CFs I am using mis-report the cable detection. I
would bet many other high-speed CFs do the same. I have already
contacted the CF manufacturer to look into it. For now, though, I'd
like to run UDMA4, and the force parameter seems like it would do what
I want.

Is force=80c what I want? Should it work?

Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Tejun Heo]

Post by Tom Sylla
Anyone have a comment? All I am asking for now is if this *should*
work or not. Is force=80c supposed to do what I want?
---------- Forwarded message ----------
Date: Wed, May 14, 2008 at 2:20 PM
Subject: confusion about libata.force=80c
I have a platform with a single CompactFlash socket connected to a
Broadcom HT1000's PATA port. With libata's pata_serverworks, it ends
up using drive-side 80-conductor cable detection (Broadcom provides no
cable bits for the BIOS to report what is attached). The
CompactFlashes I am using mis-report the cable type, and
pata_serverworks limits to UDMA2. I tried to use the recent addition
of libata.force, but it does not seem to work like I would expect it
scsi4 : pata_serverworks
scsi5 : pata_serverworks
ata5: PATA max UDMA/66 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
ata6: PATA max UDMA/66 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
ata5: FORCE: cable set to 80c
ata5.00: ATA-4: CF CARD, 20080308, max UDMA/66
ata5.00: 15662304 sectors, multi 0: LBA
ata5.00: limited to UDMA/33 due to 40-wire cable
ata5.00: configured for UDMA/33
The force parameter is certainly getting accepted, but then 3 lines
later, it believes it has a 40 conductor cable.
I have attached the full dmesg. This is vanilla 2.6.25.3 with "options
libata force=80c" added in the initrd.
Yes, I know I should just get a more well-behaved device, but both of
the high-speed (UDMA) CFs I am using mis-report the cable detection. I
would bet many other high-speed CFs do the same. I have already
contacted the CF manufacturer to look into it. For now, though, I'd
like to run UDMA4, and the force parameter seems like it would do what
I want.
Is force=80c what I want? Should it work?

It should but is overridden by device side cable detection upto 2.6.25.
2.6.26 will have it fixed. force=udma66 should work.

[Tomas Kindl]

Post by Tejun Heo

Post by Tom Sylla
Is force=80c what I want? Should it work?

It should but is overridden by device side cable detection upto 2.6.25.
2.6.26 will have it fixed. force=udma66 should work.

Hi, I get same error (Unknown boot option `libata.force=3:1.5': ignoring
) although I am trying it on 2.6.27.4 (MDV flavor - but still).

Any help?

Thanks...




--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Tejun Heo]

Post by Tomas Kindl

Post by Tejun Heo

Post by Tom Sylla
Is force=80c what I want? Should it work?

It should but is overridden by device side cable detection upto 2.6.25.
2.6.26 will have it fixed. force=udma66 should work.

Hi, I get same error (Unknown boot option `libata.force=3:1.5': ignoring
) although I am trying it on 2.6.27.4 (MDV flavor - but still).

That's not a kernel problem but how module parameters are passed to
modules loaded from initrd and is distro specific. Please note that
kernel will spit the message even when the module parameter is later
picked up by initrd. So, please ping MDV for instructions on how to
pass kernel parameter via initrd.