Bug 10238

Summary: Vesa and ATI X1400
Product: xorg Reporter: Diego <smsxeon>
Component: Driver/VesaAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: cra, jjneely, khadgaray, lakostis, wdc
Version: 7.2 (2007.02)Keywords: NEEDINFO
Hardware: x86 (IA32)   
OS: Linux (All)   
URL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=236416
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Successful DDC transfer. X version 6.8.2. RHEL 4.5
none
Failed DDC transfer. X version 7.1.1. RHEL 5.
none
Failed DDC transfer. X version 7.2.0. Ubuntu 7.04.
none
Successful DDC transfer. X version 7.1.1 with ATI proprietery driver. Ubuntu 6.10.
none
Debugging patch against RHEL 5 X server source. none

Description Diego 2007-03-09 15:09:04 UTC
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.
Comment 1 Adam Jackson 2007-03-11 18:16:07 UTC
test2 had a broken vesa driver.  this should be working in test3, or just update the vesa driver to the one in rawhide.
Comment 2 Simon Brewer 2007-03-13 02:33:37 UTC
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
Comment 3 Timo Aaltonen 2007-03-13 06:32:01 UTC
Reopening since this is not fixed upstream, and affects other distros as well.
Comment 4 Timo Aaltonen 2007-04-16 22:30:50 UTC
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
Comment 5 William Cattey 2007-05-21 13:46:50 UTC
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?
Comment 6 William Cattey 2007-05-21 13:55:27 UTC
Created attachment 10062 [details]
Successful DDC transfer.  X version 6.8.2. RHEL 4.5
Comment 7 William Cattey 2007-05-21 13:56:42 UTC
Created attachment 10064 [details]
Failed DDC transfer.  X version 7.1.1. RHEL 5.
Comment 8 William Cattey 2007-05-21 13:57:46 UTC
Created attachment 10065 [details]
Failed DDC transfer.  X version 7.2.0. Ubuntu 7.04.
Comment 9 William Cattey 2007-05-21 13:59:11 UTC
Created attachment 10066 [details]
Successful DDC transfer.  X version 7.1.1 with ATI proprietery driver.  Ubuntu 6.10.
Comment 10 William Cattey 2007-05-28 12:08:20 UTC
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.
Comment 11 William Cattey 2007-05-28 12:09:23 UTC
Created attachment 10109 [details] [review]
Debugging patch against RHEL 5 X server source.
Comment 12 William Cattey 2007-07-10 16:14:05 UTC
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.

Comment 13 Matt Turner 2010-09-11 10:27:05 UTC
Still a bug?
Comment 14 Jack Neely 2010-09-13 07:34:14 UTC
I've not seen this bug in quite some time.  I believe its been fixed.
Comment 15 William Cattey 2010-09-13 08:21:55 UTC
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."
Comment 16 Adam Jackson 2014-11-17 21:40:18 UTC
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.