Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754337AbYLNPvR (ORCPT ); Sun, 14 Dec 2008 10:51:17 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753126AbYLNPu7 (ORCPT ); Sun, 14 Dec 2008 10:50:59 -0500 Received: from netrider.rowland.org ([192.131.102.5]:3474 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752677AbYLNPu6 (ORCPT ); Sun, 14 Dec 2008 10:50:58 -0500 Date: Sun, 14 Dec 2008 10:50:56 -0500 (EST) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Greg KH cc: Keith Packard , linux-kernel , Subject: Re: USB interrupt handler routine In-Reply-To: <20081214044112.GA28733@kroah.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1796 Lines: 46 On Sat, 13 Dec 2008, Greg KH wrote: > > 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 -- 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/