On Jan 31, 2007, at 22:48, Alban Hertroys wrote:
Good day (or night, if more appropriate),
I'm seeing these for a while now, it's time to see if it can be
fixed :P
I have a setup where a KVM/USB switch (Gefen 2x1 DVI switcher) is
connected to my athlon64 machine, which is connected to yet another
hub in my TFT display to which my keyboard and mouse are connected.
I would have expected some response to this. I'm kind of disappointed.
Well, I have a new data point.
I found a PR about the Apple Cinema Display USB device hanging the
usb stack or some such. Thinking it might solve my problem I
disconnected the ACD USB device and plugged my keyboard and mouse
directly in the KVM switch and booted the machine.
Same problem, but on uhub3 this time. It gave a device write error
instead of a TIMEOUT, but I've seen that before when the ACD was
still connected too.
So the problem _does not seem to be related_ to the ACD problem(s).
Apparently the KVM switch contains a Cypress Tetra hub (acc. to the
vendor/device codes in dmesg).
Could someone please shed some light on this?
Schematically the USB devices are connected like this:
Athlon64 --- KVM switch --- Display --- Keyboard
Mac -------/ \-- Mouse
This time it looked like:
Athlon64 --- KVM switch --- Keyboard
Mac -------/ \-- Mouse
While booting I see messages like these:
uhub3: vendor 0x04b4 product 0x6560, class 9/0, rev 2.00/0.09, addr 2
uhub3: multiple transaction translators
uhub3: 4 ports with 4 removable, self powered
uhub4: vendor 0x05ac product 0x9131, class 9/0, rev 2.00/1.01, addr 3
uhub4: multiple transaction translators
uhub4: 3 ports with 2 removable, self powered
uhub4: device problem (STALLED), disabling port 1
uhub4: device problem (STALLED), disabling port 2
uhub4: device problem (TIMEOUT), disabling port 3
uhub3 is the KVM switch, while uhub4 is the display.
The messages are usually STALLED, but I've seen TIMEOUT (as above)
and SHORT_XFER as well.
I have tried eliminating the hub in the display from the equation,
the results are the same (the errors are on uhub3 in that case -
although I'm not 100% sure now I write this). I've tried different
hub cables (all but one came new with the switch), to no avail. The
KVM switch replaced a Sweex USB hub that had very similar problems.
Something that I think is odd is that the vendor/product ID's of
the hub in the KVM switch are listed among those in the sources,
yet looking them up apparently fails.
I compiled a kernel with DEBUG_USB enabled and attached the
resulting dmesg. I tried retrying usbd_new_device after the first
failure, but that just resulted in another STALLED message (as
suggested by an XXX remark in uhub.c).
Anything else I can do to help solve this?
Regards,
--
Alban Hertroys
"If you throw your hands up in the air,
how're you gonna catch them?"
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-
[EMAIL PROTECTED]"
--
Alban Hertroys
"It's not a bug!
It's a six-legged feature!"
!DSPAM:74,45e3e56f9411858390337!
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
