Latest update to -Current has broken X

BobNutfield · 02-03-2011, 03:00 PM

Hello Everyone,

Well, this is deja vu all over again! It was just a few months a ago that a major upgrade to Slack -current broke KDE, though I could boot to XFCE4 at that time. Turned out that the upgrade to mesa-7.9 was the culprit, so a downgrade to 7.8 fixed it for the time being. I figured I would wait until 7.10 came out to try the upgrade again.

Well, mesa-7.10 did indeed appear in the latest upgrades, so I (foolishly) went ahead with it. But this time, X will not work at all, not even for XFCE4. It exits with error 11 (segmentation fault at address nil). I thought I would just once again fall back to mesa-7.8, but this time it is no longer found in /var/log/packages as it was last time.

The last time this happen, there were threads galore about the problem, but I have searched the threads from the last week or so and I appear to be the only one with this particular issue.

My laptop has an ATI X1250 chip, and normally uses the open source radeon driver.

Can anyone give me a hand with this, or maybe tell me where I can get mesa-7.8 to give that a try again? I would really appreciate it if someone who is an expert could tell me why this is happening and if there is someway I can fix it.

Thanks in advance for any help

Bob

volkerdi · 02-03-2011, 03:18 PM

Did you upgrade the rest of the X packages?

I noticed problems with mesa-7.10 installed here, too. My system (with a Radeon HD 4350) runs OK at first, but suffers random freezes where it will not respond to anything for a few seconds. This even happens on the text console if X is running in the background.

I'm thinking that it might be best to move mesa-7.10 into /testing, and bring back 7.9 (with more patches from the stable git branch) in the main tree. If it's still possible to compile 7.8 I might look into that for /pasture. With X in the current state, having more options is probably a good idea.

BobNutfield · 02-03-2011, 03:29 PM

Hello volkerdi,

Thanks for your reply. On my laptop, X would not even start. As I mentioned, it seg faulted and crashed on startup. However, I did find a copy of mesa-7.8.2 on a USB stick I had used for the last time mesa broke X, downgraded to it and it has fixed my system once again. I still cannot use desktop effects, but the desktop is stable as long as desktop effects are not running. So, it was once again the upgrade to mesa that broke X. I remember from the last time that, although people with other graphics chips also had issues, it seemed that those with ATI chips were the most prominent in the threads (if I remember correctly, that was last November I believe.)

If it fixed it for me, I would definitely try to downgrade to 7.8.2. Anything beyond that just doesn't seem to work with the new Xorg.

Bob

Nille_kungen · 02-03-2011, 03:51 PM

Reading this made me wonder if you followed the instructions in CHANGES_AND_HINTS.TXT for ATI/AMD video chipset?

Quote:

If you have an ATI/AMD video chipset and are having trouble with Xorg, try
enabled KMS to see if it makes a difference - some chipsets run better with
it and some work better without it. To enabled KMS, use the following
boot parameter as a lilo append: radeon.modeset=1
Alternatively, you can create /etc/modprobe.d/radeon.conf with the following
contents: options radeon modeset=1

Because if you use an X1000 series ATI card then it won't work if you doesn't use radeon.modeset=1
So it segmentfaults by default until you add radeon.modeset=1

BobNutfield · 02-03-2011, 03:57 PM

Quote:

Originally Posted by Nille_kungen

Reading this made me wonder if you followed the instructions in CHANGES_AND_HINTS.TXT for ATI/AMD video chipset?

Because if you use an X1000 series ATI card then it won't work if you doesn't use radeon.modeset=1
So it segmentfaults by default until you add radeon.modeset=1

Thank you for your advice. I did indeed know that this option was available if X did not work correctly under any conditions. However, this was not my issue. X worked fine (without this boot parameter) until the upgrade to mesa. Now that I have downgraded mesa, X once again works fine without using modeset.

I did try that last November when I experienced this issue, but it had no affect.

Thanks again,

Bob

willysr · 02-03-2011, 07:30 PM

I have a problem with VMWare also, but i suspect it's caused by the new Mesa since everything was fine before i upgraded Mesa

Nille_kungen · 02-04-2011, 08:10 AM

You could try the new xf86-video-ati-6.14.0 and see if it works.
I use an X1400 and going to try it myself since console doesn't work after some minutes. (ctrl+alt+F6 only goes black,i think i read somewhere that using gallium 3D fixes it)

*Edit* But that needs an 2.6.36 + kernel i think but not for older harware like the X1400

cwizardone · 02-04-2011, 12:53 PM

Well, to make a positive comment on a recent upgrade

let me say I haven't had any problems, but I'm using a Nvidia card. After over 20 years of buying nothing but ATi, a couple of months ago I bought Nvidia and that was because it was all the local shop had in stock. After using it for a while I wish I had made the change to Nvidia earlier. There hasn't been a single problem, video wise, since making the change. It is the best value in a video card I've seen in all the years I've been tinkering with computers.
I know this doesn't help with the immediate problem and a notebook user can't change his card, but thought this *might* point out the X upgrade did not create difficulties for everyone (and I fully expected it to do just that)

.

zbreaker · 02-04-2011, 12:56 PM

+1

Another Nvidia user....no issues at all after upgrades.

