On Saturday 05 July 2008, Linus Torvalds wrote:
quoted text
> Alan - if it _is_ an interrupt flood, it looks like it basically starts 
> just as ohci_hub_status_data() does that spin_unlock_irqrestore() to 
> re-enable interrupts. And there has been some changes to 
> ohci_root_hub_state_changes() recently, and that OHCI_INTR_RHSC enable 
> logic in particular.
> 
> That root hub status interrupt changing thing is commit e872154921a6b5 
> ("USB: don't explicitly reenable root-hub status interrupts"), and it 
> _did_ happen after 2.6.25.

I seem to recall some oddness with RHSC on some platforms,
way back when I had lots of OHCI hardware and did comparative.
testing.  RHSC and RD did not act quite like the docs said ...

Simple experiments:  add "distrust_firmware=y" to the ohci
module options.  Or:  try a kernel without CONFIG_PM enabled.


More complex experiments:  try building with CONFIG_USB_DEBUG and
after editing drivers/usb/host/ohci-hcd.c to #define OHCI_VERBOSE_DEBUG
(just change the #undef to a #define) ... then restart things
(passing debug=8 on the kernel command line may help) and see what
it says on the system console.

If this is really an IRQ storm that may turn up more data.
Alternatively, it might not show info until you tweak ohci_irq()
(in that same file) to dump "ints" after it checks whether the
IRQ was "for some other device".  And if even that doesn't show
a storm of messages ... then the problem may not be directly
caused by OHCI.  Lots of stuff seems to be sharing that same
IRQ, after all...

- Dave
--
unsubscribe notice
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/