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 <ccox@endlessnow.com> 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.