Switched from vesafb to uvesafb, but uvesafb can't work without v86d

Bug #246269 reported by Michael Sotnikov
224
This bug affects 3 people
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
Invalid
Undecided
Unassigned
Declined for Hardy by Colin Watson
Intrepid
Invalid
Undecided
Unassigned
linux (Ubuntu)
Fix Released
High
Ben Collins
Declined for Hardy by Colin Watson
Intrepid
Fix Released
High
Ben Collins
linux-meta (Ubuntu)
Invalid
Undecided
Unassigned
Declined for Hardy by Colin Watson
Intrepid
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: linux-image-2.6.26-3-generic

After grub selection there is no any output to screen till gdm start.
This happens if VESA mode selected in grub command (vga=792 for example). VGA modes work well.

This problem exists only in 2.6.26-3 kernel.
As I can see kernel had switched to uvesafb from vesafb.

There is another bug (https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/189621) about missing v86d, which is needed for uvesafb to work correctly.

~$ lsb_release -rd
Description: Ubuntu intrepid (development branch)
Release: 8.10

$ uname -a
Linux astar-laptop 2.6.26-3-generic #1 SMP Wed Jul 2 21:56:15 UTC 2008 i686 GNU/Linux

GeForce 8400M GS installed on my laptop.

Forum threads:
http://ubuntuforums.org/showthread.php?t=850172
http://ubuntuforums.org/showthread.php?t=850361

WORKAROUND

( this workaround is similar as in comment #42 )
1) install v86d
2) create /etc/modprobe.d/uvesafb
   options uvesafb mode_option=1280x800-32 mtrr=3 scroll=ywrap
4) append
   blacklist uvesafb
 to /etc/modprobe.d/blacklist-framebuffer
3) append
   uvesafb
 to /etc/modules
4) run
   update-initramfs -u
5) reboot.

description: updated
Revision history for this message
Saivann Carignan (oxmosys) wrote :

I confirm that current uvesafb is broken due to missing v86d.

This might be another bug, but uvesafb even starts without VGA= arguments in /boot/grub/menu.lst in my case, causing corrupted splash screens on a brand new intrepid installation.

Changed in linux:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Michael Sotnikov (stari4ek) wrote :

currently there is v86d, but still it doesn't work

i think that this bug and https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/189621 is the same on current stage (missing v86d was fixed)

Revision history for this message
Michael Sotnikov (stari4ek) wrote :

Answer for post https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/189621/comments/16 about this bug:

I've tried move uvesafb options from /etc/initramfs-tools/modules to /etc/modules - same black blank terminal with errors:

~$ dmesg | grep vesa
[ 2.412814] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
[ 2.412814] uvesafb: vbe_init() failed with -22
[ 2.412814] uvesafb: probe of uvesafb.0 failed with error -22

But I booted with default "vga=792", which isn't valid for uvesafb, as I understand.

I have /boot and / on different devices.
My videocard is GeForce 8400M GS.

Revision history for this message
Saivann Carignan (oxmosys) wrote :

Michael Sotnikov : v86d has been added to repositories, however it is not a part of the default intrepid installation, at least it is not with alpha 3 which was released yesterday. I had to install it manually through synaptic to get uvesafb working.

Revision history for this message
Michael Sotnikov (stari4ek) wrote :

ok. it should be installed automatically - this is first bug.
I've installed it by hands (apt-get) and it doesn't work for me. this is second bug.

Revision history for this message
Matt Zimmerman (mdz) wrote :

This bug was correctly filed against linux, which installs this module in /lib/modules/`uname -r`/initrd, which causes it to be loaded in the initramfs. Please leave it there.

Revision history for this message
Saivann Carignan (oxmosys) wrote :

Matt Zimmerman : Thanks for your correction

Revision history for this message
Michael Sotnikov (stari4ek) wrote :

One more bug with connections to non-working uvesafb
https://bugs.launchpad.net/ubuntu/+source/usplash/+bug/249037

Revision history for this message
goto (gotolaunchpad) wrote :

I am also experiencing this problem -- multiple beeps upon reboot (sometimes) followed by either:
1. A black screen until kdm loads
2. Blue/Red background with white vertical bands instead of boot kernel messages
3. Normal boot with kernel messages but no usplash whatsoever.

It seems the beeps happen in concert with either 1. or 2., when it does 3. there are no beeps.

Interesting messages from dmesg:
=====
[ 1.703488] uvesafb: NVIDIA Corporation, GT200 Board - 0651s004, Chip Rev , OEM: NVIDIA, VBE v3.0
[ 1.772790] Program usplash tried to access /dev/mem between 0->e00000.
[ 2.594371] uvesafb: VBIOS/hardware doesn't support DDC transfers
[ 2.594371] uvesafb: no monitor limits have been set, default refresh rate will be used
[ 2.594371] uvesafb: scrolling: redraw
=====

See the second line especially...

followed by:
=====
[ 2.598371] mtrr: type mismatch for f5000000,800000 old: write-back new: write-combining
[ 2.598371] mtrr: type mismatch for f5000000,400000 old: write-back new: write-combining
[ 2.598371] mtrr: type mismatch for f5000000,200000 old: write-back new: write-combining
[ 2.598371] mtrr: type mismatch for f5000000,100000 old: write-back new: write-combining
[ 2.598371] mtrr: type mismatch for f5000000,80000 old: write-back new: write-combining
[ 2.598371] mtrr: type mismatch for f5000000,40000 old: write-back new: write-combining
[ 2.598371] mtrr: type mismatch for f5000000,20000 old: write-back new: write-combining
[ 2.598371] mtrr: type mismatch for f5000000,10000 old: write-back new: write-combining
[ 2.598371] mtrr: type mismatch for f5000000,8000 old: write-back new: write-combining
[ 2.598371] mtrr: type mismatch for f5000000,4000 old: write-back new: write-combining
[ 2.598371] mtrr: type mismatch for f5000000,2000 old: write-back new: write-combining
[ 2.598371] mtrr: type mismatch for f5000000,1000 old: write-back new: write-combining
[ 2.598371] uvesafb: framebuffer at 0xf5000000, mapped to 0xffffc20011800000, using 14336k, total 14336k
[ 2.598371] fb0: VESA VGA frame buffer device
[ 2.605070] Console: switching to colour frame buffer device 80x30
=====

System specs follow:
Hardware: Core2Duo/Intel P45/nVidia GTX260
Software: KUbuntu 8.10 Intrepid Ibex installed at Alpha 2, updated to latest via 'aptitude dist-upgrade'.
The v86d package is installed (repeatedly situation 3. without it).

=====[/etc/usplash.conf]=====
# Usplash configuration file
# These parameters will only apply after running update-initramfs.
xres=1920
yres=1200
=====[/etc/usplash.conf]=====

