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
[EMAIL PROTECTED]
(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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]