Bug 495843 - 20090413 nouveau driver segfaults on start
Summary: 20090413 nouveau driver segfaults on start
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Ben Skeggs
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-04-15 03:36 UTC by Richard Colley
Modified: 2009-04-19 22:58 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-04-19 22:58:25 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
X server log file (7.16 KB, text/plain)
2009-04-15 03:36 UTC, Richard Colley
no flags Details
full /var/log/dmesg (34.59 KB, text/plain)
2009-04-15 04:48 UTC, Richard Colley
no flags Details
output of /proc/meminfo (1.14 KB, text/plain)
2009-04-15 04:48 UTC, Richard Colley
no flags Details
output of dmesg (37.27 KB, text/plain)
2009-04-15 04:51 UTC, Richard Colley
no flags Details
cat /proc/vmallocinfo (6.12 KB, text/plain)
2009-04-15 09:40 UTC, Richard Colley
no flags Details
lspci -vvn output as requested (20.30 KB, text/plain)
2009-04-16 01:33 UTC, Richard Colley
no flags Details

Description Richard Colley 2009-04-15 03:36:38 UTC
Created attachment 339614 [details]
X server log file

Description of problem:

Today, I updated to xorg-x11-drv-nouveau-0.0.12-26.20090413 and since then X won't start with the nouveau driver.  It segfaults in the nouveau driver and exits.

Cards is an NV43, and was working fine prior to this latest nouveau update.

Xorg.log file contains a stack trace (see attached).


Version-Release number of selected component (if applicable):
xorg-x11-drv-nouveau-0.0.12-26.20090413git7100c06.fc11.i586
kernel-2.6.29.1-70.fc11.i586
xorg-x11-server-Xorg-1.6.0-20.fc11.i586


How reproducible:
Attempt to start X with NV43 card and nouveau driver selected.  Happens every time.
  
Actual results:
(see attached log for full details)
Backtrace:
0: X(xorg_backtrace+0x3b) [0x812e17b]
1: X(xf86SigHandler+0x9e) [0x80c0e0e]
2: [0xe84400]
3: /usr/lib/xorg/modules/drivers//nouveau_drv.so [0x313133]
4: X(InitOutput+0x4e9) [0x80a9339]
5: X(main+0x1d3) [0x806b933]
6: /lib/libc.so.6(__libc_start_main+0xe6) [0x51b856]
7: X [0x806afa1]



Expected results:
X starts properly.

Comment 1 Ben Skeggs 2009-04-15 03:54:18 UTC
Interesting.. What version was you using previously?  Can I also see the output of the "dmesg" command after X has failed to start?  For some reason your card failed to init, and the fallback mode seems to have failed (I'll test that here in a bit, and see why exactly).

Comment 2 Ben Skeggs 2009-04-15 04:10:11 UTC
Nevermind, I found the cause of the segfault.  I'll post an update soon.  I'd still like to know why acceleration gets disabled on your card however :)

Comment 3 Richard Colley 2009-04-15 04:29:29 UTC
Great!  In case it's still needed, here's the bottom from dmesg:

nouveau 0000:01:00.0: Unable to allocate 16MB of scatter-gather pages for PCI DMA!<6>nouveau 0000:01:00.0: Allocating FIFO number 0
nouveau 0000:01:00.0: Invalid GART type 0
nouveau 0000:01:00.0: Error creating TT ctxdma: -22
nouveau 0000:01:00.0: gpuobj -22
nouveau 0000:01:00.0: nouveau_fifo_free: freeing fifo 0
nouveau 0000:01:00.0: Error allocating GPU channel: -22

I too would be interested to know why acceleration gets disabled!  It stops me running any of the desktop effects. :)

Thanks,
Richard

Comment 4 Richard Colley 2009-04-15 04:33:22 UTC
oops ... this line precedes the above dmesg output and may be related:

vmap allocation for size 16781312 failed: use vmalloc=<size> to increase size.

Comment 5 Ben Skeggs 2009-04-15 04:37:44 UTC
Oh wow, yup it is related.  I wonder what's eating all the vmalloc space.. Can I have your full /var/log/dmesg?

You still won't get desktop effects I'm afraid, there's no 3D driver yet :)

Comment 6 Richard Colley 2009-04-15 04:46:48 UTC
Bugger about the desktop effects.  Oh well :)

Attached are the dmesg file and output from /proc/meminfo.

Comment 7 Richard Colley 2009-04-15 04:48:08 UTC
Created attachment 339623 [details]
full /var/log/dmesg

Comment 8 Richard Colley 2009-04-15 04:48:37 UTC
Created attachment 339624 [details]
output of /proc/meminfo

Comment 9 Richard Colley 2009-04-15 04:51:41 UTC
Created attachment 339625 [details]
output of dmesg

Comment 10 Richard Colley 2009-04-15 09:31:20 UTC
Adding vmalloc=128M to the kernel boot args has "fixed" the problem.

The vmap allocation error is no longer displayed.  X with the nouveau driver starts successfully.

The question is why so vmalloc needs to be so big?

NB: I have a dual-headed setup, and have the following xorg.conf screen config:

Section "Screen"
        Identifier      "Screen0"
        SubSection      "Display"
                Depth 24
                Virtual 2560 1024
        EndSubSection
EndSection

Note the screen size ... so I can have a different desktop (side-by-side) on each monitor.  Is this the reason for the memory requirements?

Comment 11 Richard Colley 2009-04-15 09:40:19 UTC
Created attachment 339660 [details]
cat /proc/vmallocinfo

In case it is useful, I have attached the output of: cat /proc/vmallocinfo

Comment 12 Ben Skeggs 2009-04-15 12:08:34 UTC
Hmm, it looks like your card may be one of the NVIDIA GPUs with a larger than normal register aperture.. Since we don't even know what lives there, it'd be safe for us to not map the unused parts of it.  Can you post "lcpsi -vvn" for me so I can confirm?

Comment 13 Richard Colley 2009-04-16 01:33:46 UTC
Created attachment 339767 [details]
lspci -vvn output as requested

Comment 14 Ben Skeggs 2009-04-19 22:58:25 UTC
This should work fine for you as of kernel-2.6.29.1-95.fc11.

Thanks!


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