Latest working kernel version: N/A Earliest failing kernel version: always Distribution: gentoo Hardware Environment: amd64 x86_64, ASUS A8N-SLI ACPI BIOS Revision 1014 + X800 R423 5F57 Software Environment: no binary modules loaded Problem Description: uvesafb: <1>BUG: unable to handle kernel paging request at ffff88017f9cf323 Steps to reproduce:
Created attachment 18075 [details] dmesg
# v86d EBDA at 9f800-9ffff VBIOS at c0000-ce3ff # cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0xc0000000 (3072MB), size= 256MB: write-combining, count=3 # cat /proc/iomem 00000000-0009f7ff : System RAM 0009f800-0009ffff : reserved 000d4200-000d7fff : pnp 00:0e 000f0000-000fffff : reserved 00100000-7ffeffff : System RAM 00200000-003ef79f : Kernel code 003ef7a0-0051a20f : Kernel data 00949000-009966c7 : Kernel bss 7fff0000-7fff2fff : ACPI Non-volatile Storage 7fff3000-7fffffff : ACPI Tables 88000000-880fffff : PCI Bus 0000:05 88000000-8800ffff : 0000:05:07.0 c0000000-cfffffff : PCI Bus 0000:01 c0000000-cfffffff : 0000:01:00.0 c0000000-cfffffff : radeonfb framebuffer d0000000-d1ffffff : PCI Bus 0000:01 d0000000-d001ffff : 0000:01:00.0 d1000000-d100ffff : 0000:01:00.0 d1000000-d100ffff : radeonfb mmio d1010000-d101ffff : 0000:01:00.1 d2000000-d3ffffff : PCI Bus 0000:05 d3000000-d3003fff : 0000:05:0b.0 d3004000-d30040ff : 0000:05:07.0 d3004000-d30040ff : sym53c8xx d3005000-d30057ff : 0000:05:0b.0 d3005000-d30057ff : firewire_ohci d3006000-d3006fff : 0000:05:07.0 d3006000-d3006fff : sym53c8xx d4000000-d4000fff : 0000:00:0a.0 d4000000-d4000fff : forcedeth d4001000-d4001fff : 0000:00:08.0 d4001000-d4001fff : sata_nv d4002000-d4002fff : 0000:00:07.0 d4002000-d4002fff : sata_nv d4003000-d4003fff : 0000:00:04.0 d4003000-d4003fff : NVidia CK804 d4004000-d4004fff : 0000:00:02.0 d4004000-d4004fff : ohci_hcd e0000000-efffffff : PCI MMCONFIG 0 e0000000-efffffff : reserved feb00000-feb000ff : 0000:00:02.1 feb00000-feb000ff : ehci_hcd fec00000-ffffffff : reserved fec00000-fec00fff : IOAPIC 0 fee00000-fee00fff : Local APIC
Created attachment 18076 [details] kernel .config file
(In reply to comment #2) > # cat /proc/iomem > c0000000-cfffffff : radeonfb framebuffer > d1000000-d100ffff : radeonfb mmio oops, wrong iomem file. Obviously, radeonfb was not loaded with uvesafb. The right file will follow next reboot. Please, ignore the /proc/iomem for the moment. thx
Looks like the probe function passed some garbage into printk. Let's assign this to our shiny new maintainer ;)
I'm sure there will be a solution soon :) As we could expect, there is no trace of uvesafb in /proc/iomem even it is still present in lsmod module list. #cat /proc/iomem 00000000-0009f7ff : System RAM 0009f800-0009ffff : reserved 000d4200-000d7fff : pnp 00:0e 000f0000-000fffff : reserved 00100000-7ffeffff : System RAM 00200000-003ef61f : Kernel code 003ef620-0051a15f : Kernel data 0094b000-009986c7 : Kernel bss 7fff0000-7fff2fff : ACPI Non-volatile Storage 7fff3000-7fffffff : ACPI Tables 88000000-880fffff : PCI Bus 0000:05 88000000-8800ffff : 0000:05:07.0 c0000000-cfffffff : PCI Bus 0000:01 c0000000-cfffffff : 0000:01:00.0 d0000000-d1ffffff : PCI Bus 0000:01 d0000000-d001ffff : 0000:01:00.0 d1000000-d100ffff : 0000:01:00.0 d1010000-d101ffff : 0000:01:00.1 d2000000-d3ffffff : PCI Bus 0000:05 d3000000-d3003fff : 0000:05:0b.0 d3004000-d30040ff : 0000:05:07.0 d3004000-d30040ff : sym53c8xx d3005000-d30057ff : 0000:05:0b.0 d3005000-d30057ff : firewire_ohci d3006000-d3006fff : 0000:05:07.0 d3006000-d3006fff : sym53c8xx d4000000-d4000fff : 0000:00:0a.0 d4000000-d4000fff : forcedeth d4001000-d4001fff : 0000:00:08.0 d4001000-d4001fff : sata_nv d4002000-d4002fff : 0000:00:07.0 d4002000-d4002fff : sata_nv d4003000-d4003fff : 0000:00:04.0 d4003000-d4003fff : NVidia CK804 d4004000-d4004fff : 0000:00:02.0 d4004000-d4004fff : ohci_hcd e0000000-efffffff : PCI MMCONFIG 0 e0000000-efffffff : reserved feb00000-feb000ff : 0000:00:02.1 feb00000-feb000ff : ehci_hcd fec00000-ffffffff : reserved fec00000-fec00fff : IOAPIC 0 fee00000-fee00fff : Local APIC
Does this happen regardless of whether uvesafb is built into the kernel or built as a module and loaded manually? Could you please compile v86d with "--with-debug" (that's USE="debug" in Gentoo) and run `testvbe` and post its output?
(In reply to comment #7) > Does this happen regardless of whether uvesafb is built into the kernel or > built as a module and loaded manually? I'm using uvesafb as module. The issue remains when the module is loaded manually. I also need to generate a new kernel to see if that will still append when it is build into the kernel directly. > Could you please compile v86d with "--with-debug" (that's USE="debug" in > Gentoo) and run `testvbe` and post its output? > v86d was already compiled with the debug USE flag during the tests. I believe uvesafb failure appends before it even had time to call v86d. Nothing is displayed about v86d in dmesg even when the module is manually loaded after root logged in. I'll run testvbe and generate a new kernel with a built in uvesafb asap. Thank you for your help
(In reply to comment #7) > Could you please compile v86d with "--with-debug" (that's USE="debug" in > Gentoo) and run `testvbe` and post its output? A nice segmentation error... This GDB was configured as "x86_64-pc-linux-gnu"... (no debugging symbols found) (no debugging symbols found) (gdb) run Starting program: /sbin/testvbe (no debugging symbols found) VBE Version: 3.00 OEM String: ATI ATOMBIOS Program received signal SIGSEGV, Segmentation fault. 0x0000000000415d1c in vsnprintf () (gdb) I'm using dev-libs/klibc-1.5.12-r1 'vbetool vbemode get' command reports 3.
Forget to launch uvesafb, sorry. After modprobe uvesafb I get the same oops as described in dmesg file (see attachment) and this time testvbe has returned, VBE Version: 3.00 EBDA at 9f800-9ffff VBIOS at c0000-ce3ff task flags: 0x01 EAX=0x00004f00 EBX=0x00000000 ECX=0x00000000 EDX=0x00000000 ESP=0x00000000 EBP=0x00000000 ESI=0x00000000 EDI=0x00000000 The mode list is in the buffer at 00012122. VBE Version: 3.00 OEM String: ATI ATOMBIOS testvbe[11798] general protection ip:415d1c sp:7fffec3cdd18 error:0 in testvbe[400000+1c000] Erreur de segmentation
Created attachment 18138 [details] Xorg.0.log In case Xorg could give some helpful indication about the videocard...
(In reply to comment #9) > (no debugging symbols found) > VBE Version: 3.00 > OEM String: ATI ATOMBIOS > > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000415d1c in vsnprintf () > (gdb) I believe the problem might be caused by a off-by-one error (see http://repo.or.cz/w/v86d.git?a=commitdiff;h=7e651cf8260df9773800250898f7fb3730d7e1f8). Could you please see whether upgrading to v86d-0.1.9 fixes it for you?
(In reply to comment #12) > Could you please see whether upgrading to v86d-0.1.9 fixes it for you? > Hello Spock, sorry for the late reply. I was stuck with an other bug. I'm using sys-apps/v86d-0.1.9 and the later 2.6.27 kernel and sorry no improvement in sight. Alway the same issue. RIP: 0010:[<ffffffff81103f55>] [<ffffffff81103f55>] strnlen+0x14/0x1e Also, I made some other tests with the vesafb driver to see if could make it work again. It hopefully works, but not with all the VESA mode given to the vga=ask kernel parameter. Anyway, with the vesafb driver I can even switch back and forth from xorg to the console even with the later compiz, xorg 1.5.2 and gdm 2.24.0. Although with a little trick when leaving Xorg. I had to run vbetool vbemode get in the Init Default script to save the current mode followed with a vbetool vbemode set <mode> in the PostSession Default script when leaving the session :) For some reason, every modes over 1152x864x32 have aborted when I was using the vesafb driver (they work with a patched radeonfb or in xorg). Also to avoid a mtrr conflict, I had to give the total vram of the video card vtotal:256. The default was 16M. Here is the output, vesafb: framebuffer at 0xc0000000, mapped to 0xffffc20010100000, using 7776k, total 262144k vesafb: mode is 1152x864x32, linelength=4608, pages=3 vesafb: scrolling: redraw vesafb: Truecolor: size=0:8:8:8, shift=0:16:8:0 After I have logged in, I checked what kind of vbe mode number I had. The numbers were quite ... strange and still work. For every vesa mode (ask=xx) I get the following, 1152x864x32 0x156 (vga=0x356) vbetool returned 16726 1152x864x16 0x154 (vga=0x354) vbetool returned 16724 1152x864x16 0x155 (vga=0x355) vbetool returned 16725 1024x768x32 0x118 (vga=0x318) vbetool returned 16664 1024x768x32 0x117 (vga=0x317) vbetool returned 16663 800x600x32 0x115 (vga=0x315) vbetool returned 16661 800x600x16 0x114 (vga=0x314) vbetool returned 16660 720x400x32 0x136 (vga=0x336) vbetool returned <I didn't remember, sorry> You get the picture. There is no "simple" correlation between vesa and vbe mode, so I didn't find one working for 1280x1024x32 for instance. It should be something related to 0x31A but the driver tells me it is not valid. The above examples could perhaps help you to find what goes wrong. IMHO, It just confirms that the video card is able to understand at least vbe 2.0 :) Finally, I passed the following options to the uvesafb module to a fresh new compiled kernel. options uvesafb mode_option=1152x864-32 options uvesafb pmipal=1 mtrr=2 scroll=ypan blank but without more success. To repeat myself, always a problem in strlen() I will now try the vbmode=16726 option and see if there is some improvement. Ps: I don't have such issue with a radeonhd video card. It works flawlessly with your uvesafb module even with the older 0.1.8 v86d helper.
(In reply to comment #13) > The above examples could perhaps help you to find what goes wrong. IMHO, It > just confirms that the video card is able to understand at least vbe 2.0 :) I have little doubt about that :) Could you please build v86d-0.1.9 using --with-debug and run `testvbe` again? Does it still segfault in the same place as it did for v86d-0.1.8?
I have already set the debug flag for v86d. I'l using 0.1.9. testvbe returns, testvbe VBE Version: 3.00 OEM String: ATI ATOMBIOS Erreur de segmentation and dmesg gives, EBDA at 9f800-9ffff VBIOS at c0000-ce3ff task flags: 0x01 EAX=0x00004f00 EBX=0x00000000 ECX=0x00000000 EDX=0x00000000 ESP=0x00000000 EBP=0x00000000 ESI=0x00000000 EDI=0x00000000 The mode list is in the buffer at 00012122. testvbe[18043] general protection ip:415d1c sp:7fff8d599778 error:0 in testvbe[400000+1c000] and with gdb # gdb testvbe GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu"... (no debugging symbols found) (no debugging symbols found) (gdb) bt No stack. (gdb) run Starting program: /sbin/testvbe (no debugging symbols found) VBE Version: 3.00 OEM String: ATI ATOMBIOS Program received signal SIGSEGV, Segmentation fault. 0x0000000000415d1c in vsnprintf () (gdb) bt #0 0x0000000000415d1c in vsnprintf () #1 0x0000000000000002 in ?? () #2 0x00007fff81e5dd20 in ?? () #3 0x0000000000000000 in ?? () There is no more output :( I compiled it from the tar file directly Have I missed something ?
I missed the eol, please read: I compiled it from the tar file directly and from the ebuild with different flags. The problem still remains.
Hello, I have looked into the source code and have find out some "oem_xx" pointers in testvbe.c didn't address a string and their values are changing at every new call. That explains the oops in fprintf(). I modified slightly your code to go further (see attachment). Now testvbe returns something significant :). I do the same for v86d_common.c. I tried many modes that I knew they were working when called from the vesafb module but none of them have worked with uvesafb :( In dmesg log file, you can read, uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default timings. and the screen goes immediately in standby mode. After a fresh reboot I could read in kernel log file the lines, Oct 17 21:04:53 s_kernel@gentoo kernel: uvesafb: , D^AE^AF^As^At^Au^Av^A<83>^A<84>^A<85>^A<86>^AÓ^AÔ^AÕ^AÖ^Aã^Aä^Aå^Aæ^Aÿÿ, , OEM: ATI ATOMBIOS, VBE v3.0 Oct 17 21:04:53 s_kernel@gentoo kernel: uvesafb: VBIOS/hardware supports DDC2 transfers Oct 17 21:04:53 s_kernel@gentoo kernel: uvesafb: monitor limits: vf = 76 Hz, hf = 82 kHz, clk = 160 MHz Oct 17 21:04:53 s_kernel@gentoo kernel: uvesafb: requested VBE mode 0x162 is unavailable Oct 17 21:04:53 s_kernel@gentoo kernel: uvesafb: scrolling: redraw Oct 17 21:04:53 s_kernel@gentoo kernel: uvesafb: framebuffer at 0xc0000000, mapped to 0xffffc20010100000, using 16384k, total 16384k Oct 17 21:04:53 s_kernel@gentoo kernel: fb0: VESA VGA frame buffer device Also testvbe gives, # testvbe VBE Version: 3.00 OEM String: ATI ATOMBIOS OEM Vendor Name: 17a0a263 <--------- not constant OEM Prod. Name: 17a0a184 <--------- not constant OEM Prod. Rev: 17a0f8f2 <--------- not constant ID attr mode --------------------------- 0100 00bf 640x400-8 0101 00bf 640x480-8 0103 00bf 800x600-8 0105 00bf 1024x768-8 0107 00bf 1280x1024-8 0109 000f 132x25-4 010a 000f 132x43-4 0130 000f 132x44-4 0110 00bf 640x480-16 0111 00bf 640x480-16 0112 00bf 640x480-32 0113 00bf 800x600-16 0114 00bf 800x600-16 0115 00bf 800x600-32 0116 00bf 1024x768-16 0117 00bf 1024x768-16 0118 00bf 1024x768-32 0119 00bf 1280x1024-16 011a 00bf 1280x1024-16 011b 00bf 1280x1024-32 010d 00bf 320x200-16 010e 00bf 320x200-16 010f 00bf 320x200-32 0120 00bf 320x200-32 0193 00bf 320x240-8 0194 00bf 320x240-16 0195 00bf 320x240-16 0196 00bf 320x240-32 01b3 00bf 512x384-8 01b4 00bf 512x384-16 01b5 00bf 512x384-16 01b6 00bf 512x384-32 01c3 00bf 640x350-8 01c4 00bf 640x350-16 01c5 00bf 640x350-16 01c6 00bf 640x350-32 0183 00bf 640x400-8 0184 00bf 640x400-16 0185 00bf 640x400-16 0186 00bf 640x400-32 0133 00bf 720x400-8 0134 00bf 720x400-16 0135 00bf 720x400-16 0136 00bf 720x400-32 0153 00bf 1152x864-8 0154 00bf 1152x864-16 0155 00bf 1152x864-16 0156 00bf 1152x864-32 0163 00bf 1280x1024-8 0164 00bf 1280x1024-16 0165 00bf 1280x1024-16 0166 00bf 1280x1024-32 0121 00bf 640x480-32 0122 00bf 800x600-32 0123 00bf 1024x768-32 0124 00bf 1280x1024-32 0143 00bf 1400x1050-8 0144 00bf 1400x1050-16 0145 00bf 1400x1050-16 0146 00bf 1400x1050-32 0173 00bf 1600x1200-8 0174 00bf 1600x1200-16 0175 00bf 1600x1200-16 0176 00bf 1600x1200-32 0183 00bf 640x400-8 0184 00bf 640x400-16 0185 00bf 640x400-16 0186 00bf 640x400-32 01d3 00bf 1856x1392-8 01d4 00bf 1856x1392-16 01d5 00bf 1856x1392-16 01d6 00bf 1856x1392-32 01e3 00bf 1920x1440-8 01e4 00bf 1920x1440-16 01e5 00bf 1920x1440-16 01e6 00bf 1920x1440-32 I tried with the following options, options uvesafb nocrtc pmipal=1 scroll=ypan options uvesafb mode_option=1152x864-32 passed to the vbemode option the modes 156, 356 and 154 but I'm quite sure I didn't passed 0x162.
Created attachment 18354 [details] v86_common.c patch
Created attachment 18355 [details] testvbe.c patch
Created attachment 18356 [details] v86d log (dmesg)
Could you please install the 'hwinfo' program, run `hwinfo --framebuffer`, and post the output here?
It doesn't return anything. Also the test was made with the vesafb driver. I will try it from xorg with uvesafb asap. Remember the video becomes blank with the uvesafb and make the things harder. See the attachment for hwinfo without argument. Reading /sys/./devices/platform/vesafb.0/graphics/fb0/modes, I get U:1152x864p-76
Created attachment 18360 [details] hwinfo
(In reply to comment #22) > It doesn't return anything. Also the test was made with the vesafb driver. I > will try it from xorg with uvesafb asap. Remember the video becomes blank > with > the uvesafb and make the things harder. Did you run hwinfo as root?
yes I was root. Also, with uvesafb loaded but from xorg for the reason described above nothing more is displayed. Perhaps a problem with sysfsutils (2.1.0) :( It certainly has to do as in your source code when calling the "oem_xx" pointers. hwinfo --framebuffer should return something like, (was made on the radeonhd videocard) 02: None 00.0: 11001 VESA Framebuffer [Created at bios.450] Unique ID: rdCR.tMTgUOhmAoF Hardware Class: framebuffer Model: "(C) 1988-2005, ATI Technologies Inc. RV670" Vendor: "(C) 1988-2005, ATI Technologies Inc. " Device: "RV670" SubVendor: "ATI ATOMBIOS" SubDevice: Revision: "01.00" Memory Size: 16 MB So, if there is some garbage in "Model" and "Vendor" views, hwinfo will simply bypass the framebuffer output. My 2cts
(In reply to comment #25) > yes I was root. Also, with uvesafb loaded but from xorg for the reason > described above nothing more is displayed. Perhaps a problem with sysfsutils > (2.1.0) :( > It certainly has to do as in your source code when calling the "oem_xx" > pointers. Yeah, I can see that. The thing is, according to the VBE spec these fields are not optional, so the fact that they contain garbage is worrying and I would like to figure out why that is before trying to fix the mode switching problem -- it might well be that solving the OEM fields corruption will solve the mode switch issue as well. Are you able to use the xf86-video-vesa driver on that system? If you are, could you please post your Xorg log when using the 'vesa' driver?
(In reply to comment #26) > Are you able to use the xf86-video-vesa driver on that system? If you are, > could you please post your Xorg log when using the 'vesa' driver? > Hello, I have installed xf86-video-vesa-2.0.0 and I have run X -probeonly. See Xorg log in attachment. It looks like there is a lot of garbage in these "oem" fields :(
Created attachment 18393 [details] xorg log with vesa driver
(In reply to comment #27) > > I have installed xf86-video-vesa-2.0.0 and I have run X -probeonly. See Xorg > log in attachment. Thanks for the log. Have you tried actually starting the X server with vesa (i.e. without -probeonly)? If so, did that work? It is important to try that, as that will tell us whether mode switching actually works in X.
(In reply to comment #29) > Thanks for the log. Have you tried actually starting the X server with vesa > (i.e. without -probeonly)? If so, did that work? It is important to try > that, > as that will tell us whether mode switching actually works in X. > Yes I tried to run X with the vesa driver in the 1280x1024 resolution. Pity, that was not successful. I will try other resolutions asap. Just let me more time :).
Created attachment 18405 [details] 1280x1024 VBESetVBEMode failed
Created attachment 18406 [details] 1152x864 ok but VBESetVBEMode failed.
Hello, #31: the driver couldn't load the video mode #32: as above VBESetVBEMode failed but 1152x864 resolution succeed. Also it is the lowest native resolution of the video display and 1680x1050 is the optimal video resolution. There is also an other problem with mtrr, Xorg:9985 freeing invalid memtype c0000000-c1000000 Xorg:9979 conflicting memory types c0000000-c1000000 write-combining<->uncached-minus reserve_memtype failed 0xc0000000-0xc1000000, track write-combining, req write-combining Xorg:9986 freeing invalid memtype c0000000-c1000000 Xorg:9979 freeing invalid memtype c0000000-c1000000 # cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0xc0000000 (3072MB), size= 256MB: write-combining, count=1
Could you please try loading the uvesafb module with the exact options: nocrtc=1 noedid=1 mode_option=1152x864-32 (and no other ones), with a version of v86d with your patch applied?
(In reply to comment #34) > Could you please try loading the uvesafb module with the exact options: > > nocrtc=1 noedid=1 mode_option=1152x864-32 > > (and no other ones), with a version of v86d with your patch applied? > uvesafb: , D^AE^AF^As^At^Au^Av^A<83>^A<84>^A<85>^A<86>^AÓ^AÔ^AÕ^AÖ^Aã^Aä^Aå^Aæ^Aÿÿ, , OEM: ATI ATOMBIOS, VBE v3.0 uvesafb: no monitor limits have been set, default refresh rate will be used uvesafb: scrolling: redraw Console: switching to colour frame buffer device 144x54 uvesafb: framebuffer at 0xc0000000, mapped to 0xffffc20010100000, using 16384k, total 16384k fb0: VESA VGA frame buffer device Command line: root=/dev/md/d0p2 splash=silent,theme:livecd-2007.0 quiet CONSOLE=/dev/tty1 nmi_watchdog=1 mce=bootlog iommu=allowed,soft,memaper loglevel=6 The display is black with the message no signal until X is run :( # grep uvesa /etc/modprobe.conf [...] options uvesafb nocrtc=1 noedid=1 mode_option=1152x864-32 #options uvesafb mode_option=1152x864-32@60 #options uvesafb scroll=ywrap pmipal=1 nocrtc mtrr=3 blank ### update-modules: end processing /etc/modprobe.d/uvesafb
(In reply to comment #35) > The display is black with the message no signal until X is run :( Can you try to detach fbcon (that's `echo 0 > /sys/class/vtconsole/vtcon1/bind` and requires a kernel built with CONFIG_VT_HW_CONSOLE_BINDING=y) after loading uvesafb to see whether this restores the original text mode for you? Also, could you please try to load uvesafb with vbemode=0x153, then 0x154, then 0x155, and finally with 0x156? This would allow us to check whether the bit depth changes anything (I suspect not, but you can never know until you actually try).
(In reply to comment #36) > Can you try to detach fbcon (that's `echo 0 > > /sys/class/vtconsole/vtcon1/bind` > and requires a kernel built with CONFIG_VT_HW_CONSOLE_BINDING=y) after > loading > uvesafb to see whether this restores the original text mode for you? > I applied echo 0 > /sys/class/vtconsole/vtcon0/bind and yes it restores the text mode until gdm is loaded. Afterwards the vts becomes scrambled as before. But don't let us bother about gdm bugs :) > Also, could you please try to load uvesafb with vbemode=0x153, then 0x154, > then > 0x155, and finally with 0x156? This would allow us to check whether the bit > depth changes anything (I suspect not, but you can never know until you > actually try). I tried all the vbemode test you asked for except 0x155. I always have got the same message about a divide error. uvesafb: , DEFstuv��������������, , OEM: ATI ATOMBIOS, VBE v3.0 uvesafb: no monitor limits have been set, default refresh rate will be used divide error: 0000 [1] PREEMPT CPU 0 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 Pid: 482, comm: insmod Not tainted 2.6.27.2-uvesa #15 RIP: 0010:[<ffffffffa0019db5>] [<ffffffffa0019db5>] fb_get_mode+0x20b/0x294 [fb] RSP: 0018:ffff88007e5d3b48 EFLAGS: 00010246 RAX: 000000003b9aca00 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 00000000000003e8 RDI: 000000000000003e RBP: ffff88007e5d3ba8 R08: 000000000000003c R09: 00000000ffffffff R10: ffff88007f9aaca8 R11: 000000023b0be30b R12: ffff88007e5bea80 R13: ffff88007f9f1008 R14: 0000000000000001 R15: 00000000017d7840 FS: 0000000000000000(0000) GS:ffffffff8131c240(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007fffdfe70000 CR3: 000000007e542000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process insmod (pid: 482, threadinfo ffff88007e5d2000, task ffff88007f9aac60) Stack: 000000000000003c ffff88007e53ba80 0000000000000000 0000000000000000 0000714800000101 0000003c00007530 000000000000003c 0000000000000000 ffff88007f9f1000 000000000000002b ffff88007f9f12b0 0000000000000000 Call Trace: [<ffffffffa004bcd4>] uvesafb_probe+0x769/0xe71 [uvesafb] [<ffffffff810ffd3f>] ? ida_get_new_above+0x115/0x1c8 [<ffffffff810d8bdc>] ? sysfs_ilookup_test+0x0/0x14 [<ffffffff8115f319>] platform_drv_probe+0x12/0x14 [<ffffffff8115e696>] driver_probe_device+0xbf/0x16c [<ffffffff8115e7bc>] ? __device_attach+0x0/0xb [<ffffffff8115e7c5>] __device_attach+0x9/0xb [<ffffffff8115dbff>] bus_for_each_drv+0x51/0x88 [<ffffffff8115e84f>] device_attach+0x64/0x79 [<ffffffff8115da3d>] bus_attach_device+0x28/0x59 [<ffffffff8115c8da>] device_add+0x3a9/0x55d [<ffffffff81100614>] ? kobject_init+0x43/0x83 [<ffffffff8115f7f5>] platform_device_add+0x10e/0x14a [<ffffffffa004c3dc>] ? uvesafb_init+0x0/0xbe [uvesafb] [<ffffffffa004c442>] uvesafb_init+0x66/0xbe [uvesafb] [<ffffffff81009047>] _stext+0x47/0x11c [<ffffffff81052a97>] sys_init_module+0xa9/0x1b6 [<ffffffff8100bfdb>] system_call_fastpath+0x16/0x1b Code: 24 3b 45 d4 0f 82 8c 00 00 00 44 39 f8 0f 87 83 00 00 00 41 8b 0c 24 be e8 03 00 00 31 d2 89 c8 f7 f6 31 d2 89 c1 b8 00 ca 9a 3b <f7> f1 b9 64 00 00 00 31 d2 41 89 45 64 41 8b 44 24 1c c1 e0 03 RIP [<ffffffffa0019db5>] fb_get_mode+0x20b/0x294 [fb] RSP <ffff88007e5d3b48> ---[ end trace 56b492a7439a548b ]---
Created attachment 18594 [details] A fix for the divide-by-zero error. I traced the divide by zero error down to a bug in the uvesafb code. Please apply the attached patch, rebuild your kernel and try loading uvesafb with the requested vbemode option values again.
(In reply to comment #38) > apply the attached patch, rebuild your kernel and try loading uvesafb with > the > requested vbemode option values again. > I have applied the patch and loaded uvesafb after each reboot to test the different modes. The results are, vbemode=0x153 and 0x154. Black screen and keyboard leds blinking. The kernel halted and needed a cold reboot. vbemode=0x155 and 0x156, The screen is still black with the message no signal coming from the monitor. Setting vtcon1/bind to 0 has not worked. Also I was able to log in gnome. The messages were, uvesafb: , DEFstuvÓÔÕÖãäåæÿÿ, , OEM: ATI ATOMBIOS, VBE v3.0 uvesafb: no monitor limits have been set, default refresh rate will be used uvesafb: scrolling: redraw Console: switching to colour frame buffer device 144x54 uvesafb: framebuffer at 0xc0000000, mapped to 0xffffc20010100000, using 16384k, total 16384k fb0: VESA VGA frame buffer device
I tried uvesafb with a radeon HD 3870 that is vbe 3.0 compliant. That is a more common videocard than the X800. Also I still cannot have the right mode working. It complains about eax=0x34f, err=0. If the issue isn't related to this one, let me know. I will open a new report for it then. uvesafb: (C) 1988-2005, ATI Technologies Inc. , RV670, 01.00, OEM: ATI ATOMBIOS, VBE v3.0 uvesafb: VBIOS/hardware supports DDC2 transfers uvesafb: monitor limits: vf = 75 Hz, hf = 82 kHz, clk = 140 MHz uvesafb: scrolling: redraw uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default timings. uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default timings. uvesafb: framebuffer at 0xd0000000, mapped to 0xffffc20011100000, using 10240k, total 16384k uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default timings. Thx.
(In reply to comment #40) > uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default > timings. > uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default > timings. > uvesafb: framebuffer at 0xd0000000, mapped to 0xffffc20011100000, using > 10240k, > total 16384k > uvesafb: mode switch failed (eax=0x34f, err=0). Trying again with default > timings. Do you get these messages when you use the 'nocrtc' uvesafb option?
I got the same error message with an radeon HD 4850 ! nocrtc seemed to have fixed it for me - thanks Michal !