PCI chipset -- module vs. compiled-in

[Lennart Sorensen]

On Sun, Feb 05, 2006 at 10:26:51PM -0500, William Park wrote:
> Normally, my PCI chipset is compiled in.  But, for experiment, I
> tried compiling in only the "generic" options, and moved all specific
> PCI chipsets (ie. via82cxxx, hpt366) as modules.

You do NOT want generic compiled in.  That is the last one you would
want compiled in.  It is a generic ide driver that runs most pci ide
controllers, but being generic does not do dma or anything else.  Since
it would now get first shot at controlling all your ide ports, the
native drivers you try and load later as modules of course can't load
because generic already took control of the ports.  Make them all
generic, and load the correct ones for your chipset in the initrd.
generic can be loaded last as a last resort for accessing the ide ports.

> Hotplug loads all the modules alright, but with all 'hdparm' options
> turned off.  When I tried turning on DMA, 
>     $ hdparm -m 16 -c 1 -u 1 -d 1 /dev/hda
> I get
>     /dev/hda:
>      setting 32-bit IO_support flag to 1
>      setting multcount to 16
>      setting unmaskirq to 1 (on)
>      setting using_dma to 1 (on)
>      HDIO_SET_DMA failed: Operation not permitted
>      multcount    = 16 (on)
>      IO_support   =  1 (32-bit)
>      unmaskirq    =  1 (on)
>      using_dma    =  0 (off)
> 
> Is this normal?  Has anyone encountered this before?  I thought I should
> check here first.

It is normal, and perfectly correct behaviour for your configuration.
The configuration is just wrong.

Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml