Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 77674

Summary: 2.6.10-r4 upgrade produces mtrr errors and no console
Product: Gentoo Linux Reporter: Frank Lomax <gentoo>
Component: [OLD] Core systemAssignee: Michal Januszewski (RETIRED) <spock>
Status: RESOLVED TEST-REQUEST    
Severity: major CC: bugs_gentoo, kernel, lct, m.debruijne, nikolaymetchev, rafaudabest, spock
Priority: High    
Version: unspecified   
Hardware: x86   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: grub config file
gzip'd /usr/src/linux/.config from 2.6.10-r4
mtrr-debug.patch
dmesg output
2.6.10-r6 dmesg dump
A minimal config file for testing

Description Frank Lomax 2005-01-12 06:14:07 UTC
Previously running 2.6.9-r13 and just upgraded to 2.6.10-r4 kernel.  Same configuration used for both.  Graphics card Matrox G450 dual-headed.  After the upgrade, while booting 2.6.10-r4 I quickly see lots of these errors in the boot console:

mtrr: size and base must be mutiples of 4 kiB

and then nothing.  However the system does boot and X starts and appears to operate just fine.  Switching to virtual consoles does not work -- it just shows  the console with the mtrr errors.  Re-booting back to 2.6.9-r13 works fine.

I looked at bug 76446 but I couldn't understand exactly what to do, whether this is a real bug in 2.6.10-r4 or whether it's something I can fix.  I did compare /proc/mtrr under both 2.6.9 and 2.6.10 and there appear to be only minor differences.  I'll attach the two files if possible.

Reproducible: Always
Steps to Reproduce:
1. boot 2.6.10-r4 and watch the console
2.
3.

Actual Results:  
mtrr: size and base must be multiples of 4 kiB

then nothing on console until X starts up

Expected Results:  
All the normal boot messages should appear.

/proc/mtrr output from 2.6.9-r13

reg00: base=0x00000000 (   0MB), size=1024MB: write-back, count=1
reg01: base=0xe0000000 (3584MB), size=  64MB: write-combining, count=1
reg02: base=0xe4000000 (3648MB), size=  16MB: write-combining, count=2
reg03: base=0xe5000000 (3664MB), size=   8MB: write-combining, count=1
reg04: base=0xe5800000 (3672MB), size=   8MB: write-combining, count=1

/proc/mtrr output from 2.6.10-r4

reg00: base=0x00000000 (   0MB), size=1024MB: write-back, count=1
reg01: base=0xe0000000 (3584MB), size=  64MB: write-combining, count=1
reg02: base=0xe5000000 (3664MB), size=   8MB: write-combining, count=1
reg03: base=0xe4000000 (3648MB), size=  16MB: write-combining, count=1
reg04: base=0xe5800000 (3672MB), size=   8MB: write-combining, count=1
Comment 1 Frank Lomax 2005-01-12 06:16:39 UTC
Note that I have 4 other machines running Gentoo, of which I've upgraded 2 of them to 2.6.10-r4 with no problems, however the problematic machine is the only one with a Matrox G450.
Comment 2 Daniel Drake (RETIRED) gentoo-dev 2005-01-12 09:34:14 UTC
Are you using any kernel parameters to select mtrr ranges?
Are you using a framebuffer? Does disabling it help?
Comment 3 Frank Lomax 2005-01-12 09:44:05 UTC
To be honest, I don't know how to answer your questions.  All I'm doing is genkernel'ing to build my kernel and AFAIK, I'm not doing anything else wierd.  Would you like a copy of my kernel config file?

Thanks for your help.
Comment 4 Daniel Drake (RETIRED) gentoo-dev 2005-01-12 10:38:26 UTC
I'd be interested to see your grub/lilo config, please.
Comment 5 Frank Lomax 2005-01-12 11:43:19 UTC
Created attachment 48332 [details]
grub config file

Grub config file attached.
Comment 6 Daniel Drake (RETIRED) gentoo-dev 2005-01-12 14:04:32 UTC
Could you please also attach your kernel .config ? Probably found at /usr/src/linux/.config

Thanks.
Comment 7 Frank Lomax 2005-01-12 14:40:05 UTC
Created attachment 48344 [details]
gzip'd /usr/src/linux/.config from 2.6.10-r4
Comment 8 Daniel Drake (RETIRED) gentoo-dev 2005-01-13 00:40:38 UTC
Could you please try this patch?

http://marc.theaimsgroup.com/?l=linux-kernel&m=110560014224304&q=raw

If you don't know how to apply it, its something like:
cd /usr/src/linux
wget "http://marc.theaimsgroup.com/?l=linux-kernel&m=110560014224304&q=raw" -O - -q | patch -p1

Then re-run genkernel and recompile kernel as usual. It will add some extra debug messages under the "size and base must be ..." message.
Comment 9 Frank Lomax 2005-01-13 06:04:59 UTC
% wget "http://marc.theaimsgroup.com/?l=linux-kernel&m=110560014224304&q=raw" -O - -q | patch -p1 --dry-run
patching file arch/i386/kernel/cpu/mtrr/main.c
patch unexpectedly ends in middle of line

Can you post the full patch here?  I'll download it and try to apply it.  Thanks!
Comment 10 Daniel Drake (RETIRED) gentoo-dev 2005-01-13 10:05:58 UTC
Created attachment 48412 [details, diff]
mtrr-debug.patch

Here you go
Comment 11 Frank Lomax 2005-01-14 05:37:54 UTC
Created attachment 48451 [details]
dmesg output

Sorry for the delay.  Here's a dump of dmesg output after applying the patch
and rebooting.	Hope it means something to you! :)
Comment 12 Daniel Drake (RETIRED) gentoo-dev 2005-01-14 12:20:07 UTC
Could you please disable framebuffer in your config?

Device Drivers -->
Graphics support  --->
[ ] Support for frame buffer devices

This may result in your system booting in a lower resolution before you get into X. but it would be useful to know whether the mtrr errors still appear.
Comment 13 Daniel Drake (RETIRED) gentoo-dev 2005-01-14 12:34:07 UTC
Something else to try, before trying the above suggestion, is to add the follow parameter to your kernel line in grub.conf :

video=vesafb:nomtrr
Comment 14 Frank Lomax 2005-01-15 06:19:18 UTC
The "video=vesafb:nomtrr" idea didn't do too much except inhibit the console errors.  During boot, the console frozen right after it printed

vesafb: scrolling: redraw

but the system still booted like before.  So this doesn't completely solve the problem.  I will try rebuilding the kernel w/o frame buffer devices next.
Comment 15 Frank Lomax 2005-01-15 07:25:24 UTC
Disabling the frame buffer device seemed to do the trick.  I've got the normal console output again, and it doesn't seem to have affected the resolution.  I don't know if that's going to be a permanent fix, but I appreciate the help.
Comment 16 Daniel Drake (RETIRED) gentoo-dev 2005-01-15 15:55:39 UTC
Please could you retest (with your old/default config) with 2.6.10-r5?
Comment 17 Frank Lomax 2005-01-18 04:47:04 UTC
2.6.10-r5 did not fix the problem :(
Comment 18 Michal Januszewski (RETIRED) gentoo-dev 2005-01-18 06:10:29 UTC
A few things to try:

1) Play with video= parameter. Try using something like: video=nomtrr,1024x768-16@60. If this doesn't change anything, post your dmesg output again (this time without any debug patches applied).

2) Choose the standard vesafb as your VESA driver in the kernel config. Then add  vga=791 (or smth similar) to the kernel command line in your grub config and see if this seems to work.
Comment 19 Frank Lomax 2005-01-19 06:03:44 UTC
I tried putting the following at the end of the kernel line during boot:

video=nomtrr,1280x1024-16@60

since I have a 1280x1024 LCD monitor.  This made no difference, as I still got the mtrr errors (did I do this incorrectly?).

I will try the other suggestion later tonight.
Comment 20 Steve Egbert 2005-01-19 09:02:52 UTC
Over at vger.kernel.org mailing list, the patch included in the mailing thread http://marc.theaimsgroup.com/?l=linux-kernel&m=110583358711121&w=2 seems to fix the MTRR.

Disabling the next generation FB for vesa seems to better deal with the lockup of the virtual terminal.
Comment 21 Frank Lomax 2005-01-20 04:59:37 UTC
To Steve: the link in that article points back to this bug, AFAICT!  The patches here don't fix things for me.  Or were you talking about a different patch?

In any case, I rebuilt 2.6.10-r5 with the standard vesafb, and used the vga=794 option.  This got me the console output, of course at a much smaller font because now it's at 1280x1024.

So it definitely looks like there's still a problem with vesafb-tng, but at least I know how to get my console back again.  I'll keep an eye out for future 2.6.10 releases, hopefully with more vesafb-tng patches and will update this bug report with whatever I find.  If you hear of more patches you'd like me to try, please attach them to this bug report and I'll try them.
Comment 22 Stoma Verbum 2005-01-20 06:09:34 UTC
The bug has been successfully reproduced with the gentoo-dev-sources 2.6.10-r6 kernel. The bug does not appear in the 2.6.10-r2 kernel.
Comment 23 Daniel Drake (RETIRED) gentoo-dev 2005-01-20 08:15:41 UTC
Stoma: please describe what you mean by "the bug". There are a number of small issues present here.
Comment 24 Michal Januszewski (RETIRED) gentoo-dev 2005-01-20 10:04:41 UTC
Frank: if you get some free time to play with your kernel, please compile it again with vesafb-tng, use 'video=nomtrr,1280x1024-16@60' and post your kernel log (`dmesg`). It is possible that there are some vesafb-tng-related error messages in the logs that we are missing here and that might help us find out what is breaking your console.
Comment 25 Stoma Verbum 2005-01-20 10:40:38 UTC
My fellow gentoo-nians, the bug I've mentioned is that spurious waterfall of:

mtrr: size and base must be mutiples of 4 kiB

I think that is the issue here... Compiling without mtrr is an instant success, but unfortunately then vesafb goes nowhere for my poor video card. But that is a completely different issue and my small experiment that will prove if the problem is with MTRR or with VESAFB is pending. Actually I'll post back the results in 45 minutes.
RespeKt for trying to help us, guys! We'll try to do our part and test with all possible combinations of settings and kernels. That is what I am trying to do now... Be righteous back.
Comment 26 Jim Nutt 2005-01-20 20:42:46 UTC
Just a me too on this one. Averatec 3250H1, vesafb-tng hangs the console with the mtrr messages, switching back to vesafb solves the problem.
Comment 27 Michal Januszewski (RETIRED) gentoo-dev 2005-01-21 03:52:05 UTC
Jim: what version of g-d-s are you using? Have you tried the latest one? Have you tried using the 'nomtrr' option with vesafb-tng?

Stoma: any luck with this experiment you have been talking about?
Comment 28 Stoma Verbum 2005-01-21 08:41:04 UTC
Ok, I guess it took 45 Saturn minutes to finish the "experiment" but here are some of the results:

Kernel: 2.6.10-r6
1. No options passed to vesafb-tng via grub. Result:
----------------------------------------------------
mtrr: size and base must be mutiples of 4 kiB
mtrr: size and base must be mutiples of 4 kiB
mtrr: size and base must be mutiples of 4 kiB
...
----------------------------------------------------
and the system does not boot. Stalled. Frozen.

2. Option passed to vesafb-tng via grub (video=vesafb:nomtrr,1024x768@60). Result:
----------------------------------------------------
vesafb: , (OEM: VIA KN400
----------------------------------------------------
The above is the last line displayed by the kernel. And that's it. Stalled. Frozen.

3. Kernel compiled without MTRR support. Result:
----------------------------------------------------
vesafb: pmi: set display start=c00c7aab, set palette=c00c7b0b
vesafb: pmi: ports=b4c3 b503 d403 d503 cc03 d703 d803 d903 ff03
vesafb: hardware supports DDC2 transfers
vesafb: monitor limits: vf=0 Hz, hf=0 kHz, clk=0 MHz
vesafb: scrolling: redraw
vesafb: cannot reserve video memory at 0xf00012cd
----------------------------------------------------
And... again... Frozen, stalled.

The kernel without vesafb boots fine - both with and without MTRR support.
Kernel with vesafb (not TNG) boots fine, but reports an error:
----------------------------------------------------
vesafb: probe of vesafb0 failed with error -6
----------------------------------------------------
Anyone any suggestions?
Comment 29 Julian Naydichev 2005-01-26 16:50:29 UTC
Does gentoo need mtrr? I have this error on a server that I'm installing gentoo remotley on, and I don't know what to do.
Comment 30 Frank Lomax 2005-01-27 05:27:45 UTC
Michal, I've finally gotten around to trying your advice, this time with 2.6.10-r6.  I still get the mtrr breakage and console fubar.  I'll upload another dump of dmesg.
Comment 31 Frank Lomax 2005-01-27 05:28:46 UTC
Created attachment 49653 [details]
2.6.10-r6 dmesg dump
Comment 32 Michal Januszewski (RETIRED) gentoo-dev 2005-01-28 06:40:02 UTC
Stoma: have you ever been able to get vesafb to work on this hardware with previous kernel versions? ('get to work' as in get an useable framebuffer, not a 'probe of vesafb0 failed' message :))
Comment 33 Rachel Greenham 2005-02-03 14:14:25 UTC
Just noting I'm also getting this with gentoo-dev-sources 2.6.10-gentoo-r6, building for Athlon and with a Matrox G550.

dmesg includes:

vesafb: Matrox, Matrox G550, 00 (OEM: Matrox Graphics Inc.)
vesafb: VBE version: 3.0
vesafb: protected mode interface info at c000:7d60
vesafb: pmi: set display start = c00c7df2, set palette = c00c7e5e
vesafb: pmi: ports = 3de 3df 
vesafb: hardware doesn't support DCC transfers
vesafb: monitor limits: vf = 0 Hz, hf = 0 kHz, clk = 0 MHz
vesafb: scrolling: redraw
mtrr: size and base must be multiples of 4 kiB
mtrr: size: 0x2000000  base: 0xf000ef6f

... and so on down until size == 0x1.

Then:

Console: switching to colour frame buffer device 80x30
vesafb: framebuffer at 0xf000ef6f, mapped to 0xf8880f6f, using 600k, total 32768k
fb0: VESA VGA frame buffer device

and off into other stuff (ACPI etc.)

The Matrox G550 is dual-head, so I checked but there's nothing on the other video output.

For now, as the consensus seems to be that it's vesafb-tng I'll switch to vesafb. The machine in question is a server, so performance or even existence of framebuffer is non-critical.
Comment 34 miro 2005-02-05 03:07:50 UTC
I discovered this problem while using vesa-tng. I tried to specify a vbemode number to force a mode, This was not supported (2.6.9 says so, it probalby cannot find the specified mode in the modes returned by vbe, so it tries with a wrong (bogus?) width and fails) but on 2.6.10 the mtrr: bug occurs. 
Hope this helps a bit.
Comment 35 Daniel Drake (RETIRED) gentoo-dev 2005-02-09 08:01:30 UTC
*** Bug 80755 has been marked as a duplicate of this bug. ***
Comment 36 Dan Damon 2005-02-09 23:06:48 UTC
I have exactly the same bug.  Celeron, 2.6.10-gentoo-r6 kernel generated using genkernel.  SiS630 Video 
Comment 37 Dan Damon 2005-02-11 19:51:19 UTC
recompiled the 2.6.10-gentoo-r6 kernel using "genkernel --menuconfig all" and deselected the vesafb,
selected the SiS630 one while I was there.  This time, mtrr cascade is gone.  Seems to indicate the problem is definately related to vesafb or vesa-tng
Comment 38 ratmice 2005-03-10 05:46:33 UTC
I seem to be getting this while running an image created with catalyst
with the default /usr/share/genkernel/x86/kernel-config-2.6 within qemu

for anyone unable to reproduce it
Comment 39 Chris Gianelloni (RETIRED) gentoo-dev 2005-03-10 08:20:53 UTC
<ratmice> wolf31o2-work: well setting CONFIG_FB_VESA_STD=y and CONFIG_FB_VESA_TNG=n works around 77674 so i'm happy

