[lkml]   [2003]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: problem with blk_queue_bounce_limit()
       From: David Mosberger <>
    Date: Fri, 6 Jun 2003 13:13:38 -0700

    Yes, but the comment certainly is confusing. How about something like

    No arguments.

    David> The whole block layer makes all kinds of assumptions about
    David> what physically contiguous addresses mean about how they'll
    David> be contiguous in the bus addresses the device will actually
    David> use to perform the DMA transfer.

    This sounds all very dramatic, but try as I might, all I find is three
    places where PCI_DMA_BUS_IS_PHYS is used:

    - ide-lib.c: used to disable bounce buffering
    - scsi_lib.c: used to disable bounce buffering

    Fix your grep,

    - tg3.c: what the heck??

    In order to workaround a "just below 4GB dma address" bug in the
    chip, we have to have a reliable way to "remap" the given networking
    buffer to some other DMA address that does not meet the hw bug case.

    If we don't have an IOMMU, we have to change the buffer itself and
    we accomplish this with SKB copy.

    But on an IOMMU system, we could end up mapping to the same bogus
    DMA address. So we have to solve this problem by keeping the
    existng bad mapping, doing a new DMA mapping, then trowing away
    the old one.

    Did I get this right (or at least close enough)?


    Otherwise, you could just always use the copy-the-entire-buffer

    The new PCI dma mapping I make could map to the SAME bad DMA
    address, that's the problem. I could loop forever making new
    DMA mappings on an IOMMU system, each and every one falls into
    the hw bug case.

    I really dislike PCI_DMA_BUS_IS_PHYS, because it introduces a
    discontinuity. I don't think it should be necessary.

    I totally disagree.

    David> We could convert the few compile time checks of
    David> PCI_DMA_BUS_IS_PHYS so that you can set this based upon the
    David> configuration of the machine if for some configurations it is
    David> true. drivers/net/tg3.c is the only offender, my bad :-)

    Yes. Would you mind fixing that?

    Sure, no problem.

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

     \ /
      Last update: 2005-03-22 13:36    [W:0.034 / U:48.468 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site