# [SOLVED] vesafb and mtrr

## atdsm

Hi all,

I'm having the following problem:

After X starts, all my virtual consoles outside of X are blank when I switch to them with CTRL+ALT+F[1-6]. (Before X starts they are not.) They are in fact not only blank, but also not sending any video to my monitor. I know this because my LCD monitor reports that the signal is out of range.

Here's some background:

I just updated to a 2.6.15 kernel (2.6.15-gentoo-r1). vesafb-tng is built in to the new kernel, nvidiafb is not. Because I have read numerous places that the stable nvidia-kernel package doesn't work with newer kernel sources, I emerged the testing version (1.0.8178-r3) of nvidia-kernel and nvidia-glx. I also reemreged splash-utils and redid all my fbsplash stuff. I rebooted to my new kernel, and framebuffer and splash work great. I have a nice big gentoo "g" on the background of my consoles. I can also switch around to all the consoles using  CTRL+ALT+F[1-6]. I can also fire up the X server (Xorg 6.8.2-r6, fluxbox), and everything in X works great as well. BUT, after that if I switch to a console using CTRL+ALT+F[1-6] I get the blank screen reported above.

What I think might be the problem

One thing I didn't do was update my grub.conf lines for fbsplash and vesa-tng. Here is what my grub.conf looks like (an excerpt):

```
# Gentoo 2.6.15

title  Gentoo Linux (2.6.15-gentoo-r1)

root (hd0,0)

kernel /boot/vmlinuz gentoo=nodevfs root=/dev/hda3 video=vesafb:ywrap,mtrr,1024x768-24@60 splash=verbose,theme:emergence quiet CONSOLE=/dev/tty1

initrd /boot/fbsplash-emergence-1024x768
```

BUT, it says in the gentoo wiki that after kernel 2.6.13 I need to specify what mode of MTRR I have:

 *Quote:*   

> Note that for kernel versions from 2.6.13 onwards you *must* specify the mtrr mode: eg "mtrr:2"

 

This seems corroborated by a dmesg output I get. Toward the front of dmesg, excerpted:

```
vesafb: unrecognized option mtrr

vesafb: NVidia Corporation, NV11 (GeForce2) Board, Chip Rev B2 (OEM: NVidia)

vesafb: VBE version: 3.0

vesafb: protected mode interface info at c000:c2c0

vesafb: pmi: set display start = c00cc305, set palette = c00cc38a

vesafb: pmi: ports = b4c3 b503 ba03 c003 c103 c403 c503 c603 c703 c803 c903 cc03 ce03 cf03 d003 d103 d203 d303 d403 d503 da03 ff03 

vesafb: VBIOS/hardware doesn't support DDC transfers

vesafb: no monitor limits have been set

vesafb: scrolling: ywrap using protected mode interface, yres_virtual=1875

```

Ok, sure, it looks like "mtrr" is no longer recognized. But I tried mtrr:2 and it really screwed with my sytem... random lines moving around. Basically, the framebuffer didn't work right at all. So what number should I try?

I can't seem to find documentation anywhere on what an mtrr mode is, or what mtrr does for that matter. I have an nVidia GeForce2 MX/MX 400 (NV11), according to lspci. How do I find out what MTRR mode I have on this graphics card?

Thanks,

Steve

----------

## _loki_

have a look on /usr/src/linux/Documentation/fb/vesafb.txt 

 *Quote:*   

> 
> 
> mtrr:n  Setup memory type range registers for the vesafb framebuffer
> 
>         where n:
> ...

 

where 3 is the "old" mtrr.. just try 2-4 to see what works for you..

----------

## atdsm

Thanks!

Hmm... this is strange.

```
cat /proc/mtrr
```

gives the following:

```
reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1

reg01: base=0x20000000 ( 512MB), size= 128MB: write-back, count=1
```

But that would be type 2, right? I'll try it again after work... I just did an emerge -u system, so maybe something changed.

----------

## marcusvini

from our Gentoo Linux nVidia Guide

 *Quote:*   

