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. ;) > 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. -- Greetings Michael. _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
