Alan Stern wrote:
All right. The patch below might help track down even more precisely where the problem starts.
FWIW, the new patch gives: uhci irq status: 0x24 usb 1-1: new full speed USB device using address 2 uhci enqueue: cdb1a2a0 Before enabling uhci fsbr Immediately after enabling uhci fsbr 3 ms after enabling uhci fsbr
I've been trying to follow how far the code runs from the previous patch you sent. As far as I can tell, the first time uhci_inc_fsbr() is called is in uhci_submit_control(), and it returns quite happily here. It then returns to uhci_urb_enqueue() as well. Here, I can't get past the spin_unlock_irqrestore() at the end of this function. I figure this is when it gives up control of the cpu, so something else gets control and then it all locks up. I can't event step past the line using kgdb.
So I'm trying to find out how setting uhci->skel_term_qh->link to the dma_handle changes how the code runs, but am struggling to find good documentation? I'm sure someone's just going to say the code is the best place to look though... :)
Thanks, Malcolm.
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
