Bug 11661

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 !