Bug 536923 - Xorg server fails to start (segfault) on nVidia GeForce GT 210M
Xorg server fails to start (segfault) on nVidia GeForce GT 210M
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Ben Skeggs
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks: 616860
  Show dependency treegraph
Reported: 2009-11-11 14:38 EST by Stephen Gallagher
Modified: 2013-01-10 03:04 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 616860 (view as bug list)
Last Closed: 2010-04-28 18:53:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Full backtrace (6.31 KB, text/plain)
2009-11-11 14:38 EST, Stephen Gallagher
no flags Details
BIOS ROM for GT210M (89 bytes, application/octet-stream)
2009-11-12 07:34 EST, Stephen Gallagher
no flags Details
BIOS ROM for GT210M (61.50 KB, text/plain)
2009-11-19 08:10 EST, Stephen Gallagher
no flags Details
I/O Logging of modeset (413.42 KB, text/plain)
2009-11-19 08:11 EST, Stephen Gallagher
no flags Details
POST log from vbtracetool (10.23 MB, application/x-gzip)
2009-11-19 08:12 EST, Stephen Gallagher
no flags Details
dmesg log with nouveau and kernel modesetting enabled (46.77 KB, text/plain)
2009-12-03 07:47 EST, Stephen Gallagher
no flags Details
EDID obtained from Windows. Sony Vaio VPC-CW17FX (128 bytes, text/plain)
2009-12-14 22:08 EST, Ricardo Hernández
no flags Details
acpidump (136.09 KB, text/plain)
2009-12-17 19:02 EST, Stephen Gallagher
no flags Details
Relax constraints on detecting ACPI video devices (1.90 KB, patch)
2009-12-18 15:25 EST, Matthew Garrett
no flags Details | Diff
Add a mechanism for extracting EDID from ACPI (2.88 KB, patch)
2009-12-18 15:26 EST, Matthew Garrett
no flags Details | Diff
Fall back to using ACPI if all else fails (6.99 KB, patch)
2009-12-18 15:27 EST, Matthew Garrett
no flags Details | Diff
Xorg log for attempted kernel fix (12.35 KB, text/plain)
2010-01-07 08:26 EST, Stephen Gallagher
no flags Details

  None (edit)
Description Stephen Gallagher 2009-11-11 14:38:03 EST
Created attachment 369094 [details]
Full backtrace

Description of problem:
Attempting to load the Fedora 12 RC4 livecd results in a black screen.

Booting with 'nomodeset' and '3' on the grub line allows access to the non-graphical OS. I then attempt to launch X manually and I get a short backtrace. Following the instructions on the Xorg wiki, I got a more extensive backtrace (attached)

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
1. Attempt to start X from runlevel 3
Actual results:
Crash with segfault

Expected results:
A working X server

Additional info:

Attached stack trace
Comment 1 Ben Skeggs 2009-11-11 17:13:48 EST
There's known issues in the support for G210 currently.  I don't have access to the hardware as of yet unfortunately.  It'd be useful if you could attach your card's VBIOS image to the bug.  If you could follow the vbtracetool instructions at http://nouveau.freedesktop.org/wiki/DumpingVideoBios, that'd be great.

As for nomodeset: there's no plans to support this chipset at all.
Comment 2 Stephen Gallagher 2009-11-12 07:34:38 EST
Created attachment 369207 [details]

BIOS rom attached. I was unable to get a POST trace because I got the error "Failed to initialize LRMI... ./vbtracetool: option requires an argument -- 's'".

Also, I didn't understand your comments about 'nomodeset'.  I had to set this option at grub or else I couldn't get access to the system at all. Did you mean that you don't support "modeset" for this chipset?
Comment 4 Ben Skeggs 2009-11-12 17:22:34 EST
No, I meant we don't support nomodeset, and support will be removed completely from upstream at some point in the near future.  The KMS (modeset) code is already far more capable, and is what we'll focus on going forward.  The KMS code has the beginnings of support for G210, but as you're seeing, it's obviously not quite there yet :)

Thanks for the rom image, I'll take a look at it when I get a chance!
Comment 6 Stephen Gallagher 2009-11-13 07:17:56 EST
I attempted to run 
sudo ./vbtracetool -p -l &>post.iolog
sudo ./vbtracetool -p -d &.post.log

