problem after updating ati-dri and libgl to version 7.9-1

NeoXP · 2010-11-27 11:27:56

Yesterday I did a pacman -Syu and I could not start X anymore, after downgrading the recently updated packages one by one I isolated the problem to ati-dri and libgl. After looking through the forum I found out that these problems are due to the fact that I have disabled KMS (link).

Enabling KMS solved the issues but throws me back to the problem why I had KMS disabled. With KMS enabled my system keeps freezing regurarly after which I keep getting following message in my kernel.log:

Nov 27 11:26:06 localhost kernel: [drm:drm_edid_block_valid] *ERROR* Raw EDID:
Nov 27 11:26:06 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:06 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:06 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:06 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:06 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:06 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:06 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:06 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:06 localhost kernel: 
Nov 27 11:26:06 localhost kernel: radeon 0000:01:00.0: DVI-I-1: EDID block 0 invalid.
Nov 27 11:26:06 localhost kernel: [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID
Nov 27 11:26:18 localhost kernel: [drm:drm_edid_block_valid] *ERROR* Raw EDID:
Nov 27 11:26:18 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:18 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:18 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:18 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:18 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:18 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:18 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:18 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:18 localhost kernel: 
Nov 27 11:26:20 localhost kernel: [drm:drm_edid_block_valid] *ERROR* Raw EDID:
Nov 27 11:26:20 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:20 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:20 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:20 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:20 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:20 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:20 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:20 localhost kernel: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Nov 27 11:26:20 localhost kernel:

For now I downgraded to ati-dri and libgl version 7.8.2-3 and keep KMS disabled to get into X without problems.

I can't find another solution for the problem with KMS enabled, so if you have any clues please point me in the right direction.

mini · 2010-11-27 13:27:08

I have got the same problem. Downgrade solved it.
Edit:
I am using x86_64 distro

Last edited by mini (2010-11-27 13:30:45)

AndyRTR · 2010-11-27 14:02:46

enable kms and disable DRI and look if it keeps crashing. if not you can expect the crasher in mesa. at least try to find out where the KMS issue comes from and look if it's known upstream. downgrading is not a long term solution.

mini · 2010-11-27 18:39:19

I do not use xorg.conf. Which way I can enable kms and disable DRI?

NeoXP · 2010-11-28 10:04:28

AndyRTR wrote:

...downgrading is not a long term solution...

I totally agree, but for now this is the only solution that keeps me working with my system ;-)

mini wrote:

I do not use xorg.conf. Which way I can enable kms and disable DRI?

Same here.

I did find this post on the ubuntu forum, but when I follow the solution I end up with the conclusion that I don't have an I2C bus (???!!!???).

I updated my wife's laptop today without any problems at all (HP NX9420), the differences I believe to be related to this issue is that hers has a ATI Mobility Radeon X1600 and mine (HP 6820s) has a ATI Mobility Radeon X1350. Both systems are running 64-bit Arch.

skunk_junior · 2010-11-28 14:39:52

