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.
> 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.
> I'm trying to help too many people with too many problems to remember all
> the details, so you'll have to forgive me when I forget some of earlier
> correspondence.
I meant in now way to offend you, I am really sorry if I did so. Of
course I can understand that you can't keep every conversation in your
mind, especially not those from weeks ago...
> 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.
> 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? :-).
Axel.
-------------------------------------------------------
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
