Bugzilla – Bug 48138
Segmentation Fault in xf86-video-ati-6.14.4 radeon driver
Last modified: 2012-05-11 02:08:04 UTC
Created attachment 59322 [details]
Xorg.0.log with segmentation fault
AMD bulldozer FX-6100, Radeon HD 7450 CAICOS, linux 3.2.12, KMS enabled. Built and loaded xf86-video-ati-6.14.4, upon attempting startx, segmentation fault encountered. Output of Xorg.0.log attached.
Can you install the debug packages for the xserver and get a proper backtrace with gdb? Instructions:
Created attachment 59352 [details]
Thanks for looking at this. Backtrace attached. Please let me know if this is not suitable.
Looks like radeon_setup_kernel_mem() is failing silently before allocating info->front_bo. Can you trace its execution to find out why it's failing?
Which version of libdrm do you have installed?
(In reply to comment #3)
> Looks like radeon_setup_kernel_mem() is failing silently before allocating
> info->front_bo. Can you trace its execution to find out why it's failing?
> Which version of libdrm do you have installed?
How would I go about tracing radeon_setup_kernel_mem() ? Sadly I'm not terribly familiar with the gnu toolchain.
Created attachment 59408 [details] [review]
Fail more verbosely and gracefully
(In reply to comment #4)
> How would I go about tracing radeon_setup_kernel_mem() ? Sadly I'm not terribly
> familiar with the gnu toolchain.
See the 'All the gdb commands you'll ever need' section on the referenced wiki page.
Anyway, this patch should make the failure more verbose and graceful. Please provide the log output from starting X with it applied.
Unfortunately it seems running with that patch applied makes the driver behave differently and terminates before I am able to get a backtrace. If I recompile without the patch applied, it behaves as previously described.
Starting program: /usr/bin/Xorg
[Thread debugging using libthread_db enabled]
[tcsetpgrp failed in terminal_inferior: Operation not permitted]
[Inferior 1 (process 28881) exited with code 01]
I've stepped through a bit more (clumsily) without the patch applied. The gdb session with that is attached; perhaps it's helpful.
Created attachment 59625 [details]
stepping through from RADEONScreenInit_KMS()
(In reply to comment #6)
> Unfortunately it seems running with that patch applied makes the driver behave
> differently and terminates before I am able to get a backtrace.
Yes, that's what I was trying to say in comment #5. :) Let me reiterate the request from there:
Please attach the Xorg.0.log from starting X with the patch applied.
(In reply to comment #7)
> I've stepped through a bit more (clumsily) without the patch applied. The gdb
> session with that is attached; perhaps it's helpful.
* As mentioned in comment #3, you'd have to step through radeon_setup_kernel_mem, before the SIGSEGV occurs in RADEONScreenInit_KMS.
* Single stepping in gdb is only really useful when gdb can access the source code files.
My apologies. I actually took some time to see if I could get this working with the fglrx driver - no luck there either. Anyway, Xorg.0.log with patch applied is attached.
Created attachment 60040 [details]
Xorg.0.log with patch applied
Created attachment 60066 [details] [review]
Debug best failure
Can you patch libdrm with that patch and run Xorg from ssh and capture stderr and attach it here. Thx
Created attachment 61025 [details]
Xorg log with Jerome's libdrm error debug messages
Different hardware here (AMD E1-1200), PALM Chip 1002:9809.
kernel 3.3.3 and Debian's DDX 6.14.4, libdrm 2.4.33 and mesa 8.0.2.
KMS is working, X server is not. I have the same error when starting the X server. Excerpt with Jerome's patch on libdrm:
(EE) RADEON(0): radeon_surface_best failed
(EE) RADEON(0): radeon_setup_kernel_mem failed
Full Xorg log in attachment.
A patch has been submitted in libdrm to fix this bug:
It's now in libdrm 2.4.34
It adds the PCI id of your card, so it should work now.
Please re-open the bug if it doesn't.