Hi, I have a ATI x1400 graphic card. Since xorg 7.2, I can't go into graphic mode because X fails to start. It gives me the following error "Vesa (0): No modes found". I got this problem with both Fedora Core 7 Test 2 and Ubuntu Feisty Daily CD (09/03/07). I can't use ati driver either. It doesn't support x1000 series. I hope this to be solved so that I can use these distros. Thanks More Hardware Info: AMILO PI 1536: Intel Core2 7200 2Ghz 2 GB RAM 120 GB HD ATI x1400 128 MB Please, ask me if you need more info.
test2 had a broken vesa driver. this should be working in test3, or just update the vesa driver to the one in rawhide.
I have this exact bug as well. Is the Fedora fix going to be merged back into the vesa driver? If not, then the bug should not be closed just yet. This bug is affecting ubuntu as well: https://launchpad.net/ubuntu/+source/xorg/+bug/89853
Reopening since this is not fixed upstream, and affects other distros as well.
the driver fails with: (EE) VESA(0): No matching modes (EE) Screen(s) found, but none have a usable configuration. and it seems to affect at least some other r5xx-cards as well
I am wondering if this is the same bug that is killing Red Hat 5, Ubuntu 7.04, and SuSE 10.1 on the ATI Radeon X1300 card. I will attach Xorg.0.log files from RHEL 4 which successfully configures the X server, and RHEL 5 which says it gets a successful DDC read but which has no actual data from the display with which to configure itself. Is this due to the alleged i2c timeout issue reported in bug 6886?
Created attachment 10062 [details] Successful DDC transfer. X version 6.8.2. RHEL 4.5
Created attachment 10064 [details] Failed DDC transfer. X version 7.1.1. RHEL 5.
Created attachment 10065 [details] Failed DDC transfer. X version 7.2.0. Ubuntu 7.04.
Created attachment 10066 [details] Successful DDC transfer. X version 7.1.1 with ATI proprietery driver. Ubuntu 6.10.
A friend and I have dug into the X server sources of RHEL 5, and understand the problem much better. We've put details into the Red Hat buzilla bug 236416 at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=236416 There we provide a patch and various Xorg.0.log output and a detailed analysis. For the convenience of people looking at the issue from this bug, we attach the patch here. The patch adds printing of a hex dump of the EDID BIOS fetch, and a sleep (2) which seems to enable that fetch to come back with something other than all zeros on the ATI Radeon X1300 card when using the vesa driver.
Created attachment 10109 [details] [review] Debugging patch against RHEL 5 X server source.
Here is additional information: Adding the line: Option "Int10Backend" "x86emu" to the Server Layout section of xorg.conf works around the kernel bug that makes the EDID transfer flaky. (I've taken up the kernel bug with kernel.org.) I'd be grateful if a subset of my debugging patch could be considered for inclusion in the X server. Specifically the two changes: 1. in hw/xfree86/ddc/interpret_edid.c, printing "EDID Major Version %i not valid\n" in the case of an invalid version, rather than silently failing. 2. in hw/xfree86/vbe/vbe.c, printing "VESA VBE DDC bad xnfalloc\n" in the event of a failed memory allocation. Those two changes will help others in the future more quickly isolate problems if the EDID transfer goes flaky again.
Still a bug?
I've not seen this bug in quite some time. I believe its been fixed.
Hi Jack, Long time no chattee! I suspect the reason why you have not seen this bug is NOT because it was fixed, but because the default now is to use the x86emu option by default, bypassing the real-mode BIOS call (with the race condition) that was the root cause of the problem. Sadly, I tore down my test rig two years ago, and don't have a proper setup to do the testing any more. As far as I know, NOBODY every found the specific race condition in the kernel to remedy the root cause and that Red Hat, and kernel.org all agreed to the strategy of, "Depricate Real Mode BIOS data fetches, and leave it broken."
Friends don't let friends use vm86
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.