# pata_atiixp selects a lower speed

## smlbstcbr

I've noticed this when reviewing the dmesg output:

```
libata version 3.00 loaded.

pata_atiixp 0000:00:14.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16

scsi0 : pata_atiixp

scsi1 : pata_atiixp

ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xf300 irq 14

ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xf308 irq 15

ata2.00: ATAPI: ATAPI   CD-ROM 52XMax, VER 1.23, max UDMA/33

ata1.00: ATA-7: Maxtor 6L160P0, BAJ41G20, max UDMA/133

ata1.00: 320173056 sectors, multi 16: LBA48 

ata2.00: configured for UDMA/33

ata1.00: configured for UDMA/100

EXT3-fs (sda4): mounted filesystem with writeback data mode

ata1.00: configured for UDMA/100

ata1: EH complete
```

And hdparm gives me this:

```
 hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media

    Model Number:       Maxtor 6L160P0                          

    Serial Number:      L30L8TRH            

    Firmware Revision:  BAJ41G20

Standards:

    Used: ATA/ATAPI-7 T13 1532D revision 0 

    Supported: 7 6 5 4 & some of 8

Configuration:

    Logical        max    current

    cylinders    16383    16383

    heads        16    16

    sectors/track    63    63

    --

    CHS current addressable sectors:   16514064

    LBA    user addressable sectors:  268435455

    LBA48  user addressable sectors:  320173056

    Logical/Physical Sector size:           512 bytes

    device size with M = 1024*1024:      156334 MBytes

    device size with M = 1000*1000:      163928 MBytes (163 GB)

    cache/buffer size  = 8192 KBytes (type=DualPortCache)

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: 254

    Recommended acoustic management value: 192, current value: 0

    DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 udma6 

         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

       *    Host Protected Area feature set

       *    WRITE_VERIFY command

       *    WRITE_BUFFER command

       *    READ_BUFFER command

       *    NOP cmd

       *    DOWNLOAD_MICROCODE

       *    Advanced Power Management feature set

            SET_MAX security extension

            Automatic Acoustic Management feature set

       *    48-bit Address feature set

       *    Device Configuration Overlay feature set

       *    Mandatory FLUSH_CACHE

       *    FLUSH_CACHE_EXT

       *    SMART error logging

       *    SMART self-test

            Media Card Pass-Through

       *    General Purpose Logging feature set

       *    WRITE_{DMA|MULTIPLE}_FUA_EXT

       *    URG for READ_STREAM[_DMA]_EXT

       *    URG for WRITE_STREAM[_DMA]_EXT

       *    SMART Command Transport (SCT) feature set

       *    SCT Data Tables (AC5)

Security: 

    Master password revision code = 65534

        supported

    not    enabled

    not    locked

    not    frozen

    not    expired: security count

    not    supported: enhanced erase

HW reset results:

    CBLID- above Vih

    Device num = 0 determined by the jumper

Checksum: correct

```

The drive is capable of a higher speed, however, I cannot manage to use udma6. I've been looking in the forum and internet and there's no satisfactory answer to what is causing the driver to use a lower speed and the cable is a brand new 80 conductor. When using hdparm this comes out:

```
hdparm -Xudma6 /dev/sda

/dev/sda:

 setting xfermode to 70 (UltraDMA mode6)

 HDIO_DRIVE_CMD(setxfermode) failed: Invalid exchange
```

Any help will be welcomed

----------

## krinn

You have no issue here. All is working as expect.

You need an udma6 drive + an udma6 controller to get udma6 speed.

Your controller doesn't do udma6 (and to my knowledge intel has never done a pata controller that could do ata7, except when it could do sata)

You might have an oboard controller (at those time, many m/b was having a promise controller) that was doing the ATA7 support

----------

## smlbstcbr

 *krinn wrote:*   

> You have no issue here. All is working as expect.
> 
> You need an udma6 drive + an udma6 controller to get udma6 speed.
> 
> Your controller doesn't do udma6 (and to my knowledge intel has never done a pata controller that could do ata7, except when it could do sata)
> ...

 

It's not intel, it's ATI, and it works (at least shows)  with udma6 ATA133 in Windows

----------

## krinn

 *smlbstcbr wrote:*   

> 
> 
> scsi0 : pata_atiixp
> 
> scsi1 : pata_atiixp
> ...

 

Maybe, but the driver say it could do UDMA/100 only.

----------

## smlbstcbr

 *krinn wrote:*   

>  *smlbstcbr wrote:*   
> 
> scsi0 : pata_atiixp
> 
> scsi1 : pata_atiixp
> ...

 

I hope the driver is not that limited...

Edition: is there a way to know exactly why libata is selecting that speed despite it's capabilities to work at faster speeds? there are no error messages.

----------

## krinn

because that driver isn't the libata one  :Wink: 

----------

## smlbstcbr

 *krinn wrote:*   

> because that driver isn't the libata one 

 

 :Surprised:  What driver is it using? (please, that's how I learn tricks in Linux and forgive my lack of knowledge regarding these things.)

----------

## krinn

Well, i'm wrong and for your case it is as your first line output says " libata v3" but it depend on kernel version, older kernels weren't using libata for pata but the names were the same.

And even if the driver could do 133, you should know drivers generally are design for more than just one chip: so your chip might not support 133, the driver might not support 133 or the driver might not support 133 for your chip.

You can look at the driver documentation for the real answer.

----------

## smlbstcbr

 *krinn wrote:*   

> Well, i'm wrong and for your case it is as your first line output says " libata v3" but it depend on kernel version, older kernels weren't using libata for pata but the names were the same.
> 
> And even if the driver could do 133, you should know drivers generally are design for more than just one chip: so your chip might not support 133, the driver might not support 133 or the driver might not support 133 for your chip.
> 
> You can look at the driver documentation for the real answer.

 

Well, that's what I've been looking for but cannot find. What really annoys me is that windoze is able to make work this disk faster.

----------

## smlbstcbr

Been looking with a friend through the code of the driver and he found this>

```
 306         hwif->ultra_mask = 0x3f;
```

since kernel 2.4.24

I wonder why they did that...

----------

## Ant P.

Maybe they did that because it's a known buggy chipset and they thought slower data was better than corrupted data  :Wink: 

----------

## energyman76b

rules of thumb:

pata is buggy as hell

windows drivers love to lie

and the difference between udma5 and 6 is nil

kernel does the fastest the devs - who have read the specs and also know about problems most people don't even dream off - considered save or workable.

So, no need to worry. Enjoy your system.

----------