Looks like a vesafb-tng bug.
Comment 40 Daniel Drake (RETIRED) gentoo-dev 2005-03-16 06:12:14 UTC
Michal any progress on this?
Comment 41 Frank Lomax 2005-03-18 07:36:12 UTC
I just tested 2.6.11-gentoo-r4 and it has the same problem.  Has there been any progress on this bug?
Comment 42 Michal Januszewski (RETIRED) gentoo-dev 2005-03-23 04:40:57 UTC
In the latest version of the vesafb-tng code I added an addional sanity check before calling mtrr_add(). I don't know whether it will fix this bug, but it might be worth a try. The update is so simple, that it can be made by hand-editing vesafb-tng.c and replacing 'if (mtrr) {' with 'if (mtrr && !(info->fix.smem_start & (PAGE_SIZE - 1))) {'.
Comment 43 rafaudabest 2005-03-23 13:34:06 UTC
Michal, how can I test your new version?
Comment 44 Hossein Mobahi 2005-03-24 04:47:28 UTC
Michael
I just installed kernel 2.6.11-r4 and it seems that I have the same problem: "mtrr: size and the base must be multiples of 4 KiB". I made the modification that you mentioned in "Comment #42" and recompiled the kernel. The problem still exists, the only change is that instead of seeing lots of that "mttr" error messages, screen locks after printing messages related to vesa framebuffer during the boot process (framebuffer messages are the last ones that I can see on the screen). However, I am sure the system continues booting normally (harddisk continues working, and CTRL+ALT+DELETE work for rebooting), but I cannot see anything on my screen except the locked screen! Anyother comment?
Comment 45 Joey Stanford 2005-03-31 23:22:56 UTC
I am also experiencing this on a generic SiS board (740).

Whether I make via Genkernel or by hand, framebuffers & bootsplash do not work and I get the mtrr error. EVEN when I use the 2005.0 cd's config the errors are present.

The VERY interesting thing about this is that framebuffers on the 2005.0 cd work as does bootsplash all without any mtrr errors.

I'm going to try this without -tng and see what happens. Seems that's the only thing in here I haven't tried.
Comment 46 Joey Stanford 2005-03-31 23:51:10 UTC
Success.  In menuconfig I changed from vesafb and at least I boot with splash and framebuff. I don't seem to be getting the error Stomma references.  So, definately an error in -tng.
Comment 47 Frank Lomax 2005-04-24 10:13:12 UTC
Any progress on this bug?  It still exists with 2.6.11-r6
Comment 48 Stoma Verbum 2005-06-17 13:35:44 UTC
There have been no changes to the vesafb-tng module for some time, so even
2.6.11-r11 with vesafb-tng gets the mtrr error message. As Joey suggested, I
also changed the framebuffer way to vesafb _only_ [not vesafb-tng] and now both
machines I've tested on work perfectly fine with the framebuffer [penguin,
splashes, all whistles and dazzles].
Probably Michal is busy these days, so my suggestion to everyone that's stuck
here - go with vesafb and temporary avoid vesafb-tng. I am sure if Michal is
able to get his hands on a machine with this kind of behaviour and reproduce the
problem, he'll be able to fix it!
My hardware is the somewhat crappy VIA [CLE266 and KM400] S3 Unichrome.
Comment 49 Andrew Leach 2005-06-18 12:35:45 UTC
(In reply to comment #48)
> There have been no changes to the vesafb-tng module for some time, so even
> 2.6.11-r11 with vesafb-tng gets the mtrr error message. As Joey suggested, I
> also changed the framebuffer way to vesafb _only_ [not vesafb-tng] and now both
> machines I've tested on work perfectly fine with the framebuffer [penguin,
> splashes, all whistles and dazzles].
> Probably Michal is busy these days, so my suggestion to everyone that's stuck
> here - go with vesafb and temporary avoid vesafb-tng. I am sure if Michal is
> able to get his hands on a machine with this kind of behaviour and reproduce the
> problem, he'll be able to fix it!
> My hardware is the somewhat crappy VIA [CLE266 and KM400] S3 Unichrome.


I have a Via Epia MEII 1000 board trying to run the 2.6.11-r11 kernel.

I've disabled the vesafb-tng setting (CONFIG_FB_VESA_TNG=n) in the .config file
and left the option CONFIG_FB_VESA=y enabled.

I've also applied the mtrr-debug.patch. 

When I boot my console hangs with the mtrr: size and base must be mutiples of 4
kiB message how the system is still functional for remote user. The debug patch
presents the following information (or at least as much as is held in the dmesg
log file):

4> [<c02833bb>] device_pm_add+0x5b/0xa0
 [<c027e7c6>] device_add+0xc6/0x160
 [<c0281782>] platform_device_register+0xb2/0x160
 [<c0410360>] vesafb_init+0x60/0x74
 [<c03f981c>] do_initcalls+0x2c/0xc0
 [<c01002c0>] init+0x0/0x110
 [<c01002c0>] init+0x0/0x110
 [<c01002ef>] init+0x2f/0x110
 [<c0100888>] kernel_thread_helper+0x0/0x18
 [<c010088d>] kernel_thread_helper+0x5/0x18
mtrr: size and base must be multiples of 4 kiB
mtrr: size: 0x800  base: 0xf000ef6f
 [<c010b83a>] mtrr_check+0x4a/0x60
 [<c010b880>] mtrr_add+0x30/0x80
 [<c0410058>] vesafb_probe+0x2e8/0x590
 [<c027f78f>] driver_probe_device+0x2f/0x80
 [<c027f81f>] device_attach+0x3f/0xa0
 [<c020bd5a>] kobject_get+0x1a/0x30
 [<c027fb6b>] bus_add_device+0x5b/0xb0
 [<c02833bb>] device_pm_add+0x5b/0xa0
 [<c027e7c6>] device_add+0xc6/0x160
 [<c0281782>] platform_device_register+0xb2/0x160
 [<c0410360>] vesafb_init+0x60/0x74
 [<c03f981c>] do_initcalls+0x2c/0xc0
 [<c01002c0>] init+0x0/0x110
 [<c01002c0>] init+0x0/0x110
 [<c01002ef>] init+0x2f/0x110
 [<c0100888>] kernel_thread_helper+0x0/0x18
 [<c010088d>] kernel_thread_helper+0x5/0x18
mtrr: size and base must be multiples of 4 kiB
mtrr: size: 0x400  base: 0xf000ef6f
 [<c010b83a>] mtrr_check+0x4a/0x60
 [<c010b880>] mtrr_add+0x30/0x80
 [<c0410058>] vesafb_probe+0x2e8/0x590
 [<c027f78f>] driver_probe_device+0x2f/0x80
 [<c027f81f>] device_attach+0x3f/0xa0
 [<c020bd5a>] kobject_get+0x1a/0x30
 [<c027fb6b>] bus_add_device+0x5b/0xb0
 [<c02833bb>] device_pm_add+0x5b/0xa0
 [<c027e7c6>] device_add+0xc6/0x160
 [<c0281782>] platform_device_register+0xb2/0x160
 [<c0410360>] vesafb_init+0x60/0x74
 [<c03f981c>] do_initcalls+0x2c/0xc0
 [<c01002c0>] init+0x0/0x110
 [<c01002c0>] init+0x0/0x110
 [<c01002ef>] init+0x2f/0x110
 [<c0100888>] kernel_thread_helper+0x0/0x18
 [<c010088d>] kernel_thread_helper+0x5/0x18
mtrr: size and base must be multiples of 4 kiB
mtrr: size: 0x200  base: 0xf000ef6f
 [<c010b83a>] mtrr_check+0x4a/0x60
 [<c010b880>] mtrr_add+0x30/0x80
 [<c0410058>] vesafb_probe+0x2e8/0x590
 [<c027f78f>] driver_probe_device+0x2f/0x80
 [<c027f81f>] device_attach+0x3f/0xa0
 [<c020bd5a>] kobject_get+0x1a/0x30
 [<c027fb6b>] bus_add_device+0x5b/0xb0
 [<c02833bb>] device_pm_add+0x5b/0xa0
 [<c027e7c6>] device_add+0xc6/0x160
 [<c0281782>] platform_device_register+0xb2/0x160
 [<c0410360>] vesafb_init+0x60/0x74
 [<c03f981c>] do_initcalls+0x2c/0xc0
 [<c01002c0>] init+0x0/0x110
 [<c01002c0>] init+0x0/0x110
 [<c01002ef>] init+0x2f/0x110
 [<c0100888>] kernel_thread_helper+0x0/0x18
 [<c010088d>] kernel_thread_helper+0x5/0x18
mtrr: size and base must be multiples of 4 kiB
mtrr: size: 0x100  base: 0xf000ef6f
 [<c010b83a>] mtrr_check+0x4a/0x60
 [<c010b880>] mtrr_add+0x30/0x80
 [<c0410058>] vesafb_probe+0x2e8/0x590
 [<c027f78f>] driver_probe_device+0x2f/0x80
 [<c027f81f>] device_attach+0x3f/0xa0
 [<c020bd5a>] kobject_get+0x1a/0x30
 [<c027fb6b>] bus_add_device+0x5b/0xb0
 [<c02833bb>] device_pm_add+0x5b/0xa0
 [<c027e7c6>] device_add+0xc6/0x160
 [<c0281782>] platform_device_register+0xb2/0x160
 [<c0410360>] vesafb_init+0x60/0x74
 [<c03f981c>] do_initcalls+0x2c/0xc0
 [<c01002c0>] init+0x0/0x110
 [<c01002c0>] init+0x0/0x110
 [<c01002ef>] init+0x2f/0x110
 [<c0100888>] kernel_thread_helper+0x0/0x18
 [<c010088d>] kernel_thread_helper+0x5/0x18
mtrr: size and base must be multiples of 4 kiB
mtrr: size: 0x80  base: 0xf000ef6f
 [<c010b83a>] mtrr_check+0x4a/0x60
 [<c010b880>] mtrr_add+0x30/0x80
 [<c0410058>] vesafb_probe+0x2e8/0x590
 [<c027f78f>] driver_probe_device+0x2f/0x80
 [<c027f81f>] device_attach+0x3f/0xa0
 [<c020bd5a>] kobject_get+0x1a/0x30
 [<c027fb6b>] bus_add_device+0x5b/0xb0
 [<c02833bb>] device_pm_add+0x5b/0xa0
 [<c027e7c6>] device_add+0xc6/0x160
 [<c0281782>] platform_device_register+0xb2/0x160
 [<c0410360>] vesafb_init+0x60/0x74
 [<c03f981c>] do_initcalls+0x2c/0xc0
 [<c01002c0>] init+0x0/0x110
 [<c01002c0>] init+0x0/0x110
 [<c01002ef>] init+0x2f/0x110
 [<c0100888>] kernel_thread_helper+0x0/0x18
 [<c010088d>] kernel_thread_helper+0x5/0x18
mtrr: size and base must be multiples of 4 kiB
mtrr: size: 0x40  base: 0xf000ef6f
 [<c010b83a>] mtrr_check+0x4a/0x60
 [<c010b880>] mtrr_add+0x30/0x80
 [<c0410058>] vesafb_probe+0x2e8/0x590
 [<c027f78f>] driver_probe_device+0x2f/0x80
 [<c027f81f>] device_attach+0x3f/0xa0
 [<c020bd5a>] kobject_get+0x1a/0x30
 [<c027fb6b>] bus_add_device+0x5b/0xb0
 [<c02833bb>] device_pm_add+0x5b/0xa0
 [<c027e7c6>] device_add+0xc6/0x160
 [<c0281782>] platform_device_register+0xb2/0x160
 [<c0410360>] vesafb_init+0x60/0x74
 [<c03f981c>] do_initcalls+0x2c/0xc0
 [<c01002c0>] init+0x0/0x110
 [<c01002c0>] init+0x0/0x110
 [<c01002ef>] init+0x2f/0x110
 [<c0100888>] kernel_thread_helper+0x0/0x18
 [<c010088d>] kernel_thread_helper+0x5/0x18
mtrr: size and base must be multiples of 4 kiB
mtrr: size: 0x20  base: 0xf000ef6f
 [<c010b83a>] mtrr_check+0x4a/0x60
 [<c010b880>] mtrr_add+0x30/0x80
 [<c0410058>] vesafb_probe+0x2e8/0x590
 [<c027f78f>] driver_probe_device+0x2f/0x80
 [<c027f81f>] device_attach+0x3f/0xa0
 [<c020bd5a>] kobject_get+0x1a/0x30
 [<c027fb6b>] bus_add_device+0x5b/0xb0
 [<c02833bb>] device_pm_add+0x5b/0xa0
 [<c027e7c6>] device_add+0xc6/0x160
 [<c0281782>] platform_device_register+0xb2/0x160
 [<c0410360>] vesafb_init+0x60/0x74
 [<c03f981c>] do_initcalls+0x2c/0xc0
 [<c01002c0>] init+0x0/0x110
 [<c01002c0>] init+0x0/0x110
 [<c01002ef>] init+0x2f/0x110
 [<c0100888>] kernel_thread_helper+0x0/0x18
 [<c010088d>] kernel_thread_helper+0x5/0x18
mtrr: size and base must be multiples of 4 kiB
mtrr: size: 0x10  base: 0xf000ef6f
 [<c010b83a>] mtrr_check+0x4a/0x60
 [<c010b880>] mtrr_add+0x30/0x80
 [<c0410058>] vesafb_probe+0x2e8/0x590
 [<c027f78f>] driver_probe_device+0x2f/0x80
 [<c027f81f>] device_attach+0x3f/0xa0
 [<c020bd5a>] kobject_get+0x1a/0x30
 [<c027fb6b>] bus_add_device+0x5b/0xb0
 [<c02833bb>] device_pm_add+0x5b/0xa0
 [<c027e7c6>] device_add+0xc6/0x160
 [<c0281782>] platform_device_register+0xb2/0x160
 [<c0410360>] vesafb_init+0x60/0x74
 [<c03f981c>] do_initcalls+0x2c/0xc0
 [<c01002c0>] init+0x0/0x110
 [<c01002c0>] init+0x0/0x110
 [<c01002ef>] init+0x2f/0x110
 [<c0100888>] kernel_thread_helper+0x0/0x18
 [<c010088d>] kernel_thread_helper+0x5/0x18
mtrr: size and base must be multiples of 4 kiB
mtrr: size: 0x8  base: 0xf000ef6f
 [<c010b83a>] mtrr_check+0x4a/0x60
 [<c010b880>] mtrr_add+0x30/0x80
 [<c0410058>] vesafb_probe+0x2e8/0x590
 [<c027f78f>] driver_probe_device+0x2f/0x80
 [<c027f81f>] device_attach+0x3f/0xa0
 [<c020bd5a>] kobject_get+0x1a/0x30
 [<c027fb6b>] bus_add_device+0x5b/0xb0
 [<c02833bb>] device_pm_add+0x5b/0xa0
 [<c027e7c6>] device_add+0xc6/0x160
 [<c0281782>] platform_device_register+0xb2/0x160
 [<c0410360>] vesafb_init+0x60/0x74
 [<c03f981c>] do_initcalls+0x2c/0xc0
 [<c01002c0>] init+0x0/0x110
 [<c01002c0>] init+0x0/0x110
 [<c01002ef>] init+0x2f/0x110
 [<c0100888>] kernel_thread_helper+0x0/0x18
 [<c010088d>] kernel_thread_helper+0x5/0x18
mtrr: size and base must be multiples of 4 kiB
mtrr: size: 0x4  base: 0xf000ef6f
 [<c010b83a>] mtrr_check+0x4a/0x60
 [<c010b880>] mtrr_add+0x30/0x80
 [<c0410058>] vesafb_probe+0x2e8/0x590
 [<c027f78f>] driver_probe_device+0x2f/0x80
 [<c027f81f>] device_attach+0x3f/0xa0
 [<c020bd5a>] kobject_get+0x1a/0x30
 [<c027fb6b>] bus_add_device+0x5b/0xb0
 [<c02833bb>] device_pm_add+0x5b/0xa0
 [<c027e7c6>] device_add+0xc6/0x160
 [<c0281782>] platform_device_register+0xb2/0x160
 [<c0410360>] vesafb_init+0x60/0x74
 [<c03f981c>] do_initcalls+0x2c/0xc0
 [<c01002c0>] init+0x0/0x110
 [<c01002c0>] init+0x0/0x110
 [<c01002ef>] init+0x2f/0x110
 [<c0100888>] kernel_thread_helper+0x0/0x18
 [<c010088d>] kernel_thread_helper+0x5/0x18
mtrr: size and base must be multiples of 4 kiB
mtrr: size: 0x2  base: 0xf000ef6f
 [<c010b83a>] mtrr_check+0x4a/0x60
 [<c010b880>] mtrr_add+0x30/0x80
 [<c0410058>] vesafb_probe+0x2e8/0x590
 [<c027f78f>] driver_probe_device+0x2f/0x80
 [<c027f81f>] device_attach+0x3f/0xa0
 [<c020bd5a>] kobject_get+0x1a/0x30
 [<c027fb6b>] bus_add_device+0x5b/0xb0
 [<c02833bb>] device_pm_add+0x5b/0xa0
 [<c027e7c6>] device_add+0xc6/0x160
 [<c0281782>] platform_device_register+0xb2/0x160
 [<c0410360>] vesafb_init+0x60/0x74
 [<c03f981c>] do_initcalls+0x2c/0xc0
 [<c01002c0>] init+0x0/0x110
 [<c01002c0>] init+0x0/0x110
 [<c01002ef>] init+0x2f/0x110
 [<c0100888>] kernel_thread_helper+0x0/0x18
 [<c010088d>] kernel_thread_helper+0x5/0x18
mtrr: size and base must be multiples of 4 kiB
mtrr: size: 0x1  base: 0xf000ef6f
 [<c010b83a>] mtrr_check+0x4a/0x60
 [<c010b880>] mtrr_add+0x30/0x80
 [<c0410058>] vesafb_probe+0x2e8/0x590
 [<c027f78f>] driver_probe_device+0x2f/0x80
 [<c027f81f>] device_attach+0x3f/0xa0
 [<c020bd5a>] kobject_get+0x1a/0x30
 [<c027fb6b>] bus_add_device+0x5b/0xb0
 [<c02833bb>] device_pm_add+0x5b/0xa0
 [<c027e7c6>] device_add+0xc6/0x160
 [<c0281782>] platform_device_register+0xb2/0x160
 [<c0410360>] vesafb_init+0x60/0x74
 [<c03f981c>] do_initcalls+0x2c/0xc0
 [<c01002c0>] init+0x0/0x110
 [<c01002c0>] init+0x0/0x110
 [<c01002ef>] init+0x2f/0x110
 [<c0100888>] kernel_thread_helper+0x0/0x18
 [<c010088d>] kernel_thread_helper+0x5/0x18
Console: switching to colour frame buffer device 80x30
vesafb: framebuffer at 0xf000ef6f, mapped to 0xdc880f6f, using 600k, total 65536k
fb0: VESA VGA frame buffer device


The problem is reproducable.

Any help would really, really, really be appreciated!!!
Comment 50 Michal Januszewski (RETIRED) gentoo-dev 2005-06-25 13:38:19 UTC
I've recently re-read all the bug comments and here's what I've come up with.
First of all, the bug isn't MTRR-related (despite all appearances). Sure, you're
seeing a lot of mtrr error messages before the console gets frozen, but this is
only a side effect of the real problem. 

The real problem is here:
vesafb: framebuffer at *0xf000ef6f*, mapped to 0xf8880f6f, using 600k, total 32768k
The value (0xf000ef6f) (which is comes straight from the Video BIOS by the way)
is plain wrong, and should probably be 0xf0000000 or smth else that's nicely
page-aligned.

I still have no idea what's causing the problem, but here are some ideas for
things that might be worth checking out and reporting here:

1) have a look at the kernel log, look for a line similar to the following one
to get the address of the framebuffer:
 (--) PCI:*(1:0:0) nVidia Corporation NV11 [GeForce2 MX/MX 400] rev 178, Mem @
