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.
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.
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 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'm battling lockups atm and the power off button runs an orderly shutdown, even though the keyboard is dead.
I have to hold the power button to force shutdown.
Quote:
Originally Posted by kikinovak
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.
Code:
# removepkg xscreensaver
Well xscreensaver wasn't running, but removed it anyway.
Quote:
Originally Posted by edorig
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.
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:
Code:
# echo mem > /sys/power/state
bash: echo: write error: No such device
I tried
Code:
# echo standby > /sys/power/state
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.
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.
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.
Also, from a terminal, see if xset -dpms accomplishes anything.
I haven't had a chance to fiddle with that, but if the crashes continue I'll try it next, thanks.
Quote:
Originally Posted by mlslk31
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.
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.
Quote:
Originally Posted by AceofSpades19
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
Thanks, I don;t use suspend to disk, but I'll keep that in mind.
Quote:
Originally Posted by edorig
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 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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.