Michael Buesch wrote: > On Wednesday 28 March 2007 19:42, Larry Finger wrote: >> Will Dyson wrote: >>> On 3/24/07, Michael Buesch <[EMAIL PROTECTED]> wrote: >>> >>>> I _still_ think that this should be fixed in the arch DMA code >>>> and _not_ in every single driver on earth. But I discussed this in >>>> the past. >>> That would be nice. What would that look like to you? A GFP flag that >>> gets memory within the dma_mask? >> To me that would mean honoring the dma_mask for _ALL_ DMA memory >> allocations. I have not followed >> all the arguments as to why this was never fixed in the i386 code, > > On i386 we are fine, as long as we don't use scatter-gather IO for the > DMA operations. If we kmalloc() the DMA buffers, we are implicitely > guaranteed (as long as nobody changed the user/kernel split) to be > under the 1G barrier (actually the barrier is at 1G minus 128M). > > Although, people want to implement SG-IO for mac80211. That > would mean buffers are not copied to kernelspace, so they could > be above 1G. > >> but I know that the x86_64 >> architecture was forced to produce the same (wrong) results as were obtained >> in the i386-specific >> code. I agree that it should be fixed; however, it will never happen. > > Explain why, please. I'm very interrested in knowing why this > is so fucking broken and why nobody fixes it. ;)
John - do you know the history? >> As a result, every driver for >> hardware with less than 32-bit DMA addressing has to address (pun intended) >> the problem. We will >> probably be fighting the problem again when > 4 GB RAM computers become >> common and 32 bits are not >> enough to address all of memory. > > Nope, see Johannes' mail. Yes, if an IOMMU is included, but why don't we have them now on our 64-bit processors? Larry _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
