Re: any chance of 2.6.0-test*?

[Benjamin Herrenschmidt]

On Mon, 2003-01-13 at 15:59, Alan Cox wrote:
> On Mon, 2003-01-13 at 03:33, Paul Mackerras wrote:
> > I'm using the patch below, which makes sure that ide_release (in
> > ide-cs.c) runs in process context not interrupt context.  The specific
> > problem I saw was that ide_unregister calls various devfs routines
> > that don't like being called in interrupt context, but there may well
> > be other thing ide_unregister does that aren't safe in interrupt
> > context.
> 
> The ide release code isnt safe in any context.

Yup, though Paul's patch is a first step in the right way as I don't
think anybody sane plan to fix the IDE release code to make it interrupt
safe ;) At least I don't...
 
> > I have "fixed" the problem for now by adding a call to
> > init_hwif_data(index) in ide_register_hw just before the first
> > memcpy.  I'd be interested to know what the right fix is. :)
> 
> The code is currently written on the basis that people don't mangle
> free interfaces (the free up code restores stuff which I grant is
> kind of ass backwards). It also needs serious review and 2.5 testing
> before I'd want to move it to the right spot.

The code is indeed strangely backward, I had to deal with that in 2.4
for the PowerBook hotswap CD bay and will soon have to review that for
2.4.21-pre & 2.5.

> Also note that freeing the IDE can fail. If it fails then the code
> should probably be a lot smarter. Right now it 'loses' the interface.
> Really it should set a timer and try again. It might also want to
> add a null iops (out does nothing in returns FFFFFFFF) to stop
> further I/O cycles.

Yup, this have been a problem for me too, as ide_unregister for example
fails with a mounted fs. So the user had effectively removed the drive
from the bay, but I couldn't free the interface... nasty. Especially if
the user then plugs some different IDE device in the bay, the kernel
will get completely confused.