public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* 2.5.64: ioremap_nocache() failes with 1 gigabyte memory, works with 512 Mb?
@ 2003-03-14  7:45 Jurriaan
  2003-03-14  8:15 ` Roland Dreier
  0 siblings, 1 reply; 2+ messages in thread
From: Jurriaan @ 2003-03-14  7:45 UTC (permalink / raw)
  To: linux-kernel

I reported a problem with the tdfxfb framebuffer yesterday, where it
said:

fb: Can't remap 3Dfx Voodoo5 register area.

when loading the module. On compiling the framebuffer into the kernel,
it oopsed.

Andrew Morton advised
> 
> http://www.kernel.org/pub/linux/kernel/v2.5/testing/cset/cset-1.1068.1.17-to-1.1104.txt.gz
> 
That file doesn't exist, but there exists a cset-1.1104.txt file. That's
about the framepointer and gcc-2.96, whereas I use 

Reading specs from /usr/lib/gcc-lib/i386-linux/3.2.3/specs
<snip>
gcc version 3.2.3 20030309 (Debian prerelease)

a somewhat more advanced version :-)

Anyway, since it fails as a module, I think I just get a failed call to
ioremap_nocache() in drivers/video/tdfxfb.c.

Now I added some information to the printk, and I now know:

fb: Can't remap 3Dfx Voodoo5 register area. (start d0000000 length 8000000)

If I boot my kernel with 'mem=512M' I can use the framebuffer just fine
(well, it doesn't work and writes funky patters to the screen, but at
least ioremap_nocache() works fine).

What is the reason ioremap_nocache() fails? Is this something that can
be prevented? I am not entirely clear on what is happening anyway (real
memory, virtual memory, nocache-memory, io-memory - a little bit above
my head :-) ).

Kind regards,
Jurriaan
-- 
A stone makes a splash when it strikes the water, Lisseut had thought,
standing by this same shore on the day she'd arrived near the end of
autumn, but no sound at all as it sinks down to the lake's deep bed.
	Guy Gavriel Kay - A Song for Narbonne
GNU/Linux 2.5.64 SMP/ReiserFS 3948 bogomips load av: 0.21 0.22 0.20

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: 2.5.64: ioremap_nocache() failes with 1 gigabyte memory, works with 512 Mb?
  2003-03-14  7:45 2.5.64: ioremap_nocache() failes with 1 gigabyte memory, works with 512 Mb? Jurriaan
@ 2003-03-14  8:15 ` Roland Dreier
  0 siblings, 0 replies; 2+ messages in thread
From: Roland Dreier @ 2003-03-14  8:15 UTC (permalink / raw)
  To: thunder7; +Cc: linux-kernel

    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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-03-14  8:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-03-14  7:45 2.5.64: ioremap_nocache() failes with 1 gigabyte memory, works with 512 Mb? Jurriaan
2003-03-14  8:15 ` Roland Dreier

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox