HEADS UP: Check your devices' UDMA settings - *TEMPORARY* *WORKAROUND*

[Basil Chupin]

On 06/04/2011 15:48, Nathan Bahn wrote:
> On Wed, Apr 6, 2011 at 1:04 AM, Basil Chupin <blchupin at iinet.net.au 
> <mailto:blchupin at iinet.net.au>> wrote:
>
>     On 05/04/2011 15:51, Basil Chupin wrote:
>
>         It appears that Bug #195221 has suddenly come back -- see
>         https://bugs.launchpad.net/ubuntu/+bug/195221.
>
>         This bug re-appeared on 1 April (my time, Australia, East
>         Coast) because the previous day my logs showed that the UDMAs
>         were being set correctly. The only thing which I can see is
>         that on 1 April there was a kernel firmware upgrade but as I
>         know nuffin' about kernels (or majors or even captains) this
>         upgrade may have nothing to do with it.
>
>         What the above Bug is about is that even though your HDD, for
>         example, can do UDMA 133 the UDMA in fact gets set to UDMA 33
>         because some check concludes incorrectly that the device is
>         connected with a 40-wire cable. Here is an example I just took
>         from my dmesg log file:
>
>     [pruned]
>
>     The temporary workaround for this problem is to add to the boot
>     parameters the following: libata.force=X:80c
>
>     where X is the IDE line which is being affected by this UDMA
>     problem. In my case, the devices on line #2 are affected so I use
>     libata.force=2:80c and now the HDD and the DVDRW are being set to
>     UDMA 100 & 100, respectively.
>
>     Using 'libata.force=X:80c' is working because libata is actually
>     statically embedded in the kernel; if it was not then you would
>     use 'force=X:80c'.
>
>     (Now I have to go and read up on grub 2 to see how I can insert
>     this workaround in grub without having to add this everything to
>     the boot parameters at boot time.)
>
>     BC
>
>
>     -- 
>     Any experiment in life will be at your own experience.
>
>
>
>
> B.C.--
>
> So, if I'm understanding you correctly (a BIG if, admittedly), then 
> S.A.T.A. hard drives are NOT affected by this bug; is my understanding 
> correct? (and by the way, thanks that response to my question in the 
> other thread!)

No, I have not idea if SATA devices are affected. SATA has been around 
well before 2007/8 when this bug was reported. And I haven't seen a 
reference where mention is made that this only affects PATA devices. So, 
the bottom line is: I don't know.

The info I have come across show that if you do a command line "sudo -Tt 
/dev/sdX" you will be given the result of how fast your device can 
transfer data - and something around 30MB/s is equivalent to UDMA 33. 
And to see to what UDMA your device(s) is/are set, look at dmesg log 
file in /var/log/  and look for ata1.00/01 (and ata2.00/01 if 
applicable) to see how they are configured.

Although not directly relevant to this problem, read in Widkidepia the 
entry, "IDE cable" to see what transfer speeds are attainable with UDMA 
33/66/ etc (SATA speeds should be a bit faster I believe).

BC

-- 
"I believe what I was programmed to believe."
                      A robot in Futurama.