Hard lock up when system is inactive
 

I don't remember when this problem started but I did not have this problem at all with 13.37 or any other distros before that.

There is no problem if the system is in use, it can keep going for hours. I also play some (native) games on the system and it doesn't happen then.

The problem always occurs when I leave it alone for about an hour and presumably power management kicks in.

It occurs irrespective of whether X is running. Once it happened before log in and the terminal was still visible but completely frozen.

nvidia driver or nouveau makes no difference.

The generic kernel, my own build of 3.2.37 or a 3.8.4 I have been trialling - makes no difference.

Magic sys rq - no effect.

There is nothing in any logfiles that I can see, but suggestions as to where else to look are very welcome.

I would suspect hardware - but in that case the system should be freezing under load (?) and it isn't.

The machine in question is nothing special, it's an old P4M800 based motherboard with a Pentium 4 3.4GHz, 1.5GB RAM and an AGP 7300GT graphics card. The wireless is a PCI BCM4318 (using b43 + the firmware).

I'm running Slackware 14 with fluxbox and no display manager.

Any ideas/pointers much appreciated.

I would suspect power management. Has it gone into some one of standby/suspend/hibernate? Disable power management and see if it occurs. It's about the only way a pc falls on it's sword doing nothing.

I'll have a look at the power management settings in the BIOS again and try to disable as much as possible. Thanks.

Is it reachable from another machine with ssh ?

I'm not sure as I don't have another machine available to try... but I might be able to get something set up.

Would trying to ssh in be worthwhile considering that not even sysrq works when it locks up?

I would also scour your window manager for power management settings. On this
the answer is yes. I'm battling lockups atm and the power off button runs an orderly shutdown, even though the keyboard is dead.

I vaguely remember a problem a while back with xscreensaver and the video driver. To be on the safe side, try to uninstall xscreensaver and see if the problem persists.

caravel: Your problem might be caused by power management. Maybe you computer has some issues with
suspend to RAM or suspend to Disk. I would advise you to back up your important data, and then try the
following.
1) as root type echo disk > /sys/power/state .
This triggers a suspend to Disk. The memory of your computer will be written to the swap partition (which
should be about twice your RAM for this to work correctly), and the computer will power off. Try to bring
back the computer with the power button and see if it hangs during the boot processs.
If the above does not give a hard lock, then try the following.
2) as root type echo mem > /sys/power/state
This triggers a suspend to RAM. The devices of your computer are put on low power, screen is turned off,
processor is stopped, but the RAM remains powered. You try to bring back your computer to working state
by pressing the power button. Again, you may get a hard lock.

The problems with the suspend to RAM are generally caused by the BIOS failing to bring back the power to
the screen, or messing the video memory. If indeed your problems are caused by suspend to RAM, you should
have a look at the kernel documentation, in the power/ directory. See in particular the files:
basic-pm-debugging.txt and s2ram.txt. The ACPI-HOWTO can be also a valuable source of information.

I have to hold the power button to force shutdown.

Well xscreensaver wasn't running, but removed it anyway.
Suspend to disk appears to work, shuts down, etc but when I boot up it's no different to a normal boot.

Suspend to RAM does not seem to be supported:
I tried

Worked fine...

Oddly enough after the second reboot from suspend to disk, I was logging in and it just locked up again... this is the first ever time it's froze when I've been sat in front of it.

Thanks for the help - much appreciated. Will have a look at BIOS settings next. Not sure when I'll be able to try to ssh into the box - it will involve either borrowing a laptop... or installing on my better half's windows PC...

...you could simply ping from the better half's windows box, or there are ssh-in-a-browser sites you could try from, without installing ssh...

Also, I had a similar issue back in the 12.2 days with a single older box, and never did find a solution, however, if you have access to another monitor, you may have better results.

Also, from a terminal, see if xset -dpms accomplishes anything.

cheers,

Here at work, I use PuTTY on Windows, which you can get from here:

http://www.chiark.greenend.org.uk/~sgtatham/

BTW, his puzzle collection compiles on slackware-current without needing non-Slackware packages.

Otherwise, I'm staying out of this one. I have multiple 32-bit PCs that have your issue. I call it "console blanking mixes with DRM and power management, causing bad results." On one PC where DRM is required in order to run X11, I compiled suspend/resume out of the kernel, but still have to be careful because the DRM power blanking absolutely insists on putting the monitor to sleep. The setterm command does nothing to help. On the PC that does not require DRM, I ripped out DRM, the console framebuffer, and suspend/resume; I've had no problems to date. Anyway, where the oopses happen, they happen either when the console is blanking, or when the console is being awakened.

On that front, there's been a tty locking fix and a DMI fix around kernel 3.8.8, so things like this might go away, might not. That's my two cents.

Maybe you have already done this - but did you update your lilo.conf to include
that append="resume" line? you need that to point to your swap space, otherwise suspend to disk will not work

caravel: I have found reports of system crashes after hibernate/resume for a system
with PM4800 motherboard like yours at https://bugs.launchpad.net/ubuntu/+s...ux/+bug/459743.
There is a line: ACPI Warning: Incorrect checksum in table [OEMB] - 6D, should be 5E 20090521 tbutils-246 in the dmesg output that is suggesting a problem with the BIOS.
Maybe you should try to do a grep ACPI /var/log/messages ; grep ACPI /var/log/syslog ; dmesg | grep ACPI
to see whether a similar warning appears.

I haven't had a chance to fiddle with that, but if the crashes continue I'll try it next, thanks.

I've just upgraded the kernel from 3.8.4 to 3.8.10 and so far the lock up has not occurred, but I'll need to see how it goes before assuming the problem is gone.

Thanks, I don;t use suspend to disk, but I'll keep that in mind.
I much appreciate your looking into this. I have searched logs for any ACPI related errors but there were none.

I also reset the optimised BIOS defaults and then configured the BIOS to disable the devices I don't use. So far so good.

Thanks again.

There have been no more hard lock ups since the upgrade to 3.8.10 - marked as solved, thanks to all.