Re: b44 driver causes panic when using swiotlb

From: Larry Finger
Date: Mon Jan 31 2011 - 23:53:10 EST

On 01/31/2011 10:41 PM, Larry Finger wrote:
> From: Robert Hancock
> Date: Mon Jan 31 2011 - 22:22:32 EST
> * Next message: Amit Shah: "Re: [PATCH 1/3] tty: move hvc drivers to
> drivers/tty/hvc/"
> * Previous message: Grant Likely: "Re: [RFC][PATCH] Power domains for
> platform bus type"
> * In reply to: FUJITA Tomonori: "Re: b44 driver causes panic when using swiotlb"
> * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> On 01/31/2011 07:28 PM, FUJITA Tomonori wrote:
> On Mon, 31 Jan 2011 18:54:21 -0600
> Robert Hancock<hancockrwd@xxxxxxxxx> wrote:
> On 01/31/2011 10:36 AM, Andi Kleen wrote:
> On Mon, Jan 31, 2011 at 10:54:12AM -0500, Chuck Ebbert wrote:
> The b44 driver is triggering this panic in swiotlb_map_page():
> if (!dma_capable(dev, dev_addr, size))
> panic("map_single: bounce buffer is not DMA'ble");
> The kernel log says the bounce buffers are at 0xdb400000, but
> b44 can
> only do DMA to the first 1GB of memory:
> b44 needs to use GFP_DMA then and do its own custom bouncing.
> The standard pci_map_* bounce buffering is only designed for at least
> 32bit capable devices.
> That seems wrong - it's a documented API and that restriction isn't
> documented. Either it should comply with the request or return a failure
> if it can't accomodate it, not just blow up internally. There's no
> reason the driver should have to deal with this on its own.
> In this case the DMA mapping code should really be falling back to
> GFP_DMA automatically if the IOMMU aperture is outside the DMA mask of
> the device.
> swiotlb allocates the bounce buffer when a system boots up. We can't
> allocate much in GFP_DMA. swiotlb uses somewhere under 4GB. So it
> can't help devices that have odd dma_mask (that is, except for 4GB).
> Unfortunately, Such device needs to do own custom bouncing or needs
> their subsystem to does that.
> Some ideas to implement something that works for such device were
> discussed. Seems that the conclusion is that it's doesn't worth making
> the common code complicated for such minor and insane devices.
> I don't think this is the only device that has sub-32-bit DMA restrictions, this
> will just lead to a bunch of duplicated code. In particular, how is LPC DMA
> supposed to work?
> At the very least we should be allowing the driver to deal with the failure
> instead of panicing the system. Otherwise we are just leaving a land mine for
> people to trip over.

Some devices driven by b43legacy and b43 only support 30-bit DMA, which is what
I suspect b44 handles. The b43* drivers use a bounce buffer. If a generic
mechanism were created, those 2 would use it.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at