As root, but I still got
mmap /dev/zero: Permission denied
Failed to initialize LRMI (Linux Real-Mode Interface)

It's possible that I don't have access to /dev/zero on a live image (I haven't installed the OS locally because of this bug). I am currently working from a LiveUSB with extra space for adding packages.
Comment 7 Ben Skeggs 2009-11-18 20:00:33 EST
Hmm, not sure what's up there.  Does /dev/zero exist, and have permissions set at all?

Also worth mentioning that the VBIOS image just contains vbtracetool error messages too, and not an actual image :)
Comment 8 Stephen Gallagher 2009-11-19 08:10:02 EST
Created attachment 370333 [details]

I found the problem. I was getting SELinux denials.

Attaching the real dumps now.
Comment 9 Stephen Gallagher 2009-11-19 08:11:56 EST
Created attachment 370334 [details]
I/O Logging of modeset

I'm not sure this will be useful or accurate, as the only way I could get to a usable console was with "nomodeset" on the grub command line.
Comment 10 Stephen Gallagher 2009-11-19 08:12:56 EST
Created attachment 370336 [details]
POST log from vbtracetool
Comment 11 Ben Skeggs 2009-12-01 22:43:24 EST
Mmm, how odd.  The panel doesn't use straps to determine the mode, nor does it do DDC.  It looks like there might be a very badly constructed EDID block hidden in the VBIOS though.  What resolution is the panel supposed to be?

Also, can I see the dmesg log of nouveau trying to boot with KMS please?
Comment 12 Stephen Gallagher 2009-12-03 07:47:05 EST
Created attachment 375758 [details]
dmesg log with nouveau and kernel modesetting enabled

The native resolution of the panel is 1366x768.

Added the dmesg log as an attachment.
Comment 13 Stephen Gallagher 2009-12-03 07:58:55 EST
Doing a little digging, I suspect this may be the same bug as http://bugs.freedesktop.org/show_bug.cgi?id=25223

I will attempt to patch the source RPM with the proposed fixes in that bug and will report my findings.
Comment 14 Stephen Gallagher 2009-12-03 08:21:14 EST
The patches in http://bugs.freedesktop.org/show_bug.cgi?id=25223 will not apply against the source tarball from xorg-x11-drv-nouveau-0.0.15-17.20091105gite1c2efd.fc12.x86_64

Please enlighten me if there exists similar patches for this version of the display driver.
Comment 15 Ben Skeggs 2009-12-03 23:49:57 EST
Those patches won't help in your case, there's something odd about your panel's configuration, none of the usual (read: the ways its done on older chipsets) methods seem to apply to your configuration.

In any case, the patches you mentioned above are in the most recent kernels available in koji already.
Comment 16 Ricardo Hernández 2009-12-14 22:08:18 EST
Created attachment 378414 [details]
EDID obtained from Windows. Sony Vaio VPC-CW17FX

I have a Sony Vaio VPC-CW17FX Laptop with nvidia gt210m. EDID obtained from Windows for using it in xorg.conf
Comment 17 Ricardo Hernández 2009-12-14 22:09:13 EST
Indeed Ben is right, there are serious problems with the method to obtain EDID. In fact i'm using the propietary driver right now and found some solution in nvnews nvidia forums. I need to obtain a .bin file from Windows, containing the EDID, then force in xorg.conf, section device. CustomEDID "filewithEDID". Is the only way around for now, but i cannot change to TTY with that solution. I'm uploading my EDID right now.
Comment 18 Stephen Gallagher 2009-12-15 07:42:22 EST
Just for the record, the Sony VAIO VPC-CW17FX is the exact model laptop I reported this original issue on as well. So thank you richerVE for providing the EDID.
Comment 19 Ben Skeggs 2009-12-17 03:14:08 EST
Just a quick question, while running linux can you "cat /proc/acpi/video/VIDn/LCDn/EDID > ~/edid" and attach it (replacing "n" with whatever numbers happen to be there for you!).  We'll see if there's something sensible there.

