On Wed, 2004-01-14 at 22:53, Alan Stern wrote: > I'm not sure. uhci_set_next_interrupt makes a trivial change to a data > structure which should cause the controller to signal an interrupt at the > end of the current or next frame. That change is undone by > uhci_clear_next_interrupt. You could try adding printk's to them to make > sure that the change is being made and not unmade.
The new printk's in uhci_clear_next_interrupt() and in uhci_set_next_interrupt() revealed the following trace: Jan 14 23:33:26 koffer kernel: >>> uhci_urb_dequeue cf02d560 Jan 14 23:33:26 koffer kernel: >>> uhci_set_next_interrupt Jan 14 23:33:26 koffer kernel: << uhci_set_next_interrupt Jan 14 23:33:26 koffer kernel: uhci_urb_dequeue cf02d560 list_empty == true Jan 14 23:33:26 koffer kernel: >>> uhci_set_next_interrupt Jan 14 23:33:26 koffer kernel: << uhci_set_next_interrupt Jan 14 23:33:26 koffer kernel: << uhci_urb_dequeue cf02d560 Jan 14 23:33:26 koffer kernel: uhci_hcd 0000:00:07.2: shutdown urb cf02d560 pipe c0020380 ep4in-bulk beyond that point there comes no uhci_clear_next_interrput and no uhci_irq call. (there follow a few more disable_endpoint calls and the mentioned givebacks for the status URBs, thats all) So I guess that is bad (meaning the hardware is buggy?). I would like to mention some other observations I have made, which I don't understand in the context of what I learned about the controller so far. Maybe they give some more hints: ----------- 1. From what you told me I understood that the set_next and clear_next calls should only occur in pairs (set_next -> uhci_irq gets called and calls clear_next) when I look at a normal URB transfer, of the same type I am investigating, I get following trace: # this first line is the last successful URB completion # the ">>>" mean entry, the " <<" mean exit Jan 14 23:33:26 koffer kernel: spheroncam.c: spheroncam_complete urb: cf02d560 status: 0 Jan 14 23:33:26 koffer kernel: << giveback cf02d560 Jan 14 23:33:26 koffer kernel: << uhci_finish_urb cf02d560 # now I get uhci_irq calls... Jan 14 23:33:26 koffer kernel: uhci_irq status 32 Jan 14 23:33:26 koffer kernel: >>> uhci_clear_next_interrupt Jan 14 23:33:26 koffer kernel: << uhci_clear_next_interrupt Jan 14 23:33:26 koffer kernel: uhci_irq status 1 Jan 14 23:33:26 koffer kernel: >>> uhci_clear_next_interrupt Jan 14 23:33:26 koffer kernel: << uhci_clear_next_interrupt # the last 4 lines repeat usually 3 or 4 times, then follows... Jan 14 23:33:26 koffer kernel: >>> uhci_set_next_interrupt Jan 14 23:33:26 koffer kernel: << uhci_set_next_interrupt Jan 14 23:33:26 koffer kernel: >>> uhci_finish_urb cf02d560 Jan 14 23:33:26 koffer kernel: >>> uhci_set_next_interrupt Jan 14 23:33:26 koffer kernel: << uhci_set_next_interrupt # here I get the next successful completion... Jan 14 23:33:26 koffer kernel: >>> giveback cf02d560 Jan 14 23:33:26 koffer kernel: spheroncam.c: spheroncam_complete urb: cf02d560 status: 0 So I see 6 to 8 clear_next calls and then 2 set_next calls. Is that like it is supposed to be? ------- 2. The controller does not always behave like that. Approximately one out of 5 times it actually completes the URB when unlinking the device with an appropriate return value (-84). The trace in this case looks pretty much the same like above except the last uhci_irq call before the giveback reads a status value of 2 instead of 1. looks like this: # here I see the same 32 -> 1 -> 32 -> 1 -> .. pattern as above and then Jan 14 23:27:03 koffer kernel: uhci_irq status 32 Jan 14 23:27:03 koffer kernel: >>> uhci_clear_next_interrupt Jan 14 23:27:03 koffer kernel: << uhci_clear_next_interrupt Jan 14 23:27:03 koffer kernel: uhci_irq status 2 Jan 14 23:27:03 koffer kernel: >>> uhci_clear_next_interrupt Jan 14 23:27:03 koffer kernel: << uhci_clear_next_interrupt Jan 14 23:27:03 koffer kernel: >>> uhci_set_next_interrupt Jan 14 23:27:03 koffer kernel: << uhci_set_next_interrupt Jan 14 23:27:03 koffer kernel: >>> uhci_finish_urb cf02dbc0 Jan 14 23:27:03 koffer kernel: >>> uhci_set_next_interrupt Jan 14 23:27:03 koffer kernel: << uhci_set_next_interrupt Jan 14 23:27:03 koffer kernel: >>> giveback cf02dbc0 Jan 14 23:27:03 koffer kernel: spheroncam.c: spheroncam_complete urb: cf02dbc0 status: -84 I have to point out that in this case there are no calls like disable_endpoint or uhci_urb_dequeue involved. Like as if its not the hub that detects the disconnect. Any thoughts? Thanks, Axel. ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