0xce000000/24, 0xc0000000/27, BIOS @ 0xcfef0000/16

2) do the same when running pure vesafb, compare this with what vesafb-tng prints

3) emerge lrmi to get the vbetest program. Learn how it works. Then reboot with
vesafb-tng enabled, and if the console is working (it might be frozen and not
display anything on the screen, but you only need to be able to type and execute
a command blindly), try running vbetest. See if you can set a mode that worked
when you were learning how it works.

4) (this will take a lot of time) Try building a really minimal test kernel.
Keep vesafb-tng and things that are absolutely necessary. Remove support for
specific chipsets, try to stick with generic drivers (for example IDE drivers).
Use 386 as processor type. Disable all optimizations such as regparm (Use
register arguments). Then try booting the new kernel and see whether vesafb-tng
works.

At this point you might be asking yourself what's broken in vesafb-tng that it
doesn't work while vesafb does. Well, the answer might be that nothing is broken
*in vesafb-tng*. vesafb runs the code that touches the BIOS very early, before
the kernel is really started. vesafb-tng doesn't. Apparently there is something
in the kernel that breaks the video BIOS and makes it return invalid values as
the address of the framebuffer. This is why I think it would be very helpful if
someone could try my suggestion no. 4.
Comment 51 Michal Januszewski (RETIRED) gentoo-dev 2005-07-03 13:47:38 UTC
Created attachment 62561 [details]
A minimal config file for testing

