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

[Timo Aaltonen (tjaalton)]

The final images are already being tested.

If a simple reconfiguring of xserver-xorg is enough, maybe installing with the alternate-cd should get a working setup. Could someone test this?

[Daniele Madama (d-madama)]

The same here, on a MacBook Pro, anyone known if the Andrea's fix is still working? Just for installing Kubuntu from a daily-live and change the driver..

[Alexander Sack (asac)]

works for me on my desktop system with X1950

Attached Xorg log

[Timo Aaltonen (tjaalton)]

So, all of you who suffer from this have a laptop with 1280x800 native resolution screen? If not, please tell us. This should help debugging the real cause.

[Daniele Madama (d-madama)]

My native resolution is 1440x900

[Mike Basinger (mike.basinger)]

My native resolution is 1440x900

[Timo Aaltonen (tjaalton)]

Please test the xorg-server which you can find here (no 64bit packages, sorry):

http://users.tkk.fi/~tjaalton/dpkg/xserver-xorg-core_1.2.0-3ubuntu7.1_i386.deb

so, to test it you'd need to install using the alternate-cd and then install that package by hand (dpkg -i), and restart gdm. It has a patch from Fedora which makes the server not to reject VESA-modes before the driver has had a chance to try them.

[Timo Aaltonen (tjaalton)]

of course if you had a working installation which you have upgraded to feisty.. that works as well.

[Jordi R (jordi1983)]

That means that the final feisty CD is not going to be installable for all the people needing to use VESA to install it? Do you think this is a good decision considering the amount of affected people and companies?
I know that the release is scheduled for tomorrow but if you have not the time you need to include it in the final release, maybe you could release a 7.04.1 version to allow that many people to install your distribution.

Anyway, I'm now downloading the alternate-cd to test this patched xorg-server you have posted.

[bro (matthijsbro)]

Sorry to be so offtopic but i'm a lost dude who wants a working distro and ones reported a bug (beta cd feisty crashing on startup with ati x1400 1280 x 800) and is now receiving emails from this thread all the time. Where/how on earth do I unsubscribe?

[Jordi R (jordi1983)]

Aaltonen the patched xorg-server doesn't work, I have tested like you said, here is the Xorg log, the error is diferent.

Bro, in the menu Actions (up-left) there is the unsubscribe option.

[Mike Basinger (mike.basinger)]

This bug should be fixed before the Feisty release.

[dazog (jlayton)]

same problem occurs on my i6400 with x1400 installed with the 0415 i386 cdimage.

[Timo Aaltonen (tjaalton)]

bro: use the web-interface and unsubscribe using 'unsubscribe' from the Actions-panel.

Jordi: Many thanks for testing! I noticed that the server lacks a ModeLine for 1440x900@60Hz, I'm now building a new version, and that will be here:

http://users.tkk.fi/~tjaalton/dpkg/xserver-xorg-core_1.2.0-3ubuntu7.2_i386.deb

I'd still like someone with a 1280x800 panel trying the workaround!

I don't know if there is a plan to do 7.04.1 cd/dvd-images, but I'll ask.

[Glen (synergy-oz)]

Same story, I have just tested the latest live cd (apparently the release candidate)

Specs: Asus A6J laptop with ATI Mobility X1600, LCD native resolution 1200x800 widescreen.

X won't start in normal mode or "safe graphics mode"
It says 1024 768 has "bad hsync" in the log...

At the bottom :
(EE) VESA(0): No matching modes
(EE) Screen(s) found, but none have a usable configuration.

Attached is full xorg log file.

