Bug 43448

Created attachment 54049 [details]
libgl verbose glxinfo

Looks like you attached the wrong glxinfo output.  Please attach your xorg log as well.

Created attachment 54077 [details] [review]
libgl verbose glxinfo

Here is the correct output of LIBGL_DEBUG=verbose glxinfo

Created attachment 54078 [details] [review]
xorg log

And here is my xorg log. Thanks for your interest and sorry for the bad glxinfo log.

Looks like /usr/lib64/dri/r600_dri.so's dri2CreateNewScreen() hook fails, but it's not clear why. Maybe you can try running glxinfo in gdb, setting a breakpoint at dri2CreateNewScreen and tracing where the failure is coming from.

check mesa is built with radeon drm support.

Dear,

I use default version of mesa (7.11.2) on Fedora 16, so I think it is build with radeon drm support, yes.

Tracing and debugging is not (yet) my skill level, but perhaps you can guide and help me. Here is what I get setting a breakpoint at dri2CreateNewScreen:

(gdb) run
Starting program: /usr/bin/glxinfo 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
name of display: :0
libGL: OpenDriver: trying /usr/lib64/dri/r600_dri.so

Breakpoint 1, dri2CreateNewScreen (scrn=0, fd=8, extensions=0x614f30, driver_configs=0x7fffffffd980, data=0x6160b0) at ../common/dri_util.c:865
865     {
(gdb) 

What else should I do ?

Thanks a lot !

(In reply to comment #7)
> What else should I do ?

First of all, run 'finish' and check that the return value of dri2CreateNewScreen is 0 as suspected.

If so, single-step through dri2CreateNewScreen and its callees with 'step' / 'next' to find out why it returns 0.

Hello,

I think I have found a solution for this problem and another. I have the same notebook with that graphics card and had some problems with it in the past months whenever I tried the open source driver from Debian unstable. It worked about a year ago but then I bought a 27" monitor which was only usable with its native resolution of 2560x1440 with the fglrx driver (which had some other problems by the way). I regularly tried the open source driver when new versions show up in Debian but since some months the XServer crashed immediately after the start with a segfault. In newer versions it became more graceful with the following log messages:

(EE) RADEON(0): radeon_surface_best failed
(EE) RADEON(0): radeon_setup_kernel_mem failed

After debugging like suggested in bug #48138 I found out that there is missing a case in r6_init_hw_info for setting num_banks. While there are cases for 0 and 1 the FirePro M7740 has a value of 2 at some bits of the tiling_config so it returns with -EINVAL from the default case. First I did not know on what to set num_banks in that case but tried something and the XServer started successfully with that change.

Then I saw in /var/log/Xorg.0.log that the 3D acceleration was not working like described in this bug report:

(EE) AIGLX error: Calling driver entry point failed
(EE) AIGLX: reverting to software rendering

I tried to debug that too, following the above hints and ended up in r600_interpret_tiling in src/gallium/drivers/r600/r600_pipe.c in the MESA code and found exactly the same reason as above, a missing case 2. In the meantime I checked out the source of xserver-xorg-video-ati too and sensitized by the above findings made a grep over all three source trees (libdri, mesa, xserver-xorg-video-ati):

grep "num_banks.*=" -rsn . -B 2 -A 1

There I found another missing case 2 in r600_interpret_tiling in src/radeon_kms.c and somewhere else an existing case 2 with num_banks = 16. So I patched all found asymmetries regarding case 2 and the 3D acceleration began to work again.

I append all three patches I made. Maybe someone can check them and add them if they are reasonable so future versions can incorporate the fixes.

Best regards
Stefan Kanarski

PS: Now my only problem is the resolution of 2560x1440 with my Fujitsu P27T-6. Via DVI I only get 1280x1440 (every second pixel column missing, looks like single-link although the cable should be dual-link) and via DisplayPort the monitor is toggling between power save and a black screen. But that's another story for another day or two. If someone has an idea where to start looking I am glad to hear.

Created attachment 62157 [details] [review]
Patch for branch debian-unstable in http://git.debian.org/pkg-xorg/lib/libdrm.git

Created attachment 62158 [details] [review]
Patch for branch debian-unstable in http://git.debian.org/pkg-xorg/lib/mesa.git

Created attachment 62159 [details] [review]
Patch for branch debian-unstable in http://git.debian.org/pkg-xorg/driver/xserver-xorg-video-ati.git

Created attachment 62246 [details] [review]
possible fix

It's actually a kernel issue.  The attached patch against Dave's drm-fixes branch should fix it.

Could libdrm_radeon also be made to deal gracefully with broken kernels?

Created attachment 62672 [details] [review]
libdrm fix

This patch should do the trick.

Created attachment 62674 [details] [review]
libdrm fix

slightly improved version.

I have a Hewlett Packard H8-1224 which has a Radeon HD7570 video card. Software is up to date Debian Wheezy, using the radeon X driver and the non-free firmware. The startup of X fails with the messages

[    18.376] (EE) RADEON(0): radeon_surface_best failed
[    18.376] (EE) RADEON(0): radeon_setup_kernel_mem failed

It's been suggested that my problem is related to the bug documented here.  To those more knowledgable than I - does this seem likely? I'll post the complete Xorg.log.

If the patches listed here are relevant, could someone explain - would ONE of the patches address the problem, or would they ALL need to be installed.

Thanks for your help!

Created attachment 63053 [details]
Xorg.log from HP H8-1224 with Radeon HD7570 and Debian Wheezy

(In reply to comment #17)
> It's been suggested that my problem is related to the bug documented here.  To
> those more knowledgable than I - does this seem likely?

Yes.

> If the patches listed here are relevant, could someone explain - would ONE of
> the patches address the problem, or would they ALL need to be installed.

Either alone should be sufficient.

The libdrm fix is in the 2.4.35 release and I think the kernel fix is in mainline as well, so resolving this report as fixed.

Further to the above - I have tried all the patches listed above, in various combinations, and the problem still exists.  The startup of X fails with the messages 

radeon_surface_best failed
radeon_setup_kernel_mem failed

Configuration (current Debian Wheezy):

Radeon 7570 card - PCI identifier 675D
Kernel: 3.2.0-2-amd64
xserver-xorg-video-radeon: 6.14.4-5
libdrm-radeon1 & libdrm2: 2.4.33-1
/etc/X11/xorg.conf.d: Does not contain a Device section.

(In reply to comment #20)
> Radeon 7570 card - PCI identifier 675D

That's a different card from the one this bug report is about.

> libdrm-radeon1 & libdrm2: 2.4.33-1

Support for your card was only added in libdrm_radeon 2.4.34.

Thank you for the information.  I found the PCI code 675D in various header files in xserver-xorg-video-ati-6.14.4 and mesa-8.0.2, leading me to believe that it was supported in Wheezy.  But now I see it is not mentioned in the .h files in libdrm-2.4.33.

A patch referencing this bug report has been merged in Linux v3.5-rc1:

commit 29d654067a98c1cb8874c774e5fd799a038af8a6
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu May 31 18:53:36 2012 -0400

    drm/radeon: fix bank information in tiling config