Re: Allocating buffers for USB transfers (again)

[Daniel Mack]

On Thu, Jul 7, 2011 at 3:08 PM, Oliver Neukum <oliver@xxxxxxxxxx> wrote:
> Am Donnerstag, 7. Juli 2011, 14:38:51 schrieb Daniel Mack:
>> On Thu, Jul 7, 2011 at 2:33 PM, Oliver Neukum <oliver@xxxxxxxxxx> wrote:
>>
>> > PS:  Do you still see this if you enable 64bit DMA for EHCI?
>>
>> The problem is that I personally don't see that issue at all. I even
>> installed 4GB of RAM to my development machine last year to be able to
>> reproduce this, but I can't, even when the memory allocator is under
>> heavy load. The only people who see this effect are Pedro Ribeiro and
>> William Light (both in Cc:), and both have been very helpful in trying
>> patches and reporting back in detail. Which instructions could we
>> probably give to these people to finally hunt this issue down?
>
> Do they have an IOMMU or are they using bounce buffers?
> If the latter, you might be able to reproduce it if you disable your
> IOMMU.

Ok, Pedro and William - can I ask you to dump the following
information to some paste bin:

- your .config
- the dmesg output of a booted kernel that shows the effect
- the output of "sudo lspci -v"

Also, the attached patch might give you at least one warning to your
kernel logs once the audio stream starts and outputs noise. I'm
curious whether it really does.

Thanks,
Daniel
diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
index 6c9fbe3..4260f78 100644
--- a/drivers/usb/host/ehci-sched.c
+++ b/drivers/usb/host/ehci-sched.c
@@ -1188,6 +1188,9 @@ itd_sched_init(
 		trans |= length << 16;
 		uframe->transaction = cpu_to_hc32(ehci, trans);
 
+		WARN_ONCE((u64)buf & (u64) 0xfff, "XXXXX URB DMA %016x is not 4k-aligned", (u64) buf);
+		WARN_ONCE((u64)buf & 0xffffffff00000000ULL, "XXXXX URB DMA %016x has upper 32bit set", (u64) buf);
+
 		/* might need to cross a buffer page within a uframe */
 		uframe->bufp = (buf & ~(u64)0x0fff);
 		buf += length;