Messages in this thread | | | Date | Sun, 11 Nov 2001 20:54:11 -0800 | From | "H . J . Lu" <> | Subject | Re: sbp2.c on SMP |
| |
On Sun, Nov 11, 2001 at 05:37:21PM -0800, Andrew Morton wrote: > > With the appended patch I can confirm that the driver happily runs > `dbench 40' for half an hour on dual x86. Even when you kick the
Thanks a lot.
> disk onto the floor (sorry, HJ).
That is a good stress test.
> > The games which scsi_old_done() plays with spinlocks and interrupt > enabling are really foul. If someone calls it with interrupts disabled > (sbp2 does this) then scsi_old_done() will enable interrupts for you. > If, for example, you call scsi_old_done() under spin_lock_irqsave(), > the reenabling of interrupts will expose you to deadlocks. Perhaps > scsi_old_done() should just use spin_unlock()/spin_lock()? > > I tried enabling SBP2_USE_REAL_SPINLOCKS in sbp2.c and that appears to > work just fine, although I haven't left that change in place here. > > You don't actually _need_ SMP hardware to test SMP code, BTW. You > can just build an SMP kernel and run that on a uniprocessor box. > This will still catch a wide range of bugs - it certainly detects > the lockup which was occurring because of the scsi_old_done() thing. > > Incidentally, it would be nice to be able to get this driver working > properly when linked into the kernel - it makes debugging much easier :) >
I guess I can try that. The only main issue will be the order of initialization.
H.J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |