Re: USB transfer_buffer allocations on 64bit systems

[Daniel Mack <daniel@caiaq.de>]

On Mon, Apr 12, 2010 at 02:47:08PM +0200, Andi Kleen wrote:
> On Mon, Apr 12, 2010 at 02:32:38PM +0200, Daniel Mack wrote:
> > Another detail I can't explain is that on his machine, the kernel oopses
> > when kmalloc() with GFP_DMA32 is used. The patch to try this also only
> > touched the allocation in sound/usb/caiaq/audio.c.
> 
> Where did it oops?

Pedro sent me an image:

  http://caiaq.de/download/tmp/GFP_DMA32.JPG

The patch I sent him for testing and that lead to this Oops was:

> 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_DMA32);                                                  
>                if (!urbs[i]->transfer_buffer) {                                                                                             
>                        log("unable to kmalloc() transfer buffer, OOM!?\n");                                                                 
>                        *ret = -ENOMEM;                                                                                                      
>                                                                                                                                             


> >   http://caiaq.de/download/tmp/pedro-dmesg
> 
> The system seems to set up the soft iotlb correctly.
> 
> [    0.468472] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
> [    0.468539] Placing 64MB software IO TLB between ffff880020000000 - ffff880024000000
> [    0.468610] software IO TLB at phys 0x20000000 - 0x24000000
> 
> Also if that was wrong a lot more things would go wrong.
> 
> I would suspect the driver. Are you sure:
> 
> - it sets up it's dma_masks correctly?
> - it uses pci_map_single/sg correctly for all transferred data?

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.

Daniel