← Back to team overview

desktop-packages team mailing list archive

  1. desktop-packages team
  2. Mailing list archive
  3. Message #82642

[Bug 89853] Re: [regression] 7.2 broke vesa: "No matching modes found"

  Thread Previous • Date Previous • • Thread Next 
Launchpad has imported 17 comments from the remote bug at
https://bugs.freedesktop.org/show_bug.cgi?id=10238.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2007-03-09T15:09:04+00:00 Diego Sánchez Román wrote:

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.

Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg-
server/+bug/89853/comments/12

------------------------------------------------------------------------
On 2007-03-11T18:16:07+00:00 Ajax-a wrote:

test2 had a broken vesa driver.  this should be working in test3, or
just update the vesa driver to the one in rawhide.

Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg-
server/+bug/89853/comments/24

------------------------------------------------------------------------
On 2007-03-13T02:33:37+00:00 Sbrewer-k wrote:

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


Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/89853/comments/25

------------------------------------------------------------------------
On 2007-03-13T06:32:01+00:00 Timo Aaltonen wrote:

Reopening since this is not fixed upstream, and affects other distros as
well.

Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg-
server/+bug/89853/comments/26

------------------------------------------------------------------------
On 2007-04-16T22:30:50+00:00 Timo Aaltonen wrote:

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

Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg-
server/+bug/89853/comments/42

------------------------------------------------------------------------
On 2007-05-21T13:46:50+00:00 William Cattey wrote:

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?

Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg-
server/+bug/89853/comments/116

------------------------------------------------------------------------
On 2007-05-21T13:55:27+00:00 William Cattey wrote:

Created attachment 10062
Successful DDC transfer.  X version 6.8.2. RHEL 4.5

Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg-
server/+bug/89853/comments/117

------------------------------------------------------------------------
On 2007-05-21T13:56:42+00:00 William Cattey wrote:

Created attachment 10064
Failed DDC transfer.  X version 7.1.1. RHEL 5.

Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg-
server/+bug/89853/comments/118

------------------------------------------------------------------------
On 2007-05-21T13:57:46+00:00 William Cattey wrote:

Created attachment 10065
Failed DDC transfer.  X version 7.2.0. Ubuntu 7.04.

Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg-
server/+bug/89853/comments/119

------------------------------------------------------------------------
On 2007-05-21T13:59:11+00:00 William Cattey wrote:

Created attachment 10066
Successful DDC transfer.  X version 7.1.1 with ATI proprietery driver.  Ubuntu 6.10.

Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg-
server/+bug/89853/comments/120

------------------------------------------------------------------------
On 2007-05-28T12:08:20+00:00 William Cattey wrote:

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.


Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/89853/comments/129

------------------------------------------------------------------------
On 2007-05-28T12:09:23+00:00 William Cattey wrote:

Created attachment 10109
Debugging patch against RHEL 5 X server source.

Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg-
server/+bug/89853/comments/130

------------------------------------------------------------------------
On 2007-07-10T16:14:05+00:00 William Cattey wrote:

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.


Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg-
server/+bug/89853/comments/135

------------------------------------------------------------------------
On 2010-09-11T10:27:05+00:00 Mattst88 wrote:

Still a bug?

Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg-
server/+bug/89853/comments/188

------------------------------------------------------------------------
On 2010-09-13T07:34:14+00:00 Jjneely-q wrote:

I've not seen this bug in quite some time.  I believe its been fixed.

Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg-
server/+bug/89853/comments/189

------------------------------------------------------------------------
On 2010-09-13T08:21:55+00:00 William Cattey wrote:

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."

Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg-
server/+bug/89853/comments/190

------------------------------------------------------------------------
On 2014-11-17T21:40:18+00:00 Ajax-a wrote:

Friends don't let friends use vm86

Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg-
server/+bug/89853/comments/192


** Changed in: xorg-server
       Status: Confirmed => Fix Released

** Bug watch added: Red Hat Bugzilla #236416
   https://bugzilla.redhat.com/show_bug.cgi?id=236416

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/89853

Title:
  [regression] 7.2 broke vesa: "No matching modes found"

Status in X.Org X server:
  Fix Released
Status in “xorg” package in Ubuntu:
  Fix Released
Status in “xorg-server” package in Ubuntu:
  Fix Released
Status in “xserver-xorg-video-vesa” package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: xorg

  Downloaded Feisty Herd 5 desktop x86 image, checked hash, burned and verified a cd.
  The testing machine is a laptop: Dell Inspiron 6400, an Intel Core 2 Duo with a Radeon Mobility X1400 and 1280x800 widescreen display.

  Launching the Live CD, at the end of the boot process a dialog box says that gdm cannot start, and the boot ends with console login.
  The error message after a startx is:
  (EE) VESA(0): No matching modes
  (EE) Screen(s) found, but none have a usable configuration.

  The solution is editing xorg.conf and adding "HorizSync	36-52" and "VertRefresh	36-60" in "Section Monitor". Giving a startx, the desktop appears with normal resolution for the vesa driver (cannot use radeon driver on this machine).
  Also, a sudo dpkg-reconfigure xserver-xorg, even accepting all default choices, solves the problem.

  This appears a minor bug, but a non-geek user would have troubles
  debugging it. Also, Feisty Herd 3 and 4 went straight to the desktop,
  so this is a regression from older releases

To manage notifications about this bug go to:
https://bugs.launchpad.net/xorg-server/+bug/89853/+subscriptions
  Thread Previous • Date Previous • • Thread Next