Bug 48138 - Segmentation Fault in xf86-video-ati-6.14.4 radeon driver
Segmentation Fault in xf86-video-ati-6.14.4 radeon driver
Status: RESOLVED FIXED
Product: xorg
Classification: Unclassified
Component: Driver/Radeon
unspecified
x86-64 (AMD64) Linux (All)
: medium major
Assigned To: xf86-video-ati maintainers
Xorg Project Team
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-31 17:02 UTC by Chris Woods
Modified: 2012-05-11 02:08 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Xorg.0.log with segmentation fault (27.34 KB, text/plain)
2012-03-31 17:02 UTC, Chris Woods
no flags Details
backtrace (2.42 KB, text/plain)
2012-04-01 11:54 UTC, Chris Woods
no flags Details
Fail more verbosely and gracefully (1.91 KB, patch)
2012-04-03 00:40 UTC, Michel Dänzer
no flags Details | Splinter Review
stepping through from RADEONScreenInit_KMS() (7.01 KB, text/plain)
2012-04-07 07:28 UTC, Chris Woods
no flags Details
Xorg.0.log with patch applied (27.10 KB, text/plain)
2012-04-15 17:04 UTC, Chris Woods
no flags Details
Debug best failure (2.71 KB, patch)
2012-04-16 07:30 UTC, Jerome Glisse
no flags Details | Splinter Review
Xorg log with Jerome's libdrm error debug messages (23.28 KB, text/plain)
2012-05-04 06:59 UTC, Anisse Astier
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Woods 2012-03-31 17:02:53 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.
Comment 1 Alex Deucher 2012-04-01 05:53:01 UTC
Can you install the debug packages for the xserver and get a proper backtrace with gdb?  Instructions:
http://wiki.x.org/wiki/Development/Documentation/ServerDebugging
Comment 2 Chris Woods 2012-04-01 11:54:09 UTC
Created attachment 59352 [details]
backtrace

Thanks for looking at this. Backtrace attached. Please let me know if this is not suitable.
Comment 3 Michel Dänzer 2012-04-02 02:09:33 UTC
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?
Comment 4 Chris Woods 2012-04-02 18:31:47 UTC
(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?

libdrm 2.4.33.

How would I go about tracing radeon_setup_kernel_mem() ? Sadly I'm not terribly familiar with the gnu toolchain.
Comment 5 Michel Dänzer 2012-04-03 00:40:56 UTC
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.
Comment 6 Chris Woods 2012-04-07 07:15:35 UTC
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]
Comment 7 Chris Woods 2012-04-07 07:26:32 UTC
I've stepped through a bit more (clumsily) without the patch applied. The gdb session with that is attached; perhaps it's helpful.
Comment 8 Chris Woods 2012-04-07 07:28:45 UTC
Created attachment 59625 [details]
stepping through from RADEONScreenInit_KMS()
Comment 9 Michel Dänzer 2012-04-10 04:23:56 UTC
(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.

Unfortunately not:

* 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.
Comment 10 Chris Woods 2012-04-15 17:03:04 UTC
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.
Comment 11 Chris Woods 2012-04-15 17:04:40 UTC
Created attachment 60040 [details]
Xorg.0.log with patch applied
Comment 12 Jerome Glisse 2012-04-16 07:30:28 UTC
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
Comment 13 Anisse Astier 2012-05-04 06:59:10 UTC
Created attachment 61025 [details]
Xorg log with Jerome's libdrm error debug messages

Hi,

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:

radeon_surface_sanity 919
radeon_surface_best 1014
(EE) RADEON(0): radeon_surface_best failed
(EE) RADEON(0): radeon_setup_kernel_mem failed

Full Xorg log in attachment.
Comment 14 Anisse Astier 2012-05-11 02:08:04 UTC
Chris,

A patch has been submitted in libdrm to fix this bug:
http://cgit.freedesktop.org/mesa/drm/commit/?id=cf7cc62a9817a495264bbb037f0175cef9bd7a53
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.