Re: [linux-usb-devel] Re: 2.6.13-mm2

["Rafael J. Wysocki" <rjw@sisk.pl>]

Hi,

On Wednesday, 28 of September 2005 22:56, David Brownell wrote:
> > On Wednesday, 28 of September 2005 22:23, David Brownell wrote:
> > > > > > > BTW, please have a look at:
> > > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=4416#c36
> > > > > > > and
> > > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=4416#c37
> > > 
> > > What's with the bogus dates in those reports ... claiming some of you
> > > were testing 2.6.13-rc2-mm2 more than two months ago, mid-July ?????
> >
> > Nothing. :-)  2.6.13-rc2-mm2 was out exactly on July 12, and that's when
> > I tested it ...
> 
> OK, sorry; pardon me!  Then the right question to ask is more like
> "So does this still happen in **2.6.14-rc2** ??".  2.6.13-rc is
> marginally more recent than 2.4.20, but it still feels old. :)
> 
> 
> My other point still stands though.  The IRQ for all HCDs _are_ freed
> on suspend, and re-requested on resume ... so lack of such free/request
> calls can't possibly be an issue.

Yes it can.  Apparently on my box the call to request_irq() from a USB HCD
driver (OHCI or EHCI) causes a screaming interrupt to be generated,
which kills any other driver that shares the IRQ with the USB and has not
called free_irq() on suspend.  Of course this only happens with the patch
at http://www.ussg.iu.edu/hypermail/linux/kernel/0507.3/2234.html
unapplied, as it masks the problem.  Actually it also depends on the
order in which the drivers' resume routines are called, but unfortunately
on my box the USB drivers' are called first.

Still, if _none_ of the drivers (including USB HCD) calls request_irq() on resume,
the box survives _even_ _without_ the above-mentioned patch.

> The old rule of thumb with USB does still apply though:  be sure to
> test with BIOS support for it disabled.

AFAICT, in this particular case it doesn't matter.

Greetings,
Rafael