x11-base/xorg-server-1.3.0.0-r2 crashes with "Caught signal 11" when using x11-drivers/ati-drivers-8.443 with an ATI Radeon X1250 on Samsung R60 notebook Reproducible: Always Steps to Reproduce: 1. emerge ati-drivers-8.443 2. use "fglrx" as driver module in xorg.conf 3. startx Actual Results: Use the fglrx module and do startx with an ATI Radeon X1250 (Samsung R60 notebook) Expected Results: X produces blank screen, Xorg.0.log says "Caught signal 11". Run Xserver properly.
Created attachment 137618 [details] Kernel .config
Created attachment 137619 [details] Xorg log
Created attachment 137621 [details] Xorg config
Complain to ATI.
enable debug useflag and emerge again. Then post back your info for segv.
Created attachment 137694 [details] Xorg log with debug useflag Added the debug useflag and re-emerged ati-drivers. Hope that helps. Thanks in advance!
Created attachment 137695 [details] emerge --info output
(In reply to comment #6) > Created an attachment (id=137694) [edit] > Xorg log with debug useflag > > Added the debug useflag and re-emerged ati-drivers. Hope that helps. Thanks in > advance! > The debug useflag is only for the kernel module, not for the x11 driver. So to get debug output do: - reemerge ati-drivers with debug enabled - reboot (or rmmod and modprobe fglrx) - Look at /var/log/messages for the debug output. I don't know if it will spit something about the segfault out.
> So to get debug output do: > - reemerge ati-drivers with debug enabled > - reboot (or rmmod and modprobe fglrx) > - Look at /var/log/messages for the debug output. > > I don't know if it will spit something about the segfault out. /var/log/messages says (imho) nothing useful: # rmmod fglrx && modprobe fglrx messages output: [fglrx] Disable PAT [fglrx] asyncIODestroy finished! [fglrx] module unloaded - fglrx 8.43.2 [Nov 9 2007] on minor 0 [fglrx] Maximum main memory for locked dma buffers: 805 MBytes. [fglrx] ASYNCIO init succeed! [fglrx] PAT is enabled successfully! [fglrx] module loaded - fglrx (...) fglrxinfo output: #fglrxinfo Error: unable to open display :0
Added Option "AIGLX" "Off" to xorg.conf - no change.
(In reply to comment #10) > Added > > Option "AIGLX" "Off" > > to xorg.conf - no change. > catchsegv startx that might get us a more complete dump of the segv. If not I have no way of duplicating this issue.
(In reply to comment #11) > catchsegv startx that might get us a more complete dump of the segv. If not I > have no way of duplicating this issue. > "catchsegv startx >> segv.log" (in various combinations) creates an empty file, so I guess there is no output by catchsegv.
(In reply to comment #12) > (In reply to comment #11) > > catchsegv startx that might get us a more complete dump of the segv. If not I > > have no way of duplicating this issue. > > > > "catchsegv startx >> segv.log" (in various combinations) creates an empty file, > so I guess there is no output by catchsegv. > I am still unable to duplicate this. I guess you are stuck using previous driver or wait for the next release which will happen by the end of this week.
I can reproduce this. It happens only with xorg-server compiled with gcc-3.4.6. If i compile xorg-server with gcc-4.2.2, i can start x11 with ati-drivers. I have this result with xorg-server-1.4-r2 and xorg-server-1.4.0.90 Could perhaps be related to the problems i had with ati-drivers-8.43.2. I had to compile xorg-server and ati-drivers with gcc-4.2.2 as gcc-3.4.6 was not able to compile ati-drivers-8.43.2 so: gcc-3.4.6: -xorg-server+ati-drivers-8.43.2 dont work because of ati-drivers cannot be build -xorg-server+ati-drivers-8.433 dont work because of xorg-crash on startup. gcc-4.2.2 both combinations do work I should add, this is on a hardened amd64 box, so the unmasked gcc-4.2.2 may simply leave out some hardened parts which could produce this problem.
But, as you can see, I was using gcc-4.1.2. What about that one? Cannot try 4.2.2 by now, cause there is no Gentoo anymore. But I will certainly get back to it, if anyone can tell me, that this error happens with 4.1.2 as well as with 3.4.6 and NOT with 4.2.2. So: 3.*: no 4.1.2: no 4.2.2: yes Could you verify that? Thanks a lot!
i did now a test with 4.1.2 and if i did not make any mistake while testing, i have a different result (but remember, my system is hardened, so may have different results to yours): 3.*: no >4.1.2: yes