Sadly its looking very much like 7.04 will be released broken for many users :(

[Glen (synergy-oz)]

 i have 1280x800
I've made some space, i'll download the alternate iso and test it for you.

[Jan Ask (janaskhoej-gmail)]

This bug is confirmed for the final Kubuntu Feisty. I have a 1280x800 laptop with a x1400 Radeon Mobile.

When booting the live-CD I end up with a blank screen.

[Jordi R (jordi1983)]

I have tried the ubuntu7.2 xorg-server and it doesn't work, the error seems to be the same I got with ubuntu7.1, it doesn't find the 1440x900@60Hz ModeLine. I have attached the Xorg log.

[Bertock85 (bertock85-deactivatedaccount)]

I have a laptop Fujitsu-Siemens Amilo 1536 with ATI Mobility Radeon x1400, and I have the same problem using the Beta-live-cd (today is 19th isn't today that Feisty Stable have to be released?)
I resolved the problem installing with alternate-cd, then in the console I've done:

apt-get update, apt-get upgrade (but it isn't enough; if I stop here I receive the same error) and at the end I mustrn apt-get install xorg-driver-fglrx and run sudo aticonfig --initial.

Only after all this steps I can run startx successfully.

[Bertock85 (bertock85-deactivatedaccount)]

I have read the release notes of final version and the big is not listed, I hope that it's been solved...and youu??!!

[Timo Aaltonen (tjaalton)]

the other workaround would be to add HorizSync and VertRefresh to the xorg.conf and use vesa. The original reporter told that running 'sudo dpkg-reconfigure xserver-xorg' and accepting default values made it work, has someone else tried that?

Jordi: I'll build debug-versions of the server and driver, so that we get a proper backtrace for the developer.

[dazog (jlayton)]

My native resolution is 1680 x 1050 on my dell i6400

[Jo-Erlend Schinstad (joerlend.schinstad-deactivatedaccount)]

Same problem with asrock K7VM3 motherboard with an onboard vga connected to a Sunstar monitor (FH 568).
(EE) VESA(0) : No Maching modes
(EE) Screen(s) Found, but none have a usable configuration
Fatal Server error
no Screens found
Press any key to restart your system

You should be able to boot from the live-cd without problems if you just boot with the monitor disconnected though.. That's not a solution, but I thought it might help anyway.

[FRIZI (f-leginski)]

I have a Notebook so it would be a little bit difficult to disconnect may
monitor :] THanx anyway !

On 4/19/07, Jo-Erlend Schinstad <email address hidden> wrote:
>
> Same problem with asrock K7VM3 motherboard with an onboard vga connected
> to a Sunstar monitor (FH 568).
> (EE) VESA(0) : No Maching modes
> (EE) Screen(s) Found, but none have a usable configuration
> Fatal Server error
> no Screens found
> Press any key to restart your system
>
> You should be able to boot from the live-cd without problems if you just
> boot with the monitor disconnected though.. That's not a solution, but I
> thought it might help anyway.
>
> --
> [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.
>

[glaroc (glaroc)]

I just tried changing the HorizSync and VertRefresh and that didn't fix it. dpkg-reconfigure xserver-xorg didn't work either.... I tried accepting defaults or changing some of the parameters, to no avail...

I am on a Dell 6400 core 2 duo with an x1400 card trying to install Feisty x64. My native resolution is 1440x900

GL

[glaroc (glaroc)]

I don't know if this can help, but in my case, using the Feisty x86 live CD (as opposed to x64, both downloaded this morning), the x server does launch properly, but the display is extremely slow and it ends up freezing after a while.

GL

[FRIZI (f-leginski)]

I'm working on that problem with a guy Scott. I've tryied to to change the
resolution and it's not working.

On 4/19/07, carpex <email address hidden> wrote:
>
> I just tried changing the HorizSync and VertRefresh and that didn't fix
> it. dpkg-reconfigure xserver-xorg didn't work either.... I tried
> accepting defaults or changing some of the parameters, to no avail...
>
> I am on a Dell 6400 core 2 duo with an x1400 card trying to install
> Feisty x64. My native resolution is 1440x900
>
> GL
>
> --
> [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.
>

[FRIZI (f-leginski)]

Okey, I could try that but i have a i386 processor/system. It's gonna work
with x86 to ? You have the same machine as I or another kind ?
I don't understand why they changed the x server or the config at boot from
live cd, it was great before. ...

[Jordi R (jordi1983)]

Reconfigure the xserver doesn't work for me either.

[glaroc (glaroc)]

>I don't know if this can help, but in my case, using the Feisty x86 live CD (as opposed to x64, both downloaded this morning), the x server does launch properly, but the display is extremely slow and it ends up freezing >after a while.

Sorry, but this comment from me is wrong. I should have said that it works with Edgy x64 but it ends up freezing. Feisty x86 does not work, which makes more sense I guess.

GL

[Timo Aaltonen (tjaalton)]

there are now debug versions available:

http://users.tkk.fi/~tjaalton/dpkg/xserver-xorg-core-dbg_1.2.0-3ubuntu7.3_i386.deb
http://users.tkk.fi/~tjaalton/dpkg/xserver-xorg-video-vesa_1.3.0-1ubuntu4.1_i386.deb

please provide a backtrace with gdb, documentation for it is here:

https://wiki.ubuntu.com/Backtrace

Jordi, could you also attach the xorg.conf that is generated by alternate install?

[Jordi R (jordi1983)]

Here is the xorg.conf Timo.

[Timo Aaltonen (tjaalton)]

Jordi: thanks, does it work if you remove "1440x900" from the modes?

[Jordi R (jordi1983)]

No, it doesn't.
In addition, I cannot install the ubuntu7.3 due to wrong dependencies, it complains about the xserver-xorg-core.

[Jordi R (jordi1983)]

Oops, sorry, there is no wrong dependencies.

[Jordi R (jordi1983)]

New correction sorry, there is wrong dependencies.

[James Hooker (james-hooker)]

Another user checking in:

Same errors etc... Macbook Pro Core2Duo

[Glen (synergy-oz)]

> http://users.tkk.fi/~tjaalton/dpkg/xserver-xorg-core_1.2.0-3ubuntu7.2_i386.deb
> I'd still like someone with a 1280x800 panel trying the workaround!

I installed alternate, as predicted giving the same error as the live cd.
I installed the above specified package and restarted GDM

Its crashing now instead of missing a screen.

See xorg log file

[Justin Helgerson (ek0nomik)]

I am getting a blank screen while trying to install Feisty.

X1400.

Surprised an issue such as this was allowed into a final version. I know plenty of people using Dell laptops with X**** video cards.

I hope you guys can find a fix. :)

[Timo Aaltonen (tjaalton)]

Please, no need to confirm this anymore, we know it's broken and are trying to find the cure.

The bug is not in the driver, since Herd5 didn't have that. I've now put new xserver-xorg-core which has debugging symbols in it. so no need to install a -dbg too, so go grab these and get a backtrace:

http://users.tkk.fi/~tjaalton/dpkg/xserver-xorg-core_1.2.0-3ubuntu7.4_i386.deb
http://users.tkk.fi/~tjaalton/dpkg/xserver-xorg-video-vesa_1.3.0-1ubuntu4.1_i386.deb

Thanks!

[Thayer Williams (thayer)]

From my understanding it's possible to get this working with the Alternate CD, but is there any way at all to get a Live CD booted? I do a lot of testing with the Live desktops and it would be a godsend if I could find a way to boot into it. Is there a way to boot without the GUI using the Live CD? Just so I can get access to the network and/or modify the xorg.conf from a terminal...

[Thayer Williams (thayer)]

I figured out a temporary workaround for the Live CD blank screen on Kubuntu:

[b]This post could be related to an Ubuntu bug filed at[/b]: [url]https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/89853[/url] [br].[/br] ---------------------------- [br].[/br] [br].[/br]
    If, like me, you have the need to use the Live CD instead of an alternate installation and you can't because you have a Dell Inspiron 6400 with an ATI X1400... I found a workaround:

Note: I have only confirmed this with the Kubuntu 7.04 Live CD, not Ubuntu... if someone would test it with Ubuntu and post results, that'd be great...

1. Boot the Live CD as normal
2. When the screen goes blank and the CD spins down, press CTRL+ALT+F6
3. Then type:

sudo apt-get update
sudo apt-get install xorg-driver-fglrx
sudo depmod -a
sudo aticonfig --initialize
sudo aticonfig --overlay-type=Xv
sudo startx

4. X should restart and load the KDM desktop

[Glen (synergy-oz)]

> Please, no need to confirm this anymore, we know it's broken and are trying to find the cure.

> The bug is not in the driver, since Herd5 didn't have that. I've now put new xserver-xorg-core which has debugging symbols in it. so no need to install a -dbg too, so go grab these and get a backtrace:

There is a back trace in my last post ....
Regardless... i've installed those 2 packages and restarted gdm...
heres the latest backtrace

------------------ Snippet from log ------------
(WW) VESA(0): No valid modes left. Trying less strict filter...

Backtrace:
0: /usr/X11R6/bin/X(xf86SigHandler+0x81) [0x80da8f1]
1: [0xffffe420]
2: /usr/X11R6/bin/X(InitOutput+0x9aa) [0x80a5b9a]
3: /usr/X11R6/bin/X(main+0x27b) [0x807456b]
4: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc) [0xb7d24ebc]
5: /usr/X11R6/bin/X(FontFileCompleteXLFD+0x1e1) [0x8073ab1]

Fatal server error:
Caught signal 11. Server aborting

[Timo Aaltonen (tjaalton)]

No, that's not a backtrace. Here are instructions for getting one with livecd (thanks, thayerw!) or alternate install:

-when the screen goes blank, switch to a virtual console (ctrl+alt+f{2..6})
-become root:
  # sudo -s
-grab the packages from my site:
  # wget http://users.tkk.fi/~tjaalton/dpkg/xserver-xorg-core_1.2.0-3ubuntu7.4_i386.deb
  # wget http://users.tkk.fi/~tjaalton/dpkg/xserver-xorg-video-vesa_1.3.0-1ubuntu4.1_i386.deb
-install them
 # dpkg -i *.deb
-make sure X isn't running (as if)
 # killall -9 X
-start X with gdb
 # gdb /usr/bin/X 2>&1 | tee gdb-x.txt
-run following commands on the gdb shell
(gdb) handle SIG33 pass nostop noprint
(gdb) set pagination 0
(gdb) run
-then X should crash, and then run these commands
(gdb) backtrace
(gdb) info registers
(gdb) thread apply all backtrace
(gdb) quit
-now try to get that file attached here :)

[Ben Strawson (ben-gladsheim)]

I'm having the same problems (X1600 on an HP Compaq nc8430) but when I run X under gdb I get a blank screen and can't seem to switch back to the gdb console to get the backtrace. The best I can do is Ctrl-Alt-Del, which kills X and gets me back to the consoles but then of course everything shuts down :-(

[FRIZI (f-leginski)]

It might work but i've found another solution what I think it's better and
easyier:

sudo -s -H
apt-get update
apt-get upgrade
apt-get install xorg-driver-fglrx
sudo aticonfig --initial
startx

Thanks anyway !

On 4/20/07, Timo Aaltonen <email address hidden> wrote:
>
> No, that's not a backtrace. Here are instructions for getting one with
> livecd (thanks, thayerw!) or alternate install:
>
> -when the screen goes blank, switch to a virtual console
> (ctrl+alt+f{2..6})
> -become root:
> # sudo -s
> -grab the packages from my site:
> # wget
> http://users.tkk.fi/~tjaalton/dpkg/xserver-xorg-core_1.2.0-3ubuntu7.4_i386.deb
> # wget
> http://users.tkk.fi/~tjaalton/dpkg/xserver-xorg-video-vesa_1.3.0-1ubuntu4.1_i386.deb
> -install them
> # dpkg -i *.deb
> -make sure X isn't running (as if)
> # killall -9 X
> -start X with gdb
> # gdb /usr/bin/X 2>&1 | tee gdb-x.txt
> -run following commands on the gdb shell
> (gdb) handle SIG33 pass nostop noprint
> (gdb) set pagination 0
> (gdb) run
> -then X should crash, and then run these commands
> (gdb) backtrace
> (gdb) info registers
> (gdb) thread apply all backtrace
> (gdb) quit
> -now try to get that file attached here :)
>
> --
> [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.
>

[Timo Aaltonen (tjaalton)]

Ben: yes, I tried it and got the same result.. the reason being that the X has crashed and gdb halts it. Here are better docs for getting a backtrace:

http://wiki.x.org/wiki/Development/Documentation/ServerDebugging

to avoid the black screen you'd have to have logged in via ssh (apt-get install openssh-server), but it seems to be possible to do it with just one computer...

[Glen (synergy-oz)]

I followed the instructions. (including the specified deb files)

Running X without gdb still results in segv.
Running X via gdb results in a unrecoverable blank black screen as soon as I ran "run"
Getting back to a console was not possible (ctrl-alt-backspace, c+a fx, c+ fx, etc)
So I ran gdb via SSH.

Hopefully it contains something useful for you.
Next message contains the xorg log file from that session.

[Glen (synergy-oz)]

Heres the Xorg log as per above.

Hope these help as it took alot of effort to bring them to you !

[S.Rey (s.rey)]

I have a Fujitsu Amilo Pi 1536, Core Duo, ATI x1400, resolution 1280x800
Ubuntu 7.04 (final) Desktop CD x86

I have this bug. More precisely, this one (as It seems to be 2 similar bugs around):

"No valid modes left. Trying less strict filter...
Fatal server error:
Caught signal 11. Server aborting"

The horizontal and vertical refresh workaround doesn't work for me, and simply reconfiguring xserver-xorg doesn't work either.

I have found a workaround. Hope it helps somebody. (See this: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/103945/comments/1)

I got to start X with a resolution of 640x480, by deleting all the other modes in xorg.conf (or by "sudo dpkg-reconfe xserver-xorg", and choosing only the 640x480 mode).
With this, I reached the live CD desktop and I managed to complete the installation.
After that (and with wifi internet working), I installed the propietary fglrx, and choose the 1280x800 native resolution).

[Gourry (marco1981)]

I'm a total noob but I confirm this bug on an Acer Aspire 5103WLMI with Mobility Radeon X1300.
Adding "HorizSync 36-52" and "VertRefresh 36-60" allows me to run the X server.

[Pietro Stroia (redcode87-deactivatedaccount)]

I confirm the bug on an Asus A6ja Centrino Duo with Ati Mobility Radeon X1600.
I've tried both modifing the xorg.conf and a sudo dpkg-reconfigure xserver-xorg, but they didn't work for me.

Also the first workaround gives a crash, telling "Caught signal 11. Server aborting".
I'll try later the Rey's workaround and tell you.

I'm afraid of the possibile consequences of this bug, thinking about people just moving from their old operating system to Feisty.

[adrianj (adrian-jayewardene)]

I got into a soup by removing the restricted ATI driver in my upgraded version of Feisty (from 6.10 through Herd 5). Not during live CD install of final Feisty. I just wanted to install the newest ATI driver and thought that was the way to go, remove first and then add latest. I was expecting Feisty to automatically replace the restricted driver with Vesa, but instead I experienced... "Server aborting" and X not loading.

Reconfiguring xserver-xorg did not work unless all resolutions but 640x480 were removed. As S. Rey has mentioned above. I then get back into GDM and can reinstall the prop ATI driver.

So steps to get it to work:

At command line after failure:

1) sudo dpkg-reconfigure xserver-xorg
2) choose Vesa
3) remove all resolutions except 640x480
4) set "HorizSync 36-52" and "VertRefresh 36-60"
5) startx

In GDM

6) sudo apt-get install xorg-driver-fglrx (or latest from ATI)
7) sudo aticonfig -initial
8) see to it that /etc/X11/xorg.conf really gets changed after aticonfig
9) should be up and running (my native resolution 1680x1050, ATI x1600 on HP nx9420)

My question is why allow a user the option of removing a functioning driver if it is not going to be replaced by another? It's one thing for "us" handy guys to experience problems. But a newbie, like the ones we want to start using Ubuntu instead of Windows don't want to experience anything of the sort. They're really not interested whether their computer is fitted with an Nvidia or ATI card! My opinion is that the Restricted driver manager should not have the option of un-enabling a working ATI driver. If it works let it work! Those who want to can do this via the terminal instead. Just my humble opinion.

[Pietro Stroia (redcode87-deactivatedaccount)]

Rey's workaround works for me. ("sudo dpkg-reconfe xserver-xorg", and choosing only the 640x480 mode).
However I didn't installed the propietary drivers because I couldn't get to Internet (my fault I think), but after that everything should go well.

[Jan Ask (janaskhoej-gmail)]

ATI Mobility Radeon x1400, resolution 1280x800

On a clean Feisty install, I can confirm that this works for me too:

1) sudo dpkg-reconfigure xserver-xorg
2) choose Vesa
3) remove all resolutions except 640x480
4) set "HorizSync 36-52" and "VertRefresh 36-60"
5) startx

