I compiled gentoo-source 2.6.23 on my Dell laptop (Precision M70) that comes with nVidia Quadro FX Go 1400 graphic card. (needless to say I followed by the letter instructions given on http://dev.gentoo.org/~spock/projects/uvesafb/) After booting, here is what dmesg | grep -i vesa gives: Kernel command line: root=/dev/sda8 video=uvesafb:1400x1050-16@60,ywrap,mtrr:3 uvesafb: Getting VBE info block failed (eax=0x4f00, err=0) uvesafb: vbe_init() failed with -22 uvesafb: probe of uvesafb.0 failed with error -22 I do have a process /sbin/v86d running. Someone on Gentoo forums mentioned a patch (see http://forums.gentoo.org/viewtopic-t-568721-postdays-0-postorder-asc-highlight-uvesafb+block-start-50.html) to v86d, I tried it, but it did not help. Reproducible: Always Note that I already had a very similar problem with vesafb-tng as reported in bug 178985 (which is the reason why I upgraded to kernel 2.6.23/uvesafb)
Compile this as a module...
Which version of v86d are you using? Try upgrading to 0.1.1 if you aren't already using it.
I had v86d version 0.1, I just emerged version 0.1.1: no change. Should I compiled uvesafb as a module? Why would it make a difference?
(In reply to comment #3) > Should I compiled uvesafb as a module? Why would it make a difference? No idea; it works as a module, never worked when compiled into kernel for me. (Note that you'll have to load uvesafb via /etc/modules.autoload.d/kernel-2.6 with resolution passed as an option, i.e. uvesafb mode=1024x768-32)
I tried your suggestion, but there is still no change: same error message in dmesg. uvseafb is correctly loaded, though (as well as three other modules: cfbcopyarea, cfbfillrect, cfbbitblt -- as far as I remember): so the configuration change is ok, it's just that uvesafb cannot cope with my card. (For what it's worth, grub correctly reports a VBE3-compliant card, so I guess it can somehow read this "vbe_info block")
I'm having the same error with a Radeon Mobility 9100 IGP, gentoo-sources-2.6.23 and v86d 0.1.1
My splash screen even my console stop to work for me with kernel 2.6.23 (gentoo-sources) my gru boot line is the following : kernel /boot/linux-2.6.23-gentoo root=/dev/hda3 udev video=vesafb:ywrap,mtrr,1280x800-32@60 splash=silent,theme:livecd-2007.0 console=tty1 but it are generating an error message on vd86 error -22 what could it be ? I'm using vesafb-tng, but my kernel config do not show me any way to configure it as I did in previous kernel versions
my mistake I'm using uvesafb, let me try to configure it properly to see if the errors keep happening
Could you please update to v86d-0.1.2 (merge it with the 'debug' USE flag enabled) and: - run vbetest and paste its output here - build uvesafb as a module, load it and attach your full kernel log (it should contain entries similar to these: [ 206.486390] v86d: task flags: 0x00 [ 206.486397] v86d: EAX=00004f02 EBX=00004161 ECX=00000000 EDX=00000000 [ 206.486402] v86d: ESP=00000000 EBP=00000000 ESI=00000000 EDI=00000000)
Created attachment 135194 [details] dmesg output
(In reply to comment #9) > - run vbetest and paste its output here Here it is: Can't get VESA info (vm86 failure)
(In reply to comment #11) > (In reply to comment #9) > > - run vbetest and paste its output here > > Here it is: > > Can't get VESA info (vm86 failure) I'm sorry, I meant: 'run testvbe', not 'run vbetest'. Can you please try it with testvbe instead? 'vbetest' is also helpful though :)
Created attachment 135263 [details] dmesg for Radeon Mobility 9100IGP Here's my dmesg, I didn't build uvesafb as a module, as I can't reboot right now
Created attachment 135264 [details] output of testvbe
(In reply to comment #13) > Created an attachment (id=135263) [edit] > dmesg for Radeon Mobility 9100IGP > > Here's my dmesg, I didn't build uvesafb as a module, as I can't reboot right > now Please try to do that when you have a chance -- since testvbe worked fine in your case, so should uvesafb when built as a module.
(In reply to comment #12) > I'm sorry, I meant: 'run testvbe', not 'run vbetest'. Can you please try it > with testvbe instead? > > 'vbetest' is also helpful though :) > Here is the result of testvbe: Getting VBE Info Block failed with eax = 4f00 Just in case, I also run the following at GRUB command prompt: > testvbe 1400x1050 Mode 0x578 is not supported > vbeprobe VBE version 3.0 Mode 0xffffff00 is not found or supported
Your right it worked when built as a module, however as I have a crypted root filesystem it would be nice to get it working when built in the kernel sometime. Anyway thanks for your help and your work :)
(In reply to comment #17) > Your right it worked when built as a module, however as I have a crypted root > filesystem it would be nice to get it working when built in the kernel > sometime. I don't know what sort of setup you're using right now, but I suggest you try putting v86d into an in-kernel initramfs using CONFIG_INITRAMFS_SOURCE, as described on http://dev.gentoo.org/~spock/projects/uvesafb/
Vincent, could you please try running `hwinfo --framebuffer`? (emerge hwinfo if you don't have it installed). Also, did the framebuffer ever work for you with vesafb-tng or vesafb? Does it work now with vesafb?
Michal, sorry for the delay, I've been busy lately... > Vincent, could you please try running `hwinfo --framebuffer`? # hwinfo --framebuffer 02: None 00.0: 11001 VESA Framebuffer [Created at bios.447] Unique ID: rdCR.JZtvLkCvJd6 Hardware Class: framebuffer Model: "NVIDIA nv42 Board - p242h0g " Vendor: "NVIDIA Corporation" Device: "nv42 Board - p242h0g " SubVendor: "NVIDIA" SubDevice: Revision: "Chip Rev" Memory Size: 256 MB Memory Range: 0xc0000000-0xcfffffff (rw) Mode 0x0300: 640x400 (+640), 8 bits Mode 0x0301: 640x480 (+640), 8 bits Mode 0x0303: 800x600 (+800), 8 bits Mode 0x0305: 1024x768 (+1024), 8 bits Mode 0x0307: 1280x1024 (+1280), 8 bits Mode 0x030e: 320x200 (+640), 16 bits Mode 0x030f: 320x200 (+1280), 24 bits Mode 0x0311: 640x480 (+1280), 16 bits Mode 0x0312: 640x480 (+2560), 24 bits Mode 0x0314: 800x600 (+1600), 16 bits Mode 0x0315: 800x600 (+3200), 24 bits Mode 0x0317: 1024x768 (+2048), 16 bits Mode 0x0318: 1024x768 (+4096), 24 bits Mode 0x031a: 1280x1024 (+2560), 16 bits Mode 0x031b: 1280x1024 (+5120), 24 bits Mode 0x0330: 320x200 (+320), 8 bits Mode 0x0331: 320x400 (+320), 8 bits Mode 0x0332: 320x400 (+640), 16 bits Mode 0x0333: 320x400 (+1280), 24 bits Mode 0x0334: 320x240 (+320), 8 bits Mode 0x0335: 320x240 (+640), 16 bits Mode 0x0336: 320x240 (+1280), 24 bits Mode 0x033d: 640x400 (+1280), 16 bits Mode 0x033e: 640x400 (+2560), 24 bits Mode 0x0347: 1400x1050 (+1400), 8 bits Mode 0x0348: 1400x1050 (+2800), 16 bits Config Status: cfg=new, avail=yes, need=no, active=unknown > > Also, did the framebuffer ever work for you with vesafb-tng or vesafb? What happened is: I had Gentoo with kernel 2.6.20 using vesafb-tng, and yes it worked perfectly (I had a resolution of 1400x1050 on my laptop). I wanted to try an other distribution, so removed Gentoo, was not satisfied with the result, and came back to Gentoo kernel 2.6.22 (and now 2.6.23): from then on, I could not have neither vesafb-tng, nor uvesafb working. > Does it work now with vesafb? I have never tried vesafb because I don't know what value to use as the mode parameter... (now that I see the result of hwinfo, I wonder if 0x0348 would be a correct value?)
(In reply to comment #20) > What happened is: I had Gentoo with kernel 2.6.20 using vesafb-tng, and yes it > worked perfectly (I had a resolution of 1400x1050 on my laptop). I wanted to > try an other distribution, so removed Gentoo, was not satisfied with the > result, and came back to Gentoo kernel 2.6.22 (and now 2.6.23): from then on, > could not have neither vesafb-tng, nor uvesafb working. Sounds like a punishment for straying from the One True Way (TM) ;) Seriously though, it looks like a weird regression.. > I have never tried vesafb because I don't know what value to use as the mode > parameter... > (now that I see the result of hwinfo, I wonder if 0x0348 would be a correct > value?) It would. Please try it and let us know whether it works.
(In reply to comment #21) > Sounds like a punishment for straying from the One True Way (TM) ;) I won't do it again, I promise :-) Anyway, I did try old vesafb with mode 0x0348 and... it works. So right now, I think I will stick to this setup and I will give a try to uvesafb when it is part of the kernel (2.6.24, right?).
(In reply to comment #22) > Anyway, I did try old vesafb with mode 0x0348 and... it works. > So right now, I think I will stick to this setup and I will give a try to > uvesafb when it is part of the kernel (2.6.24, right?). Yup, but it won't change anything. The problem is actually somewhere in userspace (v86d), not in the driver itself. One more thing that could be worth trying: - untar the v86d-0.1.3.tar.bz2 archive somewhere - configure it with: ./configure --with-x86emu --with-debug - build it: make KDIR=/usr/src/linux - run: ./testvbe This will make v86d and testvbe use a different backend (x86emu, as opposed to LRMI, which clearly does not work in your case (vbetest fails)).
Created attachment 139220 [details] output of testvbe I have the same issues also so I followed the instructions from comment #23 and only then did testvbe actually work. Attached is the output of that test. My video card is a Nvidia GeForce 8800 GTS
Created attachment 139321 [details] dmesg attachment
just to keep the bug current: building uvesafb as a module and building v86d with --with-x86emu worked for my system.
Reopening due to new info being available.
I've just added the 'x86emu' USE flag to v86d. Since this provides a fix for the described problem, I'm closing the bug. If uvesafb doesn't work for you even after v86d is compiled with the x86emu backend, feel free to reopen.
To everyone involved: thanks for patiently running different tests and helping us find a solution.
Eh, hate to spoil the party here, but this thing plain never works if compiled into kernel, *only* as a module. USE=x86emu doesn't make any difference whatsover. :/
Hi, I have the same problem as Vincent on my old Acer Travelmate 660. The graphic card is an intel 855MG. I have tested uvesafb compiled in the kernel, and as module. vesafb used to work, but only with a resolution of 1280x1024. The screen does 1400x1050, so I get black borders or interpolation. /sbin/v86d is running. x86emu USE flag doesn't make any difference. dmesg says (v86d with debug USE flag): v86d: The mode list is in the buffer at 00012140. uvesafb: Intel Corporation, Intel(r)852MG/852MGE/855MG/855MGE Graphics Controller, Hardware Version 0.0, OEM: Intel(r)852MG/852MGE/855MG/855MGE Graphics Chip Accelerated VGA BIOS, VBE v3.0 v86d: task flags: 0x0a v86d: EAX=00004f01 EBX=00000000 ECX=00000136 EDX=00000000 v86d: ESP=00000000 EBP=00000000 ESI=00000000 EDI=00000000 uvesafb: Getting mode info block for mode 0x136 failed (eax=0x14f, err=0) uvesafb: vbe_init() failed with -22 uvesafb: probe of uvesafb.0 failed with error -22 testvbe says: VBE Version: 3.00 OEM String: Intel(r)852MG/852MGE/855MG/855MGE Graphics Chip Accelerated VGA BIOS OEM Vendor Name: Intel Corporation OEM Prod. Name: Intel(r)852MG/852MGE/855MG/855MGE Graphics Controller OEM Prod. Rev: Hardware Version 0.0 ID attr mode --------------------------- Getting Mode Info Block for mode 0136 failed with eax = 014f hwinfo --framebuffer says: 02: None 00.0: 11001 VESA Framebuffer [Created at bios.447] Unique ID: rdCR.xo6eU3vGDUC Hardware Class: framebuffer Model: "Intel(r)852MG/852MGE/855MG/855MGE Graphics Chip Accelerated VGA BIOS Intel(r)852MG/852MGE/855MG/855MGE Graphics Controller" Vendor: "Intel Corporation" Device: "Intel(r)852MG/852MGE/855MG/855MGE Graphics Controller" SubVendor: "Intel(r)852MG/852MGE/855MG/855MGE Graphics Chip Accelerated VGA BIOS" SubDevice: Revision: "Hardware Version 0.0" Memory Size: 31 MB + 832 kB Memory Range: 0xe8000000-0xe9fcffff (rw) Mode 0x033c: 1400x1050 (+1400), 8 bits (*) Mode 0x034d: 1400x1050 (+2800), 16 bits (*) Mode 0x035c: 1400x1050 (+5600), 24 bits (*) Mode 0x0307: 1280x1024 (+1280), 8 bits Mode 0x031a: 1280x1024 (+2560), 16 bits Mode 0x031b: 1280x1024 (+5120), 24 bits Mode 0x0305: 1024x768 (+1024), 8 bits Mode 0x0317: 1024x768 (+2048), 16 bits Mode 0x0318: 1024x768 (+4096), 24 bits Mode 0x0312: 640x480 (+2560), 24 bits Mode 0x0314: 800x600 (+1600), 16 bits Mode 0x0315: 800x600 (+3200), 24 bits Mode 0x0301: 640x480 (+640), 8 bits Mode 0x0303: 800x600 (+800), 8 bits Mode 0x0311: 640x480 (+1280), 16 bits Config Status: cfg=new, avail=yes, need=no, active=unknown lines with the (*) are listed after running 915resolution
Hi, I'm also getting this problem. The error's the same as Spitzer's. Compiling with x86emu and using 'testvbe' also fails. I have an Intel 855GM integrated graphics card in my laptop (pentium-m processor). Before, Spock's vesafb-tng worked for me, and since upgrading to the 2.6.23 gentoo kernel, I've been unable to get uvesafb working - or more specifically, v86d. I tried the instructions on Comment 23, but as I said above, testvbe fails. It's output is: v86d-0.1.3 # ./testvbe VBE Version: 3.00 OEM String: Intel(r)852MG/852MGE/855MG/855MGE Graphics Chip Accelerated VGA BIOS OEM Vendor Name: Intel Corporation OEM Prod. Name: Intel(r)852MG/852MGE/855MG/855MGE Graphics Controller OEM Prod. Rev: Hardware Version 0.0 ID attr mode --------------------------- Getting Mode Info Block for mode 0136 failed with eax = 014f Issuing a 'dmesg | grep v86d' gives me nothing, but issuing a 'dmesg | grep uvesafb' gives me: uvesafb: Intel Corporation, Intel(r)852MG/852MGE/855MG/855MGE Graphics Controller, Hardware Version 0.0, OEM: Intel(r)852MG/852MGE/855MG/855MGE Graphics Chip Accelerated VGA BIOS, VBE v3.0 uvesafb: Getting mode info block for mode 0x136 failed (eax=0x14f, err=0) uvesafb: vbe_init() failed with -22 uvesafb: probe of uvesafb.0 failed with error -22 Finally, my 'hwinfo --framebuffer' displays: 02: None 00.0: 11001 VESA Framebuffer [Created at bios.447] Unique ID: rdCR.xo6eU3vGDUC Hardware Class: framebuffer Model: "Intel(r)852MG/852MGE/855MG/855MGE Graphics Chip Accelerated VGA BIOS Intel(r)852MG/852MGE/855MG/855MGE Graphics Controller" Vendor: "Intel Corporation" Device: "Intel(r)852MG/852MGE/855MG/855MGE Graphics Controller" SubVendor: "Intel(r)852MG/852MGE/855MG/855MGE Graphics Chip Accelerated VGA BIOS" SubDevice: Revision: "Hardware Version 0.0" Memory Size: 7 MB + 832 kB Memory Range: 0xe8000000-0xe87cffff (rw) Mode 0x0305: 1024x768 (+1024), 8 bits Mode 0x0317: 1024x768 (+2048), 16 bits Mode 0x0318: 1024x768 (+4096), 24 bits Mode 0x0312: 640x480 (+2560), 24 bits Mode 0x0314: 800x600 (+1600), 16 bits Mode 0x0315: 800x600 (+3200), 24 bits Mode 0x0301: 640x480 (+640), 8 bits Mode 0x0303: 800x600 (+800), 8 bits Mode 0x0311: 640x480 (+1280), 16 bits Config Status: cfg=new, avail=yes, need=no, active=unknown I am not using 915resolution. I hope I can help in any way possible solving this. Sam
just wanted to confirm, that uvesafb is not working when compiled into kernel but works fine as module $ dmesg | grep -i vesa uvesafb: NVIDIA Corporation, NV34 Board - p136nz , Chip Rev , OEM: NVIDIA, VBE v3.0 uvesafb: protected mode interface info at c000:e3c0 uvesafb: pmi: set display start = c00ce3f6, set palette = c00ce460 uvesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da uvesafb: VBIOS/hardware doesn't support DDC transfers uvesafb: no monitor limits have been set, default refresh rate will be used uvesafb: scrolling: ypan using protected mode interface, yres_virtual=3744 uvesafb: framebuffer at 0xd0000000, mapped to 0xf1a00000, using 10240k, total 32768k fb0: VESA VGA frame buffer device
I've tried compiling uvesafb as a module, and I get the same error as I announced above. Could it be Intel video card specific? Sam
Hi, DeJe posted a possible hint in the forums: http://forums.gentoo.org/viewtopic-p-4888883.html#4888883 He has the same Notebook as I have.
Hi, with kernel-2.6.25-r2, i compiled uvesfb into kernel. First, i I was getting the same errors described here, then I added support for initramfs, and included (i use splash) all files into initramfs image, that are in file /usr/share/v86d/initramfs. If you don't use splash, then according to spock's instructions just use /usr/share/v86d/initramfs (emerge v86d first) in Initramfs source file (that's CONFIG_INITRAMFS_SOURCE="/usr/share/v86d/initramfs"). Didnt' try the second, though. Including those files solved my problem, the uvesafb driver works without problem. Of course - YMMV.
Hello Spock, I have got a similar problem with the uvesafb module and an ATI X800 PCIE card. I have used the kernels 2.6.25.3 and 2.6.26-rc2 for the test. I don't have any problem with an ATI R3870 card. uvesafb is loaded at the very early boot process from an initramfs filesystem. /sys and /proc are loaded later. (All the modules needed are loaded as module as stated in the following error messages as well as the /sbin/v86d "userspace" daemon). The option pasted to uvesafb are, options uvesafb mode=1400x1050R-32@60 options uvesafb scroll=ywrap pmipal=1 nocrtc mtrr=3 (w/o noedid) although the real display size is 1680x1280 and switched to that resolution if uvesafb is called with the 1400x1050 mode (the test was made on an other computer that works well with uvesafb). The error returned is, kernel: Console: colour VGA+ 80x25 kernel: Calibrating delay using timer specific routine.. 4031.22 BogoMIPS (lpj=2015614) kernel: Mount-cache hash table entries: 256 kernel: CPU: AMD Athlon(tm) 64 Processor 3200+ stepping 02 kernel: ACPI: RTC can wake from S4 kernel: Total HugeTLB memory allocated, 0 kernel: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) kernel: assign_interrupt_mode Found MSI capability kernel: assign_interrupt_mode Found MSI capability kernel: assign_interrupt_mode Found MSI capability kernel: assign_interrupt_mode Found MSI capability kernel: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp kernel: registered taskstats version 1 kernel: PGD 8063 PUD 0 kernel: CPU 0 kernel: Modules linked in: uvesafb(+) cn fbcon crc32 font bitblit fbcon_rotate fbcon_ccw fbcon_cw fbcon_ud softcursor fb cfbfillrect cfbimgblt cfbcopyarea i2c_nforce2 i2c_algo_bit i2c_dev i2c_core kernel: Pid: 476, comm: insmod Not tainted 2.6.26-rc2 #6 kernel: RIP: 0010:[<ffffffff810f576d>] [<ffffffff810f576d>] strnlen+0x14/0x1e kernel: RSP: 0018:ffff81007e0af8a8 EFLAGS: 00010082 kernel: RAX: ffff81017fb2f37b RBX: ffff81007e0af9c8 RCX: ffff81007e0af9f0 kernel: RDX: ffffffffa004a873 RSI: fffffffffffffffe RDI: ffff81017fb2f37b kernel: RBP: ffff81007e0af8a8 R08: ffff81007e0ae000 R09: 00000000ffffffff kernel: R10: ffffffffa004a843 R11: ffffffff81780aa0 R12: ffffffff817806a0 kernel: R13: ffff81017fb2f37b R14: 0000000000000000 R15: 00000000ffffffff kernel: FS: 0000000000000000(0000) GS:ffffffff812f4000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b kernel: CR2: ffff81017fb2f37b CR3: 000000007e0e8000 CR4: 00000000000006e0 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 kernel: Process insmod (pid: 476, threadinfo ffff81007e0ae000, task ffff81007e788000) kernel: Stack: ffff81007e0af908 ffffffff810f687b ffff81007e1be900 ffffffff81780aa0 kernel: ffffffffa004a843 0000000000000400 ffffffff817806a0 0000000000000400 kernel: ffff81007e0af9c8 ffffffffa004a842 ffff81007f999c10 00000000fffffff4 kernel: Call Trace: kernel: [<ffffffff810f687b>] vsnprintf+0x2d2/0x560 kernel: [<ffffffff810f6c68>] vscnprintf+0x11/0x21 kernel: [<ffffffff8102ac0f>] vprintk+0x107/0x2bf kernel: [<ffffffff811d1a12>] ? schedule_timeout+0xa6/0xc2 kernel: [<ffffffff810331b2>] ? process_timeout+0x0/0xb kernel: [<ffffffffa0048a4e>] ? :uvesafb:uvesafb_exec+0x282/0x293 kernel: [<ffffffffa0049684>] ? :uvesafb:uvesafb_probe+0x119/0xe72 kernel: [<ffffffff810f1b3f>] ? ida_get_new_above+0x119/0x1d2 kernel: [<ffffffff810cb8e4>] ? sysfs_ilookup_test+0x0/0x14 kernel: [<ffffffff810cbf6c>] ? sysfs_addrm_finish+0x20/0x276 kernel: [<ffffffff810cbac3>] ? sysfs_find_dirent+0x1c/0x31 kernel: [<ffffffff810ccb42>] ? sysfs_create_link+0xde/0x12c kernel: [<ffffffff8114cf60>] ? platform_drv_probe+0x12/0x14 kernel: [<ffffffff8114c37a>] ? driver_probe_device+0xbf/0x16c kernel: [<ffffffff8114c4a0>] ? __device_attach+0x0/0xb kernel: [<ffffffff8114c4a9>] ? __device_attach+0x9/0xb kernel: [<ffffffff8114b8e3>] ? bus_for_each_drv+0x51/0x88 kernel: [<ffffffff8114c533>] ? device_attach+0x64/0x79 kernel: [<ffffffff8114b721>] ? bus_attach_device+0x28/0x59 kernel: [<ffffffff8114a6ae>] ? device_add+0x31a/0x4b3 kernel: [<ffffffff8114d381>] ? platform_device_add+0x10e/0x14a kernel: [<ffffffffa004a443>] ? :uvesafb:uvesafb_init+0x66/0xbe kernel: [<ffffffff8104d105>] ? sys_init_module+0x1799/0x18e4 kernel: [<ffffffff8102fb91>] ? __request_region+0x0/0x106 kernel: [<ffffffff8100bfcb>] ? system_call_after_swapgs+0x7b/0x80 kernel: kernel: kernel: RSP <ffff81007e0af8a8> kernel: ---[ end trace 72fe63374f68c18b ]--- kernel: Driver 'sd' needs updating - please use bus_type methods kernel: ACPI: PCI Interrupt Link [APSI] enabled at IRQ 23 kernel: ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 22 kernel: ACPI: PCI Interrupt Link [APCL] enabled at IRQ 21 kernel: ACPI: PCI Interrupt Link [APCF] enabled at IRQ 20 kernel: ACPI: PCI Interrupt Link [APCH] enabled at IRQ 23 kernel: ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 22 I believe it is an incompability specific to the X800 family card (although the complain about strnlen puzzles me). I'm a bit tired to patch ever and ever the kernel radeonfb driver to make it compatible with that card so I hope you will find what is going on ;) Thx
Sorry, typo. Read 1680x1050 instead of 1680x1280.
This also happens to 2 of my laptops, one is a savage chipset, one is an nvidia chipset. This also only started happening when I've compiled the kernels with gcc 4.3.x (the savage chipset is using 4.3, the nvidia chipset is using 4.3.1)
(In reply to comment #39) > This also happens to 2 of my laptops, one is a savage chipset, one is an nvidia > chipset. This also only started happening when I've compiled the kernels with > gcc 4.3.x (the savage chipset is using 4.3, the nvidia chipset is using 4.3.1) Could you please check whether compiling v86d with a different version of GCC or a different set of USE flags (+/-x86emu; this only matters if you're using x86) affects the problem in any way?
(In reply to comment #40) > Could you please check whether compiling v86d with a different version of GCC > or a different set of USE flags (+/-x86emu; this only matters if you're using > x86) affects the problem in any way? > It worked before the upgrade to gcc 4.3.1 - enabling x86emu allows it to work on the nvidia card, however, unfortunately I cannot test on the savage chipset laptop anymore due to it keeps overheating whenever I attempt to compile anything on it. As soon as I get a new heatsink for it, I will let you know.
I can confirm that compiling v86d with gcc4.1.2 fixed it with my radeon mobility IGP. Where as building v86d with gcc4.3 produced the VBE info block failed. I have never had these issues with any of my 6 nvidia card boxes, with uvesafb built-in the kernel. Building uvesafb in the kernel now that I have actually seen uvesafb work with this one.
ok confirmed it works even better built-in the kernel now when having v86d compiled with gcc-4.1.2. 01:05.0 VGA compatible controller: ATI Technologies Inc RS300M AGP [Radeon Mobility 9100IGP] zcat /proc/config.gz|grep UVESA CONFIG_FB_UVESA=y # dmesg |grep uvesa uvesafb: ATI Technologies Inc., MC3 , 01.00, OEM: ATI RC300M, VBE v2.0 uvesafb: protected mode interface info at c000:5259 uvesafb: pmi: set display start = c00c52c7, set palette = c00c5301 uvesafb: pmi: ports = 9010 9016 9054 9038 903c 905c 9000 9004 90b0 90b2 90b4 uvesafb: no monitor limits have been set, default refresh rate will be used uvesafb: scrolling: ywrap using protected mode interface, yres_virtual=3750 uvesafb: framebuffer at 0xe0000000, mapped to 0xf8880000, using 15000k, total 131072k # eix v86d [I] sys-apps/v86d Available versions: 0.1.3 0.1.3-r1 (~)0.1.4 (~)0.1.5 {debug x86emu} Installed versions: 0.1.5(11:57:08 PM 06/23/2008)(x86emu -debug) # emerge --info Portage 2.2_rc1 (default/linux/x86/2008.0/desktop, gcc-4.3.1, glibc-2.8_p20080602-r0, 2.6.25-tuxonice-r5 i686) ================================================================= System uname: Linux-2.6.25-tuxonice-r5-i686-Mobile_Intel-R-_Pentium-R-_4_CPU_2.80GHz-with-glibc2.0 Timestamp of tree: Sun, 22 Jun 2008 01:15:01 +0000 app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.4.4-r6, 2.5.2-r4 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.2.5 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.62 sys-devel/automake: 1.7.9-r1, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 2.2.4 virtual/os-headers: 2.6.25-r4 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks parallel-fetch preserve-libs sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://gentoo.cites.uiuc.edu/pub/gentoo/ http://open-systems.ufl.edu/mirrors/gentoo http://mirrors.acm.cs.rpi.edu/gentoo/" LANG="en_US.utf8" LDFLAGS="" LINGUAS="en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac accessibility acl acpi adns aiglx aim alsa apache2 arts audiofile avahi bash-completion bcmath berkdb bidi bindinst bluetooth branding browserplugin bzip2 cairo calendar caps cdr cli cracklib crypt cups curlwrappers dbus dedicated dga dio divx divx4linux dlloader dri dts dvd dvdr dvdread eds emacs emacs-w3 emboss emerald encode erandom escreen esd ethereal etwin evo examples expat fam fastcgi fbcon fbcondecor fbsplash ffmpeg firefox font fortran ftp gd gdbm gif glitz glut gnusetup gnutls gpm gs gstreamer gtk gtkhtml hal hardened iconv imap immqt-bc inifile innodb ipod ipv6 isdnlog ithreads java javascript jp2 jpeg jpeg2k kde kerberos krb4 ldap libcaca libclamv libffi libnotify live lm_sensors lzo mad maildir mailwrapper midi mikmod milter mime ming mmap mmx modplug mono motif mozbranding mp3 mp4 mpeg mpi msn mudflap musicbrainz ncurses nls nptl nptlonly nsplugin nvidia oav objc ogg opengl openmp oracle oscar oss pam pcre pdf perl pic png portaudio posix ppds pppd python qt3 qt3support qt4 quicktime readline real realmedia reflection samba sdl session shared spell spl sqlite sse ssl startup-notification svg symlink tcltktcpd tcpd test threads tiff truetype type1 unicode urandom usb usepackagedmakefiles userlocales vcd vhosts videos vorbis win32codecs wma wmf wxwindows x86 xcomposite xinerama xml xorg xpm xprint xrandr xulrunner xv xvid xvmc yahoo zeroconf zlib" ALSA_CARDS="atiixp" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard evdev mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="vga radeon fglrx vesa" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I compiled uvesafb as a module and during modprobe it came up with an error I haven't seen before (1st line): Jul 1 07:20:37 [kernel] [36074.845447] v86d: Trying to access an unsupported memory region at 4403 Jul 1 07:20:37 [kernel] [36074.851136] v86d[24678]: segfault at 0 ip 400ce3 sp 7fffc3a93ee0 error 4 in v86d[400000+15000] Jul 1 07:20:41 [kernel] [36079.778727] uvesafb: Getting VBE info block failed (eax=0x4f00, err=1) Jul 1 07:20:41 [kernel] [36079.778733] uvesafb: vbe_init() failed with -22 Jul 1 07:20:41 [kernel] [36079.778749] uvesafb: probe of uvesafb.0 failed with error -22
(In reply to comment #44) > I compiled uvesafb as a module and during modprobe it came up with an error I > haven't seen before (1st line): Which version of v86d are you using? Could you please upgrade to the latest one and check again (if you aren't using it already)? Everyone for whom v86d used to work with older gcc: could you please try to upgrade to klibc-1.5.12-r1, upgrade to the latest version of v86d and see whether this changes anything?
(In reply to comment #45) > Everyone for whom v86d used to work with older gcc: could you please try to > upgrade to klibc-1.5.12-r1, upgrade to the latest version of v86d and see > whether this changes anything? > As mentioned to you on IRC - this did infact work for me, though I haven't tried on the japanese laptop, but I am fairly certain it will.
(In reply to comment #45) > Everyone for whom v86d used to work with older gcc: could you please try to > upgrade to klibc-1.5.12-r1, upgrade to the latest version of v86d and see > whether this changes anything? Had the same problem with gentoo-sources 2.6.26-r1. Upgrading to klibc-1.5.12-r1 and v86d-0.1.8 solved the problem.
The recent comments seem to indicate that the problem might be fixed in the latest available versions of v86d and klibc. If it still breaks for you, feel free to reopen the bug, __but only if you are experiencing exactly the same problem as the one mentioned in the summary (i.e. Getting VBE info block failed)__. If the error message is different, open a new bug.
Hi, I still get segfaults, now even with testvbe. My current setup: sys-apps/v86d-0.1.9 +debug +x86emu gentoo-sources-2.6.25-r8 dev-libs/klibc-1.5.12-r1 (x11-drivers/xf86-video-intel-2.4.2-r3) dmesg after testvbe: EBDA at 9f800-9ffff VBIOS at c0000-ccdff task flags: 0x01 EAX=0x00004f00 EBX=0x00000000 ECX=0x00000000 EDX=0x00000000 ESP=0x00000000 EBP=0x00000000 ESI=0x00000000 EDI=0x00000000 testvbe[8823]: segfault at b7f242c1 ip 08048971 sp bfb6df10 error 7 in testvbe[8048000+21000] dmesg after modprobe uvesafb returns something equal: v86d: EBDA at 9f800-9ffff v86d: VBIOS at c0000-ccdff v86d: EBDA at 9f800-9ffff v86d: VBIOS at c0000-ccdff v86d: task flags: 0x01 v86d: EAX=0x00004f00 EBX=0x00000000 ECX=0x00000000 EDX=0x00000000 v86d: ESP=0x00000000 EBP=0x00000000 ESI=0x00000000 EDI=0x00000000 v86d[8981]: segfault at b7f1f2c1 ip 08048971 sp bfa667d0 error 7 in v86d[8048000+21000] uvesafb: Getting VBE info block failed (eax=0x4f00, err=1) uvesafb: vbe_init() failed with -22 uvesafb: probe of uvesafb.0 failed with error -2 the strange thing is that testvbe used to work, as can be seen in my previous posts what's wrong?
(In reply to comment #49) > the strange thing is that testvbe used to work, as can be seen in my previous > posts Could you please check what is the latest version of v86d which installs a working testvbe program?
the only other version besides 0.1.9 is 0.1.3-r1. testvbe is working with 0.1.3-r1: VBE Version: 3.00 OEM String: Intel(r)852MG/852MGE/855MG/855MGE Graphics Chip Accelerated VGA BIOS OEM Vendor Name: Intel Corporation OEM Prod. Name: Intel(r)852MG/852MGE/855MG/855MGE Graphics Controller OEM Prod. Rev: Hardware Version 0.0 ID attr mode --------------------------- Getting Mode Info Block for mode 0136 failed with eax = 014f does the following help (from dmesg) ? uvesafb: Intel Corporation, Intel(r)852MG/852MGE/855MG/855MGE Graphics Controller, Hardware Version 0.0, OEM: Intel(r)852MG/852MGE/855MG/855MGE Graphics Chip Accelerated VGA BIOS, VBE v3.0 v86d: task flags: 0x0a v86d: EAX=00004f01 EBX=00000000 ECX=00000136 EDX=00000000 v86d: ESP=00000000 EBP=00000000 ESI=00000000 EDI=00000000 uvesafb: Getting mode info block for mode 0x136 failed (eax=0x14f, err=0) uvesafb: vbe_init() failed with -22 uvesafb: probe of uvesafb.0 failed with error -22 task flags: 0x01 EAX=00004f00 EBX=00000000 ECX=00000000 EDX=00000000 ESP=00000000 EBP=00000000 ESI=00000000 EDI=00000000 The mode list is in the buffer at 00012140. task flags: 0x0a EAX=00004f01 EBX=00000000 ECX=00000136 EDX=00000000 ESP=00000000 EBP=00000000 ESI=00000000 EDI=00000000
Hi, I tried the other v86d versions from your archive. Version 0.1.8 segfaults too. Version 0.1.7 has a working testvbe: VBE Version: 3.00 OEM String: Intel(r)852MG/852MGE/855MG/855MGE Graphics Chip Accelerated VGA BIOS OEM Vendor Name: Intel Corporation OEM Prod. Name: Intel(r)852MG/852MGE/855MG/855MGE Graphics Controller OEM Prod. Rev: Hardware Version 0.0 ID attr mode --------------------------- Getting Mode Info Block for mode 0136 failed with eax = 0010 Versions 0.1.6 and 0.1.5.2 work too, but with another eax: Getting Mode Info Block for mode 0136 failed with eax = 014f Are the other versions interesting too?
(In reply to comment #52) What exactly happens when you run testvbe from v86d-0.1.9? Does it segfault right after it is run, or do you see the VBE version and OEM strings and it segfaults afterwards?
(In reply to comment #53) It segfaults right after it is run. I don't see the VBE version or anything else. Just the german translation for segfault. And it doesn't matter if I use x86emu or not.
Created attachment 170403 [details, diff] A patch removing PROT_EXEC for the memory maps. Could you please try to apply this patch in reverse to the v86d-0.1.8 source, build it with the x86emu backend and see whether testvbe works? If you want to modify the v86d ebuild to apply the patch, you can do `export EPATCH_OPTS="-R"` before calling epatch.
your patch works: v86d-0.1.8 $ ./testvbe Passwort: VBE Version: 3.00 OEM String: Intel(r)852MG/852MGE/855MG/855MGE Graphics Chip Accelerated VGA BIOS OEM Vendor Name: Intel Corporation OEM Prod. Name: Intel(r)852MG/852MGE/855MG/855MGE Graphics Controller OEM Prod. Rev: Hardware Version 0.0 ID attr mode --------------------------- Getting Mode Info Block for mode 0136 failed with eax = 014f but the Info Block error still remains
(In reply to comment #56) > your patch works: > > v86d-0.1.8 $ ./testvbe > Passwort: > VBE Version: 3.00 > OEM String: Intel(r)852MG/852MGE/855MG/855MGE Graphics Chip Accelerated > VGA BIOS > OEM Vendor Name: Intel Corporation > OEM Prod. Name: Intel(r)852MG/852MGE/855MG/855MGE Graphics Controller > OEM Prod. Rev: Hardware Version 0.0 > > ID attr mode > --------------------------- > Getting Mode Info Block for mode 0136 failed with eax = 014f > > but the Info Block error still remains Interesting.. Could you please open a new bug for this issue? This is actually different from what this bug was originally about (VBE info block != mode info block), and I don't think we need to keep spamming all the people CCed on this bug.
