[lkml]   [2011]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/2] x86 swiotlb: Verify we can perform the remapping requested.
    Konrad Rzeszutek Wilk <> writes:

    > On Mon, Oct 17, 2011 at 02:19:18PM -0700, Eric W. Biederman wrote:
    >> Recently I had a driver try with a peculiar 2G dma memory limit.
    >> It failed in weird and strange ways because my bounce buffers were
    >> being allocated above 2G where the driver could not reach, and
    >> no error was reported when the mappings were setup.
    > OK, so the overflow buffer was used instead.. which presumarily
    > also was allocated above the 2G? That seems to point that
    > alloc_bootmem_low_pages is not doing its job?

    I just looked alloc_bootmem_low_pages allocates memory below
    ARCH_ADDRESS_LIMIT which for everything except s390 is 4G.

    I know I was mostly using the amd gart driver. So I may be mistaken
    that the swiotlb driver had the same issue. However my only solution
    at the time was to boot with mem=2G. So I believe the swiotlb did
    have this issue.

    Mostly the patch was. Hmm. That looks stupid not wiring up the
    swiotlb address space limit check when someone has already written it.

    >> Use the swiotlb_dma_supported to avoid silent problems like this
    >> in the future.
    > Which driver was it that had this limit?

    An unmerged driver. The driver has since been fixed to use it's
    hardware in a way that doesn't hit this limit.

    At the time that I looked drivers in the kernel with a dma limit
    above 16MB and blow 4GB only existed on exotic architectures in
    very special cases.

    Unfortunately I no longer have access to this hardware to test with.


     \ /
      Last update: 2011-10-24 17:09    [W:0.026 / U:4.532 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site