[lkml]   [2001]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: alpha iommu fixes
    On Sun, May 20, 2001 at 06:07:17PM -0700, David S. Miller wrote:
    > Andrea Arcangeli writes:
    > > > [..] Even sparc64's fancy
    > > > iommu-based pci_map_single() always succeeds.
    > >
    > > Whatever sparc64 does to hide the driver bugs you can break it if you
    > > pci_map 4G+1 bytes of phyical memory.
    > Which is an utterly stupid thing to do.
    > Please construct a plausable situation where this would occur legally
    > and not be a driver bug, given the maximum number of PCI busses and
    > slots found on sparc64 and the maximum _concurrent_ usage of PCI dma
    > space for any given driver (which isn't doing something stupid).

    Assume I have a dozen of PCI cards that does DMA using SG tables that
    can map up to some houndred mbytes of ram each, so I can just program
    the cards to start the dma on those houndred mbyte of ram, most of the
    time the I/O is not simulaneous, but very rarely it happens to be
    simultaneous and in turn it tries to pci_map_sg more than 4G of physical
    ram. After that sparc64 iommu code will say "bye bye" and the machine
    will crash because the nic driver is not checking for pci_map_single

    I don't see why the above scenario should be classified as stupid. such
    pci_map_* API and the device drivers have to be generic.

    It's like if you say me that there's no need to check for
    alloc_pages(GFP_ATOMIC) faliures in the device drivers because all
    machines you are using have 256G of ram and you never use all the
    physical ram with your workloads. I would never buy such an argument.

    Furthmore currently (2.4.5pre3) on alpha you only need to ask the iommu
    to map more than 128mbyte of ram to crash (I increased it to 512mbyte at
    least, Jay said my first patch that increased it to 1G is risky because
    some device gets confused by bus addresses at around -1M and we keep the
    dynamic window above 3G, 512M should still be enough to cover 99% of
    hardware configurations I agree on that but this is not a good excuse to
    left all device drivers buggy just because those bugs doesn't trigger in
    all the hardware configurations out there).

    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 12:53    [W:7.153 / U:0.384 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site