UDMA 33 instead of UDMA 100 used

Bug #95921 reported by Sascha
10
Affects Status Importance Assigned to Milestone
linux-source-2.6.20 (Ubuntu)
Fix Released
Medium
Ben Collins
Nominated for Feisty by Luís Silva

Bug Description

Hi,

I just upgraded to feisty. After overcoming the shock of my hda having disappeared and now being sda, I have the following issue:

UDMA 33 is used, although UDMA 100 is supported.

Here the hdparm output:

konradsa@ubuntu:~$ sudo hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
        Model Number: TOSHIBA MK1031GAS
        Serial Number: 65AQ0125S
        Firmware Revision: AA204C
Standards:
        Supported: 6 5 4
        Likely used: 6
Configuration:
        Logical max current
        cylinders 16383 16383
        heads 16 16
        sectors/track 63 63
        --
        CHS current addressable sectors: 16514064
        LBA user addressable sectors: 195371568
        device size with M = 1024*1024: 95396 MBytes
        device size with M = 1000*1000: 100030 MBytes (100 GB)
Capabilities:
        LBA, IORDY(can be disabled)
        Standby timer values: spec'd by Standard, no device specific minimum
        R/W multiple sector transfer: Max = 16 Current = 16
        Advanced power management level: unknown setting (0x0080)
        DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           * SMART feature set
                Security Mode feature set
           * Power Management feature set
           * Write cache
           * Look-ahead
           * WRITE_BUFFER command
           * READ_BUFFER command
           * NOP cmd
           * DOWNLOAD_MICROCODE
           * Advanced Power Management feature set
           * Device Configuration Overlay feature set
           * Mandatory FLUSH_CACHE
           * SMART error logging
           * SMART self-test
           * General Purpose Logging feature set
           * IDLE_IMMEDIATE with UNLOAD
Security:
        Master password revision code = 65534
                supported
        not enabled
        not locked
                frozen
        not expired: security count
        not supported: enhanced erase
        92min for SECURITY ERASE UNIT.
HW reset results:
        CBLID- above Vih
        Device num = 0 determined by CSEL
Checksum: correct

and here a dmesg excerpt:

[ 4.572000] ata_piix 0000:00:1f.1: version 2.10ac1
[ 4.572000] ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 19
[ 4.572000] PCI: Setting latency timer of device 0000:00:1f.1 to 64
[ 4.572000] ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x00011810 irq 14
[ 4.572000] ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x00011818 irq 15
[ 4.572000] scsi0 : ata_piix
[ 4.736000] ata1.00: ATA-6: TOSHIBA MK1031GAS, AA204C, max UDMA/100
[ 4.736000] ata1.00: 195371568 sectors, multi 16: LBA
[ 4.900000] ata1.01: ATAPI, max MWDMA2
[ 4.908000] ata1.00: configured for UDMA/33
[ 5.072000] ata1.01: configured for MWDMA2

Revision history for this message
Sascha (konradsa) wrote :
Revision history for this message
Olivier (olivier-lacroix) wrote :

I get the same problem.

Revision history for this message
Giovanni Condello (nanomad) wrote :

Same issue here and same dmesg output (same laptop too?)

Revision history for this message
Luís Silva (luis) wrote :

I too have been having some problems with a laptop (asus Z96J) since upgrade to feisty. Sometimes it takes for ages to boot... Other times it boots normally, but with a strange error in the logs (ATA: abnormal status 0x7F on port 0x000101f7)...

I'm going to attach copies of dmesg (named dmesg.x.orig) and dmesg | grep -i ata (named dmesg.x.ata) to this bug in all the three situations. dmesg.0 corresponds to a situation where it took for ages to boot, dmesg.1 is the following boot (with no changes, just reboot). And dmesg.2 is for a boot with a hand compiled kernel (2.6.20.4, compiled the debian (or ubuntu ;)) way.

Revision history for this message
Luís Silva (luis) wrote :

Apparently there's already a patch that fixes this problem... I'm going to try it against kernel 2.6.21-rc5 in a few moments...

The patch can be found here http://lkml.org/lkml/2007/3/22/47

Revision history for this message
Luís Silva (luis) wrote :

Well, the patch resolved the problem with UDMA and now my hard drive is detected as UDMA100 as expected... But in what relates to the "ATA: abnormal status 0x7F on port 0x000101f7" message, she's still there... :(

Revision history for this message
Olivier (olivier-lacroix) wrote :

Nice.

are we supposed to let the devs know about it in any particular way ?

Changed in linux-source-2.6.20:
assignee: nobody → ben-collins
importance: Undecided → Medium
status: Confirmed → Fix Committed
Revision history for this message
Giovanni Condello (nanomad) wrote :

Sent patch to launchpad

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

This bug report was marked "Fix Committed" a while ago but there hasn't been any recent activity. Can you just verify this bug has been resolved and we'll go ahead and mark this bug report as "Fix Released". Thanks in advance.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Marking "Fix Released" as patch appears to be available in the Feisty kernel.

Changed in linux-source-2.6.20:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.