Hi Geert,
Anyway, the patch seems to be required for ramdisk use, so I better clean it up one way or the other. Geert - do we need to be able to free allocated ST-RAM? Otherwise, I'd just remove the dead freelist stuff and submit that.Sorry, I'm a bit lost. Which patch(es) do you mean?
My patch from January 3rd, under message ID Pine.LNX.4.44.0801030301480.22222-100000@onyx.biophys.uni-duesseldorf.de
(in case you can search by message IDs)In a nutshell, framebuffer init happens after mem_init these days (probably has since 2.4 at least), and loading an initramfs ramdisk eats up whatever is left of DMA (and VIDEL) addressable RAM. Hence, the framebuffer driver gets left with memory it cannot read from (it will happily read from whatever is at the same address, masked off to the lower 24 bits).
My first attempts at fixing this tried to correct the max_dma_address value, but initfamfs apparently isn't naturally gravitating towards non-DMA memory :-( The patch Stephen is talking about does reserve some fraction of DMA memory for later allocation by frame buffer etc. - such memory just cannot currently be freed.
Cheers, Michael