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

[Andrea Colangelo]

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

[Timo Aaltonen (tjaalton)]

could you try booting it without usplash: remove 'splash' from the kernel boot commands and see if that helps.

[Andrea Colangelo (warp10)]

Doesen't help. It just remain the same as above.

[SBrewer (sbrewer)]

This is a me too. Same machine, same graphics card. Xorg does not start, so install is impossible.

The graphics card is not supported by X, so vesa is the correct driver in this case. I tried copying the xorg.conf from 6.10 and that did not help.

This is quite a popular laptop by the way, so I assume there will be others who are affected.

[Timo Aaltonen (tjaalton)]

Could you attach (not paste) /var/log/Xorg.0.log, /etc/X11/xorg.conf and the output of commands lspci -vv and lspci -nvv.

[SBrewer (sbrewer)]

More information:

I tried Andrea's fix for the HorizSync and VertRefresh and it worked
for me too.

I dont think the problem is in the xorg.conf however, but probably something going wrong with the ddc probe. Just a guess.

[Diego Sánchez Román (smsxeon)]

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.

[Timo Aaltonen (tjaalton)]

indeed, please post what 'sudo xresprobe vesa' and 'ddcprobe' outputs.

[SBrewer (sbrewer)]

Ok here is something else interesting.

Here is a Xorg.0.log from the 6.10 bootdisk (which works properly).

Some bug in X 7.2??

[Timo Aaltonen (tjaalton)]

please attach the xorg.conf you had with 6.10 livecd.

[Timo Aaltonen (tjaalton)]

hm, the relevant bits look identical.

[SBrewer (sbrewer)]

This line is extra in the failing Xorg.0.log

(II) VESA(0): Modeline "1280x800" 71.11 1280 1328 1360 1440 800 802 808 823 -hsync -vsync

Dont ask me what it means though :-)

[SBrewer (sbrewer)]

Maybe upstream bug:

https://bugs.freedesktop.org/show_bug.cgi?id=10238

[Timo Aaltonen (tjaalton)]

good catch!

[SBrewer (sbrewer)]

ok, so what happens now? Do I drive a bugfix from upstream?
Or can you do that?

The other option is to hack up the autodetection to work around the
problem.

[Ajax-a (ajax-a)]

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

[Sbrewer-k (sbrewer-k)]

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

[Timo Aaltonen (tjaalton)]

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

[SBrewer (sbrewer)]

Maybe some bad news on this one. The new vesa driver (1.3) will probably not fix the problem.

The fedora guys already have 1.3 and the problem is still there. From what I can tell, the problem comes from changes in the xserver that went into 7.2.

http://fcp.surfsite.org/modules/newbb/viewtopic.php?topic_id=34445&viewmode=flat&order=ASC&start=0

The fedora guys fixed the problem by adding the attached hack to the vesa driver.

So the upstream bug in Xorg is not fixed; only Fedora 7 has the fix so far.

[Timo Aaltonen (tjaalton)]

Thanks for the patch, I've seen it before, and it'll be included in the ubuntu package soon.

[SBrewer (sbrewer)]

Great and thanks for the follow up. Please let me know when the fix makes it to a test CD and will try it out and report back.

[Timo Aaltonen (tjaalton)]

that patch is now in Feisty, and you can test it with the fresh Feisty beta livecd. Although, that might not be the real fix, see bug #95253

[Timo Aaltonen (tjaalton)]

Hold on.. that upload did _not_ make it in beta, so testing that won't help. The upload got in yesterday, so please test that if possible.

[SBrewer (sbrewer)]

I just tested this one:

feisty-desktop-i386.iso 26-Mar-2007 07:44 697M

777783ae247bdc59e701b91792322a37 *feisty-desktop-i386.iso

Did not work unfortunately. I did not check if the latest vesa driver
made it into this image.

[SBrewer (sbrewer)]