I'm attaching a very minimalistic config file for 2.6.12-gentoo-r3. This is for
doing some testing for point 4) of comment #50. Don't get too scared -- this
one won't take *THAT* much time :) All you have to do is download the config
file, place it in /usr/src/linux-2.6.12-gentoo-r3, build the kernel, add an
entry in your grub/lilo config file and reboot to do the test.

Note that there's a good chance your system will not be able to complete the
boot with a kernel built with the config file I've attached. The only purpose
of this config is to see whether it causes your console to freeze.
Comment 52 Michal Januszewski (RETIRED) gentoo-dev 2005-09-16 07:29:38 UTC
Also, should anyone feel like doing some testing, please give the following
patch a try:
 
http://dev.gentoo.org/~spock/projects/vesafb-tng/testing/vesafb-tng-testing-2005091603.patch

The patch should apply against vanilla 2.6.13* and 2.6.14-rc1 kernels.
Comment 53 T.R.Shashwath 2005-10-19 06:28:17 UTC
I'm having the same problem, with kernels 2.6.11-gentoo-r6 and 
2.6.13-gentoo-r3. The entire gamut of things (vesafb-tng, gensplash and the 
rest) worked under kernels less than or equal to 2.6.9, and started failing 
after an upgrade. 
 
This is a portion of my dmesg output: 
 
vesafb: Intel Corporation, Brookdale-G Graphics Controller, Hardware Version 
0.0 (OEM: Brookdale-G Graphics Chip Accelerated VGA BIOS) 
vesafb: VBE version: 3.0 
vesafb: hardware supports DDC2 transfers 
vesafb: monitor limits: vf = 160 Hz, hf = 71 kHz, clk = 110 MHz 
vesafb: scrolling: redraw 
mtrr: type mismatch for f0000000,100000 old: write-back new: write-combining 
mtrr: type mismatch for f0000000,80000 old: write-back new: write-combining 
mtrr: type mismatch for f0000000,40000 old: write-back new: write-combining 
mtrr: type mismatch for f0000000,20000 old: write-back new: write-combining 
mtrr: type mismatch for f0000000,10000 old: write-back new: write-combining 
mtrr: type mismatch for f0000000,8000 old: write-back new: write-combining 
mtrr: type mismatch for f0000000,4000 old: write-back new: write-combining 
mtrr: type mismatch for f0000000,2000 old: write-back new: write-combining 
mtrr: type mismatch for f0000000,1000 old: write-back new: write-combining 
mtrr: size and base must be multiples of 4 kiB 
mtrr: size: 0x800  base: 0xf0000000 
 [<c010e10a>] mtrr_check+0x4a/0x60 
 [<c010e150>] mtrr_add+0x30/0x80 
 [<c056a978>] vesafb_probe+0x338/0x5f0 
 [<c019de1c>] sysfs_make_dirent+0x2c/0xa0 
 [<c02c4bdb>] driver_probe_device+0x3b/0xb0 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c42c9>] bus_for_each_drv+0x69/0x80 
 [<c02c4cc7>] device_attach+0x67/0x70 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c4435>] bus_add_device+0x35/0xc0 
 [<c02c803c>] device_pm_add+0x5c/0xa0 
 [<c02c3410>] device_add+0xe0/0x160 
 [<c02c64e2>] platform_device_register+0xc2/0x170 
 [<c056ac90>] vesafb_init+0x60/0x74 
 [<c05549eb>] do_initcalls+0x2b/0xc0 
 [<c01003a4>] init+0x84/0x1b0 
 [<c0100320>] init+0x0/0x1b0 
 [<c0101215>] kernel_thread_helper+0x5/0x10 
