More information about this;
GetStatus port 2 status 00180b POWER sig=j PEC CSC CONNECT
I added some code to do a 10us delayed double read of the port status
and it's the same so the status of 00180b is true. The important part
of the port status is the lower nibble 0xb, that's bit's 0, 1 and 3
for device present on port (CONNECT), connect status change (CSC) and
port enable/disable change (PEC). So the usb device is still connect
but the connect status change is really (guessing here) due to the
bit 3 set. That bit indicates that the controller disabled the port
due to some condition existing at the EOF2 point. The default bios
VIA vt8253 setting is to disable the port so it's dead from there on.
I've read that with a VIA EHCI controllers are a pain in that if you
get EOF2 errors, the port is dead until the ehci controller is reset.
After much searching I finally found the vt8253 chipset doc and you
can set bit 6 at 0x40 ehci pci offset to disable the babble disable
option. It's interesting to see that at bit is defaulted set to 1 in
the docs but both the bios and WinXP have it at set to 0.
Why khubd hangs is still a mystery to me.
From my research, I'm not alone in this sporatic USB hang running
under a VIA vt8253 chipset. It's not the device, nor cables nor EMI.
Sooner or later if you have a VIA vt8253 chipset and leave a usb 2.0
device connected for a long time, you will get a hang. We have some
boxes that have run for a few months before hanging the usb
subsystem. So there's a timing issue involving the VIA frame timer
where EOF2 occurs slightly sooner than it should or the usb device
signals get to the EOF2 checkpoint slightly later.
So I have two choices;
a) set the babble option to not disable the port, trap the EOF2
condition, clear it and ignore the error and see if I still live.
b) start playing with FLADJ the frame length adjustment register to
see if that solves the problem. The FLADJ register is interesting in
that no one ever seems to change it's default setting yet it's
important enough to have as a base PCI register for the EHCI
controller.
I do have one more test before proceeding, I've disabled the spread
spectrum clock in bios. I figure that maybe the spread is wider than
VIA thinks and I'm seeing that reflected in the usb frame timing such
that the ehci and usb device frames are slighly out of phase.
I'm in slow motion on this, it takes one to two days to get a
sporadic disconnect.
Scott
-------------------------------------------------------
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
