Kernel 2.6.37 erroneously limiting to UDMA/33

Kernel 2.6.37 erroneously limiting to UDMA/33

[Stephen Clark]

Hello,

Why is the kernel limiting me to udma/33 when the device says it can do
ata2.01: CFA: TRANSCEND, 20070831, max UDMA/66

There is no cable the compact flash is a socket on the motherboard!

Loading sd_mod.ko module
Loading libata.ko module
Loading ata_generic.ko module
Loading pata_acpi.ko module
pata_acpi 0000:00:0f.0: PCI INT B -> GSI 21 (level, low) -> IRQ 21
pata_acpi 0000:00:0f.0: PCI INT B disabled
Loading pata_via.ko module
scsi0 : pata_via
scsi1 : pata_via
ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xfa00 irq 14
ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xfa08 irq 15
ata2.01: CFA: TRANSCEND, 20070831, max UDMA/66
ata2.01: 7962192 sectors, multi 0: LBA
ata2.01: limited to UDMA/33 due to 40-wire cable
ata2.01: configured for UDMA/33
scsi 1:0:1:0: Direct-Access     ATA      TRANSCEND        2007 PQ: 0 ANSI: 5
sd 1:0:1:0: [sda] 7962192 512-byte logical blocks: (4.07 GB/3.79 GiB)
sd 1:0:1:0: [sda] Write Protect is off
sd 1:0:1:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DA
  sda: sda1 sda2 sda3
sd 1:0:1:0: [sda] Attached SCSI disk
Loading ata_piix.ko module

Thanks,
Steve

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Re: Kernel 2.6.37 erroneously limiting to UDMA/33

[Robert Hancock]

(CCing linux-ide)

On 01/05/2011 12:33 PM, Stephen Clark wrote:
> Hello,
>
> Why is the kernel limiting me to udma/33 when the device says it can do
> ata2.01: CFA: TRANSCEND, 20070831, max UDMA/66
>
> There is no cable the compact flash is a socket on the motherboard!

The kernel has no way to know that, and presumably the board isn't 
connecting the signal for IDE pin 34 to ground in order to properly 
signal that an 80-wire cable (or equivalent) is connected so that speeds 
over UDMA33 can be used.

You should be able to use the libata.force=80c option on the kernel 
command line to override the cable detection.

>
> Loading sd_mod.ko module
> Loading libata.ko module
> Loading ata_generic.ko module
> Loading pata_acpi.ko module
> pata_acpi 0000:00:0f.0: PCI INT B -> GSI 21 (level, low) -> IRQ 21
> pata_acpi 0000:00:0f.0: PCI INT B disabled
> Loading pata_via.ko module
> scsi0 : pata_via
> scsi1 : pata_via
> ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xfa00 irq 14
> ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xfa08 irq 15
> ata2.01: CFA: TRANSCEND, 20070831, max UDMA/66
> ata2.01: 7962192 sectors, multi 0: LBA
> ata2.01: limited to UDMA/33 due to 40-wire cable
> ata2.01: configured for UDMA/33
> scsi 1:0:1:0: Direct-Access ATA TRANSCEND 2007 PQ: 0 ANSI: 5
> sd 1:0:1:0: [sda] 7962192 512-byte logical blocks: (4.07 GB/3.79 GiB)
> sd 1:0:1:0: [sda] Write Protect is off
> sd 1:0:1:0: [sda] Write cache: disabled, read cache: enabled, doesn't
> support DA
> sda: sda1 sda2 sda3
> sd 1:0:1:0: [sda] Attached SCSI disk
> Loading ata_piix.ko module
>
> Thanks,
> Steve
>

Re: Kernel 2.6.37 erroneously limiting to UDMA/33

[Andreas Mohr]

Hi,

Robert Hancock wrote:
> On 01/05/2011 12:33 PM, Stephen Clark wrote:
> > Hello,
> >
> > Why is the kernel limiting me to udma/33 when the device says it can do
> > ata2.01: CFA: TRANSCEND, 20070831, max UDMA/66
> >
> > There is no cable the compact flash is a socket on the motherboard!
> 
> The kernel has no way to know that, and presumably the board isn't 
> connecting the signal for IDE pin 34 to ground in order to properly 
> signal that an 80-wire cable (or equivalent) is connected so that speeds 
> over UDMA33 can be used.
> 
> You should be able to use the libata.force=80c option on the kernel 
> command line to override the cable detection.

Further comments for the OP:

If 80c happens to be correct for this machine (since it's soldered
it's quite obvious) and the machine is quite wide-spread, perhaps one needs
to add overrides within drivers/ata/pata_via.c/via_cable_detect() functionality,
analogous to the ata_piix.c/ich_pata_cable_detect() case where it uses
an entire ich_laptop device list to match against,
to detect special 80c compatible cases.

But since pata_via.c has the insightful comment
"Perform cable detection. Actually for the VIA case the BIOS
 already did this for us."
it looks like your BIOS might be considered "broken"
due to not indicating 80c for such a solder job
--> BIOS upgrade available?



And perhaps better avoid mentioning a specific kernel in the subject
line unless it's a regression (which likely isn't the case here),
or write it like "..... (on 2.6.XXX)".