Cheers

[Timo Aaltonen (tjaalton)]

Glen: many thanks for testing, but I'm afraid it doesn't contain much information.. "cannot remove breakpoints.." is puzzling me. Also, the backtrace is shorter than I'd thought, maybe running 'backtrace full' would get a more useful output? I know it's lot of work to do...

I've tried the livecd on a Thinkpad Z61p since it has a R5xx-series graphics chip, but vesa worked with it.. duh!

[András Kéri (andras-keri)]

The same bug on Thinkpad Z61m, ATI X1400, the native resolution is 1650x1080. I don't how important is this information, but the bug also occurs if I use externel monitor. I also try to send a backtrace, if it's needed.

[András Kéri (andras-keri)]

Here is the backtrace of Xorg.

[András Kéri (andras-keri)]

Some additional information: I installed the xserver-xorg-video-vesa-1.3.0 source package. When I applied the patch 100-fedora-vesa-1.3.0-mode-heuristics.patch the Xorg exited with a segmentation fault (same backtrack). Without the patch the Xorg started in 1024x768. I also tried the live cd using vesa_drv.so compiled without the patch, it also started automatically in 1024x768.

[Timo Aaltonen (tjaalton)]

Andras: Thank you for the backtrace, I believe it has useful information to find the cause.

..but I'm confused how it works without that patch, since when the original bug was reported that patch was not applied to the package. Anyway, here is a version which doesn't have the patch:

http://users.tkk.fi/~tjaalton/dpkg/xserver-xorg-video-vesa_1.3.0-1ubuntu4.2_i386.deb

[András Kéri (andras-keri)]

I've tried, it works. Xorg started in 1024x768

[Mantas Kriaučiūnas (mantas)]

Timo Aaltonen said:
> ..but I'm confused how it works without that patch, since when the original bug was reported that patch was not applied to the package. Anyway, here is a version which doesn't have the patch:
>
>http://users.tkk.fi/~tjaalton/dpkg/xserver-xorg-video-vesa_1.3.0-1ubuntu4.2_i386.deb

Shortly: it seems this bug is solved only when I install both - xserver-xorg-video-vesa_1.3.0-1ubuntu4.2_i386.deb and xserver-xorg-core_1.2.0-3ubuntu7.4_i386.deb packages from http://users.tkk.fi/~tjaalton/dpkg/ :)

Details: I just tested on Fujistu Amillo 1650G laptop with ATI Technologies Inc ATI Radeon XPRESS 200M 5955 (PCIE) video card. Ubuntu Feisty final boots fine (with default mode 1280x800) with ati driver, but doesn't boot if I change Driver "ati" to Driver "vesa".
But when I install xserver-xorg-video-vesa_1.3.0-1ubuntu4.2_i386.deb and xserver-xorg-core_1.2.0-3ubuntu7.4_i386.deb packages from http://users.tkk.fi/~tjaalton/dpkg/ then X starts fine (1024x768) even with vesa on that laptop ;)

NOTE: vesa works only when *both* packages - xserver-xorg-video-vesa_1.3.0-1ubuntu4.2_i386.deb and xserver-xorg-core_1.2.0-3ubuntu7.4_i386.deb are installed, when I install just one of them (for example just xserver-xorg-video-vesa_1.3.0-1ubuntu4.2_i386.deb) then X doesn't start with vesa driver.

[bong bungalan (bbungalan)]

I have experience these things at first run (after installation) of UBUNTU (Breezy and Feisty) and fixed it by adding horiz and vertical freqs in xorg.conf. But in Feisty release, sice Im excited about its desktop effect... i tried to enable the desktop effects and i end up with all white display (Desktop unusable). I just dont know if somebody has experience this issue and i just dont know if this has something to do with VESA driver.

CPU: AMD Sempron 2600+
MotherBoard / Chipset: ASROCK MBoard K7VM3 with VIA KM266Pro and VIA VT8235 North Bridge and south bridge Chipset controller respectively.
HDisks:
(Primary Maxtor) 40GB partition into 2 (1st partition is windowsXP, 2nd partition UBUNTu Feisty)
(Secondary Seagate) 40GB partition into 2 (1st partition is FAT32, 2nd partition is NTFS)
Video: Asrock Built-in
Memory: 256

[John Dong (jdong)]

On a Mobility Radeon X1400, I can also confirm that installing both the server and vesa debs fixed this for me.

[GabrielGrant (gabrielgrant)]

bong bungalan: please see bug 110662 - it may be related to this bug, but we have yet to confirm that it is, so you are better off following that bug for updates on solving your issue

Thanks,
-Gabriel

[dazog (jlayton)]

Since dell is going to be shipping notebooks with 7.04, I assume there will be a re-spin of 7.04 to address this very issue?

Since almost all dell model's have a x1300 or x1400 currently available.

[ne2 Luka (ne3luka)]

> ATI Mobility Radeon x1400, resolution 1280x800
> On a clean Feisty install, I can confirm that this works for me too:
> 1) sudo dpkg-reconfigure xserver-xorg
> 2) choose Vesa
> 3) remove all resolutions except 640x480
> 4) set "HorizSync 36-52" and "VertRefresh 36-60"
> 5) startx
> Cheers

I have Acer Aspire 5021 Wlmi, res: 1280x800, Ati radeon x700, the same problem. I cannot boot the live cd so I cannot install ubuntu. I tried that above (but a bit different), I did reconfigure --> ati --> horizsync, vertsync, res: 1280x800. Then startx. Then it said that one panel (panel 0) is already running (the one that crashed on ctrl+alt+f7) and that I could delete the /tmp/.X0-lock and then try to startx again if the panel is not running. When I delete it and startx, it manages to bring x up and then I get a message (in gui, so nice resolution and all) that it will shut down because some other panel is already running (of course). The point is that it got in x with 1280x800 running. I will download now the alternate disc and try that.

mail: <email address hidden>

Thanks in advance.

btw any word of an ubuntu installation disc that works, :D

[Mike Basinger (mike.basinger)]

Use an alternate CD to install and the following instruction to get video working.
http://www.mikesplanet.net/2007/04/installing-ubuntu-704-ati-x-cards/

[Benjamin Hodgetts (enverex)]

That doesn't apply to all. For instance ATi dropped support for my Radeon 9000 almost a year ago now.

[Glen (synergy-oz)]

How close is this to be resolved?
If I can help more send me instructions and i'm happy to provide more data.

[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)]

I am trying to install Feisty on a Dell Optiplex 745 with a Radeon X1300 Pro.
This bug prevents the installation from going forward because the X display
starts up, but at 800x600, and starting with the VERY FIRST dialog of the installer, selection of the language, the "Next" button is further than 600 pixels down the page.
The dialog cannot be resized any smaller.

According to the Xorg.0.log file the DDC transfer that would ordinarily enable the X server to configure at higher resolution got NO data (but a successful transfer?). So Feisty is install
is DEAD IN THE WATER on the popular Optiplex 745 line until this bug is fixed.

(MIT was hoping to standardize on that Optiplex configuration but if we can't get past step one of the Ubuntu 7.04 install, it's bad both for the Dell config, and the support of Ubuntu at MIT.

Attached is the Xorg.0.log I got.

How can I help move this forward?

William Cattey
Linux Platform Coordinator
Massachusetts Institute of Technology
Cambridge, MA, USA

[Sitsofe Wheeler (sitsofe)]

William:
Do you need 3D and/or an accelerated X? If so, I think you're in for a rough ride with your choice of hardware on Linux. Why would you choose such kit for Linux (if it's for Windows and Linux is a sideshow then the question is irrelevant)?

[William Cattey (wdc-mit)]

I scrolled back a bit, and decided to try and follow the proffered procedure of running
dpkg-reconfigure xserver-xorg

Following that procedure, X is running off the Feisty Desktop Live CD at 1280x1024.
Attached are the xorg.conf and Xorg.0.log files. The ones called "good" were after
the reconfigure. THe ones called "old" are the ones from before running dpkg-reconfigure.
(Presuming that the reconfigure made a backup file, and that the file xorg.conf.200705214138 is the backup. It appears so.)

I note the following possibly very interesting observation:
The Xorg.0.log file shows a SUCCESSFUL DDC transfer this time around.
The xorg.conf file DELETES the line "load i2c".

Does anyone else think this is significant?

[William Cattey (wdc-mit)]

One odd thing: That Xorg.0.log file I just attached was labeled Xorg.0.log.old, and to my mind, it should be the SAME as the Xorg.0.log-ubuntu-7.04 file I attached earlier.
Oh! I forgot! I aborted the reconfigure-display once halfway through. This means that the xorg.conf.old I am about to attach may not be the old one. Sigh.

[William Cattey (wdc-mit)]

