On Wed, 2011-09-07 at 00:39 -0400, David Miller wrote: > From: Ben Hutchings <ben@decadent.org.uk> > Date: Wed, 07 Sep 2011 05:16:01 +0100 > > > This is somewhat unusual in that the IDE controller will be sharing its > > IRQ, but that's supposed to work. > > > > However, the IDE core attempts to disable and enable the IRQ *before* it > > allocates it. If the UHCI driver then allocates the IRQ in the middle > > of this, the IRQ manager will reset the disable count since the IRQ is > > not yet shared! > > > > This might be fixable by changing the IDE core to allocate the IRQ with > > a dummy interrupt handler while probing. > > > > Aside from that, maybe pata_it8213 is ready as a replacement for it8213 > > now? (Kconfig still labels it as EXPERIMENTAL.) > > I've known about this IDE layer problem for at least a year and any > fix is too risky to consider seriously. I had a suspicion that was the case. > Use the PATA drivers on modern systems, don't use the deprecated IDE > layer. Well, I'm concerned with what to do in distro configurations which aren't just for 'modern systems'. We already swapped over all the drivers not labelled as experimental. With the rest, I worry that we'd be exchanging obscure IDE drivers that mostly work for obscure libata drivers that have had little if any testing. That strikes me as being even more risky for the users with the old controllers. I suppose that for those controllers where the libata driver is experimental we could build both drivers, blacklist the IDE drivers and let people override that if necessary. (And hope that most of the bugs get shaken out of the libata drivers before we do a stable release, because that is too ugly to keep doing for long.) Ben.
Attachment:
signature.asc
Description: This is a digitally signed message part