On Mon, 24 Jan 2005, Adam J. Richter wrote: > With that patch applied, USB 2.0 devices still attach > as USB 1.x devices on both the ALI and VIA PCI USB controller cards > when used with my 2.8 GHz Pentium 4 motherboard. Loading usbcore > with old_scheme_first=y, as you had suggested to some other people, > also did not change this for either controller. However, I have > some other information that may be more interesting. > > I have a 600mhz Via Samuel 2 computer, which has a VIA > USB 2.0 controller built into the motherboard. On that system, > my Avision av220 scanner seems to work correctly as usb 2.0 > devices. sysfs and the console messages say the scanner is > connecting as a usb 2.0 device, and the time it takes to > scan a 300dpi page goes from 55-65 seconds (with a USB 1.1 hub > in the middle to force it USB 1.x) to 21-25 seconds. > > (By the way, this is particularly good news for my > specific problem with my Avision av220 scanner, as it means > that my problems are probably not the result of firmware > differences between my av220 and Rene's or most differences > in our software configurations.) > > Even more interesting, my VIA USB 2.0 PCI card in this > computer works, with my USB 2.0 devices connecting at 480 Mbps > (and the scanner working faster as with the built-in USB 2.0 ports), > but the ALi PCI USB controller still only connects to devices > at 12 Mbps.
The conclusion is that something about the EHCI driver doesn't agree with the controller on the ALi card. But why should it work with the VIA card on one PC but not the other...? BIOS interference of some sort? > Also, I've observed the failure mode of the ALi card (in > either computer) is slightly different than that of the VIA > card (in the 2.8GHz Pentium 4 computer). When the VIA usb 2.0 > controller card fails, the debugging messages that it generates > always include "port 2 full speed --> companion, port status 0x1011." > (I added the status to the printk.) The port number will depend on > which plug I'm using, of course. The port status numbers vary: I've > seen 0x1011, 0x1811 and 1813. Note that 0x10 is PORT_OC (overcurrent), > and that PORT_RESET (0x100) is not set in any of these values, meaning > that the ehci chip thinks the port is drawing too much power and > that the reset has not succcessfully completed. No. PORT_RESET not set means that a reset isn't in progress, i.e., the reset has completed. A number of people have noted problems with the overcurrent indicator. Nobody has figured out what the real story is, as far as I know. Maybe the bit is completely bogus. > With the ALi card, > these messages are not printed. In fact, there are no messages > from the ehci driver printed, as far as I can tell. So, the ehci > driver with the ALi card must punt to the USB 1.x controllers at > some other point. By the way, I have checked sysfs to make sure > that it thinks that the ehci driver is bound to the ALi USB 2.0 > controller. Check the log messages for the time when the ALi card is first detected and initialized by the ehci-hcd driver. You may find a fatal error occurring then. > Finally, I tried the following patch usb_hub_port_debounce() > to make it try to wait until an overcurrent condition disappears, > but this apparently does not happen. Instead, it eventually times > out and disables the port when I apply the following patch. > > Thanks for your suggested patch anyhow. I suspect that > the problem is some kind of missing delay after powering the > port, so I basically agree with your thinking. Now if only we knew where that delay belongs... Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
