On Tue, 11 May 2010 10:00:50 -0400 (EDT) Alan Stern stern@rowland.harvard.edu wrote:
The problem goes away when Pedro boots with mem=4G. And the dma_mask value is set properly (in fact, the ehci-hcd driver currently doesn't use 64-bit DMA at all).
If anyone wants to see the debug log entries showing the buffer and DMA addresses, they are attached to this email message:
http://marc.info/?l=linux-kernel&m=127076841801054&w=2
Either the data isn't getting written to the buffer correctly or else the buffer isn't getting sent to the device correctly. Can anybody suggest a means of determining which is the case?
I can't say anything about this log that including only DMA addresses. I'm not familiar with how the USB core does DMA stuff. And the USB stack design that the USB core does DMA stuff (allocating, mappings, etc) makes debugging DMA issues really difficult.
The DMA stuff is simple enough in this case. The urb->transfer_buffer address is passed to dma_map_single(), and the DMA address it returns is stored in urb->transfer_dma. Those are the two values printed out by the debugging patch.
You've already confirmed that all the returned addresses (urb->transfer_dma) in the log is less than 4GB, right?
Drivers need to take care of more things (not only about addresses) to do DMA properly, that is, use the DMA API in the proper way (such as, once calling dma_map_single, drivers can't touch the buffer until calling dma_unmap_single)
Using the DMA API and performing DMA transfer in different places just make things complicated.