Fedora has a new driver out in the last few days that attempts to address (probably) the same problem. This is now at 1.3.0-5.fc7

As an experiment I extracted vesa_drv.so from the fedora package. Then I booted into an alpha version of the Ubuntu Feisty livecd, and copied over the vesa driver. Then i tried startx and the Xorg log had the same result.

I am starting to think that the only real way to debug this is to put in detailed debugging output in the mode selection part of the driver. I looked at how much effort it would take to build vesa_drv from source, but ran out of time.

Is there a simple set of instructions for building the driver?

[SBrewer (sbrewer)]

I think the Fedora patch is wrong, or is fixing a different problem. The Fedora patch is never even reach in the failure case presented in this bug report.
See my analysis here:

====== Cut from Vesa.c =========
    pScrn->modePool = VBEGetModePool (pScrn, pVesa->pVbe, pVesa->vbeInfo,
          V_MODETYPE_VBE);

    xf86ErrorFVerb(DEBUG_VERB, "\n");
    xf86DrvMsgVerb(pScrn->scrnIndex, X_INFO, DEBUG_VERB,
     "Total Memory: %d 64KB banks (%dkB)\n", vbe->TotalMemory,
     (vbe->TotalMemory * 65536) / 1024);

    pVesa->mapSize = vbe->TotalMemory * 65536;
    if (pScrn->modePool == NULL) {
 xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "No matching modes\n");
        vbeFree(pVesa->pVbe);

****** This is where the VESA driver bombs out ******
 return (FALSE);
    }

    VBESetModeNames(pScrn->modePool);

****** Fedora patch starts here !!! *******
    i = VBEValidateModes(pScrn, NULL, pScrn->display->modes,
     NULL, NULL, 0, 2048, 1, 0, 2048,
     pScrn->display->virtualX,
     pScrn->display->virtualY,
     pVesa->mapSize, LOOKUP_BEST_REFRESH);

    if (i <= 0) {
 xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "No valid modes\n");
        vbeFree(pVesa->pVbe);
 return (FALSE);
    }

[Timo Aaltonen (tjaalton)]

Could you try the latest vesa, because the patches are now applied to it correctly. In fact, they weren't applied to the old version at all..

[Timo Aaltonen (tjaalton)]

Oh, sorry I forgot you were testing the livecd. The current daily might have it, if the image isn't oversized.

[SBrewer (sbrewer)]

tried todays build (on a DVD) and still no good.

Please see this comment:
https://launchpad.net/ubuntu/+source/xserver-xorg-video-vesa/+bug/89853/comments/30

There could be two bugs here. I would suggest getting Xorg.0.log from bug 95253 and checking if the error message is 'No matching modes' or 'No valid modes'. If they have a different error message, then that bug is different to this one.

For me it is 'No matching modes' while for others on the internet it is the latter error. The fedora patch fixes the latter, but cannot fix the former, since it does not change any code that applies to it.

[Timo Aaltonen (tjaalton)]

Yes, you are right. Don't know why it fails now. Since Herd5 didn't have the new vesa-driver, the fault must lie in xorg-server.

[Mantas Kriaučiūnas (mantas)]

Maybe we should just patch xserver-xorg.postinst script to always use on Radeon Mobility X1400 cards, like there already is such lines for other cards ? for example such code could be added in xresprobeint() function of xserver-xorg.postinst script:

    if [ "$DEVICE_DRIVER" = "vesa" ]; then
      if [ "$DISPLAY_TYPE" = "lcd/lvds" ]; then
        if [ "$DEVICE_IDENTIFIER" = "ATI Technologies, Inc. Radeon Mobility X1400" ] || \
           echo "$DEVICE_IDENTIFIER" | grep -q "Radeon Mobility X1400"; then
          MONITOR_SYNC_RANGES="yes"
          debug_echo "Radeon Mobility X1400 laptop chipset detected; writing sync ranges"
        fi
      fi
    fi