mtrr: size and base must be multiples of 4 kiB 
mtrr: size: 0x400  base: 0xf0000000 
 [<c010e10a>] mtrr_check+0x4a/0x60 
 [<c010e150>] mtrr_add+0x30/0x80 
 [<c056a978>] vesafb_probe+0x338/0x5f0 
 [<c019de1c>] sysfs_make_dirent+0x2c/0xa0 
 [<c02c4bdb>] driver_probe_device+0x3b/0xb0 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c42c9>] bus_for_each_drv+0x69/0x80 
 [<c02c4cc7>] device_attach+0x67/0x70 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c4435>] bus_add_device+0x35/0xc0 
 [<c02c803c>] device_pm_add+0x5c/0xa0 
 [<c02c3410>] device_add+0xe0/0x160 
 [<c02c64e2>] platform_device_register+0xc2/0x170 
 [<c056ac90>] vesafb_init+0x60/0x74 
 [<c05549eb>] do_initcalls+0x2b/0xc0 
 [<c01003a4>] init+0x84/0x1b0 
 [<c0100320>] init+0x0/0x1b0 
 [<c0101215>] kernel_thread_helper+0x5/0x10 
mtrr: size and base must be multiples of 4 kiB 
mtrr: size: 0x200  base: 0xf0000000 
 [<c010e10a>] mtrr_check+0x4a/0x60 
 [<c010e150>] mtrr_add+0x30/0x80 
 [<c056a978>] vesafb_probe+0x338/0x5f0 
 [<c019de1c>] sysfs_make_dirent+0x2c/0xa0 
 [<c02c4bdb>] driver_probe_device+0x3b/0xb0 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c42c9>] bus_for_each_drv+0x69/0x80 
 [<c02c4cc7>] device_attach+0x67/0x70 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c4435>] bus_add_device+0x35/0xc0 
 [<c02c803c>] device_pm_add+0x5c/0xa0 
 [<c02c3410>] device_add+0xe0/0x160 
 [<c02c64e2>] platform_device_register+0xc2/0x170 
 [<c056ac90>] vesafb_init+0x60/0x74 
 [<c05549eb>] do_initcalls+0x2b/0xc0 
 [<c01003a4>] init+0x84/0x1b0 
 [<c0100320>] init+0x0/0x1b0 
 [<c0101215>] kernel_thread_helper+0x5/0x10 
mtrr: size and base must be multiples of 4 kiB 
mtrr: size: 0x100  base: 0xf0000000 
 [<c010e10a>] mtrr_check+0x4a/0x60 
 [<c010e150>] mtrr_add+0x30/0x80 
 [<c056a978>] vesafb_probe+0x338/0x5f0 
 [<c019de1c>] sysfs_make_dirent+0x2c/0xa0 
 [<c02c4bdb>] driver_probe_device+0x3b/0xb0 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c42c9>] bus_for_each_drv+0x69/0x80 
 [<c02c4cc7>] device_attach+0x67/0x70 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c4435>] bus_add_device+0x35/0xc0 
 [<c02c803c>] device_pm_add+0x5c/0xa0 
 [<c02c3410>] device_add+0xe0/0x160 
 [<c02c64e2>] platform_device_register+0xc2/0x170 
 [<c056ac90>] vesafb_init+0x60/0x74 
 [<c05549eb>] do_initcalls+0x2b/0xc0 
 [<c01003a4>] init+0x84/0x1b0 
 [<c0100320>] init+0x0/0x1b0 
 [<c0101215>] kernel_thread_helper+0x5/0x10 
mtrr: size and base must be multiples of 4 kiB 
mtrr: size: 0x80  base: 0xf0000000 
 [<c010e10a>] mtrr_check+0x4a/0x60 
 [<c010e150>] mtrr_add+0x30/0x80 
 [<c056a978>] vesafb_probe+0x338/0x5f0 
 [<c019de1c>] sysfs_make_dirent+0x2c/0xa0 
 [<c02c4bdb>] driver_probe_device+0x3b/0xb0 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c42c9>] bus_for_each_drv+0x69/0x80 
 [<c02c4cc7>] device_attach+0x67/0x70 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c4435>] bus_add_device+0x35/0xc0 
 [<c02c803c>] device_pm_add+0x5c/0xa0 
 [<c02c3410>] device_add+0xe0/0x160 
 [<c02c64e2>] platform_device_register+0xc2/0x170 
 [<c056ac90>] vesafb_init+0x60/0x74 
 [<c05549eb>] do_initcalls+0x2b/0xc0 
 [<c01003a4>] init+0x84/0x1b0 
 [<c0100320>] init+0x0/0x1b0 
 [<c0101215>] kernel_thread_helper+0x5/0x10 
mtrr: size and base must be multiples of 4 kiB 
mtrr: size: 0x40  base: 0xf0000000 
 [<c010e10a>] mtrr_check+0x4a/0x60 
 [<c010e150>] mtrr_add+0x30/0x80 
 [<c056a978>] vesafb_probe+0x338/0x5f0 
 [<c019de1c>] sysfs_make_dirent+0x2c/0xa0 
 [<c02c4bdb>] driver_probe_device+0x3b/0xb0 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c42c9>] bus_for_each_drv+0x69/0x80 
 [<c02c4cc7>] device_attach+0x67/0x70 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c4435>] bus_add_device+0x35/0xc0 
 [<c02c803c>] device_pm_add+0x5c/0xa0 
 [<c02c3410>] device_add+0xe0/0x160 
 [<c02c64e2>] platform_device_register+0xc2/0x170 
 [<c056ac90>] vesafb_init+0x60/0x74 
 [<c05549eb>] do_initcalls+0x2b/0xc0 
 [<c01003a4>] init+0x84/0x1b0 
 [<c0100320>] init+0x0/0x1b0 
 [<c0101215>] kernel_thread_helper+0x5/0x10 
mtrr: size and base must be multiples of 4 kiB 
mtrr: size: 0x20  base: 0xf0000000 
 [<c010e10a>] mtrr_check+0x4a/0x60 
 [<c010e150>] mtrr_add+0x30/0x80 
 [<c056a978>] vesafb_probe+0x338/0x5f0 
 [<c019de1c>] sysfs_make_dirent+0x2c/0xa0 
 [<c02c4bdb>] driver_probe_device+0x3b/0xb0 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c42c9>] bus_for_each_drv+0x69/0x80 
 [<c02c4cc7>] device_attach+0x67/0x70 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c4435>] bus_add_device+0x35/0xc0 
 [<c02c803c>] device_pm_add+0x5c/0xa0 
 [<c02c3410>] device_add+0xe0/0x160 
 [<c02c64e2>] platform_device_register+0xc2/0x170 
 [<c056ac90>] vesafb_init+0x60/0x74 
 [<c05549eb>] do_initcalls+0x2b/0xc0 
 [<c01003a4>] init+0x84/0x1b0 
 [<c0100320>] init+0x0/0x1b0 
 [<c0101215>] kernel_thread_helper+0x5/0x10 
