On Fri, 23 Dec 2005, Scott D. Davilla wrote: > >The hub driver periodically queries ehci-hcd to get port status changes. > >When the hardware reports a connect status change, the hub driver > >processes the change. There aren't any hardware interrupts involved; it's > >driven by a kernel timer. But the change notification is genuinely coming > >from the hardware. > > So you have a periodic kernel timer that triggers a read of the hub > status. Could there be a timing issue where the hub driver is reading > at the wrong time maybe when the status bits are not stable.
As far as I know, those bits are always stable. Anyway, the connect-changed bit is a latch. It goes on when the connect-change event occurs and stays on until the OS turns it off. > I've > seen some hardware where you could get a bit glitch when some other > bit is changing. Usually you have to do a double read and look for > same result. Where is the hub status actually read from hardware, > ehci or hub. The actual read is in drivers/usb/host/ehci-hub.c:ehci_hub_control(). In the big "switch" statement it's the GetPortStatus case. > >The CSC above stands for Connect Status Change. There's no question that > >the EHCI hardware detected a connection change. If it was bogus, then > >there's a hardware problem. > > > > That's the rub. I'm pretty sure everyone agrees that VIA's ehci > hardware is a little funny. So it seems we get a connect status > change, but it's the root hub glitching. Maybe. Or maybe it's an electrical glitch in the USB cable. Or in the device's USB interface. It's not so easy to be sure where the real problem lies. > Could it be coming from the > 5th and 6th USB ports that are not connected to the outside world. No. The status registers are port-specific, as is the rest of the interface hardware. > The VIA chipset has 6 USB ports but only four are brought out, two on > the back plate, two on a header. It makes no difference where we are > connected. > > >A stack trace (Alt-SysRq-T) showing exactly _where_ the khubd process is > >hung would be a big help. > > > > Anyway to pipe this to a log? I've done the stack trace but the > buffers are not big enough to scroll back to khubd. If you kill all unnecessary processes first, the trace won't be so large. Going to Single-User mode can help. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
