As can be seen in this Mandriva Linux Cooker bug: https://qa.mandriva.com/show_bug.cgi?id=61233 x11-driver-video-ati-6.13.2-3mdv2011.0 with x11-server-1.9.0-3mdv2011.0 on Mandriva Cooker, segfaults with KMS enabled on my AGP-based ATI Radeon HD 2600 Pro card (on a Pentium 4 2.4GHz machine - x86-32). Xorg.0.log containing a crash. This is an Xorg.0.log that contains a crash (I've checked it). Here is the crash backtrace from the console log: The fault we get is: [console] xauth: file /home/shlomif/.serverauth.2502 does not exist X.Org X Server 1.9.0 Release Date: 2010-08-20 X Protocol Version 11, Revision 0 Build Operating System: Linux_2.6.22.18-server-1mdv Mandriva Current Operating System: Linux telaviv1.shlomifish.org 2.6.36-desktop-0.rc7.1mnb #1 SMP Fri Oct 8 01:31:28 CEST 2010 i686 Kernel command line: BOOT_IMAGE=linux_with_kms root=UUID=0377c044-4829-11db-add1-67eccbf7a7bb resume=/dev/sdc5 splash=silent radeon.modeset=1 Build Date: 10 October 2010 08:31:12PM Current version of pixman: 0.19.4 Before reporting problems, check http://qa.mandriva.com to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Wed Oct 13 11:05:38 2010 (==) Using config file: "/etc/X11/xorg.conf" (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) Failed to load module "v4l" (module does not exist, 0) (II) [KMS] Kernel modesetting enabled. Backtrace: 0: /etc/X11/X (xorg_backtrace+0x37) [0x80e93c7] 1: /etc/X11/X (0x8048000+0x5e48a) [0x80a648a] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xffffe40c] 3: /lib/i686/libc.so.6 (0xb7421000+0x74f86) [0xb7495f86] 4: /lib/i686/libc.so.6 (0xb7421000+0x51394260) [0x87b5260] Segmentation fault at address (nil) Fatal server error: Caught signal 11 (Segmentation fault). Server aborting Please consult the The X.Org Foundation support at http://qa.mandriva.com for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. xinit: connection to X server lost. [/console] Note that debugging with gdb does not yield anything too meaningful - just that it's in memcpy. Maybe there was a stack smash. After downgrading to the Mandriva 2010.1 x11-server and x11-driver-video-ati, the problem and a related one (see https://qa.mandriva.com/show_bug.cgi?id=61251 ) disappeared. Please let us know how we can proceed. Regards, -- Shlomi Fish
Any chance you can bisect the driver and narrow down when this problem was introduced?
(In reply to comment #1) > Any chance you can bisect the driver and narrow down when this problem was > introduced? Here's what the final "git bisect bad" command returned: {{{ shlomif:~/Download/unpack/gui/xf86-video-ati$ git bisect bad f8fb9312d791af1f77020e8c2d35bb30841ed9aa is the first bad commit commit f8fb9312d791af1f77020e8c2d35bb30841ed9aa Author: Karl Tomlinson <karlt+@karlt.net> Date: Sun Aug 22 22:46:33 2010 +1200 RADEONPrepareAccess_CS: fallback to DFS when pixmap is in VRAM This avoids costly CPU VRAM reads and lets EXA manage a system memory cache of the portions of pixmaps needed for unaccelerated operations. https://bugs.freedesktop.org/show_bug.cgi?id=27139 :040000 040000 94afde6673141f2976633cbba6a946e336856e5f d7184fa36bb29ec3fd00d564293c041efd132e18 M src }}} And here's my git bisect log: {{{{ shlomif:~/Download/unpack/gui/xf86-video-ati$ git bisect log git bisect start # bad: [cc5005af61f45a3552f7358dc5aa711e42f5af54] bump version for release git bisect bad cc5005af61f45a3552f7358dc5aa711e42f5af54 # good: [fb7911912e60b2cdbc2152b96847775b767ca3ef] bump version for release git bisect good fb7911912e60b2cdbc2152b96847775b767ca3ef # good: [052cf0169ae70d5448af6dc4db840b2fc195569b] configure.ac: bump version post release git bisect good 052cf0169ae70d5448af6dc4db840b2fc195569b # good: [bb7c77ca75e857f90791b0dd1c04c8e2f19d0e3c] atom: upstream parser update git bisect good bb7c77ca75e857f90791b0dd1c04c8e2f19d0e3c # good: [9f13049ddf06f6f2138851a548cfb82f12a52f42] radeon: add correct flushing for direct rendered git bisect good 9f13049ddf06f6f2138851a548cfb82f12a52f42 # good: [bfebe039af0c0282d04eb6234b6e6d1e02097146] DownloadFromScreenCS: download via a scratch BO if pixmap domain is unknown git bisect good bfebe039af0c0282d04eb6234b6e6d1e02097146 # good: [35c4ff936601ee083f51510a5192fb97d622a483] radeon: complete UTS and DFS even when a scratch BO is not necessary git bisect good 35c4ff936601ee083f51510a5192fb97d622a483 # bad: [c4f834cdfbe96aa47ac5fb039f9dd7aa9730c8a3] radeon: Convert remaining x(c)alloc/xfree to m/calloc/free. git bisect bad c4f834cdfbe96aa47ac5fb039f9dd7aa9730c8a3 # bad: [f8fb9312d791af1f77020e8c2d35bb30841ed9aa] RADEONPrepareAccess_CS: fallback to DFS when pixmap is in VRAM git bisect bad f8fb9312d791af1f77020e8c2d35bb30841ed9aa shlomif:~/Download/unpack/gui/xf86-video-ati$ }}}}
does booting with: radeon.agpmode=-1 on the kernel command line help? I don't see why AGP would act any different then non-AGP in this case.
*** Bug 30458 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > does booting with: > radeon.agpmode=-1 > on the kernel command line help? > No, I'm getting the same bug with the latest drivers from Mandriva. I've booted with this command line: {{{ kernel (hd0,0)/boot/vmlinuz BOOT_IMAGE=linux_with_kms root=UUID=0377c044-4829-11db-add1-67eccbf7a7bb resume=/dev/sdc5 splash=silent radeon.modeset=1 radeon.agpmode=-1 }}} It loads the old driver's X fine. > I don't see why AGP would act any different then non-AGP in this case. Don't know.
Remove the EXANoDownloadFromScreen line from xorg.conf. UploadToScreen and DownloadFromScreen are required now.
*** This bug has been marked as a duplicate of bug 30647 ***
(In reply to comment #6) > Remove the EXANoDownloadFromScreen line from xorg.conf. UploadToScreen and > DownloadFromScreen are required now. Shouldn't this be enforced by the driver then? Either ignoring that option (and log it in xorg.0.log) or disabling any feature that would break then.
(In reply to comment #8) > (In reply to comment #6) > > Remove the EXANoDownloadFromScreen line from xorg.conf. UploadToScreen and > > DownloadFromScreen are required now. > > Shouldn't this be enforced by the driver then? > Either ignoring that option (and log it in xorg.0.log) or disabling any feature > that would break then. Those are EXA core options (not driver options) and the driver doesn't know if they've been been enabled or not.
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.