Andreas Mohr

Re: Kernel 2.6.37 erroneously limiting to UDMA/33

[Stephen Clark]

On 01/05/2011 06:50 PM, Robert Hancock wrote:
> (CCing linux-ide)
>
> On 01/05/2011 12:33 PM, Stephen Clark wrote:
>> Hello,
>>
>> Why is the kernel limiting me to udma/33 when the device says it can do
>> ata2.01: CFA: TRANSCEND, 20070831, max UDMA/66
>>
>> There is no cable the compact flash is a socket on the motherboard!
>
> The kernel has no way to know that, and presumably the board isn't 
> connecting the signal for IDE pin 34 to ground in order to properly 
> signal that an 80-wire cable (or equivalent) is connected so that 
> speeds over UDMA33 can be used.
>
> You should be able to use the libata.force=80c option on the kernel 
> command line to override the cable detection.
>
>>
>> Loading sd_mod.ko module
>> Loading libata.ko module
>> Loading ata_generic.ko module
>> Loading pata_acpi.ko module
>> pata_acpi 0000:00:0f.0: PCI INT B -> GSI 21 (level, low) -> IRQ 21
>> pata_acpi 0000:00:0f.0: PCI INT B disabled
>> Loading pata_via.ko module
>> scsi0 : pata_via
>> scsi1 : pata_via
>> ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xfa00 irq 14
>> ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xfa08 irq 15
>> ata2.01: CFA: TRANSCEND, 20070831, max UDMA/66
>> ata2.01: 7962192 sectors, multi 0: LBA
>> ata2.01: limited to UDMA/33 due to 40-wire cable
>> ata2.01: configured for UDMA/33
>> scsi 1:0:1:0: Direct-Access ATA TRANSCEND 2007 PQ: 0 ANSI: 5
>> sd 1:0:1:0: [sda] 7962192 512-byte logical blocks: (4.07 GB/3.79 GiB)
>> sd 1:0:1:0: [sda] Write Protect is off
>> sd 1:0:1:0: [sda] Write cache: disabled, read cache: enabled, doesn't
>> support DA
>> sda: sda1 sda2 sda3
>> sd 1:0:1:0: [sda] Attached SCSI disk
>> Loading ata_piix.ko module
>>
>> Thanks,
>> Steve
>>
>
Thanks, I'll give that a shot.

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Re: Kernel 2.6.37 erroneously limiting to UDMA/33

[Stephen Clark]

On 01/06/2011 05:30 AM, Andreas Mohr wrote:
> Hi,
>
> Robert Hancock wrote:
>    
>> On 01/05/2011 12:33 PM, Stephen Clark wrote:
>>      
>>> Hello,
>>>
>>> Why is the kernel limiting me to udma/33 when the device says it can do
>>> ata2.01: CFA: TRANSCEND, 20070831, max UDMA/66
>>>
>>> There is no cable the compact flash is a socket on the motherboard!
>>>        
>> The kernel has no way to know that, and presumably the board isn't
>> connecting the signal for IDE pin 34 to ground in order to properly
>> signal that an 80-wire cable (or equivalent) is connected so that speeds
>> over UDMA33 can be used.
>>
>> You should be able to use the libata.force=80c option on the kernel
>> command line to override the cable detection.
>>      
> Further comments for the OP:
>
> If 80c happens to be correct for this machine (since it's soldered
> it's quite obvious) and the machine is quite wide-spread, perhaps one needs
> to add overrides within drivers/ata/pata_via.c/via_cable_detect() functionality,
> analogous to the ata_piix.c/ich_pata_cable_detect() case where it uses
> an entire ich_laptop device list to match against,
> to detect special 80c compatible cases.
>
> But since pata_via.c has the insightful comment
> "Perform cable detection. Actually for the VIA case the BIOS
>   already did this for us."
> it looks like your BIOS might be considered "broken"
> due to not indicating 80c for such a solder job
> -->  BIOS upgrade available?
>
>    
Will check. The machine is an Acrosser AR-M0898B micro box, for use such as
a firewall, vpn appliance, etc.
> And perhaps better avoid mentioning a specific kernel in the subject
> line unless it's a regression (which likely isn't the case here),
> or write it like "..... (on 2.6.XXX)".
>
>    
Good point.

> Andreas Mohr
>
>    


-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Re: Kernel 2.6.37 erroneously limiting to UDMA/33

[Stephen Clark]

