lkml.org 
[lkml]   [2003]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: vesafb problem
Jurriaan wrote:

>
> I had a similar problem with 1 Gb Ram, and received this answer on the
> linux-kernel mailinglist:
>
> ======================================================
> To: thunder7@xs4all.nl
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: 2.5.64: ioremap_nocache() failes with 1 gigabyte memory, works with 512 Mb?
> From: Roland Dreier <roland@topspin.com>
> Date: 14 Mar 2003 00:15:26 -0800
>
> thunder7> Now I added some information to the printk, and I now
> thunder7> know:
>
> thunder7> fb: Can't remap 3Dfx Voodoo5 register area. (start d0000000 length 8000000)
>
> Length 0x8000000 means the driver is trying to ioremap a 128MB.
>
> thunder7> If I boot my kernel with 'mem=512M' I can use the
> thunder7> framebuffer just fine (well, it doesn't work and writes
> thunder7> funky patters to the screen, but at least
> thunder7> ioremap_nocache() works fine).
>
> thunder7> What is the reason ioremap_nocache() fails? Is this
> thunder7> something that can be prevented? I am not entirely clear
> thunder7> on what is happening anyway (real memory, virtual
> thunder7> memory, nocache-memory, io-memory - a little bit above
> thunder7> my head :-) ).
>
> ioremap_nocache() uses "vmalloc space". The kernel has some address
> space it uses for kernel virtual memory mappings -- that is, for
> mapping vmalloc()'ed memory and ioremap()'ed memory.
>
> On i386, the kernel uses whatever part of the top 1 GB of address space
> is not used for directly mapped RAM (aka lowmem). (There are a few
> other things that take some address space but that is approximately
> true).
>
> This means with "mem=512M", you will probably have about 500M of
> vmalloc space, which is more than enough to ioremap the framebuffer.
>
> With the full 1 GB of memory, you might think that there would be no
> vmalloc space available at all. However, <asm/page.h> defines a
> constant VMALLOC_RESERVE (which by default is 128 MB), and the kernel
> makes sure that there is at least this much vmalloc space available.
> However, by the time you load the module, at least some of this space
> has been consumed, so the ioremap fails. (If nothing else uses
> vmalloc space, just loading a module will call vmalloc() to get space
> for the module to be loaded into!)
>
> One not very good way for you to proceed would be to change the
> definition of VMALLOC_RESERVE from (128 << 20) to something like (256
> << 20), which should leave the driver room to ioremap the framebuffer.
> This is a little ugly. However, I don't see why a framebuffer driver
> would need to ioremap _all_ of a video card's memory -- so a better
> solution would be to fix the driver to only ioremap what it needs to.
>
> Best,
> Roland
> ======================================================
>
> To see if this is it, booting with mem=512M would be a good test.
>
> Kind regards,
> Jurriaan

Thanks for the reply. That is indeed what is doing it. When I added
mem=512M, I had two smiling penguins on boot :) My vid card does have
128MB Ram, but I also tend to agree that I'm not sure that the
framebuffer needs to remap *all* of its memory. But, for now, I think
I'll add the hack (256 << 20) to make it work. Any ideas if this might
have unforseen bad effects? Might it screw up highmem I/O? Thanks again,

-Walt

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.651 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site