Random system hang ups
 

My machine is ThinkPad T60. I use it with Slackware 13.0 with my custom generic smp kernel 2.6.29.6 (the only difference between original and my custom kernels is Tuz in the first and Tux in the second).

My system hangs up one or two times a day: the screen freezes, the keyboard locks and – if I play some music – sound system starts to play one sound in a loop. I use Window Maker. When I encountered hung ups I ran usually a few xterms, two Firefoxes (on two user accounts) and MLDonkey 3.0.0 taken from SlackBuilds.org. Sometimes I used also moc 2.4.3 (music on console) taken from SlackBuilds.org too.

I inspected /var/log/messages trying to determine what happened when the system hung up but I found nothing relevant. The system hangs up usually when I switch from one application’s window to another but it isn’t a rule.

In this example I switched applications windows:

In that example machine worked for a few hours untouched:

To determine more precisely the time of that hang up I inspected /var/log/syslog but I found nothing interesting:

I ran the same applications when I used my machine with Slackware 12.2 and everything worked well. The main difference between Slackware 12.2 and Slackware 13.0 installation in the case of that machine is the lack of the proprietary fglrx module in my new system: with Slackware 12.2 I used fglrx and with Slackware 13.0 I use radeon.

Is there any method to determine the reason of such hang ups maybe by running some tracking program in the background?

You could try disabling direct rendering in the X server to see if that stops the lock ups. If your machine keeps locking up, it's very unlikely that it's related to the video driver. You can disable this by adding these lines to the "Module" section of your xorg.conf file:

Disable "dri"
Disable "dri2"

If you don't have a Module section, you can create one.

Adam

Tonight my machine hung up untouched for the next time.

Now I disabled those two modules in /etc/xorg.conf according to your suggestions:

I inspected /var/log/Xorg.0.log and it seems dri* modules aren't loaded:

I run my machine using the same set of the applications as before. Now I can merely wait until my machine will hang up (or not).

I am having the same issue on a Toshiba A105 with 13.0 where 12.2 worked fine, seemingly random lock ups. No mouse or keyboard, ssh or networking freeze as well. I have created a new account using default settings and it has been running for ~36 hours so far without a lockup.

What's difference between your old accounts and that new one? What you mean saying about ``default settings''? What commands you use to create that new account?

This is an excerpt from my script for configuration of users' accounts:

As you see I use useradd command for the first user and adduser for the second. In the past I used useradd command for both users but it caused some strange problems. It was the first issue I posted here: Midnight Commander hangs up console or xterm.

I created the account using adduser and didn't mess with any of the KDE settings (Window Behavior, etc.). So far so good. I used useradd earlier today and my wife said it wouldn't startx properly. She refused to give me any details about the error it was giving so that's all the info you get :doh:.

It’s 32 hours after I disabled DRI in my xorg.conf and 24 hours since last reboot. My machine works flawlessly though I didn’t break yet the 36-hour record achieved by kd5zex on his Toshiba A105. Anyway I’m signing the thread as solved. If I’ll encounter the problem mentioned above anew I’ll reopen that thread once again. Thank you adamk75 for your valuable hint and thank you kd5zex for your supporting assistance.

It might be worth reporting this bug upstream on the freedesktop bugzilla if you'd like to get 3D acceleration going again :-) The first thing they'd probably suggest is trying a newer kernel to see if the lockup is still happening.

I have two ThinkPads: T60 with ATI Mobility Radeon X1300 and T40 with ATI Mobility Radeon 7500. On both machines I installed Slackware 13.0. Until now I used T60 exclusively.

Before report a bug I have to test it throughout:

1. Run T60 with DRI disabled for a few days to ensure the problem disappeared.
2. Run T60 with DRI enabled till the first hang up to ensure the problem persists.
3. Do the test with DRI enabled with the newest kernel version to ensure the problem persists.
4. If the problem will persist with the newest kernel version do the test with DRI disabled to ensure the problem disappeared.
5. Alternatively do all the above tests with my second machine.

To perform these tests for just one machine I need about one week. I'll test it throughout but don't expect that I report it here fast.

I performed a lot of tests and I narrowed the problem once more.

According to my schedule from the above post first I ran my machine using kernel 2.6.29.6 with DRI disabled for a few days to ensure disabling DRI removes the problem and next I ran my machine with DRI enabled till the first hang up to ensure the problem is caused by DRI. Everything worked according to these assumptions. Then I did the test with DRI enabled using generic smp kernel version 2.6.31 to ensure the problem persists. With the kernel 2.6.29.6 I had to wait a dozen or so hours in order to hang up the machine. With the kernel 2.6.31 it was enough to wait a dozen or so minutes. So I started further tests and finally I found the method to hang up my machine in a dozen or so seconds.

I use Window Maker and twelve dockable applications: wmCalClock, wmpower, wmnet, wmbiff, wmsm, wmtop, wmdrawer, wmSun, wmMoonClock, wmweather, wmmixer and wminfo.

To run them I use such commands:

All these programs are accessible in SlackBuilds.org – some of them require special configuration files or plug-ins.

During my tests I stated that to hang up my machine is enough to:

1. Run Window Maker and some of these dockable applications from first user’s account.
2. Run Window Maker, xterm and Midnight Commander from second user’s account.
3. In Midnight Commander highlight the directory name and then press and keep Enter.

In result Midnight Commander flashes changing repeatedly the directory down and up. After a dozen or so seconds the system hangs up. Disabling DRI removes the problem.

Some dockable applications cause that problem and some doesn’t cause it. Among vulnerable applications are:

● wminfo,
● wmCalClock with wmpower,
● wmsm with wmdrawer,
● wmnet with wmweather and wmmixer,
● some other combinations of dockable applications.

The easiest way of hang up the system is to use wminfo. It works with kernels 2.6.29.6 and 2.6.31. To test it you have some plug-in, for example:

test.wmi
To run it you have to put test.wmi plug-in in the path and use the command:

I performed all the above tests on ThinkPad T60 with ATI Mobility Radeon X1300. Then I performed short test on ThinkPad T40 with ATI Mobility Radeon 7500. That older machine works flawlessly. So perhaps the problem concerns only one version of ATI Mobility Radeon or maybe just my card is invalid.

Finally I tried to connect to https://bugs.freedesktop.org/ but Firefox displayed the warning:

I never reported bugs on the freedesktop bugzilla. Is that problem sufficiently tested to report a bug or should I perform some further tests? Is it secure to connect to bugs.freedesktop.org now or it’s better to wait for a new security certificate?

Maybe someone here has a machine with ATI Radeon and will be so kind to spend a quarter running Window Maker with wminfo from first account and Window Maker with Midnight Commander from the second one testing it with DRI enabled and disabled?

Every assistance will be welcomed.

Disabling DRI and DRI2 solves the problem with the random hang ups but it causes other problems (see: here).

I partially solved the problem with random system hang ups and described it here. I achieved it by replacing default xf86-video-ati driver in version 6.12.2 by version 6.12.4. The system still hangs up but about 8.7 times less frequently than with default driver.

Ok the Toshiba has started to freeze again every few hours. I have disabled dri and dri2 and will report back later.

Try to replace your current driver with the newest one as I described it here. In the consecutive post you'll find SlackBuild script to build xf86-video-ati driver version 6.12.4. I replaced the driver 36 hours ago. Since that time my machine hung up just once. I still observe it.

Hi,

In your previous post of the '/var/log/Xorg.0.log' you don't seem to have 'dri' dis-enabled. The bold part indicates that 'dri' is to be loaded. I noticed in my '/var/log/Xorg.0.log' the same after I disabled. The 'dri' was disabled by;
I'm not sure how to proceed to replace the 'libdri'. The use of 'xf86-video-ati-6.12.4.tar.bz2' has gotten me to this point. I'm getting used too the new Xorg. 'X' is not one of my strengths but now I'll have to finally make the jump an learn more.

I was not able to even get this far until I did;

I added the Disables for 'dri' and 'dri2'. The hardware seemed to init and recognize differently when the disables were introduced. The '200M' was initialized but that damn 'libdri' got me. The hardware is a 'Dell Inspiron 1501' with a 'ATI Radeon XPRESS 200M 5975 (PCIE)' which has been giving me fits.

Reading more than I really want about other peoples issues. 'ATI' just drives me nuts over this one. :)

You’re perceptive. I overlooked it. Now I tested it throughoutly...

1. First test:

2. Second test:

3. Third test:

4. Fourth test:

5. Fifth test:

As you see the second test (with disabled DRI and DRI2) and the third test (with additionally omitted xfree86-dga) give exactly the same result. My machine hangs up when DRI is loaded (the first and the fourth tests). When DRI is disabled (the second, the third and the fifth tests) machine works flawlessly but MPlayer is unable to scale movies and Xine scales them without anti aliasing.

What are you trying to do? ati-6.12.4?

That's right. I try xf86-video-ati-6.12.4. With DRI enabled the system hangs up when I use Window Maker with some dockable applications simultaneously on two accounts. With former xf86-video-ati results was even worse (the system hanged up more frequently).

I also had exactly the same issue as you all describe: random hangs with keyboard locked. In my case the solution was to disable hald polling my cdrom /dev/hda every 2 seconds.

I pushed my system with ati-6.12.4 and mesa-7.5.2. Mesa 7.5.1 (current) and ati-6.12.2 sould work until you build your new driver. I'm at work now and out of Slack =[

I saw your script and are in doubt if x sources are needed to build the driver (or mesa?). Mine is slightly different.

To build the driver standalone you are missing something like 'xserver_source="/tmp/x-files/xorg-server-1.6.3"' and '--with-xserver-source=${xserver_source} \', where 'x-files' is your environment to to build x and the sources are decompressed inside. Please check CFLAGS and CXXFLAGS.

Are you shure '--with-wx-config' is needed?