Your VBIOS appears to call the system BIOS to get the EDID.. Argh!
Comment 20 Stephen Gallagher 2009-12-17 08:29:58 EST
I cannot get this information. I am only able to boot the machine into anything reminiscent of a usable state by adding "nomodeset 3" to my kernel line.

When I boot into runlevel 3 with nomodeset, no virtual directory /proc/acpi/video is present.
Comment 21 Ben Skeggs 2009-12-17 17:36:24 EST
Ouch, that's inconvenient :)  Instead, are you able to install the pmtools package and run "acpidump > acpidump.log" and attach the log here.
Comment 22 Stephen Gallagher 2009-12-17 19:02:06 EST
Created attachment 379124 [details]

acpidump attached as requested
Comment 23 Ben Skeggs 2009-12-17 19:23:07 EST
Thanks!  CC'ing Matthew Garrett to work his magic :)
Comment 24 Matthew Garrett 2009-12-18 09:37:08 EST
Your system has an EDID block in the ACPI table, and should be exporting a video interface. Can you check that the video module is loaded?
Comment 25 Matthew Garrett 2009-12-18 11:17:57 EST
Ah, the lack of the video device should be fixed when we rebase to 2.6.32. However, we don't have an in-kernel way of retrieving the EDID. I'll work on that.
Comment 26 Matthew Garrett 2009-12-18 15:25:27 EST
Created attachment 379284 [details]
Relax constraints on detecting ACPI video devices

This should result in the video device showing up
Comment 27 Matthew Garrett 2009-12-18 15:26:55 EST
Created attachment 379285 [details]
Add a mechanism for extracting EDID from ACPI
Comment 28 Matthew Garrett 2009-12-18 15:27:27 EST
Created attachment 379286 [details]
Fall back to using ACPI if all else fails
Comment 29 Matthew Garrett 2009-12-18 15:29:32 EST
These are untested, and I know that they won't actually work at present. The ACPI table you provided shows that nvidia use non-standard device IDs for the TFT. I'll work out how to handle this.
Comment 30 Stephen Gallagher 2009-12-18 15:30:42 EST
Ok, let me know if you have a build you'd like me to test for you.
Comment 31 Ricardo Hernández 2009-12-20 12:51:36 EST
Matthew thank you for all your work. Looking forward to new changes
Comment 32 Matthew Garrett 2009-12-21 15:13:27 EST
Can you give the kernel from http://koji.fedoraproject.org/koji/taskinfo?taskID=1884330 a go once it's built?
Comment 33 Stephen Gallagher 2009-12-21 19:42:43 EST
I'd love to, but that build failed with the errors:

+ make -s ARCH=powerpc V=1 -j4 modules
crypto/anubis.c: In function 'anubis_crypt':
crypto/anubis.c:581: warning: 'inter' is used uninitialized in this function
sound/isa/sb/sb16.c: In function 'snd_sb16_isa_probe':
sound/isa/sb/sb16.c:527: warning: 'err' may be used uninitialized in this function
In file included from sound/isa/sb/sbawe.c:2:
sound/isa/sb/sb16.c: In function 'snd_sb16_isa_probe':
sound/isa/sb/sb16.c:527: warning: 'err' may be used uninitialized in this function
sound/ppc/awacs.c: In function 'snd_pmac_awacs_init':
sound/ppc/awacs.c:886: warning: 'master_vol' may be used uninitialized in this function
sound/ppc/awacs.c:886: warning: 'speaker_vol' may be used uninitialized in this function
fs/fuse/dev.c: In function 'fuse_notify_inval_entry':
fs/fuse/dev.c:925: warning: the frame size of 1072 bytes is larger than 1024 bytes
drivers/gpu/drm/nouveau/nouveau_state.c: In function 'nouveau_ioctl_getparam':
drivers/gpu/drm/nouveau/nouveau_state.c:843: warning: integer constant is too large for 'long' type
drivers/gpu/drm/nouveau/nouveau_state.c:854: warning: integer constant is too large for 'long' type
drivers/gpu/drm/nouveau/nouveau_state.c:861: warning: integer constant is too large for 'long' type
drivers/gpu/drm/nouveau/nouveau_connector.c: In function 'nouveau_connector_create_lvds':
drivers/gpu/drm/nouveau/nouveau_connector.c:687: error: 'struct nouveau_connector' has no member named 'acpi_edid'
make[4]: *** [drivers/gpu/drm/nouveau/nouveau_connector.o] Error 1
make[3]: *** [drivers/gpu/drm/nouveau] Error 2
make[2]: *** [drivers/gpu/drm] Error 2
make[1]: *** [drivers/gpu] Error 2
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....
net/dccp/timer.c: In function 'dccp_timestamp':
net/dccp/timer.c:281: warning: comparison of distinct pointer types lacks a cast
+ exit 1
error: Bad exit status from /var/tmp/rpm-tmp.fjWjGK (%build)
RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.fjWjGK (%build)
Child returncode was: 1
EXCEPTION: Command failed. See logs for output.
 # ['bash', '--login', '-c', 'rpmbuild -bb --target ppc --nodeps builddir/build/SPECS/kernel.spec']
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/mock/trace_decorator.py", line 70, in trace
    result = func(*args, **kw)
  File "/usr/lib/python2.4/site-packages/mock/util.py", line 324, in do
    raise mock.exception.Error, ("Command failed. See logs for output.\n # %s" % (command,), child.returncode)
Error: Command failed. See logs for output.
 # ['bash', '--login', '-c', 'rpmbuild -bb --target ppc --nodeps builddir/build/SPECS/kernel.spec']
Comment 34 Matthew Garrett 2009-12-22 17:25:16 EST
Sorry about that. Can you try 


Comment 35 Stephen Gallagher 2010-01-04 08:50:53 EST
Many apologies, but it appears that koji scratch build has expired while I was on vacation. Could you rerun it, please?
Comment 37 Stephen Gallagher 2010-01-07 08:26:20 EST
Created attachment 382226 [details]
Xorg log for attempted kernel fix

The above kernel did not resolve my issues. Attaching the Xorg.0.log acquired whilre running that kernel.
Comment 38 Ben Skeggs 2010-01-10 22:26:16 EST
You need to use KMS, the fix is there.  There is *no* chance of your card *ever* working with nouveau UMS (which is now removed completely upstream).
Comment 39 Stephen Gallagher 2010-01-11 07:05:32 EST
My apologies. I didn't realize that "nomodeset" had been selected for my grub command line. It must have been because I did the initial install in nomodeset (so that it would work at all)

Removing "nomodeset" allows the system to work as expected.

Thanks for all the help!
Comment 40 Piotr Drąg 2010-02-10 22:24:49 EST
On kernel- it is indeed fixed, but on 2.6.32 and newer it appears again. Is it possible that the fixes are not there anymore?
Comment 41 Piotr Drąg 2010-02-17 17:40:09 EST
Sorry for the comment above. Now I've complied kernel- with these patches, but it still doesn't work. Is there anything I can do to help fixing this issue?
Comment 42 Piotr Drąg 2010-02-17 18:10:54 EST
I'm sorry again. I will not bother you again on this (or any other) bug.
Comment 43 Stephen Gallagher 2010-03-30 12:41:00 EDT
The patch for this has been available for three months. Why hasn't it made its way into Fedora?

I'm trying to use one of the Fedora 13 Test Day livecds, and this bug is rearing its ugly head again.
Comment 44 Matthew Garrett 2010-03-30 12:48:31 EDT
Upstream still haven't given any feedback. I'll try them again.
Comment 45 Stephen Gallagher 2010-04-12 13:29:01 EDT
It would be REALLY nice if this made its way into Fedora in time for tomorrow's (April 13) Nouveau Graphics Test Day.
Comment 46 Ben Skeggs 2010-04-15 20:20:34 EDT
The patches did make it in for the test day if I understand correctly.  I've done some additional fixes in kernel- (http://koji.fedoraproject.org/koji/taskinfo?taskID=2118272), which could benefit from testing!

Thank you :)
Comment 47 Stephen Gallagher 2010-04-28 07:07:14 EDT
Sorry it got me so long to get back to you on this.

I just tested booting from the nightly GNOME livecd for Fedora 13, and this problem seems to have been resolved at least as of kernel

Thank you for your hard work!
Comment 48 Ben Skeggs 2010-04-28 18:53:05 EDT
Excellent, glad to hear :)

Note You need to log in before you can comment on or make changes to this bug.