I had the same problems and after downgrade of ati-dri and libgl [and libev for awesome] X works again. But unfortunately the Problem is not KMS. Even with KMS enabled I was not able to start X. The `log' (short text after typing xinit that appears on tty1 when X is started) says that KMS was enabled.

I'm running
[skunk@deskskunk ~] $ uname -a
Linux deskskunk 2.6.36-ARCH #1 SMP PREEMPT Wed Nov 24 00:39:57 CET 2010 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ AuthenticAMD GNU/Linux
with a radeon-card
[skunk@deskskunk ~] $ lspci | grep VGA
04:00.0 VGA compatible controller: ATI Technologies Inc Radeon R350 [Radeon 9800 Pro]
I've got an up-to-date xorg-server etc.

What could I do to use new versions of ati-dri and libgl? right now they're blocked from upgrading but as AndyRTR wrote: ...downgrading is not a long term solution...

NeoXP · 2010-12-04 11:51:32

bump

benke · 2010-12-05 14:34:04

AndyRTR wrote:

enable kms and disable DRI

How to disable DRI if there's no xorg.conf file?

AndyRTR · 2010-12-05 15:11:18

add a xorg.conf file ?

NeoXP · 2010-12-05 19:09:37

AndyRTR wrote:

add a xorg.conf file ?

Problem is not X related, it is also occurring when X is not started. Also, isn't going back to an xorg.conf file a step back in the past and therefor not a solution to the problem?

Strangest thing is that my laptop doesn't have a DVI port.... is there a way to disable the seeking for a monitor on the DVI port?

Last edited by NeoXP (2010-12-05 19:13:22)

NeoXP · 2010-12-18 18:39:40

Summarizing the problem (and bumping the thread):

Upgrading to the latest versions of ati-dri, libgl and mesa forces me to enable KMS to be able to start X.
With KMS enabled my system freezes regulary and showing errors in kernel.log as posted in the OP
The problem is not "X" related because it also happens when booting to runlevel 3.
For now I'm stuck with "old" versions to be able to work with my system.

I've been looking around the net for the solution, but have not found it yet.

Regarding the tips about trying to disable DRI, is it possible to do this with use of the package driconf??? If so, a short howto would be nice.

hit · 2010-12-20 21:15:45

Disabling DRI is easy, but without it you have to forget about glx programs (i.e games), which are painfully slow.

/etc/X11/xorg.conf.d/10-modules.conf:

Section "Module"
  Disable "dri"
EndSection

Edit: Booted with no extra parameters (i.e nomodeset), no disabled modules (i.e dri or glx). So KMS is enabled now. X starts up with low resolution (800x600), but can be changed to the right one (xrandr -s 1680x1050). So question: why doesn't X automatically use it?

Last edited by hit (2010-12-22 15:07:08)

NeoXP · 2011-01-02 09:41:25

Been away for a while, but after updating my system I found out that the problem still exists.

I disabled dri, however this is not the solution (I would have been suprised if it was, since the problem with the freezing also happens when in runlevel 3). Still stuck with "old" versions for now.

I'll keep digging but related tips are still most welcome.

edit: typo

Last edited by NeoXP (2011-01-02 09:41:53)

kalski · 2011-01-09 14:23:21

Hi guys.

NeoXP, I had the same issue with my hp6820s, but here is how I solved it after spending couple of DAYS(unfortunately) in searching how to workaround the issue and finally dug into the code. Here is what I did:

I patched inside the kernel source (version 2.6.36.2) the drivers/gpu/drm/radeon/radeon_atombios.c file with the following changes(don't ask me how did I decide to do particularly this ) :

--- a/drivers/gpu/drm/radeon/radeon_atombios.c  2010-12-10 00:17:27.000000000 +0200
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c  2011-01-09 15:57:43.000000000 +0200
@@ -1040,6 +1040,16 @@
                                atombios_get_connector_object_id(dev,
                                                      bios_connectors[i].connector_type,
                                                      bios_connectors[i].devices);
+
+                       /* Ati Mobility Radeon x1350 - this board's DVI-I output port is not properly handled by the driver */
+                       if ((dev->pdev->device == 0x7196) &&
+                               (dev->pdev->subsystem_vendor == 0x103c) &&
+                               (dev->pdev->subsystem_device == 0x30d7)) {
+                               if (bios_connectors[i].connector_type == DRM_MODE_CONNECTOR_DVII) {
+                                       continue;
+                               }
+                       }
+
                        radeon_add_atom_connector(dev,
                                                  bios_connectors[i].line_mux,
                                                  bios_connectors[i].devices,

This actually fixes the issue with KMS enabled operation.

Of course you have to rebuild the radeon module. For me the easiest way was issuing these after performing the "Build configuration steps" from the "Kernel_Compilation_From_Source" wiki page:

make modules_prepare
make modules SUBDIRS=drivers/gpu/drm/radeon/
cp drivers/gpu/drm/radeon/radeon.ko /lib/modules/2.6.36-ARCH/kernel/drivers/gpu/drm/radeon/

Guys, I know this is not related to the current thread but..what is the easiest way to propose this fix to kernel maintainers?

Regards,
Kaloyan Dimitrov

Last edited by kalski (2011-01-09 14:28:49)

NeoXP · 2011-01-09 19:57:13

kalski wrote:

....
Kaloyan Dimitrov

Thxs man, It will be my first kernel-build, so I have to do some reading first, but I'll give it a try.

Will keep you posted.

NeoXP · 2011-01-10 21:07:02

@kalski,

Sorry to bother you, but I like to be sure that I understand everything correctly. This is how I've interpeted your fix:

1. I download the latest kernel from kernel.org.
2. I locate the "atombios_get_connector_object_id" section in the drivers/gpu/drm/radeon/radeon_atombios.c and add the lines starting with '+' from your post (without the '+' I presume).
3. I save the file and compile my kernel.
4. I build the radeon module.
5. I install the new compiled kernel.
6. I edit /boot/grub/menu.lst and add the lines to start my system with the new compiled kernel.

Thxs, NeoXP

skunktrader · 2011-01-10 21:45:23

NeoXP wrote:

2. I locate the "atombios_get_connector_object_id" section in the drivers/gpu/drm/radeon/radeon_atombios.c and add the lines starting with '+' from your post (without the '+' I presume).

man patch

PAPPPmAc · 2011-01-11 08:26:11

I'm getting the same behavior on my T60p with a Mobility FireGL V5250 (Workstation variant of the M56/ Mobility x1700, device 0x71d4). I've just downgraded for now, as it is not my primary machine, and the amount of special-case ugly in drivers/gpu/drm/radeon/ is more than I want to take on at the moment. Just chiming in to note that the regression is apparently not isolated to the Mobility Radeon x1350 for anyone hunting.

kalski · 2011-01-12 06:28:37

@NeoXP, I believe skunktrader gave you a clue how to perform step 2.
@PAPPPmAc, then what is to be done? Should I externalize these "quirks" in a new function and everybody having issues add their own card details to this quirk function?

BTW have in mind that there is a similar situation in the drivers/gpu/drm/radeon/radeon_atombios.c file in function radeon_atom_apply_quirks. However I don't even hit the case where it is executed so I am not sure whether this function should be extended with new quirks and called where the issue occurs. I think It's more safe to add a new function with quirks rather than reuse the mentioned one.

Regards,
Kaloyan

PAPPPmAc · 2011-01-12 19:15:42

@kalski Your solution seems to be consistent with the ones in radeon_atom_apply_quirks, the entry points to the function are at lines 771 and 959 of drivers/gpu/drm/radeon/radeon_atombios.c in 2.6.36... it looks like it is always called during setup, and adding checks for device, subsystem_vendor, and subsystem_device like yours should work. That said, you likely have to refer to the connectors by the notation used in the other quirk cases... and if I understood that completely I would fix it for both cards, but I don't quite.

If you haven't been exposed to it, the best tool I've found for figuring out the Linux kernel is http://lxr.linux.no/linux, it really is enormously helpful.

In general, the problem with graphics drivers isn't with the code, it's in the hardware. Several of the projects in the research group I work with are wrangling OpenCL, so I've had plenty of exposure to just how bad the hardware/software situation with GPUs is of late, I just try not to think about it too much.

kalski · 2011-01-12 20:04:10

@PAPPPmAc radeon_atom_apply_quirks doesn't get called for me. I already debugged this. I've gone through the code and where I placed the patch was the most suitable place I found.

Anyway, I won't bother you with this any longer. Concerning the tool - thanks, It looks like a neat kernel browser

EDIT: I am going to check this again. A second glance made me think that I was wrong when I debugged this.

Last edited by kalski (2011-01-12 20:17:34)

kalski · 2011-11-13 15:26:57

Hi all,

seems like radeon_atom_apply_quirks now is the proper place to put the patch. So here is how the patched file looks like for the linux-3.0.7 version:

--- a/drivers/gpu/drm/radeon/radeon_atombios.c  2011-10-17 00:15:11.000000000 +0300
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c  2011-11-13 18:12:09.000000000 +0200
@@ -375,6 +375,15 @@
                        return false;
        }
 
+       /* Ati mobility radeon x1350 - this board's DVI-I output is not properly handled by the driver */
+       if ((dev->pdev->device == 0x7196) &&
+           (dev->pdev->subsystem_vendor == 0x103c) &&
+           (dev->pdev->subsystem_device == 0x30d7)) {
+               if (*connector_type == DRM_MODE_CONNECTOR_DVII) {
+                       return false;
+               }
+       }
+
 
        /* Funky macbooks */
        if ((dev->pdev->device == 0x71C5) &&
@@ -1084,6 +1093,7 @@
                                atombios_get_connector_object_id(dev,
                                                      bios_connectors[i].connector_type,
                                                      bios_connectors[i].devices);
+
                        radeon_add_atom_connector(dev,
                                                  bios_connectors[i].line_mux,
                                                  bios_connectors[i].devices,

Arch Linux

#1 2010-11-27 11:27:56

problem after updating ati-dri and libgl to version 7.9-1

#2 2010-11-27 13:27:08

Re: problem after updating ati-dri and libgl to version 7.9-1

#3 2010-11-27 14:02:46

Re: problem after updating ati-dri and libgl to version 7.9-1

#4 2010-11-27 18:39:19

Re: problem after updating ati-dri and libgl to version 7.9-1

#5 2010-11-28 10:04:28

Re: problem after updating ati-dri and libgl to version 7.9-1

#6 2010-11-28 14:39:52

Re: problem after updating ati-dri and libgl to version 7.9-1

#7 2010-12-04 11:51:32

Re: problem after updating ati-dri and libgl to version 7.9-1

#8 2010-12-05 14:34:04

Re: problem after updating ati-dri and libgl to version 7.9-1

#9 2010-12-05 15:11:18

Re: problem after updating ati-dri and libgl to version 7.9-1

#10 2010-12-05 19:09:37

Re: problem after updating ati-dri and libgl to version 7.9-1

#11 2010-12-18 18:39:40

Re: problem after updating ati-dri and libgl to version 7.9-1

#12 2010-12-20 21:15:45

Re: problem after updating ati-dri and libgl to version 7.9-1

#13 2011-01-02 09:41:25

Re: problem after updating ati-dri and libgl to version 7.9-1

#14 2011-01-09 14:23:21

Re: problem after updating ati-dri and libgl to version 7.9-1

#15 2011-01-09 19:57:13

Re: problem after updating ati-dri and libgl to version 7.9-1

#16 2011-01-10 21:07:02

Re: problem after updating ati-dri and libgl to version 7.9-1

#17 2011-01-10 21:45:23

Re: problem after updating ati-dri and libgl to version 7.9-1

#18 2011-01-11 08:26:11

Re: problem after updating ati-dri and libgl to version 7.9-1

#19 2011-01-12 06:28:37

Re: problem after updating ati-dri and libgl to version 7.9-1

#20 2011-01-12 19:15:42

Re: problem after updating ati-dri and libgl to version 7.9-1

#21 2011-01-12 20:04:10

Re: problem after updating ati-dri and libgl to version 7.9-1

#22 2011-11-13 15:26:57

Re: problem after updating ati-dri and libgl to version 7.9-1

Board footer