=====[/boot/grub/menu.lst]=====
(...)
title Ubuntu intrepid (development branch), kernel 2.6.26-5-generic
root (hd0,1)
kernel /boot/vmlinuz-2.6.26-5-generic root=UUID=03cbe687-58cb-4805-a4f3-5b6c5d11c4db ro quiet splash crashkernel=384M-2G:64M@16M,2G-:128M@16M
initrd /boot/initrd.img-2.6.26-5-generic
quiet
(...)
=====[/boot/grub/menu.lst]=====

If any more details are needed, please ask...

Changed in linux:
assignee: nobody → ubuntu-kernel-team
status: Confirmed → Triaged
Revision history for this message
André Barmasse (barmassus) wrote :

Bug is confirmed here with Intrepid Ipex on my Sony Vaio with Nvidia and linux kernel 2.6.26-5-generic. The following messages are displayed during boot:

[ 2.152084] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
[ 2.152140] uvesafb: vbe_init() failed with -22
[ 2.152193] uvesafb: probe of uvesafb.0 failed with error -22

Trying to manually add vga modes in /boot/grub/menu.lst (for example vga=791) result in an entirely black screen though the whole booting sequence. Installing or uninstalling v86d has no influence on this nasty bug. Would be nice to have back again the possibility for slightly larger boot display ...

Revision history for this message
Harvey Muller (hlmuller) wrote :

Andre,

Your problem is most likely due to using incorrect modes on the kernel parameter line, and not a confirmation of the bug. The documentation in the kernel describes the correct method (Documentation/fb/uvesafb.txt):

    video=uvesafb:1024x768-32,mtrr:3,ywrap

The specific mode that you use would depend on your hardware and supported modes. On an Inspiron 1420 with integrated Nvidia 8400M GS graphics this mode works like a champ:

    video=uvesafb:1440x900,mtrr:3,ywrap

The documentation also describes how you may determine supported modes, note that v86d must be properly installed and the uvesafb module loaded:

    $ less /sys/bus/platform/drivers/uvesafb/uvesafb.0/vbe_modes

If the uvesafb.0 directory is not present, then you can assume that you have not properly installed v86d and/or loaded the uvesafb module.

Once you have the correct mode, and v86d is installed and you are still having problems at boot, then you should suspect a problem with the initramfs. At this point I would guess the v86d executable is probably missing from the initramfs.

In the last case, I would return and report the issue.

Thanks,

Harvey

Revision history for this message
Michael Sotnikov (stari4ek) wrote :

~$ dmesg | grep vesa
[ 2.776166] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
[ 2.776166] uvesafb: vbe_init() failed with -22
[ 2.776166] uvesafb: probe of uvesafb.0 failed with error -22

on nvidia 8400gs

$ lsmod | grep vesa
uvesafb 34660 0
cn 15648 1 uvesafb

but I don't have uvesafb.0:
$ ls /sys/bus/platform/drivers/uvesafb/
bind uevent unbind v86d

I have v86d:

$ whereis v86d
v86d: /sbin/v86d /usr/share/man/man8/v86d.8.gz

according to Harvey's post probably it's initramfs problem, but last time I unpack initram there was v86d, and I had same behavior.

Revision history for this message
Michael Sotnikov (stari4ek) wrote :

one more experiment:

after clean boot I see uvesafb as loaded module (lsmod), but it doesn't work: I have no /sys/bus/platform/drivers/uvesafb/uvesafb.0 and /sys/class/graphics/fb0, and all terminals have usual text mode (40x25 or like that)

I can reload uvesafb:
$ sudo modprobe -r uvesafb
$ sudo modprobe uvesafb mode=1280x800-32

got it:
$ dmesg | tail
[ 225.876067] uvesafb: NVIDIA Corporation, G86 Board - e415h01 , Chip Rev , OEM: NVIDIA, VBE v3.0
[ 225.930869] uvesafb: protected mode interface info at c000:b7e0
[ 225.930869] uvesafb: pmi: set display start = c00cb843, set palette = c00cb89e
[ 225.930869] uvesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da
[ 225.999969] uvesafb: VBIOS/hardware doesn't support DDC transfers
[ 225.999969] uvesafb: no monitor limits have been set, default refresh rate will be used
[ 225.999980] uvesafb: scrolling: ypan using protected mode interface, yres_virtual=1600
[ 226.003950] Console: switching to colour frame buffer device 160x50
[ 226.003950] uvesafb: framebuffer at 0xcd000000, mapped to 0xfba00000, using 8000k, total 14336k
[ 226.003950] fb0: VESA VGA frame buffer device

and it looks like module start working (stuff in /sys/bus, /sys/class mentioned before) but terminals become totally blank (no login prompt, no blinking cursor. no reaction on keyboard input)

Revision history for this message
reh4c (gene-hoffler) wrote :

After returning two junk desktops by Gateway and HP, I built a new rig to run Linux...Ubuntu as my primary choice. Anyway, I tried installing Hardy and the desktop CD for Ibex Alpha 4. Hardy froze up with a busybox error while Ibex gave me this one:
[ 2.422795] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
[ 2.422795] uvesafb: vbe_init() failed with -22
[ 2.422795] uvesafb: probe of uvesafb.0 failed with error -22
As a last ditch effort, I downloaded and installed from the alternate CD. Somehow, the installation completed and now I can graphically start up my new system. However, I can still see the error when I boot up. What effect did installing from the alternate CD vice live cd have on getting around this messy problem? I'm not a Linux guru, but will provide whatever feedback needed to get this and other bugs fixed. Thanks.

Revision history for this message
nullack (nullack) wrote :

reh4c the bug system is not for user support. You have various support avenues, such as IRC, community documentation or the Ubuntu forums. Intrepid has not been released to production and given it's Alpha status bugs are to be expected.

While this error prevents high resolution modes in virtual consoles I find that the system will still progress to GDM and allow gnome sessions as expected.

Revision history for this message
nanog (sorenimpey) wrote :

Actually on my system I typically get kernel panic that can only be terminated by REISUB. (TTY is not available - I checked.) This occurs immediately after vbe_init fails.

Very occasionally the boot continues to GDM:

[ 1.678748] uvesafb: failed to execute /sbin/v86d
[ 1.678748] uvesafb: make sure that the v86d helper is installed and executable
[ 1.678748] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2)
[ 1.678748] uvesafb: vbe_init() failed with -22
[ 1.678748] uvesafb: probe of uvesafb.0 failed with error -22

Revision history for this message
nanog (sorenimpey) wrote :

I am no longer getting kernel panic (blank screen flashing lights) and the bahavior of this bug is identical to what has been reported above.

Revision history for this message
Brian Murray (brian-murray) wrote :

The linux task is the appropriate one for this bug, linux-meta is usually for bugs that affect multiple kernel releases.

Changed in linux-meta:
status: New → Invalid
Revision history for this message
Fahim Abdun-Nur (fahim-a) wrote :