4Strings · 02-04-2011, 01:49 PM

Hi! Same issue here with my laptop with an ATI X1400 on board.

I couldn't start X after the latest mesa upgrades (mesa-7.10_84b857e and mesa-7.9).
I obtained the following segmentation fault:

Code:

Backtrace:
[  1858.369] 0: /usr/bin/X (xorg_backtrace+0x3b) [0x80e6f2b]
[  1858.369] 1: /usr/bin/X (0x8048000+0x5da65) [0x80a5a65]
[  1858.369] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xffffe40c]
[  1858.369] 3: /usr/lib/xorg/modules/extensions/libglx.so (0xb74b6000+0x4049c) [0xb74f649c]
[  1858.369] 4: /usr/lib/xorg/modules/extensions/libglx.so (0xb74b6000+0x37708) [0xb74ed708]
[  1858.369] 5: /usr/bin/X (InitExtensions+0x9d) [0x80cb9cd]
[  1858.369] 6: /usr/bin/X (0x8048000+0x1acf2) [0x8062cf2]
[  1858.369] 7: /lib/libc.so.6 (__libc_start_main+0xe6) [0xb7556c66]
[  1858.369] 8: /usr/bin/X (0x8048000+0x1aa71) [0x8062a71]
[  1858.369] Segmentation fault at address (nil)
[  1858.369] 
Fatal server error:
[  1858.369] Caught signal 11 (Segmentation fault). Server aborting
[  1858.369] 
[  1858.369]

I could partially fix in two ways:

Downgrading to the mesa-7.8.2 package (and re-installing the xf86-video-ati-6.13.2).
I could start X but I couldn't activate the KDE Desktop Effects in order to avoid KDE crashes.
In fact, KDE still crashes when i minimize a program and I try to restore it (as reported here)
Booting with the radeon module option "radeon.modeset=1".
I could start X and I could activate the KDE desktop effects without crashes, but unfortunately the desktop is very slow!

BobNutfield · 02-04-2011, 03:11 PM

It appears as though my laptop had exactly the same issues. Even with downgrading to mesa-7.8.2 I cannot use desktop effects (crashes KDE as well, and radeon.modeset=1 will not even allow desktop effects to start.) But I least have a stable desktop, albeit a little slower than it used to be.

Bob

allend · 02-04-2011, 10:39 PM

KDE 4.5 tries to implement desktop effects using OpenGL Shading Language for performance reasons as it addresses the hardware more directly. Hardware drivers may claim support for the OpenGL Extensions to do this when in reality they are not fully supported. http://blog.martin-graesslin.com/blo...orkspaces-4-5/

The Blur and Lancoz filter desktop effects are most affected by this problem. As a first attempt you could try disabling these desktop effects (either by using the KDE System Settings or by editing ~/.kde/share/config/kwinrc directly).
The preferred way is to add a blacklist to ~/.kde/share/config/kwinrc. See the post dated Sun, 07 Nov 2010 17:57:40 at http://web.archiveorange.com/archive...dtVvaRaXXoz4eq for a way to generate the required information as well as http://blog.martin-graesslin.com/blo...-kwin-effects/ for further details.

Another more drastic method is, as I understand it, to emulate the OpenGL Extensions in software. To do this: (from http://osdir.com/ml/kwin/2010-11/msg00177.html )

Quote:

..."export LIBGL_ALWAYS_INDIRECT=1" to ~/.xprofile (interpreted by kdm - for eg. startx
you'd have to add it to .xsession), then logout/login (just restarting kwin
won't work, you'll have to pass it the env explicitly then)

I have also seen reports that ATI hardware can be made to work if the KDE OpenGL startup checks are disabled. This is done by editing ~/.kde/share/config/kwinrc
e.g. http://kubuntuforums.net/forums/inde...0826#msg240826

Also be aware that if these startup checks have been performed and the OpenGL Extension support has not been found, then KDE will record this in ~/.kde/share/config/kwinrc as "OpenGLIsUnsafe=true". This needs to be changed to false for desktop effects to work.

kiroff · 02-06-2011, 12:33 PM

Quote:

Originally Posted by volkerdi

I'm thinking that it might be best to move mesa-7.10 into /testing, and bring back 7.9 (with more patches from the stable git branch) in the main tree. If it's still possible to compile 7.8 I might look into that for /pasture. With X in the current state, having more options is probably a good idea.

Hi Patrick,

I think that doing this will make people's life a lot more easier. I'm also one of those sad people having troubles with ATI and mesa.

dolphin77 · 02-06-2011, 01:46 PM

Dear Pat, dear all,

Please do not downgrade mesa. The kernel used in current has issues with some of ATI chips. It was reported here some time ago by Adam. http://www.linuxquestions.org/questi...update-855707/

We should either wait for the newer from longterm, or downgrade a kernel.

I am running on 2.6.37 but this is not a choice probably since we need a long term.

Also please think of enabling kms by default through radeon.conf for default installation since most chips today need it.

Would be also reasonable to modprobe it from let's say rc.modules.

Best regards,
Vladimir

willysr · 02-07-2011, 08:17 AM

2.6.35.11 is out now with bunch of bug fixes, including Radeon