vesafb problem

vesafb problem

[Walt H]

Hello all,

I've got a strange problem with my 760MPX system dual proc system. If I 
try to use vesafb to setup the video on boot, the system will boot fine, 
but will be unable to display anything on the console. The system 
appears to be largely unaffacted by any underlying problem, as it is 
stable after boot and seems to run fine. In looking through logs 
afterward, I find these suspect messages:

mtrr: your CPUs had inconsistent fixed MTRR settings
vesafb: abort, cannot ioremap video memory 0x8000000 @ 0xe8000000

I've tried using the rivafb frame buffer, which also does not work. From 
what I could see in scanning the archives, this appears to possibly be a 
BIOS issue, however, I'm game to throw nearly anything at it to try and 
resolve it. Hardware is as follows:

Chaintech 7KDD 760MPX chipset motherboard
2 x AMD 2400MP
1 GB Ram
Nvidia GeForce 4600

I've tried a vanilla 2.4.20 linux kernel as well as my current 2.4.20-ck 
patched kernel, both with same result. I've also tried compiling as UP, 
which has no effect. I'm currently using acpi and apic, however, I've 
tried disabling both, to no avail. Any other ideas? Please CC me, as I'm 
not susbscribed. Thanks,

-Walt

PS. Maybe unrelated, but... I have to pass mem=nopentium as boot param, 
otherwise I system appears to get corrupted memory issues within short 
period of time after boot. ie: unable to launch apps, segfaults etc...

Re: vesafb problem

[Jurriaan]

From: Walt H <waltabbyh@comcast.net>
Date: Thu, Mar 27, 2003 at 08:41:54AM -0800
> Hello all,
> 
> I've got a strange problem with my 760MPX system dual proc system. If I 
> try to use vesafb to setup the video on boot, the system will boot fine, 
> but will be unable to display anything on the console. The system 
> appears to be largely unaffacted by any underlying problem, as it is 
> stable after boot and seems to run fine. In looking through logs 
> afterward, I find these suspect messages:
> 
> mtrr: your CPUs had inconsistent fixed MTRR settings
> vesafb: abort, cannot ioremap video memory 0x8000000 @ 0xe8000000
> 
> I've tried using the rivafb frame buffer, which also does not work. From 
> what I could see in scanning the archives, this appears to possibly be a 
> BIOS issue, however, I'm game to throw nearly anything at it to try and 
> resolve it. Hardware is as follows:
> 
> Chaintech 7KDD 760MPX chipset motherboard
> 2 x AMD 2400MP
> 1 GB Ram
> Nvidia GeForce 4600
> 
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
-- 
War does not determine who is right -- only who is left.
	Bertrand Russell
Debian (Unstable) GNU/Linux 2.5.65-mm3 4276 bogomips load av: 0.90 0.80 0.61

Re: vesafb problem

[Walt H]

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

Re: vesafb problem

[Bongani Hlope]

[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]

On Thu, 27 Mar 2003 11:34:25 -0800
Walt H <waltabbyh@comcast.net> wrote:

> Jurriaan wrote:
> 
> > 
> > I had a similar problem with 1 Gb Ram, and received this answer on the
> > linux-kernel mailinglist:

<sip>

> >     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

<snip>

> > This means with "mem=512M", you will probably have about 500M of
> > vmalloc space, which is more than enough to ioremap the framebuffer.
> > 

<snip>

> > 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


Strange I'm having the same problem, but I only have 256MB of memory and my GeForce 2 only has 32MB. This is what's on my messages file:


vesafb: framebuffer at 0xe0000000, mapped to 0xd0807000, size 32768k
vesafb: mode is 800x600x16, linelength=1600, pages=3
vesafb: protected mode interface info at c000:c060
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
Looking for splash picture.... found (800x600, 13683 bytes).
Console: switching to colour frame buffer device 82x30
fb0: VESA VGA frame buffer device


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: vesafb problem

[Walt H]

> 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

Well, I've answered my own question regarding highmem. Reserving 256MB 
ram causes high-mem mapped IO to fail. I can have penguins, but no 
filesystems or no penguins and a useable system. I'm guessing that I 
could probably turn off HIGHMEM and HIGHMEM-IO and might be able to get 
penguins back, but at the cost of reduced system performance. I'm not a 
kernel hacker, but I might just see how bad I can break vesafb to remap 
only the necessary memory for the requested video mode. Perhaps that 
would fix the whole thing?

-Walt

Re: vesafb problem

[Walt H]

Bongani Hlope wrote:

> Strange I'm having the same problem, but I only have 256MB of memory and my GeForce 2 only has 32MB. This is what's on my messages file:
> 
> 
> vesafb: framebuffer at 0xe0000000, mapped to 0xd0807000, size 32768k
> vesafb: mode is 800x600x16, linelength=1600, pages=3
> vesafb: protected mode interface info at c000:c060
> vesafb: scrolling: redraw
> vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
> Looking for splash picture.... found (800x600, 13683 bytes).
> Console: switching to colour frame buffer device 82x30
> fb0: VESA VGA frame buffer device
> 

Hmmm. That's a different problem than I'm experiencing. Your system 
appears to be correctly remapping the framebuffer and switching to it. 
You don't get a graphical boot? Seems as if you should from the log 
snippet you posted.

-Walt

Re: vesafb problem

[Walt H]

Walt H wrote:

> Well, I've answered my own question regarding highmem. Reserving 256MB 
> ram causes high-mem mapped IO to fail. I can have penguins, but no 
> filesystems or no penguins and a useable system. I'm guessing that I 
> could probably turn off HIGHMEM and HIGHMEM-IO and might be able to get 
> penguins back, but at the cost of reduced system performance. I'm not a 
> kernel hacker, but I might just see how bad I can break vesafb to remap 
> only the necessary memory for the requested video mode. Perhaps that 
> would fix the whole thing?
> 
> -Walt
> 

Well, here's what I've done. I've made a change in video/vesafb.c to 
change __init vesafb_init to only allocate the amount of memory required 
  for the requested framebuffer (I think). So far, it appears to work 
fine. I haven't tried many modes yet, but it's worked with what I've 
thrown at it. Thanks again,

The trivial change I made was changing this:

video_size	= screen_info.lfb_size * 65536;

to this:

video_size	= screen_info.lfb_width * screen_info.lfb_height * video_bpp;


-Walt

Re: vesafb problem

[Bongani Hlope]

[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]

On Thu, 27 Mar 2003 14:30:21 -0800
Walt H <waltabbyh@comcast.net> wrote:

> Bongani Hlope wrote:
> 
> > Strange I'm having the same problem, but I only have 256MB of memory and my GeForce 2 only has 32MB. This is what's on my messages file:
> > 
> > 
> > vesafb: framebuffer at 0xe0000000, mapped to 0xd0807000, size 32768k
> > vesafb: mode is 800x600x16, linelength=1600, pages=3
> > vesafb: protected mode interface info at c000:c060
> > vesafb: scrolling: redraw
> > vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
> > Looking for splash picture.... found (800x600, 13683 bytes).
> > Console: switching to colour frame buffer device 82x30
> > fb0: VESA VGA frame buffer device
> > 
> 
> Hmmm. That's a different problem than I'm experiencing. Your system 
> appears to be correctly remapping the framebuffer and switching to it. 
> You don't get a graphical boot? Seems as if you should from the log 
> snippet you posted.


It is just black until X starts up, and if I try to switch to a virtual 
terminal I get a corrupt screen

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]