Messages in this thread | | | Date | Sun, 14 Dec 2008 10:50:56 -0500 (EST) | From | Alan Stern <> | Subject | Re: USB interrupt handler routine |
| |
On Sat, 13 Dec 2008, Greg KH wrote:
> <added linux-usb list, that's the proper place for it...) > > On Thu, Dec 11, 2008 at 08:35:37PM -0800, Keith Packard wrote: > > We recently made a patch in the Intel DRM driver: > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b60678a75d44fa9d5969f79781bd856ad5858609 > > > > This switches from non-MSI to MSI-mode. > > > > It "should" have had no effect, but our concern is that what we're > > really seeing is interrupt sharing troubles. We've had several people > > say that they got an interrupt flood when plugging in a USB stick or > > external disk.
Which drivers are using the IRQ that gets flooded? Can we see a dmesg log from a kernel built with CONFIG_USB_DEBUG enabled?
> > Switching the graphics driver to MSI mode "cures" the > > bug, but that sure seems like a work-around rather than a bug fix to me. > > > > When our driver is active, it can generate a lot of interrupts, > > potentially thousands per second. Is it possible that the UHCI or EHCI > > drivers could get confused if checking for interrupt status this often?
I don't think so.
> > Eric noted that the USB driver
Which USB driver? Does this refer to usb_hcd_irq()?
> > appears to not check and ACK interrupt > > status unconditionally, preferring to check the software state > > beforehand. I'm wondering if this may open up a potential race between > > hardware state change and ISR bit setting.
Not if the drivers are written correctly. As far as I know, they are.
Alan Stern
| |