Quoting Scott Bronson <[EMAIL PROTECTED]>: > I own a Mitsubishi Diamond Pro 2040u monitor. It has a built-in > USB hub for the monitor and keyboard. The problem is, when I plug > this hub into my computer, I get a ton of timeout delays and error > messages. Something is going very wrong. > > Amazingly, after about 5 minutes of thrashing (see the end of the > dmesg log below), everything sorts out and the hub starts to work! > However, there's still a problem: /proc/bus/usb/devices is very > garbled. > > I'm pretty sure this indicates a bug in the Linux USB stack. > Below I've included as much information as I could gather. What > else should I investigate? > > Here is /proc/bus/usb/devices. It looks excellent except for > the following three lines. The following strings are clearly > corrupted: > > S: Manufacturer=MITSUBISHI ELECTRIC?NSB1107U?911001603 ?? > S: Product=NSB1107U?911001603 ???????�??~?????�???? > S: SerialNumber=911001603 ???????�??~?????�???�
What about monitor warm-up? Does it affect anything? The descriptors are probably corrupted. Each string has its length declared, and if the data gets corrupted then the extra data gets read. These are not NUL-terminated (ASCIIZ) strings. This seems likely because the manufacturer and the product strings are merged into one, and same with the serial number too. They are sitting in the EEPROM one after another. Either the device controller messes them up and serves to the host incorrectly, or something else is wrong... maybe even the EEPROM itself. > usb-uhci.c: interrupt, status 3, frame# 395 > usb_control/bulk_msg: timeout > usb_control/bulk_msg: timeout Could it be caused by the device sending incorrect response packets? To investigate, I would use Win98 + sniffer to find out what descriptors the hub sends back on Windows. Then it would be easy to see the difference between that and what Linux sees. My guess is that it is a hardware bug, in the USB device (hub). The question is: how to work around it? Also, if the device installs its own drivers on Win98 then it would be also a strong indication of "issues" with the hardware. They can easily put a filter driver anywhere in the USB stack to compensate for bugs... Dmitri -- The chat program is in public domain. This is not the GNU public license. If it breaks then you get to keep both pieces. (Copyright notice for the chat program)
msg01676/pgp00000.pgp
Description: PGP signature
