Bug 24348

Summary: x86emu doesn't handle the data:jump near combination properly: failing VBE.
Product: xorg Reporter: robert <veel_mail>
Component: Server/GeneralAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED INVALID QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: high CC: libv, remi, terrible.broom
Version: 7.4 (2008.09)   
Hardware: x86 (IA32)   
OS: Linux (All)   
URL: https://bugs.launchpad.net/xserver-xorg-driver-vesa/+bug/258764
i915 platform: i915 features:
Description Flags
full xorg log.
Result of vbe-edid work.
Xorg log none

Description robert 2009-10-06 09:06:44 UTC
This bug has been described previously here:


I am not the original reporter of the issue, but I am affected by it. Here's the original description: 

"Since Feisty, no LiveCD is usable with a KM400 video card and vesa. Same problem when switching to vesa on an installed distro, I get the classic
(EE) VESA(0): No matching modes
(EE) Screen(s) found, but none have a usable configuration.

The only way to use the LiveCDs is to replace the xorg.conf file with one configured for the 'via' driver (which requires some technicals skills, and a previous xorg.conf file).

The problem still exists with xubuntu 8.04.1"

The issue also stil exists in (at least) x/k/ubuntu 9.04 and 9.10. The package version is 1:2.2.1-1.

Steps to reproduce:

In xorg.conf, "Device" section, set Driver to "vesa". Reboot.

Actual results:

The only option to log in is at a text console. 

Expected results:

X is started and a graphical login screen appears.
Comment 1 Pierre Asselin 2009-10-25 04:43:05 UTC
Also reported at Gentoo, see http://bugs.gentoo.org/show_bug.cgi?id=288570
Comment 2 Anna Martynova 2010-09-30 00:26:19 UTC
I understand, that this bug concerns only old platform and it's unlikely that someone will fix it. But I have met this problem and will describe it here. If someone give me an advice, maybe I will try to fix it by myself.

My videocard: VIA VT8623 [Apollo CLE266] integrated CastleRock graphics
My monitor: Belinea 1730S1 (but I have tried with another monitor with the same result).

Full xorg log is attached below (via-Xorg.0.log).
The end of log:

(II) VESA(0): Searching for matching VESA mode(s):

(II) VESA(0): Total Memory: 1024 64KB banks (65536kB)
(EE) VESA(0): No matching modes
(II) UnloadModule: "vesa"
(II) UnloadModule: "int10"
(II) Unloading /usr/lib/xorg/modules/libint10.so
(II) UnloadModule: "vbe"
(II) Unloading /usr/lib/xorg/modules/libvbe.so
(EE) Screen(s) found, but none have a usable configuration.

So, the problem is that "no matching modes" found. I can't uderstand, why.

I think, that another solution for this problem is to make an option to disable getting EDID information. Vesa driver ignores all options like "NoDDC", "NoDDCValue", etc. If we have such option, we could set the mode manually...
Comment 3 Anna Martynova 2010-09-30 00:27:48 UTC
Created attachment 39058 [details]
full xorg log.
Comment 4 Luc Verhaegen 2010-09-30 04:43:05 UTC
Aha, with xserver 1.7.7, which is like debian testing. Let me see whether i can get an install going on a CLE266/KM400 machine on friday evening.

I wouldn't be surprised if this is a bug in the VESA BIOSes of these things, i dealt with an IBM vesa bug at SUSE which turned out to be an issue with the Chrome9 VESA bios.

NoDCC should always work iirc. It could be something else entirely, especially since we are dealing with the bios.
Comment 5 Anna Martynova 2010-09-30 05:58:03 UTC
My videocard (CLE266) was working with Xorg 1.3. Is it because old Xorg didn't rely on videocard bios? And now do?
Ang again, I tried options "NoDDC", "NoDDC1", "NODDC2", "NoDDCValue", "IgnoreEDID" with no effect. Also, I didn't found any options (cases, conditions) in vesa driver source - DDC is always used.
Comment 6 Luc Verhaegen 2010-09-30 06:05:08 UTC
Urgh... They even broke the vesa driver...
Comment 7 Luc Verhaegen 2010-10-10 06:45:23 UTC

This seems like a build option thing... opensuse 11.something with xserver 1.5.2 is just happy, while everyone and everything else breaks using the hardware...

I guess this will prove to be the difference inn x86 support between the different distributions. As SUSE employs, still, one of the people who integrated x86emu with the xserver, Egbert Eich, SUSE will undoubtedly still be running x86emu instead of lrmi/libx86.

Some subtle difference in interpretation of some calls leads the other distributions to have some VESA calls return the standard "VBE failed" (0x14f) error, while SUSE just works. Since it does return the standard 0x14F error, the basic infrastructure is working, but something subtle is interpreted differently.

This will be _FUN_ to debug, I think i will start taking read-edid code apart to locate the exact opcode in the VESA bios where it does go wrong. I have this bios dissasembled to the exact failing calls already.
Comment 8 Luc Verhaegen 2010-10-16 08:40:57 UTC
Ok, status report before i start hacking again:
* the debian xserver with vm86 works, with x86emu it breaks.
* read-edid was analysed and then completely rewritten... Check out http://cgit.freedesktop.org/~libv/vbe-edid be-edid dumps nicely on the aspire, when an external monitor is attached, and a hacked version handles the call that fails on x86emu nicely, as of course, it also uses vm86.
* next up: testing x86emu more directly...
Comment 9 Anna Martynova 2010-10-18 02:53:54 UTC
Created attachment 39498 [details]
Result of vbe-edid work.

Thank you very much for your work! I compiled your utility and ran it on my CLE266 videocard (VIA C3 platform). The result file is attached.
Unfortunately, I don't know the EDID structure and can't understand is result bad or good. :)
Comment 10 Luc Verhaegen 2010-10-18 05:52:20 UTC
I have a patch sitting at home, it needs testing inside the xserver, and then i'll send it upstream. More on that tomorrow morning (CET - doing nokia stuff now, and gf needs me in the evening)
Comment 11 Luc Verhaegen 2010-10-24 15:04:52 UTC
Patch is on the ml: http://lists.x.org/archives/xorg-devel/2010-October/014483.html

Feel free to add it in a debian build tree's patchset, it works just fine there.
Comment 12 Anna Martynova 2010-11-10 01:30:25 UTC
Sorry for long delay.
Unfortunately, xorg 1.7.7 with your patch still doesn't work at VIA CLE266 videocard with vesa driver.
If you are still interested, I can provide any kind of configs and logs...
Comment 13 Luc Verhaegen 2010-11-10 03:43:33 UTC
Yeah, a log of Xorg -logverbose 7 would be nice for this one.

Either something went wrong, or your cle266 bios is running into a different issue than the km400 one.
Comment 14 Anna Martynova 2010-11-11 02:05:31 UTC
Created attachment 40201 [details]
Comment 15 Anna Martynova 2010-11-11 02:19:04 UTC
Created attachment 40202 [details]
Xorg log
Comment 16 Anna Martynova 2010-11-11 02:19:57 UTC
While I was trying to reproduce the problem, I suddenly investigated, that the problem "No matching modes" appears only if xorg-server is built with "minimal" use-flag (I use Gentoo build system). "minimal" use flag disables next features:
xvfb xnest record xfree86-utils install-libxf86config dri dri2 glx
So, now I CAN start Xorg on my CLE266. :) BUT:
for some reason Xorg starts for a very long time (about 3 minutes), and then works normally. If I press Ctrl-Alt-F1 to switch to console, system again freezes for a couple of minutes (screen is black). The same when switching from console back to X.
I dont't know how to see what is happening when screen is black (login through ssh and run top?). Anyway, this is another problem, but I don't know is it still platform-depending or not...
I will continue the investigation.
Just in case, my config and full xorg log are attached (files xorg.conf and Xorg log).
Comment 17 Adam Jackson 2018-06-12 18:43:17 UTC
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.