Bug 26986 - TNT2 crashed on startup with 2.6.34-rc1
Summary: TNT2 crashed on startup with 2.6.34-rc1
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-09 18:57 UTC by Andrew Randrianasulu
Modified: 2010-09-11 23:41 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
X log (26.95 KB, text/plain)
2010-03-09 18:58 UTC, Andrew Randrianasulu
no flags Details
/var/log/debug (75.28 KB, text/plain)
2010-03-09 19:01 UTC, Andrew Randrianasulu
no flags Details
/var/log/messages (131.98 KB, text/plain)
2010-03-09 19:01 UTC, Andrew Randrianasulu
no flags Details
/var/log/syslog (12.79 KB, text/plain)
2010-03-09 19:02 UTC, Andrew Randrianasulu
no flags Details
X log (26.98 KB, application/octet-stream)
2010-03-09 21:21 UTC, Andrew Randrianasulu
no flags Details

Description Andrew Randrianasulu 2010-03-09 18:57:27 UTC
Well, i have nouveau_vieux_dri.so in my system.

But thing is ... exactly this setup works with 2.6.32-based nouveau kernel tree.

Trees used:
mesa: commit e5923a1240d8b32f5af080b0b4191d3b9299a630 (Merge branch '7.8')
drm: commit 04fd3872ee8bd8d5e2c27740508c67c2d51dbc11 (nouveau: Small lighting related addition to nouveau_class.h.)

kernel (good): commit 4b52473c354f7238afe0c78f50a6c84c40aa3478 ( drm/nv50: add a memory barrier to pushbuf submission)

kernel (bad): commit 57d54889cd00db2752994b389ba714138652e60c ( Linux 2.6.34-rc1)

xf86-video-nouveau: commit 29647021044463768cbfa3eead1416ef1cf27fa1 ( remove drm patchlevel check, libdrm checks this for us )

xserver: commit db4f676f25c6d8e58263d5151942be730592d444  ( xselinux: Bump extension minor version.)

usual logs follow ....
Comment 1 Andrew Randrianasulu 2010-03-09 18:58:04 UTC
Created attachment 33902 [details]
X log
Comment 2 Andrew Randrianasulu 2010-03-09 19:01:05 UTC
Created attachment 33903 [details]
/var/log/debug

manually echoed "15" into drm module parameter in /sys after kms init. KMS console was OK. Only X start caused strange splash effect and then X segfaulted/killed.
Comment 3 Andrew Randrianasulu 2010-03-09 19:01:47 UTC
Created attachment 33904 [details]
/var/log/messages
Comment 4 Andrew Randrianasulu 2010-03-09 19:02:12 UTC
Created attachment 33905 [details]
/var/log/syslog
Comment 5 Andrew Randrianasulu 2010-03-09 19:05:31 UTC
This crash is unfortunate, because i has hope to improve nv04 DRI driver a bit. 
Comment 6 Andrew Randrianasulu 2010-03-09 21:21:59 UTC
Created attachment 33909 [details]
X log

Upgrading X (to latest master + Francisco's  dri2 patches, due to new dri2proto installed), Mesa, DDX doesn't help. Nor removing dri driver ....

I found this  a bit weird:

[100.725] (II) NOUVEAU(0): GART: 32MiB available
[   100.725] (EE) NOUVEAU(0): Unable to allocate GART memory

....

[   100.775] (WW) NOUVEAU(0): Failed to retrieve fbcon fb: id 25
[   100.775] (II) NOUVEAU(0): NVEnterVT is called.
[   100.775] Unable to get master: -1

May be some changes in gart drivers in new kernel caused this bug to surface?
Comment 7 Andrew Randrianasulu 2010-03-10 10:46:56 UTC
Ok, setting AGP aperture size in BIOS down to 4mb helped!



guest@slax:~$ dmesg | grep gart 
Linux agpgart interface v0.103
agpgart: Detected VIA KT266/KY266x/KT333 chipset
agpgart-via 0000:00:00.0: AGP aperture is 4M @ 0xe0000000
agpgart-via 0000:00:00.0: AGP 2.0 bridge
agpgart-via 0000:00:00.0: putting AGP V2 device into 4x mode

guest@slax:~$ dmesg | grep apert
agpgart-via 0000:00:00.0: AGP aperture is 4M @ 0xe0000000
[drm] nouveau 0000:01:00.0: 4 MiB GART (aperture)


guest@slax:~$ cat /usr/X11/var/log/Xorg.0.log | grep GART
[    58.010] (II) NOUVEAU(0): GART: 4MiB available
[    58.099] (II) NOUVEAU(0): GART: Allocated 3MiB as a scratch buffer
Comment 8 Andrew Randrianasulu 2010-09-11 23:41:04 UTC
Because i see no crashes with same TNT2 and kernel 2.6.36-rc3 - closing.


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.