HEADS UP: Check your devices' UDMA settings -- ADDENDUM

[Basil Chupin]

On 06/04/2011 00:52, J wrote:
> On Tue, Apr 5, 2011 at 10:44, Basil Chupin<blchupin at iinet.net.au>  wrote:
>> On 06/04/2011 00:11, J wrote:
>>> On Tue, Apr 5, 2011 at 10:07, Basil Chupin<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:
>>>>>
>>>>> (the ata1 refers to the HDD/CDROM I have on the first PATA line and ata2
>>>>> refers to the HDD/DVDRW on line #2)
>>>>>
>>>>> [ 1.476324] ata1.00: ATA-8: WDC WD5000AAKB-00H8A0, 05.04E05, max
>>>>> UDMA/133
>>>>> <=======XXXXXXXXXXXXX
>>>>> [ 1.476327] ata1.00: 976773168 sectors, multi 16: LBA48
>>>>> [ 1.476359] ata1.01: ATAPI: HL-DT-STDVD-ROM GDR8164B, 0L06, max UDMA/33
>>>>> <=======XXXXXXXXXXXXX
>>>>> [ 1.476384] ata1: nv_mode_filter: 0x7f39f&0x7f39f->0x7f39f, BIOS=0x7f000
>>>>> (0xc7c0c6c6) ACPI=0x7f01f (15:60:0x1f)
>>>>> [ 1.476391] ata1: nv_mode_filter: 0x739f&0x739f->0x739f, BIOS=0x7000
>>>>> (0xc7c0c6c6) ACPI=0x701f (15:60:0x1f)
>>>>> [ 1.492585] ata1.00: configured for UDMA/133<=======XXXXXXXXXXXXX
>>>>> [ 1.508263] ata1.01: configured for UDMA/33<=======XXXXXXXXXXXXX
>>>>> ......................................................
>>>>>
>>>>> [ 1.884316] ata2.00: HPA unlocked: 312579695 ->    312581808, native
>>>>> 312581808
>>>>> [ 1.884322] ata2.00: ATA-7: ST3160215A, 3.AAD, max UDMA/100
>>>>> <========ZZZZZZZZZZZZ
>>>>> [ 1.884326] ata2.00: 312581808 sectors, multi 16: LBA48
>>>>> [ 1.884356] ata2.01: ATAPI: PIONEER DVD-RW DVR-118L, 1.02, max UDMA/100
>>>>> <========ZZZZZZZZZZZZ
>>>>> [ 1.884382] ata2: nv_mode_filter: 0x3f39f&0x3f39f->0x3f39f, BIOS=0x3f000
>>>>> (0xc7c0c6c6) ACPI=0x3f01f (20:20:0x1f)
>>>>> [ 1.884386] ata2.00: limited to UDMA/33 due to 40-wire cable
>>>>> <========!!!!!!!!!!!!!!!!!!!!!
>>>>> [ 1.884391] ata2: nv_mode_filter: 0x3f39f&0x3f39f->0x3f39f, BIOS=0x3f000
>>>>> (0xc7c0c6c6) ACPI=0x3f01f (20:20:0x1f)
>>>>> [ 1.884394] ata2.01: limited to UDMA/33 due to 40-wire cable
>>>>> <========!!!!!!!!!!!!!!!!!!!!!!
>>>>> [ 1.896098] firewire_core: created device fw0: GUID 00e0180000402cfe,
>>>>> S400
>>>>> [ 1.930139] ata2.00: configured for UDMA/33<========@!@!@!@!@!@!
>>>>> [ 1.944263] ata2.01: configured for UDMA/33<========@!@!@!@!@!@!
>>>>> [ 1.944792] scsi 1:0:0:0: Direct-Access ATA ST3160215A 3.AA PQ: 0 ANSI:
>>>>> 5
>>>>> [ 1.944935] sd 1:0:0:0: Attached scsi generic sg2 type 0
>>>>> [ 1.947782] sd 1:0:0:0: [sdb] 312581808 512-byte logical blocks: (160
>>>>> GB/149 GiB)
>>>>>
>>>>>
>>>>>
>>>>> Now, you may not be affected in this way but it would pay to check.
>>>>>
>>>>> I haven't read all what is needed to fix this problem - there is a
>>>>> workaround but requires a patch, or something, to the kernel and I ain't
>>>>> too
>>>>> damn keen to do this considering that all was OK until beginning of 1
>>>>> April.
>>>>>
>>>>> BC
>>>> I just finished installing openSUSE 11.4. It is using kernel
>>>> 2.36.37.1-1.2
>>>> and this is also showing that my system has a 40-wire cable on line #2
>>>> when
>>>> it is, and has been for years, an 80-wire cable (and I replaced it 2 days
>>>> ago with a new one just in case). So it appears that there has been a
>>>> regression in the kernel.
>>>>
>>>> BC
>>> Interesting... good catch.  What's the number of the bug you filed?  I
>>> can't seem to find it.  The one you reference as the original was last
>>> commented on in 2009.
>> That's the one - after being marked as resolved it has come back after 2
>> years to bite us all again.
>>
>> But if you look around you will find that it goes back to at least 2007.
>>
>> BC
>>
>> PS Oh, I misread your post. I haven't filed any bug report. Saw no reason to
>> as it is already a known thing but which had been resolved way back.
> Ahhh... got it... but to be honest, that bug (yeah I noticed how old
> it was, just mentioning that the last actual comment was from 2009)
> was marked Fix Released ages ago... you have some good evidence that
> this is in fact a regression, but without a new bug indicating this
> and pointing back to the original, no one will ever know.  I can't
> open it, I don't have the hardware to reproduce this...

I guess I am waiting for someone to come up and state that they are also 
now experiencing the same situation re the UDMA not being set correctly. 
Perhaps this has already been picked up but as I don't access the kernel 
mail list I don't know.

BC

-- 
Any experiment in life will be at your own experience.