On Tue, 17 Feb 2004, Axel Waggershauser wrote: > On Tue, 2004-02-17 at 17:31, Alan Stern wrote: > > Did the debugging log end up looking exactly the same as last time? > > No it didn't, the difference was that my completion handler used to be > called with the urb->status == 0. After I applied the patch it got > called with urb->status == -108. Besides this difference the log looked > the same.
-ESHUTDOWN is an appropriate error code for an URB sent to a device that has been removed. So that much is working correctly now, good. > > And are you sure that the URB hadn't been resubmitted after being sent to > > finish_urb? > > I checked to see if the urb got resubmitted by adding a printk to > uhci_urb_submit and got the following surprising result (I modified some > other printks, so the log looks different than before): > > The first line shows the interrupt caused by reconnecting my test device > after I ran my usual unplugging-test. > > 19:56:29: uhci_irq status = 36, uhci->state = -10 > 19:56:29: uhci_remove_pending_urbps processed cc82b140 > 19:56:29: >>> uhci_finish_urb cc82b140 > 19:56:29: uhci_set_next_interrupt > 19:56:29: spheroncam.c: spheroncam_complete urb: cc82b140 status: -108 > 19:56:29: << uhci_finish_urb cc82b140 > 19:56:29: drivers/usb/host/uhci-hcd.c: c800: wakeup_hc > 19:56:30: hub 1-0:1.0: new USB device on port 2, assigned address 6 > 19:56:30: >>> uhci_urb_enqueue cc82b140 > 19:56:30: << uhci_urb_enqueue ret = 0 > 19:56:35: usb 1-2: control timeout on ep0out > 19:56:35: >>> uhci_urb_dequeue cc82b140 > 19:56:35: uhci_set_next_interrupt > 19:56:35: uhci_set_next_interrupt > 19:56:35: << uhci_urb_dequeue cc82b140 uhci->state: 2 > > I made sure my driver is not responsible for re-submitting this urb > (cc82b140). I expected an urb to be enqueued during the enumeration > process but not "my" urb. Could it be that the submitted urb is actually > an other/new one but it happens to use the same memory since I > usb_free_urb'ed "my" urb in my drivers disconnect function, which gets > called after the disconnection is detected. I want to point out again > that my driver does currently _not_ wait for that urb to complete in its > disconnect/release functions, since this wait would hang. Later, if any > problems are sort out I would make it wait for every urb it submitted, > of course. It's quite likely that another URB would be allocated in the same memory location. The USB core uses URBs to communicate with newly-attached devices, in order to assign bus addresses and enumerate them. So this is to be expected. > > I'm interested in seeing the state of the controller registers as printed > > in the /proc/driver/uhci/... file as well as whether or not an interrupt > > occurred. Can you provide the debugging log from that test? > > "cat /proc/driver/uhci/0000\:00\:11.2" output: > > HC status > usbcmd = 00c1 Maxp64 CF RS > usbstat = 0000 > usbint = 000f > usbfrnum = (1)af4 > flbaseadd = 08d3c000 > sof = 40 > stat1 = 0480 > stat2 = 0495 PortEnabled PortConnected > Frame List > Skeleton QH's > > There is no interrupt following this > > uhci->term_td->status |= cpu_to_le32(TD_CTRL_IOC); > > call in my uhci_proc_open function. I tried it several times. Okay. Whatever the flaw is in the VIA chips that causes them to stop working, your system triggers it somehow -- and not through babbling. The problem of the URB not completing right away will get solved in time. There are several other changes to the driver that need to be made first. I'm still a little surprised that the controller doesn't terminate the URB with an error once the device is disconnected from the bus. I think you said before that this does happen, but only 9 times out of 10. Maybe the disconnection itself is the event that causes the controller to stop working sometimes. Maybe the transient electrical noise in the data lines looks enough like babble to trigger the flaw. > > That workaround was only supposed to address "babble" packets, which you > > don't observe. Unfortunately it doesn't even seem to do that! > > You don't happen to have some more of these "special" bits to be set to > fix all other VIA problems? :-). I wish I did... :-( The company is very reluctant to give out information about their USB controllers. Alan Stern ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
