Alan Cox wrote:
> This requires a lot of care to do right. Remember that on PC systems > interrupts can be substantially posted. A "stop_interrupt" may prevent > IRQ issue but if an IRQ is already on the PC APIC bus it will kill you > later on because the IRQ delivery and PCI bus access on the PC class > machines are totally asynchronous > > ie > > Interrupt leaves PCI devices > Interrupt hits APIC > stop_interrupt > IRQ masked on PCI device (but too late for APIC) > spin_lock > > Interrupt arrives down slow Pentium III APIC bus > spin_lock > > Deadlock > > so you actually can't pull this stunt and a PIII will deadlock every day > or so if you do (painful experience with the ne2k-pci until I figured > that one out)
Indeed, must hurt .
For this specific case, the interrupt handler should manage it:
>if ( (!(status & ~USBSTS_HCH)) /* shared interrupt, not mine */
> || (!uhci->IntEnableReg_SW) )
>{
> retval = IRQ_NONE;
> goto end;
>}uhci->IntEnableReg_SW is the "software" view of the "Interrupt Enable" register of our UHCI chipset.
So if the interrupt arrives between stop_interrupt and spin_lock, the handler will no be taken because IntEnableReg_SW would be 0 (set by stop_interrupt) and the spin_lock would not be executed.
Of course, this is "my point of view". I would be happy to have external mind about it. And that's why I included this changes in the patch.
I have not so much experiences in device driver...
Bye
PS: Sorry, I'm not use to that ML!
------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