Sitsofe, in answer to your query: MIT, like many enterprises, standardizes on ONE hardware recommendation. Most customers buy it first and ask if Linux runs on it only later. We are following a successful multi-use recommendation of the Dell Optiplex GX 620 which served extremely well for both Windows and Linux use. MIT buys a LOT of Dell and a LOT of Optiplex, to the extent that at our recent Hardware Core Team meeting the discussion was, "Well, if Linux doesn't work on the Dell hardware we're buying this year, we'll just tell people to wait until next year to buy new desktop hardware.

I.E. I don't get much choice about what hardwaqre we standardize upon. My job is "Make it work" whatever it is.

[S.Rey (s.rey)]

>>I am trying to install Feisty on a Dell Optiplex 745 with a Radeon X1300 Pro.
>>This bug prevents the installation from going forward because the X display
>>starts up, but at 800x600, and starting with the VERY FIRST dialog of the installer, selection of the language, the "Next" button is further than 600 pixels down the page.
>>The dialog cannot be resized any smaller.

Now it seems irrelevant, but you can always move the windows so that the buttons are clickable. You can press Alt and simultaneously click in any point of the window, and move the mouse without releasing the mouse button.

I had to install in 640x480 mode and it worked. After instalation I switched to fglrx and everything worked fine (except AIGLX, of course).

[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)]

S.Rey: Thanks very much for the clue of the keyboard accelerator to move the window. My problem was I could not find any way to do that.

[William Cattey (wdc-mit)]

Folks, a friend helped me dig into the X server sources, and I now understand this situation much better.

Many have suggested a work-around that involves setting explicit HorizSync and VertRefresh values.
This will not help if your monitor is connected to the DVI port of the ATI Radeon X1300 series, (and probably related cards) because the DVI configuration carefully ignores any xorg.conf input, and goes with what is returned by the EDID BIOS transfer.

The root cause here is flaky EDID BIOS transfer.

My friend and I have posted up-to-date work on fault isolation on that EDID BIOS tranfer in Red Hat Bugzilla bug 236416
at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=236416

By adding in a sleep(2) just before the EDID BIOS read, we get a partial or complete fetch of the monitor data.
Apparently the latest 7.2 X server in use by Ubuntu 7.04 is able to time things differently by fiddling with the module load order. (I have Xorg.0.log file output showing failed or successful EDID transfers depending on the addition or deletion of a module load i2c line.)

I've searched the x.org bug tree and found a relevant bug:
https://bugs.freedesktop.org/show_bug.cgi?id=10238
But the understanding is not as detailed as what my friend and I have recorded n the Red Hat Bugzilla bug.
I think that even the Fedora folks working this bug think the remedy is code to set explicit HorizSync and VertRefresh values, because that seems to be what is in the patch for Fedora 7 test3 which some people report as helpful.

[William Cattey (wdc-mit)]

I just ran a new test case:

I managed to run the version 6.8.2 X server under RHEL 5 which normally runs the 7.1.1 X server. I got it to go far enough to manifest the SAME "partial read with zero padding" flakiness that stock RHEL 5, and which Ubuntu 7.04 manifest.

I conclude that this is a kernel problem. It seems to affect the VESA EDID fetch under Red Hat, Ubuntu, and perhaps SLED 10.1. I've never before submitted a bug to kernel.org, but that seems like the next step.

Can anyone advise me the polite way to move this forward?

Note that a stand alone utility, get-edid (which is actually available as the Debian read-edid package) is always 100% successful in the EDID transfer, and so part of the mystery is, "Why does X fail whereas the small stand-alone utility succeed?"

Who wants to help resolve this mystery?

Or are people going to say, "The reverse engineered Radeon Server is going to take care of this so we don't need to care." and wait for some OTHER manifestation of this bug to hurt people?

[Pietro Stroia (redcode87-deactivatedaccount)]

I think it's not really useful to solve the problem but I tried to use Ubuntu Gutsy Gibbon Tribe 1 cd under VMWare. The live cd starts flawlessly... maybe it's really a kernel problem? Gutsy has the new kernel 2.6.22-6.13 (2.6.22-rc3-based)...

Hope it helps...

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

[cedric santran (santran)]

Hi,

I have an AMILO Pi 1536 with an ATI X1400 video card.

When I tried the Ubuntu Gutsy Gibbon Tribe 2,I have the same problem. See attachements.

[cedric santran (santran)]

Ask me if you want more details and how can I help you.

[William Cattey (wdc-mit)]

With help from a friend, I built a test kernel that cuts out a change to vm86.c that silenced superfluous errors from the audit subsystem, but which messed with the registers on the return from the int10 call. That fixed the problem. We KNOW what the root cause is!

ajackson from Red Hat also pointed out that one can do on the x86 platform what is done on the other platforms, use x86emu. So HERE is the bottom line:

The definitive symptom here is if the EDID hex output in Xorg.0.log is missing, or mostly zeros. If you don't have this symptom, you're being bit by a different bug.

The definitive work-around until the vm86.c kernel bug is fixed, or a more clever approach to getting the EDID data is added to the X server, is to add the line:

        Option "Int10Backend" "x86emu"

to the ServerLayout section of xorg.conf.

[SBrewer (sbrewer)]

Hi William, I am one of the original bug reporters for this issue. Looking at your comments I think you are reporting your issues in the wrong bug report. All the initial reports of this bug show the same symptom: the error message 'No Matching modes found'. In all original reports the EDID data was actually transferred correctly. If you look through all the xorg.0.log files you will see that is the case. I would suggest, if you have not already done so, that you open a separate bug report. This way the developers can focus on fixing these issues separately.

[William Cattey (wdc-mit)]

Wow! You're right. I should have gone back and reviewed the earlier log files.

In the learning I've done since jumping into this situation, I think I understand what your problem is:

In the situation when the EDID transfer is good, if the display offers a mode line that the BIOS does not support, you will lose.

In the Xorg.log file you attached on 3/9/2007, indeed there's a good EDID transfer. A detailed modeline is supplied for 1280x800, but then there are no 1280x800 configurations offered by the BIOS. (If I've understood how the log file works, and my assumption that the detailed mode specs are from the BIOS, whereas the 1280x800 spec is from the monitor.)

I have also been tracking my symptom in another bug. I apologize for inadvertently hijacking your bug.

-Bill

[Andrea Colangelo (warp10)]

I downloaded Gutsy Gibbon Tribe 3 (Desktop) and tried to launch it live to check about this bug.
Well, the situation isn't changed so much. I can't still boot X due to this "No matching modes found" problem.

Anyway, in the original report for this bug, I said: "a sudo dpkg-reconfigure xserver-xorg, even accepting all default choices, solves the problem." Now, this is no more true, because an xserver-xorg reconfigure doens't help at all. You can check out attached Xorg.conf and Xorg.log after the reconfigure.

The only solution is to connect to the Internet and download the fglrx driver (a simple apt-get install xorg-driver-fglrx). After that, a dpkg-reconfigure xserver-xorg, accepting all default values (except regarding the resolution), solves to problem¹.

My hardware isn't changed from the original report for this bug (a Dell Inspiron 6400 with an Ati Mobility Radeon X1400 and 1280x800 LCD panel).

[1] After installing fglrx, when I reconfigure xserver-xorg, I can't choose Monitor autodetection, otherwise screen goes black and system is no more usable - need to reboot)

[William Cattey (wdc-mit)]

The interpretation I make of your Xorg.log output, (and someone more knowledgable than I should correct me if I get this wrong) is:

1. You got a perfectly good EDID transfer that described your monitor.
2. Your monitor said the ONLY video mode it will accept is 1280x800.
3. The BIOS of the video card said it would accept 1280x1024, but made no mention 1280x800, and so the X server concluded it could not work.

It looks like you're running an ATI Radeon X1400 on a widescreen laptop.

[Daniele Dellafiore (ildella)]

So, I would like to access the shell after xserver crashes loading the LiveCD.
I have read this solution from thayerw that says to:

2. When the screen goes blank and the CD spins down, press CTRL+ALT+F6

I can't figure out when to use the magic combo :)
After X crashes and you says it to show log and then you re sent back to console?

[Daniele Dellafiore (ildella)]

Ehi, I am experiencing this problem with Tribe3, but I know gutsy is getting pieces of xorg 7.3.
When is this supposed to be a reality, in Ubuntu? http://people.ubuntu.com/~bryce/BulletProofX/

If someone say: "Tribe5!" I will leave for my holidaty happy and get back more happy to install Ubuntu on macbook pro with no problems at all.

Come on, give me some good news, it's summer!

[William Cattey (wdc-mit)]

Going back to Andrea Colangelo's comment, can someone who understands this better than I sanity check this?

Xorg.0.log showed the monitor could support 1280x800:

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

The bios returned SEVERAL 1280x1024 modes:
Mode: 107 (1280x1024)
Mode: 119 (1280x1024)
Mode: 11a (1280x1024)
Mode: 11b (1280x1024)
Mode: 163 (1280x1024)
Mode: 164 (1280x1024)
Mode: 165 (1280x1024)
Mode: 166 (1280x1024)
Mode: 124 (1280x1024)

but then it concluded:

(II) VESA(0): Total Memory: 256 64KB banks (16384kB)
(II) VESA(0): Generic Monitor: Using hsync range of 28.00-51.00 kHz
(II) VESA(0): Generic Monitor: Using vrefresh range of 43.00-60.00 Hz
(II) VESA(0): Not using built-in mode "1024x768" (no mode of this name)
(II) VESA(0): Not using built-in mode "1024x768" (no mode of this name)
(II) VESA(0): Not using built-in mode "800x600" (no mode of this name)
(II) VESA(0): Not using built-in mode "800x600" (no mode of this name)
(II) VESA(0): Not using built-in mode "640x480" (no mode of this name)
(II) VESA(0): Not using built-in mode "640x480" (no mode of this name)
(WW) VESA(0): No valid modes left. Trying less strict filter...

Backtrace:
0: /usr/bin/X11/X(xf86SigHandler+0x81) [0x80c8641]
1: [0xffffe420]
2: /usr/bin/X11/X(InitOutput+0x9a4) [0x80a8304]
3: /usr/bin/X11/X(main+0x27b) [0x8076c7b]
4: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0) [0xb7d20030]
5: /usr/bin/X11/X(FontFileCompleteXLFD+0x1ed) [0x80761b1]

Is that backtrace because of a possible bug in the "less strict filter"?

It seems to me that an available 1280x1024 mode of the video card should be able to be masked off as a portal into a 1280x800 display, or am I just being silly?

[Andrea Colangelo (warp10)]

Updates from Tribe 4:

The bug is still there, but sudo dpkg-reconfigure xserver-xorg now allows to start X (no more backtrace and server fatal error) with vesa driver, without needing to download fglrx.

Sadly, the situation is identical with my original report for this bug, 4 months ago.

[Tal Shachar (shachtal)]

yeap, here too
same bug still here on tribe 4

i use radeon mobile x1400

[mabovo (mabovo)]

Installing fglrx driver 8.40.4 on Tribe4 got this message:

marcos@linux-ubuntu:~$ fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.4 (2.1 Mesa 7.0)

marcos@linux-ubuntu:~$

I think some problem with kernel version ? Here is my Xorg.0.log

X Window System Version 1.3.0
Release Date: 19 April 2007
X Protocol Version 11, Revision 0, Release 1.3
Build Operating System: Linux Ubuntu
Current Operating System: Linux linux-ubuntu 2.6.22-9-386 #1 Fri Aug 3 00:21:52 GMT 2007 i686
Build Date: 26 July 2007
 Before reporting problems, check http://wiki.x.org
 to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Fri Aug 17 23:22:54 2007
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "Default Layout"
(**) |-->Screen "Default Screen" (0)
(**) | |-->Monitor "SyncMaster"
(**) | |-->Device "ATI Technologies Inc RV350 AR [Radeon 9600]"
(**) |-->Input Device "Generic Keyboard"
(**) |-->Input Device "Configured Mouse"
(**) |-->Input Device "stylus"
(**) |-->Input Device "cursor"
(**) |-->Input Device "eraser"
(==) FontPath set to:
 /usr/share/fonts/X11/misc,
 /usr/share/fonts/X11/cyrillic,
 /usr/share/fonts/X11/100dpi/:unscaled,
 /usr/share/fonts/X11/75dpi/:unscaled,
 /usr/share/fonts/X11/Type1,
 /usr/share/fonts/X11/100dpi,
 /usr/share/fonts/X11/75dpi,
 /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType
(==) RgbPath set to "/etc/X11/rgb"
(==) ModulePath set to "/usr/lib/xorg/modules"
(**) Extension "Composite" is disabled
(II) Open ACPI successful (/var/run/acpid.socket)
(II) Loader magic: 0x81e5980
(II) Module ABI versions:
 X.Org ANSI C Emulation: 0.3
 X.Org Video Driver: 1.2
 X.Org XInput driver : 0.7
 X.Org Server Extension : 0.3
 X.Org Font Renderer : 0.5
(II) Loader running on linux
(II) LoadModule: "pcidata"
(II) Loading /usr/lib/xorg/modules//libpcidata.so
(II) Module pcidata: vendor="X.Org Foundation"
 compiled for 1.3.0, module version = 1.0.0
 ABI class: X.Org Video Driver, version 1.2
(++) using VT number 7

(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 1106,0282 card 1043,80a3 rev 00 class 06,00,00 hdr 80
(II) PCI: 00:00:1: chip 1106,1282 card 0000,0000 rev 00 class 06,00,00 hdr 00
(II) PCI: 00:00:2: chip 1106,2282 card 0000,0000 rev 00 class 06,00,00 hdr 00
(II) PCI: 00:00:3: chip 1106,3282 card 0000,0000 rev 00 class 06,00,00 hdr 00
(II) PCI: 00:00:4: chip 1106,4282 card 0000,0000 rev 00 class 06,00,00 hdr 00
(II) PCI: 00:00:7: chip 1106,7282 card 0000,0000 rev 00 class 06,00,00 hdr 00
(II) PCI: 00:01:0: chip 1106,b188 card 0000,0000 rev 00 class 06,04,00 hdr 01
(II) PCI: 00:0b:0: chip 109e,036e card 0000,0000 rev 11 class 04,00,00 hdr 80
(II) PCI: 00:0b:1: chip 109e,0878 card 0000,0000 rev 11 class 04,80,00 hdr 80
(II) PCI: 00:0d:0: chip 10b7,9200 card 10b7,1000 rev 74 class 02,00,00 hdr 00
(II) PCI: 00:0e:0: chip 1102,0002 card 1102,8040 rev 05 class 04,01,00 ...

[David Jaša (dejv)]

I can confirm this bug on integrated ati xpress 1250 on HP Compaq 6715s notebook.

[brokencrystal.com (admin-brokencrystal)]

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

Confirmed

[brokencrystal.com (admin-brokencrystal)]

Installed restricted driver from command line... These are my logs and outputs after I did this and was able to get into Gnome...

[Timo Aaltonen (tjaalton)]

If anyone of you is using gutsy at the moment, please test a new xserver version available here:

http://users.tkk.fi/~tjaalton/dpkg/xserver

It has a patch which should fix this for good.

[Tormod Volden (tormodvolden)]

Tested the -12 xserver and vesa will still not start on ATI X700. Tried to debug a little with gdb:
- segfaults at line 683 in vesa.c
- the pScrn->display->modes linked list is corrupted, ->next is invalid (see gdb session)

[Andrea Colangelo (warp10)]

@ Timo Aaltonen: Sorry, but your fix is not working for me.

I downloaded and launched (in live mode) Tribe 5 on my Inspiron 6400 (Ati Radeon Mobility X1400, my hardware isn't changed at all).
As I thought, X is not working yet. Anyway, the behaviour is just slightly changed: as you can see in the log, I have not either a backtrace information or a clear error message.

I installed Timo's xserver (I made a dpkg -i xserver-xorg-*) but nothing is changed. I attach the Xorg.0.log both before and after the upgrade.

Anyway, the usual sudo dpkg-reconfigure xserver-xorg allowed me to start x, altough with a poor 1024x768 resolution, as always.

[Timo Aaltonen (tjaalton)]

Andrea:

You managed to get the server working by reconfiguring it, so the patch _does_ work :) Poor resolution is because of vesa, it doesn't support widescreen modes.

[Andrea Colangelo (warp10)]

Well, I really hope this is true, but since my original report for this bug I said that reconfiguring xserver allows to start x, so nothing looks changed to my non_developer & non_X_expert eyes. :)
Probably a good test would be to launch ubuntu live with your patched server. Do you have any indications about the best way to do this?

[Timo Aaltonen (tjaalton)]

Andrea: If that's the case, then your issue is different from this one. There are reports that the live-cd doesn't generate a working config, but after reconfiguration things are working...

[Andrea Colangelo (warp10)]

Timo: probably my poor english is not helping to understand each other.
Anyway, what I say is that when I reconfigure xserver-xorg I can start X, and this is true both if the standard xserver is installed and if I upgrade to your patched xserver. But I noted that launching X, using the original xorg.conf, after installing your patched xserver doesn't work, so it appears to me that your patch doesn't change the situation. I am not an expert about X, but I believe that it could be interesting to see what happens if I boot a live-cd with your patched xserver.

[GabrielGrant (gabrielgrant)]

Timo: I don't think Andrea's issue could be "different from this one" - Andrea is the original reporter :)

Perhaps some other people have other issues that are addressed by the patch, but if it doesn't fix Andrea's original problem that would mean that their bugs have been misdiagnosed and should be moved to separate reports.

...just to clear things up...

Thanks a lot for all of your work towards fixing this,
-Gabriel

[Matt Myers (msquared-gmail)]

I don't know if it helps at all, but I installed the x86_64 version of 7.04 on my T60 and it worked fine.

[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