On 01/05/2011 06:50 PM, Robert Hancock wrote:
> (CCing linux-ide)
>
> On 01/05/2011 12:33 PM, Stephen Clark wrote:
>> Hello,
>>
>> Why is the kernel limiting me to udma/33 when the device says it can do
>> ata2.01: CFA: TRANSCEND, 20070831, max UDMA/66
>>
>> There is no cable the compact flash is a socket on the motherboard!
>
> The kernel has no way to know that, and presumably the board isn't 
> connecting the signal for IDE pin 34 to ground in order to properly 
> signal that an 80-wire cable (or equivalent) is connected so that 
> speeds over UDMA33 can be used.
>
> You should be able to use the libata.force=80c option on the kernel 
> command line to override the cable detection.
>
>>
>> Loading sd_mod.ko module
>> Loading libata.ko module
>> Loading ata_generic.ko module
>> Loading pata_acpi.ko module
>> pata_acpi 0000:00:0f.0: PCI INT B -> GSI 21 (level, low) -> IRQ 21
>> pata_acpi 0000:00:0f.0: PCI INT B disabled
>> Loading pata_via.ko module
>> scsi0 : pata_via
>> scsi1 : pata_via
>> ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xfa00 irq 14
>> ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xfa08 irq 15
>> ata2.01: CFA: TRANSCEND, 20070831, max UDMA/66
>> ata2.01: 7962192 sectors, multi 0: LBA
>> ata2.01: limited to UDMA/33 due to 40-wire cable
>> ata2.01: configured for UDMA/33
>> scsi 1:0:1:0: Direct-Access ATA TRANSCEND 2007 PQ: 0 ANSI: 5
>> sd 1:0:1:0: [sda] 7962192 512-byte logical blocks: (4.07 GB/3.79 GiB)
>> sd 1:0:1:0: [sda] Write Protect is off
>> sd 1:0:1:0: [sda] Write cache: disabled, read cache: enabled, doesn't
>> support DA
>> sda: sda1 sda2 sda3
>> sd 1:0:1:0: [sda] Attached SCSI disk
>> Loading ata_piix.ko module
>>
>> Thanks,
>> Steve
>>
>

Hmm... libata.force=80c - didn't seem to work.

   Booting command-list

root (hd0,0)
  Filesystem type is ext2fs, partition type 0x83
kernel /vmlinuz-2.6.37 ro root=LABEL=/ console=ttyS0,115200n8 
libata.force=80c
    [Linux-bzImage, setup=0x3c00, size=0x2ad060]
initrd /initrd-2.6.37.img
    [Linux-initrd @ 0x1fd59000, 0x286776 bytes]
...
Loading pata_via.ko module
scsi0 : pata_via
scsi1 : pata_via
ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xfa00 irq 14
ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xfa08 irq 15
ata2.01: CFA: TRANSCEND, 20070831, max UDMA/66
ata2.01: 7962192 sectors, multi 0: LBA
ata2.01: limited to UDMA/33 due to 40-wire cable
ata2.01: configured for UDMA/33
scsi 1:0:1:0: Direct-Access     ATA      TRANSCEND        2007 PQ: 0 ANSI: 5
sd 1:0:1:0: [sda] 7962192 512-byte logical blocks: (4.07 GB/3.79 GiB)
sd 1:0:1:0: [sda] Write Protect is off
sd 1:0:1:0: [sda] Write cache: disabled, read cache: enabled, doesn't 
support DA
  sda: sda1 sda2 sda3
sd 1:0:1:0: [sda] Attached SCSI disk

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)

Re: Kernel 2.6.37 erroneously limiting to UDMA/33

[Stan Hoeppner]

Robert Hancock put forth on 1/5/2011 5:50 PM:
> (CCing linux-ide)
> 
> On 01/05/2011 12:33 PM, Stephen Clark wrote:
>> Hello,
>>
>> Why is the kernel limiting me to udma/33 when the device says it can do
>> ata2.01: CFA: TRANSCEND, 20070831, max UDMA/66
>>
>> There is no cable the compact flash is a socket on the motherboard!

Make and model of the motherboard?  Is it possible the trace layout
between the CF socket and the IDE chip on that board doesn't actually
support UDMA/66, due to noise, cross talk, etc, thus the omission of the
pin 34 connection?  If we assume the board designer did his job
correctly, that pin 34 no-connect is there for a reason, and limiting
you to UDMA/33 was also done for a reason.  Most board designers don't
just forget specs, or throw them out the window on a whim.  The pin 34
no-connect was very likely intentional.

> The kernel has no way to know that, and presumably the board isn't
> connecting the signal for IDE pin 34 to ground in order to properly
> signal that an 80-wire cable (or equivalent) is connected so that speeds
> over UDMA33 can be used.
> 
> You should be able to use the libata.force=80c option on the kernel
> command line to override the cable detection.

Stephen, you may want to absolutely verify the board supports UDMA/66 on
that CF socket before forcing it as to avoid possible data corruption, etc.

Something you didn't note in your original post is whether UDMA/66
worked with this mobo/cf slot with older kernels, or if the problem
magically appeared with 2.6.37.  If the latter, forcing UDMA/66 should
obviously be ok.

-- 
Stan

Re: Kernel 2.6.37 erroneously limiting to UDMA/33

[Tejun Heo]

Hello,

On Thu, Jan 06, 2011 at 01:29:37PM -0500, Stephen Clark wrote:
> Hmm... libata.force=80c - didn't seem to work.

Is libata.ko a module which is loaded from initrd?  The initrd could
be dumb and fail to pass the kernel param to the module when loading
it.  In those cases, you'll need to modify initrd so that the
parameter is specified.

Thanks.

-- 
tejun