2005/10/11, Alan Stern <[EMAIL PROTECTED]>:
> > hmm, this example may be correct not because you're _reading_ the
> > value but because printk statement doesn't _use_ urb's data
> > structure.
>
> Or because the printk statement doesn't require the URB's internal data
> not to change. Yes, but reading (or rather, not writing) is also part of
> it. If you write urb->status without holding urb->lock, you run the risk
> of the error I described earlier.
>
ok, I agree
> Remember that the only data protected by urb->lock is urb->status,
> urb->urb_list, and urb->reject. Your HCD should change nothing but the
> status.
>
it also changes hcpriv, actual_length, interval, start_frame...hcpriv
and actual_length seem to be only used by hcd. I don't know for the 2
others.
> > Well, I have my own lists of active ep (actually it's the same
> > mechanism as sl811-hcd driver by David Brownell). Each active ep have
> > a reference to its associated usbcore ep. It allows to retrieve list
> > of URB for that ep.
>
> I suppose that's okay, provided you remember that new entries can be added
> to the list before your driver has accepted them.
>
I suspect this is the problem of kref madness...let's follow this call graph
usb_internal_control_msg
usb_start_wait_urb
usb_submit_urb
hcd_submit_urb <- urb->kref->count = 1
link urb in ep's list
<- HCD interrupt, send URB
[ ....]
<- give back urb:
urb->kref->count = 0
usb_get_urb
kref_get <- MADNESS urb->kref->count = 0
hcd->urb_enqueue
If an interrupt occurs right after inserting the urb into ep's list,
this urb can be transfered and gave back to the driver before
usb_get_urb is called ! A simple fix is to link urb right after
calling hcd->urb_enqueue. What do you think about this ?
> > > What would happen if your urb_enqueue method had to reject the submission
> > > because it couldn't allocate memory for the private data structure? The
> > > hardware might already be transferring the rejected URB!
> > >
> >
> > In that case it can't happen. Allocation happens only when scheduling
> > an ep the first time. At this time this ep in not in my list of active
> > ep so it's not a candidate for transfering URB.
>
> So your urb_enqueue method can never fail, except on the first URB for an
> endpoint?
Yes.
Thanks
--
Franck
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