> 
> 
> Optional: Check for Legacy Card Support
> 
> Note: Unfortunately, certain legacy video cards are not supported by the newer versions of nvidia-glx and nvidia-kernel. nVidia provides a list of supported cards. Please check the list before installing the drivers. 
> ...

 

I hope that help ya, bud.

----------

## _loki_

this is abozt framebuffer and shouldn't be related to nvidia-kernel module.. Did you try all options? When I run

```

cat /proc/mtrr

```

I get

```

reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1

reg01: base=0x20000000 ( 512MB), size= 128MB: write-back, count=1

reg02: base=0xd8000000 (3456MB), size=  32MB: write-combining, count=2

reg06: base=0xe0000000 (3584MB), size=  64MB: write-combining, count=1

```

also option 2 (write-back) is not working for me..

----------

## atdsm

Ok, let's see, I have several replies to make here...

First, marcusvini, I don't have an integrated MX card... I have an MX 400. It's still supported by the new drivers (8178). I know this because it's on the list at nvidia's website: http://www.nvidia.com/object/IO_18897.html

Besides, my nvidia driver is working great... its the vesa framebuffer driver that isn't.

Second, I tried "mtrr:2" again, and it definitely gave me the same problem: a slow updating screen that updates only a few scattered lines at a time over several seconds. There is also a 1-2 second delay before any typed characters begin to be echoed to the screen (and then they come in piecemeal). "mtrr:1" works, but it doesn't solve my X and VT problem.

Third, loki, I would try "mtrr:3" (write-combining) for you, based on your /proc/mtrr output. Dunno if that will solve anything though.

I'm going to have a look through the vesa documentation that loki helpfully provided the path to, and see if I can find anything else.

----------

## atdsm

Ah! I found the magic bullet. First off, though, both "mtrr:1" and "mtrr:3" seem to work for me, and "mtrr:2" doesn't, which is counterintuitive to me, but whatever. Moral: just try stuff to see if it works.

So... the magic bullet. I found the following useful information in vesafb.txt:

 *Quote:*   

> vbemode:x
> 
>         Force the use of VBE mode x. The mode will only be set if it's
> 
>         found in VBE-provided list of supported modes.
> ...

 

I don't use vbemode:x, but the entry for vbemode:x mentions that the nocrtc option can "ensure that the video mode is properly restored after console <-> X switches." Hmm, that sounds like my problem. So I set "nocrtc" as an option in my vesa kernel parameters, and now it works! I can switch to VTs without losing my video. Dunno why it should be different now than before though.

So now my kernel parameters in grub.conf read like this:

```
# Gentoo 2.6.15

title  Gentoo Linux (2.6.15-gentoo-r1)

root (hd0,0)

kernel /boot/vmlinuz gentoo=nodevfs root=/dev/hda3 video=vesafb:ywrap,mtrr:1,1024x768-24@60,nocrtc splash=verbose,theme:emergence quiet CONSOLE=/dev/tty1

initrd /boot/fbsplash-emergence-1024x768

```

Thanks all for the help.

----------

## Anchialus

Okay, this almost solves all of my problems.  I also couldn't switch between X and console, until I put "nocrtc" in the grub boot options.  Now, I can switch with no problems.

However, when I leave X, my console does not come back.  I get a blank screen, it doesn't matter which console I try to get to (using alt+[1-6]).  There is some kind of signal coming to the monitor, as it doesn't go into "low power" mode like it has done before.

Do you have this problem?  I suppose I could just never shutdown X after I start it, but I don't like this solution.

----------

## _loki_

do you use nvidia kernel module?

----------

## Anchialus

 *_loki_ wrote:*   

> do you use nvidia kernel module?

 

No, I have an ATi card.  I'm using vesafb-tng (because radeonfb didn't help me at all), and the closed-source drivers.

----------

## _loki_

nvidia kernel module doesn't like the framebuffer and keeps killing it (for me) when I quit X.. Doesn't know about the ati though never heard that kind of behaviour for that..

----------

## assaf

