Summary: | TNT2 doesn't start with current nouveau | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Andrew Randrianasulu <randrik> | ||||||||||
Component: | Driver/nouveau | Assignee: | Nouveau Project <nouveau> | ||||||||||
Status: | RESOLVED DUPLICATE | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||
Severity: | normal | ||||||||||||
Priority: | medium | ||||||||||||
Version: | git | ||||||||||||
Hardware: | x86 (IA32) | ||||||||||||
OS: | Linux (All) | ||||||||||||
Whiteboard: | |||||||||||||
i915 platform: | i915 features: | ||||||||||||
Attachments: |
|
Description
Andrew Randrianasulu
2009-08-02 01:32:42 UTC
Created attachment 28254 [details]
full X log
Created attachment 28255 [details]
xorg.conf
Bug present with both KMS and non-KMS cases. Option NoAccel "1" gives me different segfault: (II) Module shadowfb: vendor="X.Org Foundation" compiled for 1.6.99.1, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (--) Depth 24 pixmap format is 32 bpp (II) NOUVEAU(0): Saving VGA fonts (II) NOUVEAU(0): Saving crtcs (II) NOUVEAU(0): Saving encoders (==) NOUVEAU(0): Backing store disabled (==) NOUVEAU(0): Silken mouse enabled (II) NOUVEAU(0): NVEnterVT is called. (II) NOUVEAU(0): Saving VGA fonts (II) NOUVEAU(0): Saving crtcs (II) NOUVEAU(0): Saving encoders Backtrace: 0: /usr/X11/bin/X(xorg_backtrace+0x34) [0x80a2134] 1: /usr/X11/bin/X [0x80a5614] 2: [0xffffe410] 3: /usr/X11R7/lib/xorg/modules/drivers/nouveau_drv.so [0xb7941fb2] 4: /usr/X11R7/lib/xorg/modules/drivers/nouveau_drv.so [0xb7942b50] 5: /usr/X11/bin/X(AddScreen+0x1a4) [0x8069784] 6: /usr/X11/bin/X(InitOutput+0x222) [0x80b4072] 7: /usr/X11/bin/X [0x806335c] 8: /lib/libc.so.6(__libc_start_main+0xe5) [0xb7a1e6a5] 9: /usr/X11/bin/X [0x8063101] Segmentation fault at address 0x8 So, i'm using vesa driver right now. Just making sure: did you recompile all X drivers after updating xorg-server? Especially evdev has been quite segfaulty in the past. Based on the backtrace it looks like it would be stuck in an ioctl call in kernel. I'm guessing a kernel log with drm.debug=1 could be useful (and very verbose, watch out for kernel message buffer overruns). We're mainly interested in the KMS case with acceleration. Yes, i recompiled evdev and bug still here. Once i even run eterm sucessfully, but it segfaults very fast afterwards. i'll add drm debug log tonight. Created attachment 28283 [details]
newer X log
Created attachment 28284 [details]
last 4000 lines from /var/log/debug
(In reply to comment #7) > Created an attachment (id=28284) [details] > last 4000 lines from /var/log/debug Right, so for some reason it is spinning in DRM_NOUVEAU_GEM_CPU_PREP ioctl, which never completes. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.