[G100] DDC takes so long (to fail) that gdm times out on a slow computer

[Jarno Suni]

Binary package hint: xorg

OS: 8.10

With undetected monitor, an error dialog is opened telling ubuntu is running in low-resolution mode besides this:

(EE) MGA(0): Static buffer allocation failed, not initializing the DRI
(EE) MGA(0): Need at least 9216 kB video memory at this resolution, bit depth

It happens even if you have defined monitor properties in xorg.conf. Whereas when you boot with a detected monitor and empty xorg.conf, 1024x768 mode works fine an no error dialog is displayed. However, Xorg.0.log contains the previously mentioned two lines even then; please see the attachment.

[lspci]
00:00.0 Host bridge [0600]: Intel Corporation 440LX/EX - 82443LX/EX Host bridge [8086:7180] (rev 03)
01:00.0 VGA compatible controller [0300]: Matrox Graphics, Inc. MGA G100 [Productiva] AGP [102b:1001] (rev 02)
     Subsystem: Matrox Graphics, Inc. Device [102b:ff01]

[Jarno Suni (jarnos)]

If I start with the undetected monitor (Nokia Valugraph 447V), the message in the error dialog is slightly different:
It tells that DRI is supported only in G200 and above models.

Xorg.0.log attached for this case.

[Jarno Suni (jarnos)]

Then I made a special xorg.conf

[Jarno Suni (jarnos)]

And when I boot with the special xorg.conf, Xorg.0.log is like the attached one.

[Jarno Suni (jarnos)]

So it seems that adding a manual xorg.conf does not have much effect on Xorg.0.log:
Number after "(II) VESA(0): virtual address =" changes.

[Jarno Suni (jarnos)]

This time I disabled DRI in xorg.conf. The error dialog is different this time: "Your screen, graphics card and input devices could not be detected correctly. You will need to configure those by yourself."

See the attachement for more information. I don't know what should I configure more.

[Jarno Suni (jarnos)]

I really think this is a bug. X can detect everything else than monitor without error so it should not stop in that it can't detect my screen after I have configured it myself in xorg.conf.

[Bryce Harrington (bryce)]

Hi jarnos,

Please attach the output of `lspci -vvnn` too.

[This is an automated message. If this script has reached you erroneously, please accept our apologies; any reply to this message will be sufficient to prevent it from doing further automated processing.]

[Tormod Volden (tormodvolden)]

What do you mean by "undetected"? Does it work fine if you use the default (or no) xorg.conf?

[Jarno Suni (jarnos)]

I mean that X can't get monitor specifications automatically for an undetected monitor. It does not work fine by default xorg.conf; that case is explained at https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/319363/comments/2

[Tormod Volden (tormodvolden)]

In comment #2 you are using the VESA driver. Do you mean the "Failsafe Graphics Mode"? Or do you mean the driver is not able to detect a specific monitor? Please attach a log from using your "undetected" monitor and the mga driver (not vesa).

[Jarno Suni (jarnos)]

Note that in comment #1 mga driver is used with the same xorg.conf, but then different monitor was used. When using the Nokia monitor, display mode is forced to "Failsafe Graphics Mode". In comment #3 I have explicitly told system to use MGA driver, but as you can see in comment #4, VESA driver is still used.

[Tormod Volden (tormodvolden)]

Ok, I am interested in the log where the mga driver fails, before it tries vesa. It's maybe in your failsafe tarball?

[Jarno Suni (jarnos)]

Well, the only tarball I have attached is one for which there was a special xorg.conf; the Xorg.0.log in it (and the whole tarball) was made by using a troubleshoot dialog before getting into desktop environment. The other Xorg.0.log files have been stored from the desktop environment once I got there. Maybe the files would have been different in tarball?

[Tormod Volden (tormodvolden)]

This is the log in your tarball, it is using mga but unfortunately with your xorg.conf, and it does not indicate any failure.

Can you please try again with a standard (or no) xorg.conf, and if it ends up with vesa, the mga log maybe Xorg.0.log.old