I have both the vt-switching problem and the freeze when shutting down x problem. I've tried the mtrr:3 and nocrtc, and they didn't help. Switching to the nv driver or disabling the framebuffer solves the problem (had to patch vesafb_tng to add an off option because I couldn't figure out another way to disable it   :Evil or Very Mad: ).

I'm not sure what causes the problem because I've upgraded both the kernel and the nvidia-kernel driver recently (and I don't leave X most of the time). It used to work fine with 2.6.12-r10 (not sure about the exact nvidia version), doesn't work with 2.6.15-r1 and 8178-r3.

----------

## _loki_

it never worked for me the last two years!!!

----------

## Anchialus

I have to say that this is very discouraging.  I suppose I'll just have to never leave X once I've gone in.

Something interesting that may help the ATi side of things:

I killed X from a virtual terminal, and got this:

```

kernel BUG at arch/i386/mm/pageattr.c:137!

invalid operand: 0000 [#1]

PREEMPT SMP

Modules linked in: fglrx agpgart uhci_hcd ehci_hcd usblp sata_sx4 sata_sis floppy firmware_class

CPU:    1

EIP:    0060:[<c01151a1>]    Tainted: P      VLI

EFLAGS: 00210082   (2.6.15-gentoo-r1)

EIP is at __change_page_attr+0x1ac/0x1c6

eax: 0000aadc   ebx: c17b9300   ecx: c100aadc   edx: c1000000

esi: c04bff6c   edi: 00000163   ebp: f6ec0000   esp: f7647e70

ds: 007b   es: 007b   ss: 0068

Process X (pid: 6266, threadinfo=f7646000 task=f75e0530)

Stack: f6ec0000 f6ebf000 36c001e3 c17b9300 00000040 00000000 00200202 c0115202

       c17b9300 00000163 f7f17360 f9400000 00000006 00000000 c0114e19 c17b8a00

       00000041 00000163 00001000 00000000 f93863ce f9400000 00000040 00000163

Call Trace:

 [<c0115202>] change_page_attr+0x47/0x5c

 [<c0114e19>] iounmap+0xd3/0x106

 [<f93863ce>] agp_generic_free_gatt_table+0x69/0xcd [fglrx]

 [<f938d677>] agp_backend_cleanup+0xf/0x55 [fglrx]

 [<f938d6bd>] agp_power+0x0/0x21 [fglrx]

 [<f93910e5>] __ke_agp_uninit+0x19/0x24 [fglrx]

 [<f93a90e5>] _firegl_release_agp+0x15/0x140 [fglrx]

 [<f93966c5>] firegl_takedown+0x335/0xb80 [fglrx]

 [<f9395a6f>] firegl_release+0x12f/0x190 [fglrx]

 [<c015da17>] __fput+0x16c/0x17e

 [<c015c00d>] filp_close+0x4d/0x79

 [<c015c0a5>] sys_close+0x6c/0x82

 [<c0102e91>] syscall_call+0x7/0xb

Code: 25 fe ff ff 89 d9 e9 ff fe ff ff 80 3e 00 78 1b 29 d3 c1 fb 02 69 db 39 8e e3 38 c1 e3 0c 09 fb 89 1e f0 ff 49 04 e9 f0 fe ff ff <0f> 0b 89 00 e5 05 3c c0 e9 e3 fe ff ff 0f 0b 73 00 e5 05 3c c0

 <6>note: X[6266] exited with preempt_count 2

```

I could switch between terminals... but the video stopped responding after I switched to F7 (shouldn't have done that).  I had to [ctrl][alt][del] to reboot.

----------

## assaf

I get something of this sort in the system log:

```
Feb  8 22:51:44 blackbird (assaf-16373): Received signal 15, shutting down cleanly

Feb  8 22:51:46 blackbird (assaf-16373): Exiting

Feb  8 22:51:49 blackbird kde(pam_unix)[16236]: session closed for user assaf

Feb  8 22:51:50 blackbird kdm: :0[31843]: IO Error in XOpenDisplay

Feb  8 22:51:50 blackbird kdm[16232]: Display :0 cannot be opened

Feb  8 22:51:50 blackbird kdm[16232]: Unable to fire up local display :0; disabling.
```

----------