I can test and attach such patch if Ubuntu developers will accept my patch.

[Timo Aaltonen (tjaalton)]

ok, a quick test for you all:

please run "discover --disable=serial,parallel,usb,ide,scsi --format="%V %M\t%S\t%D\n" video | awk 'BEGIN { FS="\t" } {print $1}'"

and post the result. It seems that the ATI vendor string should be without a comma and a dot. There are similar entries in the postinst, and they all seem to be wrong :) The vendor string might have been changed in discover-data some time ago...

[Timo Aaltonen (tjaalton)]

Don't bother, it's confirmed that the vendor string was changed in discover-data.

[Timo Aaltonen (tjaalton)]

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

[Timo Aaltonen (tjaalton)]

this seems to affect some other X1xx cards as well.. Enfortunately, the fix didn't wasn't accepted in Feisty final, but maybe as a post-release update.

[Timo Aaltonen (tjaalton)]

bah, silly typo.. that was "_un_fortunately"

[Tyler Brock (tjb13)]

How can that be possible? There is no way it will make it to the final release of feisty? It isn't even out yet...

-----Original Message-----
From: Timo Aaltonen <email address hidden>
Date: Tue, 17 Apr 2007 05:33:27
To:<email address hidden>
Subject: [Bug 89853] Re: [regression] 7.2 broke vesa: "No matching modes found"

this seems to affect some other X1xx cards as well.. Enfortunately, the
fix didn't wasn't accepted in Feisty final, but maybe as a post-release
update.

** Changed in: xorg (Ubuntu)
Sourcepackagename: xorg-server => xorg

--
[regression] 7.2 broke vesa: "No matching modes found"
https://bugs.launchpad.net/bugs/89853
You received this bug notification because you are a direct subscriber
of a duplicate bug.

[William Cattey (wdc-mit)]

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?

[William Cattey (wdc-mit)]

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

[William Cattey (wdc-mit)]

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

[William Cattey (wdc-mit)]

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

[William Cattey (wdc-mit)]

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

[William Cattey (wdc-mit)]

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.

[William Cattey (wdc-mit)]

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

[William Cattey (wdc-mit)]

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.

[Petr Nemec (nemecpe-deactivatedaccount)]

I am experincing troubles with this "Failed to start the X server" since Ubuntu 7.04 on my laptop with ATi Mobility Radeon X1600.
I tried todays gutsy daily-live(20070825), where "xorg-server 2:1.3.0.0.dfsg-12ubuntu1" already presents, but the problem still remains.

[brokencrystal.com (admin-brokencrystal)]

I was hoping this would be fixed by tribe 5, but I am still having the same problem with tribe 5 as well.

Dell Inspiron E1505 Notebook
ATI Mobility Radeon X1300
1280 by 800 Native Pixels 32Bit Color 60 Hertz PnP LCD Monitor
Gutsy Tribe 5

[Tormod Volden (tormodvolden)]

I noticed that my trace with X700 in comment #142 seems to be the same as the one from András in comment #98 (from April): crash in same function and line number. But in the original report there is no crash and the server log is different. So this must be another issue, although one may trigger/expose the other in some situations. So I opened bug #135218 for our crash issue.

[brokencrystal.com (admin-brokencrystal)]

https://bugs.launchpad.net/ubuntu/+bug/131799

[Glen (synergy-oz)]

I wouldn't get your hopes up, I've been waiting since Feburary for this bug
to be fixed.
Perhaps 8.03 with the next version of xorg.

On 8/28/07, brokencrystal.com <email address hidden> wrote:
>
> I was hoping this would be fixed by tribe 5, but I am still having the
> same problem with tribe 5 as well.
>
> Dell Inspiron E1505 Notebook
> ATI Mobility Radeon X1300
> 1280 by 800 Native Pixels 32Bit Color 60 Hertz PnP LCD Monitor
> Gutsy Tribe 5
>
> --
> [regression] 7.2 broke vesa: "No matching modes found"
> https://bugs.launchpad.net/bugs/89853
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Tormod Volden (tormodvolden)]

