On 13 April 2010 19:22, Daniel Mack <daniel@xxxxxxxx> wrote: > On Mon, Apr 12, 2010 at 12:57:16PM -0400, Alan Stern wrote: >> On Mon, 12 Apr 2010, Andi Kleen wrote: >> > On Mon, Apr 12, 2010 at 12:17:22PM -0400, Alan Stern wrote: >> > > On Mon, 12 Apr 2010, Andi Kleen wrote: >> > > >> > > > > Well, the sound driver itself doesn't care for any of those things, just >> > > > > like any other USB driver doesn't. The USB core itself of the host >> > > > > controller driver should do, and as far as I can see, it does that, yes. >> > > > >> > > > Hmm, still things must go wrong somewhere. Perhaps need some instrumentation >> > > > to see if all the transfer buffers really hit the PCI mapping functions. >> > > >> > > Such a test has already been carried out earlier in this thread: >> > > >> > > http://marc.info/?l=linux-usb&m=127074587029353&w=2 >> > > http://marc.info/?l=linux-usb&m=127076841801051&w=2 >> > > http://marc.info/?l=linux-usb&m=127082890510415&w=2 >> > >> > Hmm, thanks. But things must still go wrong somewhere, otherwise >> > the GFP_DMA32 wouldn't be needed? >> >> Indeed, something must go wrong somewhere. Since Daniel's patch fixed >> the problem by changing the buffer from a streaming mapping to a >> coherent mapping, it's logical to assume that bad DMA addresses have >> something to do with it. But we don't really know for certain. > > Some more ideas to nail this down would be to boot the machine with > mem=4096M and mem=2048M to see whether this makes any difference. Also, > I think it would be interesting to know whether the patch below helps. > > As the real reason seems entirely obfuscated, there's unfortunately need > for some trial error approach. Pedro, as you're the only one who can > actually reproduce the problem, do you see any chance to do that? > > Thanks, > Daniel > > > diff --git a/sound/usb/caiaq/audio.c b/sound/usb/caiaq/audio.c > index 4328cad..26013be 100644 > --- a/sound/usb/caiaq/audio.c > +++ b/sound/usb/caiaq/audio.c > @@ -560,7 +560,7 @@ static struct urb **alloc_urbs(struct snd_usb_caiaqdev *dev, int dir, int *ret) > } > > urbs[i]->transfer_buffer = > - kmalloc(FRAMES_PER_URB * BYTES_PER_FRAME, GFP_KERNEL); > + kmalloc(FRAMES_PER_URB * BYTES_PER_FRAME, GFP_KERNEL | GFP_DMA); > if (!urbs[i]->transfer_buffer) { > log("unable to kmalloc() transfer buffer, OOM!?\n"); > *ret = -ENOMEM; > > Good news, I can't trigger the interference with either: - mem=2048m - mem=4096m - your patch Any idea why is mem=4096m different than a regular boot since I have 4GB anyway? Regards, Pedro -- 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
