Unfortunately, I don't have access to an SMP machine, myself. The only
reports I get are that the system deadlocks when one of the PARIDE drivers
is loaded into a 2.1.95 kernel.
There are some unique "features" of the PARIDE drivers. First, they
do not use interrupts. Instead, both timer queues and task queues are
used to simulate a stream of "pseudo-interrupts". Secondly, because
the strategy routines can take a lot of time, the drivers enable
interrupts (in the rest of the system) for much of their work.
Presumably some of the cli/sti stuff needs to be replaced with spinlocks,
but without either a test machine or a clear understanding of the issues,
I'm not in a good position to fix this. For instance, if I re-enable
interrupts in the strategy routines, is sti() still the right way to do
that, or should I be releasing some specific spinlock ? Because
the pseudo interrupts can come from two different queues, there's
some trickiness to ensure that only one "thread" actually makes it
back into the driver. I think the mutex code in the two handlers
should be using a spinlock, but should it be the io_request_lock, or
a different lock ?
If someone with a good knowledge of SMP issues could please have a look
at pd.c and pseudo.h in drivers/block/paride/ and give me a hand, I'd
appreciate it.
Thanks
--------------------------------------------------------------------------
Grant R. Guenther grant@torque.net
--------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu