Kernel 2.6.24 and UVesaFB

solstice · 2008-02-20 09:47:22

yes i use arch64 and it failed for me too

Last edited by solstice (2008-02-20 09:47:42)

lloeki · 2008-02-20 10:14:39

works on arch32. this seems to make sense.

ech0s7 · 2008-02-22 09:53:00

if i put uvesafb into initramfs this is the log:

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
uvesafb: protected mode interface info at c000:af46
uvesafb: pmi: set display start = c00cafd4, set palette = c00cb014
uvesafb: VBIOS/hardware supports DDC2 transfers
uvesafb: monitor limits: vf = 60 Hz, hf = 49 kHz, clk = 68 MHz
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000018
printing eip: c025b9c3 *pde = 00000000 
Oops: 0000 [#1] PREEMPT SMP 
Modules linked in: uvesafb ext3 jbd mbcache ide_disk piix ide_core ata_piix ata_generic libata
 
Pid: 40, comm: modprobe Not tainted (2.6.24-ARCH #1)
EIP: 0060:[<c025b9c3>] EFLAGS: 00010246 CPU: 0
EIP is at fb_try_mode+0x3/0x90
EAX: f7f79008 EBX: f7f79008 ECX: 00000010 EDX: f7f79000
ESI: 00000001 EDI: 00000000 EBP: 00000007 ESP: f7f95be0
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process modprobe (pid: 40, ti=f7f94000 task=f7f58ff0 task.ti=f7f94000)
Stack: f7f28f95 c025c488 00000008 00000000 00200200 f7f28f95 f7f79000 f7f79008 
       00000001 00000001 00000000 00000320 00000258 00000020 000003e8 00000001 
       00000000 00000000 00000000 00000246 22222222 22222222 22222222 f7c0dc00 
Call Trace:
 [<c025c488>] fb_find_mode+0x578/0x650
 [<f88388d0>] uvesafb_exec+0x130/0x260 [uvesafb]
 [<c018098b>] __kmalloc+0x2b/0x110
 [<f88398d2>] uvesafb_probe+0x772/0x1010 [uvesafb]
 [<c01252bb>] kunmap_atomic+0x8b/0xd0
 [<c012526d>] kunmap_atomic+0x3d/0xd0
 [<c0240cac>] idr_get_empty_slot+0xec/0x280
 [<c0240ebb>] ida_get_new_above+0x7b/0x180
 [<c01c7190>] sysfs_ilookup_test+0x0/0x10
 [<c01c7824>] sysfs_addrm_finish+0x14/0x1e0
 [<c01c7534>] sysfs_add_one+0x44/0xe0
 [<c01c760f>] sysfs_addrm_start+0x3f/0xb0
 [<c01c839d>] sysfs_create_link+0x8d/0x120
 [<c02acedc>] platform_drv_probe+0xc/0x10
 [<c02ab998>] driver_probe_device+0x88/0x190
 [<c036c39f>] klist_next+0x5f/0xc0
 [<c02aac44>] bus_for_each_drv+0x44/0x70
 [<c02abb5d>] device_attach+0x7d/0x90
 [<c02abaa0>] __device_attach+0x0/0x10
 [<c02aabb5>] bus_attach_device+0x45/0x90
 [<c02a9c78>] device_add+0x428/0x510
 [<c02ad279>] platform_device_add+0xf9/0x150
 [<f883a42f>] uvesafb_init+0x5f/0xb0 [uvesafb]
 [<c01522d6>] sys_init_module+0x126/0x19d0
 [<c02429ef>] prio_tree_insert+0x1f/0x240
 [<c01054e2>] sysenter_past_esp+0x6b/0xa1
 [<c0360000>] c_show+0x60/0xd0
 =======================
Code: 8d 42 d0 3c 09 76 04 89 d8 5b c3 0f be d2 83 c1 01 8d 04 9b 8d 5c 42 d0 eb e3 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 53 89 c3 <8b> 41 08 89 03 8b 41 0c 89 43 04 8b 41 08 89 43 08 8b 41 0c 83 
EIP: [<c025b9c3>] fb_try_mode+0x3/0x90 SS:ESP 0068:f7f95be0
---[ end trace c52da5e5d44148ff ]---

As you can seen, the error probably is caused from missing klibc compiled against 2.6.24. But klibc compiled against 2.6.24 doesn't boot! ( http://bugs.archlinux.org/task/9482#comment24956 )

brain0 · 2008-03-03 09:42:24

Just FYI, the testing repository has now updated klibc packages and a v86d package. I updated the instructions in the wiki. Basically, you only have to install v86d (make sure all klibc-* packages are up to date, if one of them is older, your setup will break), add v86d to your HOOKS in mkinitcpio.conf and adjust /etc/modprobe.d/uvesafb. Then regenerate your initramfs.

Roman had this working fine on i686, however I cannot get it working on x86_64 with Intel i945 graphics. I would be very interested in reports from more users.

Again, the required package versions:

klibc 1.5-5 (1.5-4 also works)
klibc-extras 2.3-2
klibc-module-init-tools 3.2.2-2
klibc-udev 116-3 (or later, an update to 118 is pending)
v86d 0.1.3-3

lloeki · 2008-03-03 11:11:35

so it modprobes uvesafb in the hook? one should then remove uvesafb from /etc/mkinitcpio.conf MODULES if it was there.

that said, from /etc/mkinitcpio.conf

# The following modules are loaded before any boot hooks are
# run.

having it in modules would allow to have it loaded a tad earlier.
also, having a hook named 'v86d' load uvesafb doesn't make much sense (although they are obviously tied)

Last edited by lloeki (2008-03-03 11:12:41)

brain0 · 2008-03-03 12:22:03

The hook adds the v86d binary to the initramfs, thus the name. In addition, it adds the /etc/modprobe.d/uvesafb file to set uvesafb options and adds a runtime-hook to modprobe the uvesafb module. I guess you can place the hook even before the udev hook, then it will make virtually no difference whether you place uvesafb in MODULES or not.

I was thinking about calling the hook uvesafb instead of v86d, but I didn't care that much.

The advantage with this method is, that you can easily disable uvesafb with 'disablehooks=v86d' on the kernel commandline.

Mikko777 · 2008-03-03 12:57:20

Well it seems to work but gave no new resolutions to play with and it even made the arch boot logo to go bye bye

(Should this give more resolutions or not?)

lloeki · 2008-03-03 13:19:28

hmm, just tried it. here it FAILS! (everything to latest testing)

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

as for loading it early,

HOOKS="base v86d keymap udev autodetect sata uresume filesystems"

that's what I was doing anyway in the first revisions of my AUR package.

The advantage with this method is, that you can easily disable uvesafb with 'disablehooks=v86d' on the kernel commandline.

good point. generally speaking I didn't know of that possibility!

brain0 · 2008-03-03 13:29:09

lloeki wrote:

hmm, just tried it. here it FAILS! (everything to latest testing)

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

That's not good news at all. Did this work with your own package? Did you remove all other things about v86d from mkinitcpio.conf (except the v86d hook)? Do you use i686?

Something seems wrong here with the i686 package, it doesn't seem to be linked against klibc, but statically instead. (EDIT: the glibc version is linked statically as well, something must have gone wrong in the build process)

Last edited by brain0 (2008-03-03 13:33:25)

lloeki · 2008-03-03 13:40:39

that's a 'yes' to all questions.

patroclo7 · 2008-03-03 15:28:29

It works fine here with an intel i915 on i686 (again combined with the 915resolution hook to patch the bios and get the native resolution of the widescreen, as I had suggested in the second part of the wiki article; this second part needs some fixes due to the chosen implementation of v86d, I promise to fix it soon).

patroclo7 · 2008-03-03 16:06:41

I have revised the wiki article, and created a 915resolution-static in the AUR, so that I have been able to remove all that longish and boring stuff I had written about the combination with uvesafb.

brain0 · 2008-03-03 21:34:06

lloeki wrote:

that's a 'yes' to all questions.

Weird, as it seems to work perfectly for other people. I have to rebuild the i686 version anyway, so stay tuned.

brain0 · 2008-03-03 21:37:04

patroclo7 wrote:

It works fine here with an intel i915 on i686 (again combined with the 915resolution hook to patch the bios and get the native resolution of the widescreen, as I had suggested in the second part of the wiki article; this second part needs some fixes due to the chosen implementation of v86d, I promise to fix it soon).

I tried uvesafb on a i945, but without the resolution hack (at normal 1024x768). It fails (blank screen, system freeze), while vesafb works fine. Does it work for you without the hack?

shining · 2008-03-03 22:08:23

lloeki wrote:

hmm, just tried it. here it FAILS! (everything to latest testing)
$ dmesg | grep uvesafb
uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
uvesafb: vbe_init() failed with -22
uvesafb: probe of uvesafb.0 failed with error -22
as for loading it early,

Arf, I have exactly the same error. At least I am not alone.
I was using a custom 2.6.25-rc3 kernel, because of some troubles with iwlwifi.

I switched back to arch stock kernel 2.6.24.3-1, and it worked perfectly!

I just built a custom 2.6.24.3 kernel, with a similar config than what I had on 2.6.25-rc3, and uvesafb still fails with same error. I tried a bunch of different framebuffer options, but it didn't change anything

I am on i686 btw. Are you using arch stock kernel?

lloeki · 2008-03-04 08:31:39

yes, stock.

besides, maybe not related, but klibc 1.5-5 breaks stuff: with klibc 1.5-3, I can start /bin/dash, and once upgraded, 'bash: /bin/dash: file not found'. but it is there, it has not moved (not a hash -r problem), and file /bin/dash and test -f /bin/dash ; echo $? work as they should. same behavior with zsh. downgrading klibc, and shazam! it works on the double.

so out of luck I tried testing/v86d+klibc 1.5-3, but it fails the same.

Last edited by lloeki (2008-03-04 08:32:34)

brain0 · 2008-03-04 10:47:28

lloeki wrote:

yes, stock.
besides, maybe not related, but klibc 1.5-5 breaks stuff: with klibc 1.5-3, I can start /bin/dash, and once upgraded, 'bash: /bin/dash: file not found'. but it is there, it has not moved (not a hash -r problem), and file /bin/dash and test -f /bin/dash ; echo $? work as they should. same behavior with zsh. downgrading klibc, and shazam! it works on the double.
so out of luck I tried testing/v86d+klibc 1.5-3, but it fails the same.

I didn't know there was a dash binary for klibc. If so, it has to be rebuilt. v86d cannot work with klibc 1.5-3 and can't be built against it.

patroclo7 · 2008-03-04 10:56:15

brain0 wrote:

I tried uvesafb on a i945, but without the resolution hack (at normal 1024x768). It fails (blank screen, system freeze), while vesafb works fine. Does it work for you without the hack?

Yes, my i915 works fine at 1024x768 without the hack.

lloeki · 2008-03-04 11:10:10

I didn't know there was a dash binary for klibc

I didn't know either. straight from the pkgbuild.

makedepends=('klibc>=1.5')

as for v86d supposedly not working with klibc-1.5-3, my AUR package just works with it... it seems I build it against glibc though, since I don't take any steps to build it against klibc.

Last edited by lloeki (2008-03-04 11:14:55)

lloeki · 2008-03-04 12:48:21

- rebuilt dash against new klibc => works

- updated v86d still fails on boot

$ pacman -Q |grep -e klibc -e v86d
klibc 1.5-5
klibc-extras 2.3-2
klibc-module-init-tools 3.2.2-2
klibc-udev 116-3
v86d 0.1.3-3.1

- this works though:

/sbin/v86d_klibc && rmmod uvesafb && modprobe uvesafb

Last edited by lloeki (2008-03-04 12:50:51)

brain0 · 2008-03-04 14:41:35

lloeki wrote:

- rebuilt dash against new klibc => works

dash was supposed to be built statically, which is now fixed in testing.

- updated v86d still fails on boot

$ pacman -Q |grep -e klibc -e v86d
klibc 1.5-5
klibc-extras 2.3-2
klibc-module-init-tools 3.2.2-2
klibc-udev 116-3
v86d 0.1.3-3.1

- this works though:

/sbin/v86d_klibc && rmmod uvesafb && modprobe uvesafb

That is weird, as it seems to work for others. I will have to try on my i686 machine tonight.

lloeki · 2008-03-04 15:18:23

just to be clear "- this works though:" was meant to be read "- once booted on runlevel 3/5 and logged in, this works though:"

thanks for the dash update.

Last edited by lloeki (2008-03-04 15:18:39)

shining · 2008-03-04 16:11:37

Hmm, well I made some progress with my custom kernels, but it still doesn't work.
I added udev and autodetect to the initcpio HOOKS, and it seemed to help since I get the same dmesg output now :

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
uvesafb: VBIOS/hardware doesn't support DDC transfers
uvesafb: no monitor limits have been set, default refresh rate will be used
uvesafb: scrolling: redraw
uvesafb: framebuffer at 0xe0000000, mapped to 0xf8900000, using 7872k, total 7872k

But with arch stock kernel, it also changes the resolution, while it doesn't with mine.
I configured /etc/modprobe.d/uvesafb which is added by the v86d hook, so it should work with all kernels. I don't get it.

shining · 2008-03-04 17:35:39

Well, I don't know if Gentoo is useful, but at least Gentoo Forums are.
I found the answer there :
http://forums.gentoo.org/viewtopic-p-47 … ml#4763330

<*> Framebuffer Console support
//I compiled it as a module, I guess what really was missing

Either Framebuffer Console must be built in, or fbcon module must be put in the initrd, otherwise it won't work

patroclo7 · 2008-03-04 20:40:45

Yes, you need Y on Framebuffer Console Support. Never tried to compile it as M and to put in the initramfs (the arch stock kernel has Y on it)

Arch Linux

#26 2008-02-20 09:47:22

Re: Kernel 2.6.24 and UVesaFB

#27 2008-02-20 10:14:39

Re: Kernel 2.6.24 and UVesaFB

#28 2008-02-22 09:53:00

Re: Kernel 2.6.24 and UVesaFB

#29 2008-03-03 09:42:24

Re: Kernel 2.6.24 and UVesaFB

#30 2008-03-03 11:11:35

Re: Kernel 2.6.24 and UVesaFB

#31 2008-03-03 12:22:03

Re: Kernel 2.6.24 and UVesaFB

#32 2008-03-03 12:57:20

Re: Kernel 2.6.24 and UVesaFB

#33 2008-03-03 13:19:28

Re: Kernel 2.6.24 and UVesaFB

#34 2008-03-03 13:29:09

Re: Kernel 2.6.24 and UVesaFB

#35 2008-03-03 13:40:39

Re: Kernel 2.6.24 and UVesaFB

#36 2008-03-03 15:28:29

Re: Kernel 2.6.24 and UVesaFB

#37 2008-03-03 16:06:41

Re: Kernel 2.6.24 and UVesaFB

#38 2008-03-03 21:34:06

Re: Kernel 2.6.24 and UVesaFB

#39 2008-03-03 21:37:04

Re: Kernel 2.6.24 and UVesaFB

#40 2008-03-03 22:08:23

Re: Kernel 2.6.24 and UVesaFB

#41 2008-03-04 08:31:39

Re: Kernel 2.6.24 and UVesaFB

#42 2008-03-04 10:47:28

Re: Kernel 2.6.24 and UVesaFB

#43 2008-03-04 10:56:15

Re: Kernel 2.6.24 and UVesaFB

#44 2008-03-04 11:10:10

Re: Kernel 2.6.24 and UVesaFB

#45 2008-03-04 12:48:21

Re: Kernel 2.6.24 and UVesaFB

#46 2008-03-04 14:41:35

Re: Kernel 2.6.24 and UVesaFB

#47 2008-03-04 15:18:23

Re: Kernel 2.6.24 and UVesaFB

#48 2008-03-04 16:11:37

Re: Kernel 2.6.24 and UVesaFB

#49 2008-03-04 17:35:39

Re: Kernel 2.6.24 and UVesaFB

#50 2008-03-04 20:40:45

Re: Kernel 2.6.24 and UVesaFB

Board footer