Messages in this thread | | | From | "Tom Sightler" <> | Subject | Slow PPP, SCSI, and spinlocks | Date | Sat, 13 Feb 1999 17:39:55 -0500 |
| |
Ok, this is really a follow up to my previous Slow PPP problem with my PS/2 at home. I had originally traced this to the 2.1.102 patch where the cli/sti routines were converted to save_flags/restore_flags. Thanks to input from another user who pointed out that the most likely scenario here was that the cli/sti routine was inadvertenly renabling interrupts that had been disabled by other code I pushed further into my studies of the irq handling in Linux 2.2. Sure enough, the problem actually stems from the change to wrap the SCSI interrupts handlers with spinlocks, basically meaning that all interrupts remain disabled during the entire interrupt handling routine, and by sheer luck the IBM SCSI driver contained a cli/sti routine that reenabled interrupts causing my serial port to continue to function properly until 2.1.102 when the routine was replaced by save_flags/restore_flags.
I then tested this more completely by using the stock 2.2.1 IBM SCSI driver with only one change, I removed the spin_lock_irqsave/spin_lock_irqrestore from the do_interrupt_hanlder routine. With this minor change I no longer loose serial interrupts.
The most information I could find about this change was in Linus' comments about the 2.1.95 patch, and by my limited interpretation the changes were mainly for SMP. So, my big question then is this, is it really neccessary to do spin_locks on SCSI interrupt handlers even on UP machines? So far I've noticed no ill effects with my change.
The problem with this seems to occur on machines other than mine. I received several emails from other users who were experiencing similar trouble with the Seagte scsi driver.
I'd like to hear some other comments on this. Perhaps there are better ways to handle this such as trimming down the interrupt handler and moving some portions to another routine that will funtion with interrupts enabled.
Any help would be greatly appreciated.
Later, Tom
- 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/
| |