SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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.
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
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.
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
Last edited by Nille_kungen; 02-04-2011 at 08:22 AM.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,097
Rep:
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) .
Last edited by cwizardone; 02-04-2011 at 12:55 PM.
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!
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
Last edited by BobNutfield; 02-04-2011 at 03:53 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.
..."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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.