Re: [alsa-devel] USB transfer_buffer allocations on 64bit systems
On Tue, Apr 20, 2010 at 01:16:58AM +0100, Pedro Ribeiro wrote:
On 15 April 2010 16:20, Alan Stern stern@rowland.harvard.edu wrote:
On Thu, 15 Apr 2010, Pedro Ribeiro wrote:
I enabled CONFIG_DMAR_BROKEN_GFX_WA=y and the result is the same. A delay in the boot process and usb devices don't work properly, including my USB mouse.
Strange, since you have the same platform as me. The extra usb devices you were seeing are because of my docking station - but it makes no difference whether I'm docked or not for the purposes of the original bug or this situation right now. The dmesg I'm attaching is without the computer being docked.
It's not possible to determine the reason for the timeout errors between timestamps 16 and 53 from the small amount of debugging information in the log. Clearly something is going wrong with the communication between the computer and the EHCI controller. And clearly the kernel config changes are responsible.
But I don't know what to do to track it down any farther.
Alan Stern
I guess this is pretty much a dead end until anyone else can reproduce it!
Hmm, I think I finally found the reason for all this confusion. No idea why I didn't come up with the following explanation any earlier.
The problem is again (summarized):
On 64bit machines, with 4GB or more, the allocated buffers for USB transfers might be beyond the 32bit boundary. In this case, the IOMMU should take care and install DMA bounce buffer to copy over the buffer before the transfer actually happens. The problem is, however, that this copy mechanism takes place when the URB with its associated buffer is submitted, not when the EHCI will actually do the transfer.
In the particular case of audio drivers, though, the contents of the buffers are likely to change after the submission. What we do here is that we map the audio stream buffers which are used by ALSA to the output URBs, so they're filled asychronously. Once the buffer is actually sent out on the bus, it is believed to contain proper audio date. If it doesn't, that's due to too tight audio timing or other problems. This breaks once buffers are magically bounced in the background.
So - long story short: these audio buffers need to be DMA coherent.
The patch below does that, and Pedro excessively tested this patch for weeks now :) It was just the final explanation _why_ it does the right thing that was yet missing.
If nobody has objections, can we still squeeze it into .34?
Thanks, Daniel
Daniel Mack wrote:
The problem is again (summarized):
On 64bit machines, with 4GB or more, the allocated buffers for USB transfers might be beyond the 32bit boundary. In this case, the IOMMU should take care and install DMA bounce buffer to copy over the buffer before the transfer actually happens. The problem is, however, that this copy mechanism takes place when the URB with its associated buffer is submitted, not when the EHCI will actually do the transfer.
In the particular case of audio drivers, though, the contents of the buffers are likely to change after the submission. What we do here is that we map the audio stream buffers which are used by ALSA to the output URBs, so they're filled asychronously. Once the buffer is actually sent out on the bus, it is believed to contain proper audio date. If it doesn't, that's due to too tight audio timing or other problems. This breaks once buffers are magically bounced in the background.
At least the audio class and ua101 drivers don't do this and fill the buffers before they are submitted.
So - long story short: these audio buffers need to be DMA coherent.
Does the USB API actually guarantee that all controllers use DMA, i.e., that the buffers can be filled after submission?
Regards, Clemens
On Fri, May 07, 2010 at 11:47:37AM +0200, Clemens Ladisch wrote:
Daniel Mack wrote:
The problem is again (summarized):
On 64bit machines, with 4GB or more, the allocated buffers for USB transfers might be beyond the 32bit boundary. In this case, the IOMMU should take care and install DMA bounce buffer to copy over the buffer before the transfer actually happens. The problem is, however, that this copy mechanism takes place when the URB with its associated buffer is submitted, not when the EHCI will actually do the transfer.
In the particular case of audio drivers, though, the contents of the buffers are likely to change after the submission. What we do here is that we map the audio stream buffers which are used by ALSA to the output URBs, so they're filled asychronously. Once the buffer is actually sent out on the bus, it is believed to contain proper audio date. If it doesn't, that's due to too tight audio timing or other problems. This breaks once buffers are magically bounced in the background.
At least the audio class and ua101 drivers don't do this and fill the buffers before they are submitted.
Gnaa, you're right. I _thought_ my code does it the way I described, but what I wrote is how I _wanted_ to do it, not how it's currently done. I have a plan to change this in the future.
So unfortunately, that doesn't explain it either. Sorry for the noise.
Daniel
participants (2)
-
Clemens Ladisch -
Daniel Mack