Hi, On Tuesday, 17 of May 2005 02:26, David Brownell wrote: > On Monday 16 May 2005 2:19 pm, Jordan Crouse wrote: > > On Mon, 16 May 2005 16:16:06 -0400 > > "Adam Belay" <ambx1@xxxxxxxxxx> wrote: > > > > > b.) You're assuming every device has its own interrupt. This may not > > > be the case. Let's say one device was sharing interrupts with a few > > > other devices... > > > > I ran into this very problem a while back on 2.4. On my platform, the > > EHCI and OCHI host controllers share an interrupt. ... > > > > Now, granted that particular scenario is a corner case, and the PCI > > hardware should have been configured better, but it shows that you > > can't assume that any given interrupt handler will only be called with > > active hardware underneath. > > Very true, and that's part of why drivers/usb/core/hcd-pci.c frees > IRQs during suspend, and reclaims them later. > > AFAICT that code is the most generic PCI suspend/resume code now > available ... since it's got to work with dozens of different > implementations of EHCI, OHCI, and UHCI; with widely varying > BIOS versions and bugs; and where not all controllers support > the PCI PM extensions. > > Note the wierdnesses there ... cases where the PCI API calls are > wierdly asymmetric, and where "swsusp" can really bork things > by entering bizarre "resume" paths. Could you please have a look at http://bugzilla.kernel.org/show_bug.cgi?id=4416 There seems to be a problem with OHCI and EHCI drivers wrt suspend/resume (swsusp) in the current -mm on that box. Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland"