Thank you for the suggestions. Former SlackBuild for xf86-video-ati driver was sloppy. I updated it and added SlackBuilds for xorg-server and mesa. All SlackBuilds are accessible here.

Instal mesa-7.5.1 from current or wait 7.5.2 and revert to ati-6.12.2. Start a fresh build. Maybe you'll need to update some some other libs too. Try to keep the variables from Slackware and you will assure at least compatibility... And don't mess wiss xorg-server =]

In post #20 you suggested to switch to ati driver 6.12.4 and mesa 7.5.2. In post #21 you suggested to include xorg-server during ati driver compilation. In post #23 you suggest to not to use mesa 7.5.2, to revert to ati 6.12.2 and to not to mess with xorg-server.

I'm trying different driver's versions because I hope the new driver will work better in my system. I have real problem and I try different solutions. Before I changed the driver only. After your suggestions I compile it including xorg-server. I test it with different versions of mesa. I do it following your suggestions.

Sorry, maybe I wasn't clear enought. I tried to say that it is possible to accomplish you goal.

You needed only the xorg-server source, decompressed. You don't need to rebuild xorg-server, but the driver need the xorg source to implement some functions.

I built by hand mesa-7.5.2, a bugfix for 7.5.1. Mesa 7.5.1 was officially shipped for test by Slackware and maybe soon mesa 7.5.2 will hit current (or not).

So, if you try mesa-7.5.1 and keep ati-6.12.2, all of them built 'for' and 'by' Slackware, you should be playing on the safe side.

Relax, I just tried to help as was messing with almost the same things =]

Mesa-7.5.2
libdrm-2.4.14
xf86-video-ati-6.12.4
xf86driproto-2.1.0

As I wrote in the complementary thread (messages #9, #21 and #23) I tried different combinations of drivers and libraries. Unfortunately any of them helped me to get rid of the system hang ups.

Two weeks ago the situation was clear. Newest ATI driver worked significantly better than older versions. I decided to wait a while before I'll submit the bug. Now I repeated the tests and the situation is ambivalent. The system works slightly better with new ATI driver or new Mesa but the difference isn't so distinct.

It seems I finally solved the problem of random system hang ups. I found the solution thanks to that thread: Radeon kms works! by dolphin77.

I used two scripts by dolphin77 to download and build xf86-video-ati driver from GIT...

First script downloads sources and builds source package:

get-xf86-video-ati
Second script builds the package:

xf86-video-ati.SlackBuild
After upgrade to xf86-video-ati-20091010_git-i486-1 I was unable to hang up the system using the procedures described here.

I used that newest driver with default 2.6.29.6 generic smp kernel, default mesa 7.5 (build 2) and default xorg-server 1.6.3.

***

I wrote about it also in that fork thread.

***

[EDIT]
In post #33 I describe simpler method of avoid random system hang ups.
[/EDIT]

Hi,

I'm curious about your '/var/Xorg.0.log' after the changes now. I would appreciate it if you would post the modules portion along with the loads informational (II). What about 'dri', any warnings or errors as before?

Xorg.0.log with xf86-video-ati-6.12.2-i486-2:

Xorg.0.log with xf86-video-ati-20091010_git-i486-1:

The above two log files are slightly shortened.

Complete differences between two above log files:

DRI messages with xf86-video-ati-6.12.2-i486-2 and xf86-video-ati-20091010_git-i486-1 are exactly the same:

I suppose the key feature above is disabled unsupported XAA render acceleration in the case of old driver (6.12.2 build 2) and enabled EXA acceleration in the case of the newest driver (20091010_git).

I found simpler solution of the problem described in that thread:

1. I downgraded the system to default xf86-video-ati 6.12.2 build 2 driver.

2. I generated xorg.conf.new with X -configure command.

3. I copied it from /root to /etc/X11 directory and renamed to xorg.conf.

4. I added Option "AccelMethod" "EXA" line to Section "Device" of xorg.conf:

X Window using EXA acceleration method works flawlessly. Here's comparison of Xorg.0.log without and within EXA:

So to avoid random system hang ups is enough to include in xorg.conf that option:

Hi,

I'm getting a error when I run the script 'get-xf86-video-ati';

I'm getting the same error but xf86-video-ati-20091011_git.tar.bz2 source package is valid.

As I described in post #33 above I solved the problem using default xf86-video-ati 6.12.2 build 2. Driver xf86-video-ati 20091011_git includes option EXA by default. With driver xf86-video-ati 6.12.2 you have to include that option in xorg.conf yourself:

Try it and perhaps you'll avoid to install GIT version of the driver.

I encountered new problem with enabled:

When I run X Window as first user with startx command and then I run X Window as second user with startx -- :1 command the second user's session slows down when using such programs as: Firefox, Seamonkey, Konqueror, Opera etc. During window operations CPU usage for X jumps up to 97%. The first user can use these programs smoothly.

I found the solution of that problem as well. It's enough to enable:

So my Section "Device" looks now: