On Mon, 4 Jun 2007, Vortex wrote: > Hi!! > > Currently im playing with the ds2490 USB-to-OneWire Bridge from Dallas > Semiconductor and built an interface circuit. Two of this devices > are working on different machines with kernel versions from 2.6.18 > up to 2.6.21 perfectly. > > Now one of the intended target machines (HP Omnibook xt1000s) causes > Problems. It happens with the Kernelspace 1-Wire device drivers as well > as with the userspace 1-Wire project owfs using libusb. Therefore i > suppose it's more related to the core usb-system than to one of these > projects. But i'm certainly not familiar with all this usb stuff. > The error can be observed with a self compiled 2.6.21 kernel > (which generated the following debuging output). But it's the same > with the 2.6.18 kernel that come's with debian-testing. > > With usb debuging activated the dmesg output looks like this: > > uhci_hcd 0000:00:11.3: reserve dev 2 ep81-INT, period 1, phase 0, 36 us > uhci_hcd 0000:00:11.3: release dev 2 ep81-INT, period 1, phase 0, 36 us > uhci_hcd 0000:00:11.3: reserve dev 2 ep81-INT, period 1, phase 0, 36 us > uhci_hcd 0000:00:11.3: release dev 2 ep81-INT, period 1, phase 0, 36 us > uhci_hcd 0000:00:11.3: reserve dev 2 ep81-INT, period 1, phase 0, 36 us > uhci_hcd 0000:00:11.3: release dev 2 ep81-INT, period 1, phase 0, 36 us > usb 2-1: uhci_result_common: failed with status 500000
The 500000 status means Babble and Stalled. In other words, the computer's USB controller detected signals on the USB bus at a time when the device should not have been sending anything. Maybe the signals were electrical noise, or maybe the controller's detection circuitry isn't working right. > usb 2-1: owfs timed out on ep0out len=-8/0 > usb 2-1: owfs timed out on ep0out len=-8/0 > usb 2-1: usbfs: USBDEVFS_CONTROL failed cmd owfs rqt 64 rq 1 len 0 ret -110 > usb 2-1: owfs timed out on ep0out len=-8/0 > usb 2-1: usbfs: USBDEVFS_CONTROL failed cmd owfs rqt 64 rq 1 len 0 ret -110 > usb 2-1: owfs timed out on ep0out len=-8/0 > usb 2-1: usbfs: USBDEVFS_CONTROL failed cmd owfs rqt 64 rq 1 len 0 ret -110 > usb 2-1: owfs timed out on ep0out len=-8/0 > usb 2-1: usbfs: USBDEVFS_CONTROL failed cmd owfs rqt 64 rq 1 len 0 ret -110 > usb 2-1: owfs timed out on ep0out len=-8/0 > usb 2-1: usbfs: USBDEVFS_CONTROL failed cmd owfs rqt 64 rq 1 len 0 ret -110 > > After a few successful interactions on the bus, the communication fails > obviously. To recover from this it's not enough to replug the device. > If i don't, it looks like this: > > usb usb2: wakeup_rh (auto-start) > hub 2-0:1.0: state 7 ports 2 chg 0000 evt 0002 > uhci_hcd 0000:00:11.3: port 1 portsc 0093,00 > hub 2-0:1.0: port 1, status 0101, change 0001, 12 Mb/s > hub 2-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101 > usb 2-1: new full speed USB device using uhci_hcd and address 7 > usb 2-1: khubd timed out on ep0in len=-8/64 > usb 2-1: khubd timed out on ep0in len=-8/64 > usb 2-1: khubd timed out on ep0in len=-8/64 > usb 2-1: device descriptor read/64, error -110 > usb 2-1: khubd timed out on ep0in len=-8/64 > usb 2-1: khubd timed out on ep0in len=-8/64 > usb 2-1: khubd timed out on ep0in len=-8/64 > usb 2-1: device descriptor read/64, error -110 > usb 2-1: new full speed USB device using uhci_hcd and address 8 > usb 2-1: khubd timed out on ep0in len=-8/64 > usb 2-1: khubd timed out on ep0in len=-8/64 Evidently the controller isn't able to recover from its error state. This could be a result of an incorrect PCI config setting or some other sort of bug. For example, maybe the USB controller hardware is initialized incorrectly by the BIOS. Try changing the BIOS settings. > After reloading uhci_hcd it looks like this: ... > and everything can be repeated from start. So reinitializing the controller allows it to recover. Until the next time... > I must mention that several other USB devices are working > flawlessly on this notebook as well as this 1-wire bridge device > is working perfectly on several other computers. It's apparently > only this combination which makes problems. Things often happen that way. However it looks like once the error has been triggered, the controller is unable to recover by itself. That's a bug or a misconfiguration in the controller. > Even more curious: > As soon as the bridge-device is connected via a USB-hub > (without external power supply) it works too! > Of course this would be a work around but it's quite > unsatisfying. > > AND: > The failure can be reproduced with another of these bridge > devices which is using the same chipset (ds2490) but another > surrounding circuit design. So it's unlikely that it's an > electrical problem. But the fact that sticking an unpowered hub in between makes it work indicates that it _is_ an electrical problem! At least in part. > I'm a bit helpless at the moment. Sometimes you just run up across marginal hardware; there isn't much you can do except to change it. In this case, I would certainly be suspicious of the computer's USB host controller. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
