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...
From: Walt H <[email protected]>
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: [email protected]
Cc: [email protected]
Subject: Re: 2.5.64: ioremap_nocache() failes with 1 gigabyte memory, works with 512 Mb?
From: Roland Dreier <[email protected]>
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
Jurriaan wrote:
>
> I had a similar problem with 1 Gb Ram, and received this answer on the
> linux-kernel mailinglist:
>
> ======================================================
> To: [email protected]
> Cc: [email protected]
> Subject: Re: 2.5.64: ioremap_nocache() failes with 1 gigabyte memory, works with 512 Mb?
> From: Roland Dreier <[email protected]>
> 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
On Thu, 27 Mar 2003 11:34:25 -0800
Walt H <[email protected]> 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
> 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
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
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
On Thu, 27 Mar 2003 14:30:21 -0800
Walt H <[email protected]> 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