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
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.
Are you using any kernel parameters to select mtrr ranges? Are you using a framebuffer? Does disabling it help?
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.
I'd be interested to see your grub/lilo config, please.
Created attachment 48332 [details] grub config file Grub config file attached.
Could you please also attach your kernel .config ? Probably found at /usr/src/linux/.config Thanks.
Created attachment 48344 [details] gzip'd /usr/src/linux/.config from 2.6.10-r4
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.
% 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!
Created attachment 48412 [details, diff] mtrr-debug.patch Here you go
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! :)
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.
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
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.
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.
Please could you retest (with your old/default config) with 2.6.10-r5?
2.6.10-r5 did not fix the problem :(
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.
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.
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.
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.
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.
Stoma: please describe what you mean by "the bug". There are a number of small issues present here.
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.
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.
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.
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?
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?
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.
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.
Created attachment 49653 [details] 2.6.10-r6 dmesg dump
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 :))
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.
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.
*** Bug 80755 has been marked as a duplicate of this bug. ***
I have exactly the same bug. Celeron, 2.6.10-gentoo-r6 kernel generated using genkernel. SiS630 Video
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
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
<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.
Michal any progress on this?
I just tested 2.6.11-gentoo-r4 and it has the same problem. Has there been any progress on this bug?
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))) {'.
Michal, how can I test your new version?
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?
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.
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.
Any progress on this bug? It still exists with 2.6.11-r6
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.
(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!!!
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.
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.
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.
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?
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>?
