I found several old __cli and ide__sti that dangle and never set a
spinlock. These are not paired either and get set and cleard in different
calls.
There appears to be two levels of locking......
Well I'll be darned.....the butchering compiled.....
Oh, yeah
ide_hwgroup_t *hwgroup = HWGROUP(drive);
spin_lock_irqsave(&hwgroup->spinlock, flags);
spin_unlock_irqrestore(&hwgroup->spinlock, flags);
spin_lock_irqsave (&io_request_lock, flags);
spin_unlock_irqrestore (&io_request_lock, flags);
ide__sti(); (aka __sti();) -->> spin_unlock_irq(&io_request_lock);
__cli(); -->> spin_lock_irq(&io_request_lock);
Almost all of "block" is littered with no spinlock calls.
Thus there are unlimited combinations of deadlock that can randomly clear
one or another by chance....you know the old russian game...BANG!!!!
Andre Hedrick
The Linux IDE guy
On Mon, 11 Oct 1999, Alan Cox wrote:
> > Yes it is going to be messy and long......
>
> I've been going through the locking and its really hard to follow quite
> what is being locked in places. The irq one is pretty nasty. We can't allow
> an IRQ to come in - even momentarily during the lock and disable irq
> sequence, yet we can't disable the irq with locks held as the IRQ might
> already be running.
>
> I have the request queue stuff partly fixed now, I need to sort out the error
> propogation bit.
>
> > Recall that it was around 2.1.122 that offered to pick up the pieces and
> > go.......Thus I have been playing catchup from before day one.
>
> Yes. And I dont envy any one trying to fix that IDE locking bug - its a nasty
> one
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/