Dear experts,
Normally, my PCI chipset (ie. via82cxxx, hpt366) are compiled in, and it
correctly enables DMA of my harddisk.
But, for experiment, I tried compiling in only the "generic" options,
and moved all specific PCI chipsets as modules. Hotplug loads the
modules, 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? How do I turn on DMA, if I load my PCI chipset as
module?
--
William Park <[email protected]>, Toronto, Canada
ThinFlash: Linux thin-client on USB key (flash) drive
http://home.eol.ca/~parkw/thinflash.html
BashDiff: Super Bash shell
http://freshmeat.net/projects/bashdiff/
On Sun, 2006-02-05 at 22:43 -0500, William Park wrote:
> But, for experiment, I tried compiling in only the "generic" options,
> and moved all specific PCI chipsets as modules. Hotplug loads the
> modules, but with all 'hdparm' options turned off. When I tried turning
> on DMA,
Generic and chipset specific support are not complementary, they are
mutually exclusive. Having generic PCI IDE support enabled will prevent
the chipset specific support from working properly.
This is actually a problem in several areas of the kernel (it's the same
for "Generic RTC" vs. the normal RTC) - I don't think the name "Generic"
properly reflects that it will prevent more specific device support from
working.
Lee
Hi Lee,
On Monday 06 February 2006 05:32, Lee Revell wrote:
> This is actually a problem in several areas of the kernel (it's the same
> for "Generic RTC" vs. the normal RTC) - I don't think the name "Generic"
> properly reflects that it will prevent more specific device support from
> working.
What about "Fallback $DEVICE" instead?
Regards
Ingo Oeser
On Sul, 2006-02-05 at 23:32 -0500, Lee Revell wrote:
> Generic and chipset specific support are not complementary, they are
> mutually exclusive. Having generic PCI IDE support enabled will prevent
> the chipset specific support from working properly.
Untrue.
The PCI generic driver by default grabs only hardware with PCI IDS it
knows can be driven generically. That list purposefully has no overlaps
with chipset drivers.
Alan
On Mon, 2006-02-06 at 19:49 +0000, Alan Cox wrote:
> On Sul, 2006-02-05 at 23:32 -0500, Lee Revell wrote:
> > Generic and chipset specific support are not complementary, they are
> > mutually exclusive. Having generic PCI IDE support enabled will prevent
> > the chipset specific support from working properly.
>
> Untrue.
>
> The PCI generic driver by default grabs only hardware with PCI IDS it
> knows can be driven generically. That list purposefully has no overlaps
> with chipset drivers.
OK. But wasn't this a problem in previous kernels?
Lee
On Mon, 2006-02-06 at 20:31 +0100, Ingo Oeser wrote:
> Hi Lee,
>
> On Monday 06 February 2006 05:32, Lee Revell wrote:
> > This is actually a problem in several areas of the kernel (it's the same
> > for "Generic RTC" vs. the normal RTC) - I don't think the name "Generic"
> > properly reflects that it will prevent more specific device support from
> > working.
>
> What about "Fallback $DEVICE" instead?
Yes, that would be much better for the RTC case.
Lee
On Mon, Feb 06, 2006 at 07:49:25PM +0000, Alan Cox wrote:
> On Sul, 2006-02-05 at 23:32 -0500, Lee Revell wrote:
> > Generic and chipset specific support are not complementary, they are
> > mutually exclusive. Having generic PCI IDE support enabled will prevent
> > the chipset specific support from working properly.
>
> Untrue.
>
> The PCI generic driver by default grabs only hardware with PCI IDS it
> knows can be driven generically. That list purposefully has no overlaps
> with chipset drivers.
The kernel I'm using is 2.6.14. My chipset is Via 82c694x and 82c686b
(Abit VP6 dual-P3 with HighPoint 370). DMA is on only when 'via82cxxx'
and 'hpt366' are compiled in. Most importantly, DMA cannot be turned on
if loading by module.
Does it mean that this "bug" is pecular to my chipset?
--
William Park <[email protected]>, Toronto, Canada
ThinFlash: Linux thin-client on USB key (flash) drive
http://home.eol.ca/~parkw/thinflash.html
BashDiff: Super Bash shell
http://freshmeat.net/projects/bashdiff/
On 2/6/06, Lee Revell <[email protected]> wrote:
> On Mon, 2006-02-06 at 19:49 +0000, Alan Cox wrote:
> > On Sul, 2006-02-05 at 23:32 -0500, Lee Revell wrote:
> > > Generic and chipset specific support are not complementary, they are
> > > mutually exclusive. Having generic PCI IDE support enabled will prevent
> > > the chipset specific support from working properly.
> >
> > Untrue.
> >
> > The PCI generic driver by default grabs only hardware with PCI IDS it
> > knows can be driven generically. That list purposefully has no overlaps
> > with chipset drivers.
>
> OK. But wasn't this a problem in previous kernels?
It wasn't. The issue is more complicated, you can have
three host drivers driving the same hardware:
* ide-generic driver
- ISA like support
- also works for PCI in legacy mode
* IDE PCI generic (the one Alan refers to)
- generic IDE PCI support
- by default doesn't grab IDs for which we have other drivers
(can be forced by using kernel parameter)
* chipset specific driver
The most common mistake is to built-in ide-generic driver
and compile chipset specific driver as module...
To William:
CONFIG_IDE_GENERIC=n is a likely solution for your problem.
Bartlomiej
On Maw, 2006-02-07 at 09:14 +0100, Bartlomiej Zolnierkiewicz wrote:
> * chipset specific driver
>
> The most common mistake is to built-in ide-generic driver
> and compile chipset specific driver as module...
Oh that no longer works. That worked in 2.4, as it would take over the
chipset. Didn't work if it was in use at the time but did work correctly
if idle.
On 2/7/06, Alan Cox <[email protected]> wrote:
> On Maw, 2006-02-07 at 09:14 +0100, Bartlomiej Zolnierkiewicz wrote:
> > * chipset specific driver
> >
> > The most common mistake is to built-in ide-generic driver
> > and compile chipset specific driver as module...
>
> Oh that no longer works. That worked in 2.4, as it would take over the
> chipset. Didn't work if it was in use at the time but did work correctly
> if idle.
I'm talking about _driver_ here and it works just fine.
If you are talking about "taking over" feature, you are right.
It was racy and indeed "worked" depending on timing.
Bartlomiej
On Tue, Feb 07, 2006 at 12:14:09PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On 2/7/06, Alan Cox <[email protected]> wrote:
> > On Maw, 2006-02-07 at 09:14 +0100, Bartlomiej Zolnierkiewicz wrote:
> > > * chipset specific driver
> > >
> > > The most common mistake is to built-in ide-generic driver
> > > and compile chipset specific driver as module...
> >
> > Oh that no longer works. That worked in 2.4, as it would take over the
> > chipset. Didn't work if it was in use at the time but did work correctly
> > if idle.
>
> I'm talking about _driver_ here and it works just fine.
>
> If you are talking about "taking over" feature, you are right.
> It was racy and indeed "worked" depending on timing.
Interesting. I'll move the "generic" as module, and see how it goes.
--
William Park <[email protected]>, Toronto, Canada
ThinFlash: Linux thin-client on USB key (flash) drive
http://home.eol.ca/~parkw/thinflash.html
BashDiff: Super Bash shell
http://freshmeat.net/projects/bashdiff/