Please try the new xserver-xorg-video-vesa 1.3.0-1ubuntu5 now in Gutsy.

[Petr Nemec (nemecpe-deactivatedaccount)]

Tormod Volden: With daily-live 20070831 the X server finally started without a problem on my Mobility Radeon X1600.

[Timo Aaltonen (tjaalton)]

Petr: that's good news, hopefully it works for others, too :)

[brokencrystal.com (admin-brokencrystal)]

Where do I get the daily-live build iso? (Path)

I will try it and let you know.

[Petr Nemec (nemecpe-deactivatedaccount)]

brokencrystal.com: http://cdimage.ubuntu.com/daily-live/current/

[garrin (garrinm)]

Hey I just tried the daily build and it worked for me as well. Great job thanks to all the devs who helped fix this bug... it had been bugging me for quite a while.

By the way I have an Inspiron 6400 with Radeon X1300 (128mb).

[Andrea Colangelo (warp10)]

I tried the daily-live build and for the first time since Herd 4 I went straight to the Desktop without X troubles. Wrong resolution, but at least aI have X working.
Looks like we can finally close this bug.

Thanks to everyone who took care for this bug. It's people like you that make strong our community.

[Tal Shachar (shachtal)]

finally
for the first time
since ubuntu 6.04
i can finally install the system without jumping through hoops!!!!
thanks to the daily 31/08 iso of ubuntu gutsy gibbon

my system is lg P1 pro express dual, running on ati radeon x1400 with a widescreen

the resolution seems to work fine btw
which is sth that was fucked up in previouse verssions as well :)

thank you all crazy programers that know more than me on how to fix these things

now if only my agre modem and soundcard would work fine .... :)

[brokencrystal.com (admin-brokencrystal)]

OK, now will it support my native resolution? The last time I checked, I didn't see 1280 by 800 even listed...

Dell Inspiron E1505 Notebook
ATI Mobility Radeon X1300
1280 by 800 Native Pixels 32Bit Color 60 Hertz PnP LCD Monitor
Gutsy Tribe 5

[Matthew Garrett (mjg59)]

No. The vesa driver will only support vesa modes, which doesn't include any widescreen modes.

[brokencrystal.com (admin-brokencrystal)]

Do we need to do a bug report, or is one already in progress? Maybe they will just consider this a wishlist item...

[brokencrystal.com (admin-brokencrystal)]

https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/136699

[Bryce Harrington (bryce)]

Thanks for confirming that Timo's patch to -vesa fixed the issue. Closing as such.

[Bryce Harrington (bryce)]

By the way, for those wishing to participate in more in-depth testing of new drivers for Radeon and other chipsets, you may wish to join the Ubuntu X Testing Forum at http://ubuntuforums.org/showthread.php?t=490982. We're currently analyzing the xrandr-enabled 2.7.192 -ati driver, and hope to start testing AMD's new driver as soon as code becomes available.

[Timo Aaltonen (tjaalton)]

Closing for the other components as well!

[Djainette (djainette)]

I have a samilar problem with Ubuntu Hardy alpha 5 :

(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found

http://launchpadlibrarian.net/12164870/log.txt

[Devils_chile (devils-chile77)]

I had the same problem in Ubuntu Intrepid Ibex when booting form live CD or USB.

The video card is an ATI HD2400 Mobility Radeon in a Toshiba A200 laptop.

[Mattst88 (mattst88)]

Still a bug?

[Jjneely-q (jjneely-q)]

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

[William Cattey (wdc-mit)]

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

[Timothy R. Chavez (timrchavez)]

The bug task for the somerville project has been removed by an automated script. This bug has been cloned on that project and is available here: https://bugs.launchpad.net/bugs/1305977

[Ajax-a (ajax-a)]

Friends don't let friends use vm86