[Tormod Volden (tormodvolden)]

Can you look through your /var/log/gdm/ files? There should be one that is not using failsafe, and might have an error message or backtrace that indicates that the mga driver crashed. There is nothing in this mga log.

[Jarno Suni (jarnos)]

The log you attached has line "(EE) MGA(0): [drm] Direct rendering only supported with G200/G400/G450/G550." The same line is included in /var/log/gdm/:0.log.3 and /var/log/gdm/:0.log.4. Additionally there is a fatal error logged in :0.log.1.
(Remaining two :0.log files are about some warning from xkbcomp that is not fatal to the X server.)

[Tormod Volden (tormodvolden)]

The drm error should not be fatal. The error in :0.log.1 was only temporary I suppose? There should be no /tmp/.X0-lock
 if X is stopped properly. You can run "sudo /etc/init.d/gdm stop" on a virtual console to stop X, and start it the same way. You can also boot with "text" as a kernel option and X will not be started, in which case you can start it manually with "startx".

[Jarno Suni (jarnos)]

There is no /tmp/.X0-lock when desktop environment is started after I choose low-resolution mode by the given dialog. But I don't want that kind of dialog, but 1024x768 video mode with decent refresh rate.

[Tormod Volden (tormodvolden)]

What makes you think I don't understand what you want?

Please run "sudo /etc/init.d/gdm stop" on a virtual console to stop X.
Then run: sudo Xorg > x.out 2&>1
and attach x.out here.

[Jarno Suni (jarnos)]

Well, I guess it is a bug in X that it shows the dialog. As for your request, what kind of xorg.conf should I have, when I run the commands?

[Jarno Suni (jarnos)]

I did that with a standard xorg.conf and the xorg.conf that is used in comment 6. Both times the x.out is empty.

[Tormod Volden (tormodvolden)]

So it seems like the xserver with mga driver just quits without any error message. Do you have the possibility to log in with ssh from another computer? In that case, stop any X running, and run gdb in the ssh session:
 sudo gdb /usr/bin/Xorg
... now gdb starts and gives you a (gdb) prompt
 set logging file xorg-gdb.txt
 set logging on
 run
... gdb will then start X. If it crashes, you'll be back in gdb and can type
 bt full
 set logging off
 quit
... and you can attach xorg-gdb.txt

[Jarno Suni (jarnos)]

I have the possibility, but I am not going to do it tonight.

[Jarno Suni (jarnos)]

This is with standard xorg.conf.

[Tormod Volden (tormodvolden)]

Very good. Can you please try again, but enter these commands before the "run" command:
 handle SIGUSR1 nostop
 handle SIGUSR2 nostop
 handle SIGPIPE nostop

Additionally, it would help to make the backtrace more complete if you install the xserver-xorg-core-dbg and xserver-xorg-video-savage-dbg packages. At least for the latter you will need to add the "ddebs" repository, see https://wiki.ubuntu.com/DebuggingProgramCrash

Finally, if you have the chance to test a Jaunty live CD, it would be great to see if the bug is already resolved there.

[Tormod Volden (tormodvolden)]

Wait, do not try the Jaunty live CD yet, there is currently another bug in Jaunty that breaks the mga driver.

[Jarno Suni (jarnos)]

This time X did not crash so I did not run "bt full", but exited in host by Ctrl-Alt-Backspace as there was only cross cursor on rasterized grey background.

[Tormod Volden (tormodvolden)]

The cross cursor on rasterized grey background means X by itself is working fine, this is the default background, and there are no X clients running.

Can you try stopping X (or booting with "text") and then run "xinit" from the command line? It should give you a barebone X session with an xterm window. If you get so far, run for instance "xrandr" or "glxinfo" in that window and see if it makes X crash.

[Jarno Suni (jarnos)]

no crash.

[Jarno Suni (jarnos)]

...But low resolution mode with standard xorg.conf. But if I use the xorg.conf of comment 6, I will get 1024x768@78Hz video mode by xinit.

[Tormod Volden (tormodvolden)]

Can you try "startx" instead of "xinit"? This should give you a full Gnome session, as if you were logging in from gdm, but will not fall back to "failsafeX".

[Jarno Suni (jarnos)]

In my case it gives a LXDE session. So proper workaround with the customized xorg.conf is using the kernel option "text" and entering "startx" command after login. Thanks for that.

[Tormod Volden (tormodvolden)]

Can you please attach the log you get with startx, so that I can compare it to the mga log? I don't get why it fails or quits when started from gdm. I guess you never touched /etc/gdm/gdm.conf or gdm.conf-custom?

[Tormod Volden (tormodvolden)]

Wait, did you run startx without any xorg.conf? We want everything to work without having to fiddle with xorg.conf, so it is important that you do the tests without your own configuration tweaks.

[Jarno Suni (jarnos)]

No I didn't in the last comment. If I remove the file and startx, I'll get low-resolution mode (800x600@60Hz).

[Tormod Volden (tormodvolden)]

Thanks. This is the expected behaviour, if it cannot detect the monitor it will use pretty conservative settings for sync ranges and you end up with 800x600.

Can you please start out with the default xorg.conf and only add the sync ranges? This should give a higher resolution. And maybe some of the other stuff you had in your xorg.conf earlier broke mga, so that failsafeX was started?

This will reset your xorg.conf to the default one:
 sudo dexconf -o /etc/X11/xorg.conf

[Tormod Volden (tormodvolden)]

So this is the only thing you should add, to the Monitor section:
    HorizSync 30-64
    VertRefresh 50-100
    DisplaySize 320 240

I should maybe explain that low resolution can be two different things:

1. Low resolution with the MGA driver (or any driver really) because the monitor is not detected and default sync ranges are used. There is no way around it other than to add the sync ranges to the config. In the future, the default sync ranges might be picked more generously so it will come up in 1024x768 for instance. There will also be a GUI to adjust sync ranges.

2. Low resolution because starting with the default driver (MGA in this case) failed. "failsafeX" will then kick in, showing the "low resolution" dialog and start X with the "VESA" driver.

I am trying to figure out why number 2 happens.

[Jarno Suni (jarnos)]

I used such an xorg.conf and I get 1440x1024@60Hz mode, which has different aspect ratio (and which is not handled well by at least LXDE). There is also mode 1024x768@75Hz which is slightly worse rate than with the modelines. If I add a "Display" subsection including "Virtual 1024 768" line (and maybe line "Depth 24") within "Screen" section, I get 1024x768@75Hz mode right after startx.

[Tormod Volden (tormodvolden)]

And it still fails when you boot normally (without "text"), that is, you get the failsafeX dialog?

[Jarno Suni (jarnos)]

yes. The dialog complains that static buffer allocation failed, not initializing the DRI, and that at least 9216 kB video memory needed at this resolution, bit depth. (I had "Virtual 1024 768" line in xorg.conf).

[Tormod Volden (tormodvolden)]

Sorry, I made a typo in comment 22:
Then run: sudo Xorg > x.out 2&>1
It should have been:
Then run: sudo Xorg > x.out 2>&1

No wonder that log file was empty. Can you instead run:
startx > x.out 2>&1
and attach x.out? This should show the same error messages, but prove that they are not critical, since X starts anyway.

[Jarno Suni (jarnos)]

How could it prove they are not critical?

[Jarno Suni (jarnos)]

Oh, since X starts anyway.

[Tormod Volden (tormodvolden)]

I read something in the Fedora bug about problems if the driver is compiled against an older server. I therefore rebuilt the mga driver in my PPA https://launchpad.net/~tormodvolden/+archive/ppa so you can get the .deb from there. Shouldn't hurt to try it at least.

[Jarno Suni (jarnos)]

I supose you mean package xserver-xorg-video-mga.

[Tormod Volden (tormodvolden)]

Yes, xserver-xorg-video-mga.

Ok, so these DRI messages are not critical. It checks first if you have enough memory (so it disables DRI if you are using 1024x768, but goes on if you have 800x600), then checks what card you have. And with a G100 it will disable DRI in any case, since it is not supported.

If I understand correctly, with the same xorg.conf:
- startx (after booting with "text") will successfully run an X session with the mga server
- gdm (booting without "text") will try the mga driver, fail, and fall back to "failsafeX" with vesa driver

Can you please attach /etc/gdm/gdm.conf and gdm.conf-custom so I can check them?

[Tormod Volden (tormodvolden)]

Thanks. Nothing special in there. I have no further ideas at the moment.

[Jarno Suni (jarnos)]

I enabled sending debugging information to the system log in /etc/gdm/gdm.conf. Could I have done it in gdm.conf-custom, instead? Anyway, see the attachment for what gdm put in /var/log/syslog (when no "text" kernel option is used).

[Tormod Volden (tormodvolden)]

Good idea. It shows that gdm starts X like this:
 /usr/X11R6/bin/X :0 -br -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7
Can you try this from the console (with sudo)?

There is also GdmXserverTimeout=10. Maybe 10 seconds is not enough on your machine, so that gdm thinks X is broken while it has just not finished started yet?

[Jarno Suni (jarnos)]

I added GdmXserverTimeout=20 in /etc/gdm/gdm-custom.conf under the [daemon] section and that fixed the problem. Thanks. The machine has 333MHz Pentium II CPU by the way. GDM could state more explicitly that my hardware is too slow, if it is not meant to be supported ;)

[Jarno Suni (jarnos)]

Maybe it is impossible to detect specifications for that 12 years old monitor automatically, so I can't blame X, let alone the MGA driver. Still GDM configuration file could have bigger GdmXserverTimeout, by defaul.

[Tormod Volden (tormodvolden)]

Yes, for instance 15s wouldn't hurt, I think. On the other hand, maybe there is something in the mga driver that takes unreasonably long to start. In newest Jaunty we have timestamping in the X log, so we can get an idea what takes time. If you have a chance to test Jaunty later, please upload the logs.

And your computer is on the border of what we can expect to run Ubuntu :)

[Bryce Harrington (bryce)]

The issue that X fails with old monitors that don't provide proper EDID is covered by bug 194760.

The need for a GUI tool for manually setting up xorg.conf is covered by bug 240916.

We can focus this bug on the gdm timeout issue. If the solution is to increase the timeout, this bug should be retargeted to gdm. Otherwise, seeing the jaunty Xorg.0.log with timestamping would help. Note that only the Jaunty Alpha releases have timestamping; we're disabling timestamping as of the beta release.

[Jarno Suni (jarnos)]

The solution is to set GdmXserverTimeout=15 (at least for my system).

[Tormod Volden (tormodvolden)]

Jarno, if you attach a log with timestamps as Bryce suggests, we might find out why it starts so slow and if there is something we can do to speed it up.

[Jarno Suni (jarnos)]

I don't know about timestamps, but I attached Xorg.0.log of jaunty dev alpha. I was using GdmXserverTimeout=15 and custom xorg.conf to get high-resolution video mode. (The monitor makes notable high noise when I use the 1024x768@75 mode, like it did in intrepid, but the image is good.)

[Tormod Volden (tormodvolden)]

Thanks! There is a good chance this can be improved because it hangs 9 seconds on DDC probing. The rest of the X startup takes just a few seconds.

[ 1.465091] (II) Module "ddc" already built-in
[ 5.920683] (II) MGA(0): VESA VBE DDC supported
[ 5.920835] (II) MGA(0): VESA VBE DDC Level none
[ 5.920919] (II) MGA(0): VESA VBE DDC transfer in appr. 0 sec.
[ 10.384862] (II) MGA(0): VESA VBE DDC read failed

[Tormod Volden (tormodvolden)]

There used to be an option:
 Option "noDDCvbe"
but I am not sure if still works or whether it would go into the Device or the Monitor section of xorg.conf. Please try it out.

[Tormod Volden (tormodvolden)]

Try also "NoDDC".

Would be good to know if other tools are slow also. Can you please try:
 sudo time ddcprobe
 sudo time get-edid|parse-edid
and attach the output and time results?

[Jarno Suni (jarnos)]

Option "NoDDC" worked in the monitor section of xorg.conf. (Option "noDDCvbe" just made things worse.)

main@ubuntu:~$ sudo time ddcprobe
Calling INT 0x42 (F000:F065)
 EAX is 0xBD50
vbe: VESA 2.0 detected.
oem: Matrox Graphics Inc.
memory: 8192kb
mode: 640x400x256
mode: 640x480x256
mode: 800x600x16
mode: 800x600x256
mode: 1024x768x256
mode: 1280x1024x256
mode: 80x60 (text)
mode: 132x25 (text)
mode: 132x43 (text)
mode: 132x50 (text)
mode: 132x60 (text)
mode: 640x480x32k
mode: 640x480x64k
mode: 640x480x16m
mode: 800x600x32k
mode: 800x600x64k
mode: 800x600x16m
mode: 1024x768x32k
mode: 1024x768x64k
mode: 1024x768x16m
mode: 1280x1024x32k
mode: 1280x1024x64k
edid:
edidfail
0.27user 1.04system 0:01.50elapsed 87%CPU (0avgtext+0avgdata 0maxresident)k
48inputs+0outputs (1major+161minor)pagefaults 0swaps
main@ubuntu:~$ sudo time get-edid|parse-edid
parse-edid: parse-edid version 1.4.1
get-edid: get-edid version 1.4.1

 Performing real mode VBE call
 Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
 Function supported
 Call successful

 VBE version 200
 VBE string at 0xc7300 "Matrox Graphics Inc."

VBE/DDC service about to be called
 Report DDC capabilities

 Performing real mode VBE call
 Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
 Function supported
 Call successful

 Monitor and video card combination does not support DDC1 transfers
 Monitor and video card combination does not support DDC2 transfers
 0 seconds per 128 byte EDID block transfer
 Screen is not blanked during DDC transfer

Reading next EDID block

VBE/DDC service about to be called
 Read EDID

 Performing real mode VBE call
 Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
 Function supported
 Call failed

The EDID data should not be trusted as the VBE call failed
Error: output block unchanged
Command exited with non-zero status 1
0.20user 1.10system 0:01.74elapsed 75%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+143minor)pagefaults 0swaps
parse-edid: IO error reading EDID

[davidj (david219)]

Jarno Suni wrote on 2009-02-09: (permalink)

I added GdmXserverTimeout=20 in /etc/gdm/gdm-custom.conf under the [daemon] section and that fixed the problem. Thanks. The machine has 333MHz Pentium II CPU by the way. GDM could state more explicitly that my hardware is too slow, if it is not meant to be supported ;)

This worked for me (increased the timeout.) FYI.

David

[Jarno Suni (jarnos)]

In a couple of previous of my posts I mentioned "/etc/gdm/gdm-custom.conf" where I meant "/etc/gdm/gdm.conf-custom".

[Bryce Harrington (bryce)]

[This is an automatic notification.]

Hi Jarno,

This bug was reported against an earlier version of Ubuntu, can you
test if it still occurs on Lucid?

Please note we also provide technical support for older versions of
Ubuntu, but not in the bug tracker. Instead, to raise the issue through
normal support channels, please see:

    http://www.ubuntu.com/support

If you are the original reporter and can still reproduce the issue on
Lucid, please run the following command to refresh the report:

  apport-collect 319363

If you are not the original reporter, please file a new bug report, so
we can work with you as the original reporter instead (you can reference
bug 319363 in your report if you think it may be related):

  ubuntu-bug xorg

If by chance you can no longer reproduce the issue on Lucid or if you
feel it is no longer relevant, please mark the bug report 'Fix Released'
or 'Invalid' as appropriate, at the following URL:

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

[Timo Aaltonen (tjaalton)]

no reply to the inquiry, closing.