mtrr: size and base must be multiples of 4 kiB 
mtrr: size: 0x10  base: 0xf0000000 
 [<c010e10a>] mtrr_check+0x4a/0x60 
 [<c010e150>] mtrr_add+0x30/0x80 
 [<c056a978>] vesafb_probe+0x338/0x5f0 
 [<c019de1c>] sysfs_make_dirent+0x2c/0xa0 
 [<c02c4bdb>] driver_probe_device+0x3b/0xb0 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c42c9>] bus_for_each_drv+0x69/0x80 
 [<c02c4cc7>] device_attach+0x67/0x70 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c4435>] bus_add_device+0x35/0xc0 
 [<c02c803c>] device_pm_add+0x5c/0xa0 
 [<c02c3410>] device_add+0xe0/0x160 
 [<c02c64e2>] platform_device_register+0xc2/0x170 
 [<c056ac90>] vesafb_init+0x60/0x74 
 [<c05549eb>] do_initcalls+0x2b/0xc0 
 [<c01003a4>] init+0x84/0x1b0 
 [<c0100320>] init+0x0/0x1b0 
 [<c0101215>] kernel_thread_helper+0x5/0x10 
mtrr: size and base must be multiples of 4 kiB 
mtrr: size: 0x8  base: 0xf0000000 
 [<c010e10a>] mtrr_check+0x4a/0x60 
 [<c010e150>] mtrr_add+0x30/0x80 
 [<c056a978>] vesafb_probe+0x338/0x5f0 
 [<c019de1c>] sysfs_make_dirent+0x2c/0xa0 
 [<c02c4bdb>] driver_probe_device+0x3b/0xb0 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c42c9>] bus_for_each_drv+0x69/0x80 
 [<c02c4cc7>] device_attach+0x67/0x70 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c4435>] bus_add_device+0x35/0xc0 
 [<c02c803c>] device_pm_add+0x5c/0xa0 
 [<c02c3410>] device_add+0xe0/0x160 
 [<c02c64e2>] platform_device_register+0xc2/0x170 
 [<c056ac90>] vesafb_init+0x60/0x74 
 [<c05549eb>] do_initcalls+0x2b/0xc0 
 [<c01003a4>] init+0x84/0x1b0 
 [<c0100320>] init+0x0/0x1b0 
 [<c0101215>] kernel_thread_helper+0x5/0x10 
mtrr: size and base must be multiples of 4 kiB 
mtrr: size: 0x4  base: 0xf0000000 
 [<c010e10a>] mtrr_check+0x4a/0x60 
 [<c010e150>] mtrr_add+0x30/0x80 
 [<c056a978>] vesafb_probe+0x338/0x5f0 
 [<c019de1c>] sysfs_make_dirent+0x2c/0xa0 
 [<c02c4bdb>] driver_probe_device+0x3b/0xb0 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c42c9>] bus_for_each_drv+0x69/0x80 
 [<c02c4cc7>] device_attach+0x67/0x70 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c4435>] bus_add_device+0x35/0xc0 
 [<c02c803c>] device_pm_add+0x5c/0xa0 
 [<c02c3410>] device_add+0xe0/0x160 
 [<c02c64e2>] platform_device_register+0xc2/0x170 
 [<c056ac90>] vesafb_init+0x60/0x74 
 [<c05549eb>] do_initcalls+0x2b/0xc0 
 [<c01003a4>] init+0x84/0x1b0 
 [<c0100320>] init+0x0/0x1b0 
 [<c0101215>] kernel_thread_helper+0x5/0x10 
mtrr: size and base must be multiples of 4 kiB 
mtrr: size: 0x2  base: 0xf0000000 
 [<c010e10a>] mtrr_check+0x4a/0x60 
 [<c010e150>] mtrr_add+0x30/0x80 
 [<c056a978>] vesafb_probe+0x338/0x5f0 
 [<c019de1c>] sysfs_make_dirent+0x2c/0xa0 
 [<c02c4bdb>] driver_probe_device+0x3b/0xb0 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c42c9>] bus_for_each_drv+0x69/0x80 
 [<c02c4cc7>] device_attach+0x67/0x70 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c4435>] bus_add_device+0x35/0xc0 
 [<c02c803c>] device_pm_add+0x5c/0xa0 
 [<c02c3410>] device_add+0xe0/0x160 
 [<c02c64e2>] platform_device_register+0xc2/0x170 
 [<c056ac90>] vesafb_init+0x60/0x74 
 [<c05549eb>] do_initcalls+0x2b/0xc0 
 [<c01003a4>] init+0x84/0x1b0 
 [<c0100320>] init+0x0/0x1b0 
 [<c0101215>] kernel_thread_helper+0x5/0x10 
mtrr: size and base must be multiples of 4 kiB 
mtrr: size: 0x1  base: 0xf0000000 
 [<c010e10a>] mtrr_check+0x4a/0x60 
 [<c010e150>] mtrr_add+0x30/0x80 
 [<c056a978>] vesafb_probe+0x338/0x5f0 
 [<c019de1c>] sysfs_make_dirent+0x2c/0xa0 
 [<c02c4bdb>] driver_probe_device+0x3b/0xb0 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c42c9>] bus_for_each_drv+0x69/0x80 
 [<c02c4cc7>] device_attach+0x67/0x70 
 [<c02c4c50>] __device_attach+0x0/0x10 
 [<c02c4435>] bus_add_device+0x35/0xc0 
 [<c02c803c>] device_pm_add+0x5c/0xa0 
 [<c02c3410>] device_add+0xe0/0x160 
 [<c02c64e2>] platform_device_register+0xc2/0x170 
 [<c056ac90>] vesafb_init+0x60/0x74 
 [<c05549eb>] do_initcalls+0x2b/0xc0 
 [<c01003a4>] init+0x84/0x1b0 
 [<c0100320>] init+0x0/0x1b0 
 [<c0101215>] kernel_thread_helper+0x5/0x10 
vesafb: mode switch failed (eax: 0x14f) 
Console: switching to colour frame buffer device 128x48 
vesafb: framebuffer at 0xf0000000, mapped to 0xe0980000, using 1536k, total 
1536k 
fb0: VESA VGA frame buffer device 
... 
mtrr: type mismatch for f0000000,8000000 old: write-back new: write-combining 
 
I don't think that #50 applies to this - it's quite properly page aligned (or 
at least, seems so to my untrained eyes! :-) )... Hardware is an Intel 845GAV 
chipset. 
 
Any ideas? 
Comment 54 Michal Januszewski (RETIRED) gentoo-dev 2005-10-29 09:12:28 UTC
Could everyone who is still affected by this please do the following:
- upgrade to gentoo-sources 2.6.14
- if you see a lot of MTRR error messages in your kernel log, try booting with
video=vesafb:nomtrr,<resolution>?