Re: libata 2.6.5->2.6.6 regression -part II

[Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>]

On Friday 21 of May 2004 14:06, Bill Davidsen wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > On Monday 17 of May 2004 18:34, Brad Campbell wrote:
> >>G'day all,
> >>I caught the suggestion on my last post in the archives, but because I'm
> >>not subscribed and wasn't cc'd I can't keep it threaded.
> >>
> >>I tried backing out the suggested acpi patch (No difference at all), and
> >> I managed to get apic to work but it still hangs solid in the same
> >> place.
> >>
> >>dmesg attached.
> >>
> >>I managed to figure out that the VIA ATA driver captures my sata drives
> >> on the via ports, explaining why sata_via misses them, but writing data
> >> to those drives (hde & hdg) causes dma timeouts and locks the machine.
> >> No useful debug info produced. The machine becomes non-responsive,
> >> throws a couple of dma timeouts to the console and then loses all
> >> interactivity (keyboard, serial, network) forcing a reset push.
> >>
> >>Is there any way I can prevent the VIA ATA driver capturing this device?
> >>Unfortunately my boot drive is on hda on the on-board VIA ATA interface
> >> so I need it compiled in.
> >
> > Disable the fscking PCI IDE generic driver.
> > [ You are not the first one tricked by it. ]
> >
> > AFAIR support for VIA 8237 was added to it before sata_via.c was ready.
> > [ but my memory is... ]
>
> What would happen if the generic driver was initialized last? That would
> let other more specific drivers grab devices first. The model which
> comes to mind is a route table, smallest subnet (or in this case most
> specific) being used first. Or would that open a whole other nest of
> snakes?

I think that you are confusing PCI IDE generic driver with IDE generic driver
(the latter is already called after the former).

Brad's problem was IDE driver (pci/generic.c) vs libata driver (sata_via.c).

Bartlomiej