Not that I'm being pushy in any way, but was wondering if there was a planned fix (and rough timeframe) for this. I've gotten by for the most part by removing usplash (prior to this I was getting a completely blank screen, so I ssh'ed, apt-get removed, and rebooted, and voila I can see the gdm login screen), but in any case I presume it'll be resolved by the time 8.10 is formally released.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Revision history for this message
Fahim Abdun-Nur (fahim-a) wrote :

Thanks Leann! Took your suggestion and installed the latest kernel (and re-installed usplash and the corresponding ubuntu theme package; I think I already had v86d installed manually before)

As the system went down, got the usual red screen with white bars I saw when I had usplash installed. In any case, was more interested to see what would happen as the system came back up: I didn't get a completely blank screen (instead got a message from a monitor something along the lines of it not supporting that display mode/resolution). But more importantly, proceeded to gdm!!! :)

On another good note, also I'm no longer seeing the VBE-related errors in the dmesg logs

fahim@fahim-gx280:~$ uname -a
Linux fahim-gx280 2.6.27-1-server #1 SMP Sun Aug 24 00:04:57 UTC 2008 i686 GNU/Linux

fahim@fahim-gx280:~$ dmesg | grep vesa
[ 3.170630] uvesafb: Intel Corporation, Intel(r)915G/915GV/910GL Graphics Controller, Hardware Version 0.0, OEM: Intel(r)915G/915GV/910GL Graphics Chip Accelerated VGA BIOS, VBE v3.0
[ 3.180005] uvesafb: VBIOS/hardware supports DDC2 transfers
[ 3.190005] uvesafb: monitor limits: vf = 75 Hz, hf = 80 kHz, clk = 140 MHz
[ 3.190005] uvesafb: scrolling: redraw
[ 3.200006] uvesafb: framebuffer at 0xc0000000, mapped to 0xf8880000, using 7872k, total 7872k
[ 34.440635] uvesafb: mode switch failed (eax=0x14f, err=0). Trying again with default timings.
[ 34.610635] uvesafb: mode switch failed (eax=0x14f, err=0). Trying again with default timings.
fahim@fahim-gx280:~$

I'll try rebooting and/or cold starting the system a couple of times just in case...

Revision history for this message
Providence SALUMU M. (providence-salumu) wrote :

Hi Leann,

Thanks for this post. After updating to kernel 2.6.27-1,After bootup, I'm having the following problems :

boomer@boomer-laptop:~$ dmesg | grep uvesa
[ 0.000000] Kernel command line: root=UUID=c48d6261-5fb3-45fd-9cec-ade1e3816556 ro video=uvesafb:800x600-16,mtrr:3,ywrap
[ 1.897079] uvesafb: Unknown parameter `mode'
[ 6.976027] uvesafb: Getting VBE info block failed (eax=0x4f00, err=1)
[ 6.976109] uvesafb: vbe_init() failed with -22
[ 6.976263] uvesafb: probe of uvesafb.0 failed with error -22

More weird, lsmod | grep uvesafb says the module is loaded, but
boomer@boomer-laptop:~$ less /sys/bus/platform/drivers/uvesafb/uvesafb.0/vbe_modes
/sys/bus/platform/drivers/uvesafb/uvesafb.0/vbe_modes: No such file or directory

Re-loading the uvesafb using the 'mode' parameter doesn't work neither :
root@boomer-laptop:/home/boomer# modprobe -r uvesafb
root@boomer-laptop:/home/boomer# modprobe uvesafb mode=1024x768-32 mtrr=3 scroll=ywrap
FATAL: Error inserting uvesafb (/lib/modules/2.6.27-1-generic/initrd/uvesafb.ko): Unknown symbol in module, or unknown parameter (see dmesg)

So, I wonder if anything is wrong with my uvesafb version (I don't know how to figure it) as 'mode' the parameter seems to never work when used in kernel command line bootup options, nor in modprobe reload options.

However, re-loading uvesafb without 'mode' parameter (with modprobe) seems to work fine and the supported mode can now be printed as in :
boomer@boomer-laptop:~$ cat /sys/bus/platform/drivers/uvesafb/uvesafb.0/vbe_modes
...
800x600-8, 0x0103
1024x768-8, 0x0105
320x200-16, 0x010e
320x200-32, 0x010f
640x480-16, 0x0111
640x480-32, 0x0112
800x600-16, 0x0114
800x600-32, 0x0115
1024x768-16, 0x0117
1024x768-32, 0x0118
...

Does anyone have a clue why 'mode' parameter is reported 'unknown' now?

Revision history for this message
nullack (nullack) wrote :

Leann to clarify, on .27 VESA modes still cannot be achieved. Also the usual boot time messages about the -22 error still occurs. Thanks.

Revision history for this message
Michael Sotnikov (stari4ek) wrote :

nothing changed with 2.7.1 about uvesafb:
$ dmesg | grep uvesa
[ 2.712002] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
[ 2.712002] uvesafb: vbe_init() failed with -22
[ 2.712002] uvesafb: probe of uvesafb.0 failed with error -22

Revision history for this message
Michael Sotnikov (stari4ek) wrote :

Leann Ogasawara,

I'd like to inform about positive changes with 2.7.1, but this is not about uvesafb. I can't find any contact info\mechanism for it. Point me, please.

Revision history for this message
Fahim Abdun-Nur (fahim-a) wrote :

Oddly enough, on a cold boot I was actually surprised to see the almost-forgotten Ubuntu startup splash bar rendered properly. I'm still seeing a different uvesafb error, but not the -22 error as some are still apparently seeing.

fahim@fahim-gx280:~$ dmesg | grep vesa
[ 3.170630] uvesafb: Intel Corporation, Intel(r)915G/915GV/910GL Graphics Controller, Hardware Version 0.0, OEM: Intel(r)915G/915GV/910GL Graphics Chip Accelerated VGA BIOS, VBE v3.0
[ 3.180005] uvesafb: VBIOS/hardware supports DDC2 transfers
[ 3.190005] uvesafb: monitor limits: vf = 75 Hz, hf = 80 kHz, clk = 140 MHz
[ 3.190005] uvesafb: scrolling: redraw
[ 3.200006] uvesafb: framebuffer at 0xc0000000, mapped to 0xf8880000, using 7872k, total 7872k
[ 34.440635] uvesafb: mode switch failed (eax=0x14f, err=0). Trying again with default timings.
[ 34.610635] uvesafb: mode switch failed (eax=0x14f, err=0). Trying again with default timings.

This is on a Dell GX280 system with GMA900 graphics. I'll give it a try tomorrow on my work PC which is an Optiplex 755 with GMA3100 (?) Not even sure this has anything to do with the graphics card/IGP...I doubt it. But definitely interested in seeing if the new kernel really does do the trick or not

Revision history for this message
Fahim Abdun-Nur (fahim-a) wrote :

Yep, seems like it worked even better on my work PC:

before:
[ 3.668437] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
[ 3.668437] uvesafb: vbe_init() failed with -22
[ 3.668437] uvesafb: probe of uvesafb.0 failed with error -22

after:
[ 3.780626] uvesafb: Intel Corporation, Intel(r)Q33/Q35/G33 Graphics Controller, Hardware Version 0.0, OEM: Intel(r)Q33/Q35/G33 Gr
aphics Chip Accelerated VGA BIOS, VBE v3.0
[ 3.780627] uvesafb: VBIOS/hardware supports DDC2 transfers
[ 3.810626] uvesafb: monitor limits: vf = 75 Hz, hf = 83 kHz, clk = 150 MHz
[ 3.810626] uvesafb: scrolling: redraw
[ 3.812880] uvesafb: framebuffer at 0xd0000000, mapped to 0xf8880000, using 8128k, total 8128k

Revision history for this message
Chris Jones (cmsj) wrote :

Installing v86d shows uvesafb setup messages, but causes X to fail to start, saying it cannot work in framebuffer mode. This is on an intel 965 with no xorg.conf

Revision history for this message
Fahim Abdun-Nur (fahim-a) wrote :

Ok, I'm back home (i.e. the Intel 915 system), and mistakenly decided to update the kernel once more to 2.6.27.2 from 27.1. :(

I'm guessing I'll just have to wait till 8.10 formally comes out before I'll try again. Or I could try reverting back to 27.1

fahim@fahim-gx280:~$ uname -a
Linux fahim-gx280 2.6.27-2-server #1 SMP Thu Aug 28 18:05:08 UTC 2008 i686 GNU/Linux
fahim@fahim-gx280:~$ dmesg | grep vesa
[ 2.906117] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
[ 2.906173] uvesafb: vbe_init() failed with -22
[ 2.906224] uvesafb: probe of uvesafb.0 failed with error -22

Revision history for this message
Christian Stöveken (excogitation) wrote :

on an Acer Travelmate TM8106wlmi

~# lsb_release -rd
Description: Ubuntu intrepid (development branch)
Release: 8.10

~# uname -a
Linux bored 2.6.27-2-generic #1 SMP Thu Aug 28 17:20:02 UTC 2008 i686 GNU/Linux

~# lsmod | grep uvesafb
uvesafb 34788 0
cn 15776 1 uvesafb

~# dmesg | grep vesa
[ 2.472002] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
[ 2.472002] uvesafb: vbe_init() failed with -22
[ 2.472002] uvesafb: probe of uvesafb.0 failed with error -22

~# whereis v86d
v86d: /sbin/v86d /usr/share/man/man8/v86d.8.gz

~# ls /sys/bus/platform/drivers/uvesafb/
bind uevent unbind v86d

~# sudo modprobe -r uvesafb
~# sudo modprobe uvesafb mode=1280x800-32
FATAL: Error inserting uvesafb (/lib/modules/2.6.27-2-generic/initrd/uvesafb.ko): Unknown symbol in module, or unknown parameter (see dmesg)
~# cat /sys/bus/platform/drivers/uvesafb/uvesafb.0/vbe_modes
cat: /sys/bus/platform/drivers/uvesafb/uvesafb.0/vbe_modes: No such file or directory
[ 1706.062122] uvesafb: Unknown parameter `mode'

~# sudo modprobe uvesafb
root@bored:~# cat /sys/bus/platform/drivers/uvesafb/uvesafb.0/vbe_modes
640x400-8, 0x0100
640x480-8, 0x0101
800x600-8, 0x0103
1024x768-8, 0x0105
1280x1024-8, 0x0107
640x480-15, 0x0110
640x480-16, 0x0111
640x480-32, 0x0112
800x600-15, 0x0113
800x600-16, 0x0114
800x600-32, 0x0115
1024x768-15, 0x0116
1024x768-16, 0x0117
1024x768-32, 0x0118
1280x1024-15, 0x0119
1280x1024-16, 0x011a
1280x1024-32, 0x011b
320x200-15, 0x010d
320x200-16, 0x010e
320x200-32, 0x010f
320x200-32, 0x0120
320x240-8, 0x0193
320x240-15, 0x0194
320x240-16, 0x0195
320x240-32, 0x0196
512x384-8, 0x01b3
512x384-15, 0x01b4
512x384-16, 0x01b5
512x384-32, 0x01b6
640x350-8, 0x01c3
640x350-15, 0x01c4
640x350-16, 0x01c5
640x350-32, 0x01c6
640x400-8, 0x0183
640x400-15, 0x0184
640x400-16, 0x0185
640x400-32, 0x0186
720x400-8, 0x0133
720x400-15, 0x0134
720x400-16, 0x0135
720x400-32, 0x0136
1152x864-8, 0x0153
1152x864-15, 0x0154
1152x864-16, 0x0155
1152x864-32, 0x0156
1280x1024-8, 0x0163
1280x1024-15, 0x0164
1280x1024-16, 0x0165
1280x1024-32, 0x0166
640x480-32, 0x0121
800x600-32, 0x0122
1024x768-32, 0x0123
1280x1024-32, 0x0124
1400x1050-8, 0x0143
1400x1050-15, 0x0144
1400x1050-16, 0x0145
1400x1050-32, 0x0146
640x400-8, 0x0183
640x400-15, 0x0184
640x400-16, 0x0185
640x400-32, 0x0186

[ 1845.056513] uvesafb: (C) 1988-2005, ATI Technologies Inc. M26-P01.00, M26-P01.00, 01.00, OEM: ATI ATOMBIOS(C) 1988-2005, ATI Technologies Inc. M26-P01.00, VBE v3.0
[ 1845.074888] uvesafb: protected mode interface info at c000:adce
[ 1845.074894] uvesafb: pmi: set display start = c00cae5c, set palette = c00cae9c
[ 1845.261580] uvesafb: VBIOS/hardware supports DDC2 transfers
[ 1845.394236] uvesafb: monitor limits: vf = 61 Hz, hf = 65 kHz, clk = 121 MHz
[ 1845.394674] uvesafb: scrolling: ypan using protected mode interface, yres_virtual=9187
[ 1845.399671] uvesafb: framebuffer at 0xd0000000, mapped to 0xf9000000, using 11484k, total 16384k

Revision history for this message
Harvey Muller (hlmuller) wrote :

Regarding my previous comment above:

    https://bugs.launchpad.net/ubuntu/+source/linux/+bug/246269/comments/11

When I made the comment above, I was working within a system I had personally built by hand. I manually built the kernel, klibc, and v86d. It of course worked perfectly in that environment. I assumed WRONGLY that since v86d was now being shipped in Ubuntu that it should work there too.

I am now testing an installation on a Dell Inspiron 1420, using the 20080829 daily-live amd64 desktop (Alpha 5) iso which includes kernel version 2.6.27. I can confirm that uvesafb DOES NOT work in this environment. This is documented in the Debian v86d readme. Uvesafb will not work in Ubuntu until Debian/Ubuntu begin shipping v86d built against klibc. Or the user successfully builds v86d against klibc themselves.

uvesafb will not work during boot while v86d is built against glibc. I apologize for the previous noise.

Revision history for this message
Providence SALUMU M. (providence-salumu) wrote :

Updated from .27-1 to .27-2, I only have now :

boomer@boomer-laptop:~$ dmesg | grep uvesa
[ 1.937205] uvesafb: Unknown parameter `mode'

I no longer have the "error -22".

Thanks to Harvey Muller for the following news:

"Uvesafb will not work in Ubuntu until Debian/Ubuntu begin shipping v86d built against klibc. Or the user successfully builds v86d against klibc themselves."

Revision history for this message
L Jones (isharra) wrote :

apparently the name changed from "mode" to "mode_option" in uvesafb (modinfo uvesafb)
"modprobe mode_option=1440x900 mtrr=3 scroll=ywrap" works, but the short form of "video=vesafb:1440x900,mtrr:3,ywrap" on the kernel line is not working (gives the complaint about unknown mode parameter.)

Revision history for this message
Fred (eldmannen+launchpad) wrote :

Who is working on this?
What is the status?
When will it be fixed?
Will it be fixed in time for Intrepid?

Revision history for this message
Johannes R. (ringe-efreun) wrote :

Still the Same with new Kernel

root@merlin:~# lsb_release -rd
Description: Ubuntu intrepid (development branch)
Release: 8.10

root@merlin:~# uname -a
Linux merlin 2.6.27-2-generic #1 SMP Thu Aug 28 17:20:02 UTC 2008 i686 GNU/Linux

root@merlin:~# dmesg | grep uvesa
[ 2.346102] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
[ 2.346220] uvesafb: vbe_init() failed with -22
[ 2.346329] uvesafb: probe of uvesafb.0 failed with error -22

Revision history for this message
D. Hugh Redelmeier (hugh-mimosa) wrote :

This bug affects Hardy when the 2.6.27 kernel is installed from http://kernel.ubuntu.com/pub/next/2.6.27-rc3/{all,hardy}

I installed this because of the response to 236937.

Is there any .deb containing v86d made available for Hardy?

Revision history for this message
James Le Cuirot (chewi) wrote :

Did no one look at the Gentoo bug report?
http://bugs.gentoo.org/196848

I think Harvey is right, v86d must be built against klibc. Having said that, while I get the -22 error when trying to manually load uvesafb from the initramfs (by adding break=modules to the kernel command line), if I then fully boot up, rmmod uvesafb and then modprobe uvesafb, it works. v86d is definitely present on the initramfs so I don't know why this is.

Revision history for this message
Rafi (rafi-theater-kgr) wrote :

i used this howto
http://otamay.wordpress.com/2008/01/12/howto-uvesafb-on-debian-in-my-case-sid-d/
for intrepid with 2.6.27 and works very well.
u have to compile kernel and v86d your self

here is a german howto i made one month ago for ubuntu
http://forum.ubuntuusers.de/topic/hochaufloesende-konsole-uvesafb-howto/

Revision history for this message
Julio Lajara (ju2wheels) wrote :

I am having this issue on my machine while using Intrepid alpha 6 64bit. I didnt have this issue while using 8.0.4.1 64bit live cd.

My machine is:

MSI P7N SLI-FI 750i SLI Chipset LGA775
NVIDIA GeForce 8500 GT 512MB 16X PCI Express
Core 2 Quad Q6600 @ 2.4GHz 1066FSB 8MB L2 Cache 64-bit
4gb PC6400 DDR2/800 Dual Channel Memory
Sata II HD on Sata2

Revision history for this message
Julio Lajara (ju2wheels) wrote :

*Clarification on my last post... I am not able to boot into the alpha 6 live cd, I end up at a Busybox prompt as a result of the errors.

Revision history for this message
Luca Carrogu (motoplux) wrote :

Finally I'm able to run uvesafb.
This is what I did:
-- installed v86d from intrepid repo
-- added the module uvesafb in /etc/initramfs-tools/modules
-- removed all the old parameter in /boot/grub/menu.lst, like video=...
-- created /etc/modprobe.d/uvesafb containing the parameters for uvesafb. In my case the line : "options uvesafb mode=1280x768-32 mtrr=3 scroll=ywrap" (without ")
-- updated the initramfs with the command update-initramfs -u
-- rebooted

got it!
hope this can help

Revision history for this message
rockpiper (rob-burningsoda) wrote :

make that “mode_option” instead of “mode” and it works for me, too! thanks.

Revision history for this message
Rune K. Svendsen (runeks) wrote :

I experience this bug when trying to use the Alpha 6 Live CD:

Sep 21 13:23:41 ubuntu kernel: [ 1.712833] uvesafb: failed to execute /sbin/v86d
Sep 21 13:23:41 ubuntu kernel: [ 1.712875] uvesafb: make sure that the v86d helper is installed and executable
Sep 21 13:23:41 ubuntu kernel: [ 1.712912] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2)
Sep 21 13:23:41 ubuntu kernel: [ 1.712948] uvesafb: vbe_init() failed with -22
Sep 21 13:23:41 ubuntu kernel: [ 1.712988] uvesafb: probe of uvesafb.0 failed with error -22

Revision history for this message
Dean Loros (autocrosser) wrote :

I tried what motoplux & rockpiper had work for them--I get a different response:

[ 11.295996] v86d[1086]: segfault at 0 ip 08049cd1 sp bf87b600 error 4 in v86d[8048000+17000]
[ 16.132008] uvesafb: Getting VBE info block failed (eax=0x4f00, err=1)
[ 16.132061] uvesafb: vbe_init() failed with -22
[ 16.132115] uvesafb: probe of uvesafb.0 failed with error -22

I used mode-1024x768-32 for mine. Any ideas?

Revision history for this message
Christian Roessner (christian-roessner-net) wrote :

Following

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/246269/comments/41

and changing mode to mode_option= does not work here, too.

[ 1.982693] v86d[1080]: segfault at 0 ip 0000000000402069 sp 00007fffba7333a0 error 4 in v86d[400000+1a000]
[ 6.804010] uvesafb: Getting VBE info block failed (eax=0x4f00, err=1)
[ 6.804049] uvesafb: vbe_init() failed with -22
[ 6.804086] uvesafb: probe of uvesafb.0 failed with error -22

This is on x86_64. Intrepid 64bit

@motoplux: Is your system 32 or 64? Maybe v86d is buggy just on 64?

Revision history for this message
Luca Carrogu (motoplux) wrote :

@Christian Roessner I'm on 32

and this is my dmsg:

[ 1.487817] uvesafb: ATI Technologies Inc., C24 , 01.00, OEM: ATI MOBILITY RADEON X600 , VBE v2.0
[ 1.585195] uvesafb: protected mode interface info at c000:5b20
[ 1.585198] uvesafb: pmi: set display start = c00c5b8e, set palette = c00c5bc8
[ 1.585200] uvesafb: pmi: ports = 3010 3016 3054 3038 303c 305c 3000 3004 30b0 30b2 30b4
[ 1.585207] uvesafb: no monitor limits have been set, default refresh rate will be used
[ 1.585322] uvesafb: scrolling: ywrap using protected mode interface, yres_virtual=2048
[ 1.590033] uvesafb: framebuffer at 0xd0000000, mapped to 0xf8880000, using 6144k, total 65472k

Revision history for this message
Martin Capitanio (capnm) wrote :

( this workaround is similar as in comment #42 )

    1) install v86d

    2) create /etc/modprobe.d/uvesafb

options uvesafb mode_option=1280x800-32 mtrr=3 scroll=ywrap

    4) append

blacklist uvesafb

    to /etc/modprobe.d/blacklist-framebuffer

    3) append

uvesafb

    to /etc/modules

    4) run

update-initramfs -u
reboot

[ 16.996674] uvesafb: Intel Corporation, Intel(r)Crestline Graphics Controller, Hardware Version 0.0, OEM: Intel(r)Crestline Graphics Chip Accelerated VGA BIOS, VBE v3.0
[ 17.019563] uvesafb: VBIOS/hardware supports DDC2 transfers
[ 17.039816] uvesafb: monitor limits: vf = 75 Hz, hf = 83 kHz, clk = 150 MHz
[ 17.040016] uvesafb: scrolling: redraw
[ 17.201234] Console: switching to colour frame buffer device 128x48
[ 17.203656] uvesafb: framebuffer at 0x80000000, mapped to 0xffffc20004c80000, using 6144k, total 7616k
[ 17.203717] fb0: VESA VGA frame buffer device

C de-Avillez (hggdh2)
description: updated
Revision history for this message
Bogdan Butnaru (bogdanb) wrote :

@captn: Strange: I tried the exact same parameters you gave, and I receive this error:

[ 14.298314] uvesafb: Unknown parameter `mttr'

Any idea why that'd be missing? I don't think I ever saw a help file that mentioned it mightn't exist.

I tried removing that parameter and modprobeing the module myself. This took me to 1024x768 instead of the mode I wanted. fbset doesn't seem to know how to set the mode, either.

$ dmesg | tail
[ 558.888174] CPU1 attaching sched-domain:
[ 558.888178] domain 0: span 0-1 level MC
[ 558.888183] groups: 1 0
[ 1021.792123] uvesafb: Intel Corporation, Intel(r) 82945GM Chipset Family Graphics Controller, Hardware Version 0.0, OEM: Intel(r) 82945GM Chipset Family Graphics Chip Accelerated VGA BIOS, VBE v3.0
[ 1021.805758] uvesafb: VBIOS/hardware supports DDC2 transfers
[ 1021.818305] uvesafb: monitor limits: vf = 60 Hz, hf = 49 kHz, clk = 68 MHz
[ 1021.827251] uvesafb: scrolling: redraw
[ 1022.267697] Console: switching to colour frame buffer device 128x48
[ 1022.272493] uvesafb: framebuffer at 0xd0000000, mapped to 0xf9200000, using 6144k, total 7872k
[ 1022.272497] fb0: VESA VGA frame buffer device

$ fbset -i
mode "1024x768-60"
    # D: 64.033 MHz, H: 47.714 kHz, V: 60.018 Hz
    geometry 1024 768 1024 768 32
    timings 15617 159 52 23 1 107 3
    vsync high
    rgba 8/16,8/8,8/0,8/24
endmode

Frame buffer device information:
    Name : VESA VGA
    Address : 0xd0000000
    Size : 6291456
    Type : PACKED PIXELS
    Visual : TRUECOLOR
    XPanStep : 0
    YPanStep : 0
    YWrapStep : 0
    LineLength : 4096
    Accelerator : No

$ sudo fbset -xres 1280 -yres 800
Linux Frame Buffer Device Configuration Version 2.1 (23/06/1999)
(C) Copyright 1995-1999 by Geert Uytterhoeven

Opening frame buffer device `/dev/fb0'
Using current video mode from `/dev/fb0'
Setting video mode to `/dev/fb0'
ioctl FBIOPUT_VSCREENINFO: Invalid argument

Revision history for this message
Bogdan Butnaru (bogdanb) wrote :

OK, ignore the part about mttr, I noticed the typo. (It should have been mtrr.)

Any idea how I can get a better resolution?

Revision history for this message
Martin Capitanio (capnm) wrote :

Until somebody decides to fix the Intel fb driver ;-) you have to patch the VGA BIOS
( Read http://dev.gentoo.org/~spock/projects/uvesafb/faq.php )

e.g .for 1280x800:

    * wget 'https://launchpad.net/ubuntu/hardy/+source/915resolution/0.5.3-1ubuntu1/+files/915resolution_0.5.3.orig.tar.gz'

    * tar xvzf 915resolution_0.5.3.orig.tar.gz && cd 915resolution-0.5.3/ && make

    * sudo cp -a 915resolution /sbin/

    * read README.txt

    * sudo 915resolution -l gives me
Intel chipset detected. However, 915resolution was unable to determine the chipset type.

    * for my chipset fgrep Chipset /var/log/Xorg.0.log
(II) intel: Driver for Intel Integrated Graphics Chipsets: i810, Mobile Intel GM45 Express Chipset,
(II) intel(0): Integrated Graphics Chipset: Intel(R) 965GM

    * forcing 915resolution -c G965 -l works
Intel 800/900 Series VBIOS Hack : version 0.5.3
Chipset: G965
BIOS: TYPE 1
Mode Table Offset: $C0000 + $268
Mode Table Entries: 36

Mode 30 : 640x480, 8 bits/pixel
Mode 32 : 800x600, 8 bits/pixel
Mode 34 : 1280x800, 8 bits/pixel
Mode 38 : 1280x1024, 8 bits/pixel
Mode 3a : 1600x1200, 8 bits/pixel
Mode 3c : 1920x1440, 8 bits/pixel
Mode 41 : 640x480, 16 bits/pixel
Mode 43 : 800x600, 16 bits/pixel
Mode 45 : 1280x800, 16 bits/pixel
Mode 49 : 1280x1024, 16 bits/pixel
Mode 4b : 1600x1200, 16 bits/pixel
Mode 4d : 1920x1440, 16 bits/pixel
Mode 50 : 640x480, 32 bits/pixel
Mode 52 : 800x600, 32 bits/pixel
Mode 54 : 1280x800, 32 bits/pixel
Mode 58 : 1280x1024, 32 bits/pixel
Mode 5a : 1600x1200, 32 bits/pixel
Mode 5c : 1920x1440, 32 bits/pixel

   * insert
/sbin/915resolution -c G965 54 1280 800

   in the /etc/init.d/module-init-tools file just before the line
# Loop over every line in /etc/modules.

   * be happy
[ 17.371765] Console: switching to colour frame buffer device 160x50
[ 17.374929] uvesafb: framebuffer at 0x80000000, mapped to 0xffffc20004c80000, using 7616k, total 7616k

cat /sys/class/graphics/fb0/virtual_size
1280,800

cat /sys/devices/platform/uvesafb.0/vbe_modes
1280x800-8, 0x0105
1280x800-16, 0x0117
1280x800-32, 0x0118
640x480-32, 0x0112
800x600-16, 0x0114
800x600-32, 0x0115
640x480-8, 0x0101
800x600-8, 0x0103
640x480-16, 0x0111

Changed in linux:
importance: Medium → High
Revision history for this message
Dean Loros (autocrosser) wrote :

Thank You for changing the importance to High--is there any information you need that has not been supplied?

Revision history for this message
Bogdan Butnaru (bogdanb) wrote :

@captn: Thanks for reminding me; I actually put in an /etc/modprobe/uvesafb install scriptlet, so it's run automatically whenever uvesafb is loaded.

@everyone else:

On my machine (Dell Latitude D620 with intel 945GM video) I couldn't get uvesafb to start during the boot. The module got loaded, but dmesg had:
[ 2.170230] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
[ 2.170303] uvesafb: vbe_init() failed with -22
[ 2.170360] uvesafb: probe of uvesafb.0 failed with error -22

However, after the boot I could rmmod & modprobe it again, and it worked correctly. So I tried stepping through the init script (using "panic" between the steps), and tried modprobing it by hand. I noticed that it refuses to work unless it's started _after_ udev in init-premount. No idea why, but maybe this gives someone a hint where to look.

(If you just want a workaround, add an entry in /etc/initramfs-tools/scripts/init-premount that has "udev" as a prerequisite, and put something like "sleep 2; modprobe -r uvesafb; modprobe uvesafb" as the action. The sleep is to allow udev to fire its events. I found the -r needed because uvesafb is triggered earlier in by init process, and it just stands there looking silly...)

Revision history for this message
Martin Capitanio (capnm) wrote :

@Bogdan: Than someone should resurrect that package? I suppose ubuntu has to ride
the dead horse here about a 1/2 - 1 year (until the kernel mode setting driver arrives).

https://launchpad.net/ubuntu/hardy/+source/915resolution

Revision history for this message
Bogdan Butnaru (bogdanb) wrote :

Aye, captn! I already filed a bug on that :) bug #274442

Revision history for this message
Martin Capitanio (capnm) wrote :

Arrr ;-) Unfortunately the intel xorg driver doesn't seems to like it.

It causes sometimes overlay and opengl lockups. Generally the coexistence with any frame-buffer makes the opengl system more
unstable. Still in deep water here. (No wonder why without an intel network card you feel lucky these days...)

Revision history for this message
Shriramana Sharma (jamadagni) wrote :

Hello. Somehow motoplux's instructions did not work for me, but captn's on comment #47 above (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/246269/comments/47) did. Thank you captn!

dmesg shows me the following lines:

[ 23.179171] uvesafb: Intel Corporation, Intel(r)GM965/PM965/GL960 Graphics Controller, Hardware Version 0.0, OEM: Intel(r)GM965/PM965/GL960
Graphics Chip Accelerated VGA BIOS, VBE v3.0
[ 23.186806] uvesafb: VBIOS/hardware supports DDC2 transfers
[ 23.199090] uvesafb: monitor limits: vf = 60 Hz, hf = 49 kHz, clk = 69 MHz
[ 23.199244] uvesafb: scrolling: redraw
[ 23.253770] Console: switching to colour frame buffer device 100x37
[ 23.254707] uvesafb: framebuffer at 0x20000000, mapped to 0xe0600000, using 6144k, total 7616k
[ 23.254732] fb0: VESA VGA frame buffer device

I have installed: v86d 0.1.5-1ubuntu2 and linux-generic 2.6.27.4.4.

Revision history for this message
Shriramana Sharma (jamadagni) wrote :

Hello. Sorry for extra comment (should have included in previous), but I note that the framebuffer comes into effect only later, i.e. after first few kernel messages (as you can see, for first 23 seconds) pass. It is unlike the previous vga=792 functionality where right from the start, the framebuffer is ready. What do I have to do to achieve that previous functionality? Or is it designed to display like this only? Because it is "user mode" vesafb (if I read the meaning of the name uvesafb correctly).

Revision history for this message
denisius.sion (denisius-sion) wrote :

Still doesn't work:

[ 16.040648] uvesafb: NVIDIA Corporation, G86 Board - e416h01 , Chip Rev , OEM: NVIDIA, VBE v3.0
[ 16.284005] uvesafb: VBIOS/hardware doesn't support DDC transfers
[ 16.284074] uvesafb: no monitor limits have been set, default refresh rate will be used
[ 16.285459] uvesafb: scrolling: redraw
[ 16.285745] mtrr: type mismatch for fb000000,800000 old: write-back new: write-combining
[ 16.285827] mtrr: type mismatch for fb000000,400000 old: write-back new: write-combining
[ 16.285908] mtrr: type mismatch for fb000000,200000 old: write-back new: write-combining
[ 16.285989] mtrr: type mismatch for fb000000,100000 old: write-back new: write-combining
[ 16.286080] mtrr: type mismatch for fb000000,80000 old: write-back new: write-combining
[ 16.286172] mtrr: type mismatch for fb000000,40000 old: write-back new: write-combining
[ 16.286254] mtrr: type mismatch for fb000000,20000 old: write-back new: write-combining
[ 16.286345] mtrr: type mismatch for fb000000,10000 old: write-back new: write-combining
[ 16.286426] mtrr: type mismatch for fb000000,8000 old: write-back new: write-combining
[ 16.286506] mtrr: type mismatch for fb000000,4000 old: write-back new: write-combining
[ 16.286588] mtrr: type mismatch for fb000000,2000 old: write-back new: write-combining
[ 16.286669] mtrr: type mismatch for fb000000,1000 old: write-back new: write-combining
[ 16.286855] uvesafb: framebuffer at 0xfb000000, mapped to 0xffffc20010180000, using 13781k, total 14336k
[ 16.286938] fb0: VESA VGA frame buffer device

Revision history for this message
Jesper Larsen (knorr) wrote :

I got the uvesafb working by the descriptions above.
Although it gets loaded too late for usplash to function.
Seeing in dmesg it's only after 34 seconds the module is loaded.

How can I make it load earlier?

Revision history for this message
MartinCarlsen (martin-carlsen-deactivatedaccount) wrote :

Bug confirmed and the workaround fixed the problem. Thanks

Revision history for this message
D. Hugh Redelmeier (hugh-mimosa) wrote :

denisius.sion in #58 (probably 3 messages up, but I cannot tell until after I post) seems to have an MTRR problem.

This message means that the kernel is refusing to change the type of an MTRR as the driver is telling it to do:
[ 16.285745] mtrr: type mismatch for fb000000,800000 old: write-back new: write-combining

The problem is likely due to nested MTRRs. I bet you have 4GiB of RAM or more on your machine. Anyway, I think that you can ignore this problem for now: I expect the only effect to be reduced performance from uvesafb.

The same problem may or may come up when you run the X device driver. It may or may not be serious then. I don't know what nvidia driver you use nor do I know much about those drivers anyway.

The proprietary ATI X driver that I have refuses to run if it cannot adjust the MTRRs.

There are several workarounds for this nested MTRR problem (if, indeed, I have correctly identified the problem). One place to look is https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/224404

If I'm right, the MTRR problem is not really related to this particular bug report. Further MTRR discussion should be elsewhere.

Revision history for this message
chris_c (c-camacho) wrote :

when I chose a resolution of 1024x768-32 or even 1024x768 in /etc/modprobe.d/uvesafb
if got the -22 error

However after checking /sys/class/graphics/fb0/modes
notice this is NOT /sys/devices/platform/uvesafb.0/vbe_modes

I specified 1024x768p-60 which was in the list (/sys/class/graphics/fb0/modes)

everything now works!

Revision history for this message
Dean Loros (autocrosser) wrote :

Thank you chris_c!!!! That has FINALLY allowed me to partly fix a bug I've been fighting quite a while now....see: https://bugs.launchpad.net/ubuntu/+source/usplash/+bug/235662

I now can see my usplash for more that one time in a row--only problem is that "splash" is still broken (text below usplash)--I need to use "quiet splash" to have it work.........

nullack (nullack)
Changed in linux:
milestone: none → ubuntu-8.10
Revision history for this message
Gilles Teisseire (gilles-teisseire1) wrote :

Thank you captn!!
for this:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/246269/comments/47

It works on Asus M50VM-AS010C with resolution set to 1440*900.

No beep, and stripes, and such poor things...

Revision history for this message
Gerhard Radatz (gerhard-radatz) wrote :

I am afraid that captn's solution did not fully work for me:

The situation is not as bad as before (computer now boots without beeping and stripes, and I can use the X desktop now without problems), but:

-) The text on the console window is displaced about 1/2 of the screen width to the right and about 1/3 of the screen height to the bottom.
-) When I see the gnome login screen, switching to the console by pressing Ctrl-Alt-F1 only works once. When switching back to the X screen (Ctrl-Alt-F7) I again see the login screen, but: pressing Ctrl-Alt-F1 again fails. My screen turns black and switches off after a while, which apparently means there is no valid input signal anymore. (Ctrl-Alt-F7 again restores the X-screen, then).

Any ideas? I tried several resolution settings in the uvesafb config file, but none worked.
I am using an nvidia Quadro FX 4600 card, the native resolution of the monitor is 1280*1024 pixels.

Revision history for this message
ru7hl3ss (gods-proprietor) wrote :

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/246269/comments/47

Works for me with 1440x900 also. I am running the solution on a HP dv9500t. Thank you.

Revision history for this message
Chow Loong Jin (hyperair) wrote :

I noticed that someone mentioned the need for using 915resolution on Intel GPUs. However, I managed to get the solution working without 915resolution, using the Intel GMA965 GPU on a Lenovo Y410. What I did was this:
1. Install v86d
2. Add /etc/modprobe.d/uvesafb containing this line:
options uvesafb mode_option=1280x800-32 mtrr=3 scroll=ywrap
3. sudo depmod -a
4. sudo update-initramfs -u
5. Restart.

Something I noticed was that when either starting or resuming from hibernation from a cold boot, I get artefacts when usplash starts, then booting stalls, presumably because I didn't see the cryptsetup prompt and didn't key in the encryption key. However, if I try starting again (Alt+SysRq+B), then usplash works.

Revision history for this message
manysounds (manysounds) wrote :

I am assuming this is not fixed in beta release
attempting to "try ubuntu" not intstall
I got the "v86dhelper not installed or missing"
then the machine yells alot beepbeepbeepbeep and I shut it down to stop the noises

Revision history for this message
Colin Watson (cjwatson) wrote :

Ben says we don't need the initramfs-tools task on this bug; it'll be fixed in the kernel.

Changed in initramfs-tools:
status: New → Invalid
Revision history for this message
kseise (kevin-seise) wrote :

I just wanted to add the following-
I get the bug also
I didn't see anything wrong until I added my nvidia card into the system.

Is that normal?

Revision history for this message
Ben Collins (ben-collins) wrote :

Fixed with last kernel upload.

Changed in linux:
assignee: ubuntu-kernel-team → ben-collins
status: Triaged → Fix Released
Revision history for this message
Dean Loros (autocrosser) wrote :

I reversed all the mods suggested above & uninstalled v86d---my system now boots with a "quiet splash" as it should. I next tried to boot with "splash" instead of "quiet splash" to see the text below usplash. Boot-up with this mode is text-only, not usplash + text below--Shut-down/reboot works as expected---so there is still a regression somewhere.

Contact me if more info is needed.....

Revision history for this message
Ben Collins (ben-collins) wrote :

For completeness, kernel 2.6.27-7.11 enabled and made default the vesafb module, which is what we used in the past. To get the benefit, uninstall v86d.

Dean> If usplash doesn't work without quiet, that's a usplash bug. Please file a report there.

Revision history for this message
Dean Loros (autocrosser) wrote :

Thank you Ben--noted & acted upon.

Revision history for this message
Henrik Nilsen Omma (henrik) wrote :

Tested on a system with Intel 82G33, running 64-bit. Boots fine with vga=792. The bootsplash appears, but is a bit large and down to the right.

Revision history for this message
pietjepuk (pietjepuk72) wrote :

According to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/246269/comments/71 a fix was released.
1. I am however not sure, if it is fixed for 8.10 final only? RC of Kubuntu Live CD (kubuntu-8.10-rc-desktop-i386.iso) shows still shows the bug. The boot stalls for half a minute, but then continues. On completion of boot I observe no further effects.
2. You can't use any workaround if you use a live cd, and I am not sure whether you want to accept this behavior to remain on every live session you do.

Revision history for this message
Ivan Ivanoff (spammeroff) wrote :

I have made workaround mentioned above at first post. And it works with 1200x1600 resolution! At my Intel G45 with intel 2.4.1 driver on my Ubuntu Linux 8.10 box.

Revision history for this message
Ivan Ivanoff (spammeroff) wrote :

When I made kernel recompiling with PAE (for 64 Gb RAM), I lose the ability to use my uvesafb. Is it possible to enable uvesafb with PAE at the same time?

Revision history for this message
Chow Loong Jin (hyperair) wrote : Re: [Bug 246269] Re: Switched from vesafb to uvesafb, but uvesafb can't work without v86d

On Mon, 2009-02-02 at 20:32 +0000, Ivan Ivanoff wrote:
> When I made kernel recompiling with PAE (for 64 Gb RAM), I lose the
> ability to use my uvesafb. Is it possible to enable uvesafb with PAE at
> the same time?
>
I don't know, but this certainly isn't related to the bug. Perhaps you
should haed over to the forums, mailing list, or IRC to ask your
question.
--
Chow Loong Jin

tags: added: iso-testing
Revision history for this message
Christopher (soft-kristal) wrote :

I'm also getting the FATAL: error inserting vesafb, but it's not doing any harm other than slowing my boot time by several seconds.

12.10 on AMD 32 bit kernel 3.5.0-21.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.