I removed the queue and the system is working well, with the exception
of an error message from usbnet.c
drivers/net/usb/usbnet.c
@@ -278,7 +278,7 @@ void usbnet_defer_kevent (struct usbnet *dev, int work)
{
set_bit (work, &dev->flags);
if (!schedule_work (&dev->kevent))
deverr (dev, "kevent %d may have been dropped", work);
else
devdbg (dev, "kevent %d scheduled", work);
}
I am seeing a significant number of kevent 2 may have been dropped
messages. Should this be converted to a debug statement instead of an
error, rate limited, or removed?
On Tue, Oct 20, 2009 at 2:28 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, 20 Oct 2009, Greg Crocker wrote:
>
>> I am using the PLX Technologies OXU210HP USB Host Controller and would
>> like guidance on the best approach for working with memory constrained
>> devices. The OXU210 is a slave DMA device with 72K of SRAM and I have
>> modified an existing EHCI-OXU210HP driver to 'work' using
>> HCD_LOCAL_MEM.
>>
>> One issue I have not resolved is how to deal with the case where Linux
>> USB core system expects memory to available when usb_hcd_submit_urb is
>> called. I cannot provide a new implementation of ehci_urb_enqueue
>> because the call to map_urb_for_dma in usb_hcd_submit_urb fails before
>> ehci_enqueue_urb is called. To get through the initial board debug, I
>> have implemented an URB queue that allows the memory allocation to
>> fail and retry without depending on the higher level device drivers to
>> handle the failure. Most of them do not handle this situation
>> gracefully. As a result of breaking the USB state machine, I have
>> (not surprisingly) run into race conditions in how URBs are unlinked
>> and when devices are removed unexpectedly.
>>
>> At this point I am looking for recommendations on the best path going
>> forward. One option is to move the changes I made in usb/core to
>> usb/ehci-oxu210hp.c and add new functions to the hc_driver, similar to
>> ehci_urb_enqueue/dequeue, but this does not resolve the root cause of
>> needing the queue in the first place.
>
> You shouldn't need another queue at all; we've already got a queue of
> URBs for each endpoint. Instead you need to figure out how to deal
> with failures of map_urb_for_dma during submission.
>
> Here's a possible approach: Add a flag to the HCD structure indicating
> that the driver will handle its own DMA mapping, and avoid calling
> map_urb_for_dma and unmap_urb_for_dma when the flag is set. Then your
> driver can do whatever it wants.
>
> Alan Stern
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
