# hdparm dma setting fails

## th3y3llowd4rt

Whenever I try to set my hard drive to use dma, I get this error: 

/dev/hda:

 setting using_dma to 1 (on)

 HDIO_SET_DMA failed: Operation not permitted

 using_dma    =  0 (off)

but when I use the livecd, it has no problem making these changes, is there something wrong w/ my kernel or what? thx in advance for suggestions

----------

## SithMaddox

make sure your chipset is enabled in your kernel under Device Drivers ---> ATA/ATAPI/MFM/RLL support

----------

## th3y3llowd4rt

that did it! thanx!

----------

## Spider-One

Same problem here, I get this from lspci:

```
0000:00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c4)
```

What should I enable to get my chipset working?

Nevermind, fixed it. I guess /boot/ wasnt mounted when I was trying to copy over the new kernel files.

----------

## duckie

Hi,  I also have an ALI M5229 rev C IDE controller

I still cant enable DMA

What optins did you have enabled in the kernel?   (Im using 2.6.11-gentoo)

Thanks

----------

## Sade

I've got an nForce2 chipset, and have the same error as statet above, i need some help on finding the kernel drivers, i've searched the kernel menuconfig but couldn't find the right driver.

[EDIT]

i needed the "AMD and Nvidia" Driver and the VIA driver mentioned above to fix the problem.

----------

## moocha

 *Spider-One wrote:*   

> Same problem here, I get this from lspci:
> 
> ```
> 0000:00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c4)
> ```
> ...

  *duckie wrote:*   

> Hi, I also have an ALI M5229 rev C IDE controller 
> 
> I still cant enable DMA 
> 
> What optins did you have enabled in the kernel? (Im using 2.6.11-gentoo) 
> ...

 The ALi M5229 IDE controller which is part of the ALi 1533 and 1543 chipsets is extremely buggy. Only the M5229 version used in the 1543C (C stands for "corrected") chipset is safe to use with UltraDMA transfers, as well as certain revisions of the 1543 chipset. However ALi never made available a list of which M5229 revisions are safe. From my experience, the revisions 0xC2, 0xC3 and 0xC4 are safe to use with UDMA. The 0x20 revision is not safe, and expect data corruption and data loss if you try it. That's why all Linux kernels after 2.4.17 (if I remember correctly) disable UDMA on the buggy revisions. It's possible to manually hack drivers/ide/pci/alim15x3.c in order to bypass the checks for buggy revisions, but it's extremely unsafe to do so. If you decide to do it, the function you need to modify is ali15x3_can_ultra(). Specifically, you need to change

```
if (m5229_revision <= 0x20)
```

 to 

```
if (m5229_revision < 0x20)
```

(sometimes higher revisions don't get correctly detected, so the driver falls back to assuming revision 0x20). But, again, this is extremely unsafe and you run a good chance to kiss your data goodbye. So if your system breaks, you get to keep the pieces.

My advice is to grit your teeth and stick to Multiword DMA modes on those controllers (the relevant hdparm parameter is -X mdma2, although the kernel libata should enable that all by itself). It's better to have your data accessed in a slower fashion than to risk losing your data completely.

----------

