https://bugzilla.novell.com/show_bug.cgi?id=422928
User ccox@endlessnow.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=422928#c2
--- Comment #2 from Chris Cox 2008-09-04 22:49:13 MDT ---
My clever workaround. THIS IS NOT A FIX... just an fyi.
I noticed that usb5 was on a clear interrupt (nothing else and most
specifically NO interrupt count)... that is to say... appears to be a good set
of ports if I can find them.
Turns out, these are the front ports of the unit.
So... first I need to disable ehci_hcd (since that will ride all of the ports
and it's the first thing to tank because of the spurious interrupts). I didn't
know how to do this "correctly", so I renamed the kernel module to something
unrecognizable.
But I believe the USB stuff is brought in dynamically be the detection of the
hubs and I think when ehci-hcd fails, the rest don't come in... (I may be wrong
on this one)... so I had uhci-hcd brought into the initrd (to make sure it's
there)... then I plugged my device into the front side port... and voila!
This at least has curbed my anger level... this is still a problem... it's
either a hw issue or an issue because the other usb ports (and all encompassing
ehci) are on interrupts that are shared with other things.
Somebody told me that the usb driver doesn't receive interrupts (???). I'm
going based on what is seen via /proc/interrupts... there I see usb ports
(hubs) on interrupts. usb5 was clear... leading me to this workaround for my
one important device (usb tv tuner acting as my pvr).
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.