Tiny Core Linux
Tiny Core Base => TCB Bugs => Topic started by: TaoTePuh on April 11, 2011, 09:04:35 PM
-
I have the following phenomenon on my notebook:
If swap was used during work, I can not shutdown the computer. It hangs during shutdown - the screen still shows the FLWM - cursor and keyboard are frozen - sometimes the keyboard LED are flashing (but not always).
If ramzswap is disabled with boot code "nozswap" and so the "regular" swap partition is used (in my case: /dev/sda2), all works well.
Does this sound familiar?
-
Could you be more exact about which LED is/are flashing?
-
Could you be more exact about which LED is/are flashing?
"Caps Lock" and "Scroll Lock"
-
AFAIK, flashing CapsLock is indication for kernel panic. :-\
-
AFAIK, flashing CapsLock is indication for kernel panic. :-\
Kernel panic? Yikes! Maybe there is a HAL 9000 inside my notebook which is fighting against shut down? Am I in danger? Should I change my identity? Okay, call me Bowman ...
-
I'm sorry Dave, I can't do that.
-
.. 2, 3, 4 : There is a flower within my warm heart, Daisy, Daisy ...
-
i can verify exactly the same problem some times
-
Would help to have the dmesg output of it, if you can catch it.
-
How to debug a system while it shuts down?
How to fetch dmesg during this time?
I thought I could place a few lines (like "dmesg > /foo/bar") in /sbin/poweroff, but this is not a script ...
EDIT: I tried syslogd, unfortunately without success. The last line that was logged is:
Apr 12 22:49:49 (none) daemon.info init: starting pid 8513, tty '': '/etc/init.d/rc.shutdown'
-
For example ssh to the system from a different box, and if it hangs on shutdown, see if you can still get dmesg from the ssh session.
Or shutdown from the cli instead of X with a bootcode of "debug", then you should see any errors on the console.
-
For example ssh to the system from a different box, and if it hangs on shutdown, see if you can still get dmesg from the ssh session.
Or shutdown from the cli instead of X with a bootcode of "debug", then you should see any errors on the console.
ssh
The ssh session is closed very soon after the poweroff command. At this time, there's nothing important logged in dmesg.
cli
If ramzswap was used during work, I can not switch to the cli. The system hangs immediately after the click on "Exit to Prompt" (with flashing "Caps Lock" LED).
-
edit: Sorry, misread your post. You get a kernel panic just killing Xvesa? Does a VT switch also cause that?
If not, what happens if you kill Xvesa from a VT?
-
Well, the way it sounds now the topic might be a bit misleading if the symptoms are not exclusively particular to system shutdown.
-
edit: Sorry, misread your post. You get a kernel panic just killing Xvesa? Does a VT switch also cause that?
If not, what happens if you kill Xvesa from a VT?
The VT way I did not understand.
But with killing Xorg and "sudo poweroff" I have a result. With some effort, I could create a "screen copy". Now I just need someone who speaks that language ...
-
Please tell us what version you are running, and show the output of 'free'.
-
Please tell us what version you are running ...
3.5.1
... and show the output of 'free'.
tc@box:~$ free
total used free shared buffers
Mem: 1033536 899348 134188 0 49880
-/+ buffers: 849468 184068
Swap: 2354844 0 2354844
tc@box:~$ cat /proc/swaps
Filename Type Size Used Priority
/dev/ramzswap0 partition 258372 0 -1
/dev/sda2 partition 2096472 0 -2
-
Why are you running ramzswap when you have real swap?
-
hihihi, that was my next question ... :D
ramzswap is a TC default ... I used it because it's there ... sorry, I'm just beginning to understand this all ...
The questions I have now are:
1.) Is ramzswap faster/better than a swap partition, although it must be compressed?
2.) If so, how do you calculate the size?
-
ramzswap is dynamically sized compressed swap in RAM.
It uses some RAM to hopefully provide more RAM via compressing as it swaps out.
If you have real swap, turn it off.
If you have a RAM problem, you may get kernel panics when it tries to swap back in.
I would run memtest86 overnight.
-
If you have real swap, turn it off.
Turn off ramzswap or the swap partition ?
If you have a RAM problem, you may get kernel panics when it tries to swap back in.
I would run memtest86 overnight.
I don't think that there is something wrong with the RAM - but here are some new information after more tests:
1) I can reduce the problem to ramzswap. With the following scenario, the notebook definitely crashes:
tc@box:~$ tce-load -i stress
/mnt/sda3/tce/optional/stress.tcz: OK
tc@box:~$ stress --cpu 8 --io 4 --vm 2 --hdd 1 --timeout 10s
stress: info: [6862] dispatching hogs: 8 cpu, 4 io, 2 vm, 1 hdd
stress: info: [6862] successful run completed in 10s
tc@box:~$ free
total used free shared buffers
Mem: 1033536 219984 813552 0 5704
-/+ buffers: 214280 819256
Swap: 2354844 33624 2321220
tc@box:~$ cat /proc/swaps
Filename Type Size Used Priority
/dev/ramzswap0 partition 258372 33624 -1
/dev/sda2 partition 2096472 0 -2
tc@box:~$ sudo swapoff /dev/ramzswap0
But if I turn off ACPI (boot code acpi=off), the computer does not crash with this scenario.
-
That may be a BIOS problem.
See if there is an update.
I meant to turn off ramzswap.
If you are just short of RAM, swapping to RAM makes little sense if you have real disk swap.
-
IIRC, you have complained about bugginess with ACPI before, is that the same machine?
IMHO, if acpi on or off under certain circumstances could make the difference between a kernel panic or not, I would not boot with acpi at all.
Exception would be after a BIOS update as gerald_clark suggested, or when changing kernel to a different version.
-
Actually, ramzswap is often useful even if one has real swap. If the ramzswap doesn't get full (and so the swapping continues to the next device) the responsiveness is hugely better than with disk-based swap only.
But the fact ACPI affects things makes me wonder where the blame really is.
-
Which is why I said "just short of RAM".
Many times dormant processes are swapped out to make room for
more processes and buffers.
Swapping these out to real HD frees up more RAM than swapping to ramzswap.
Thus you may see that some swap is in use, but the machine is not actively swapping.
-
IIRC, you have complained about bugginess with ACPI before, is that the same machine?
Yes, this is the machine (Toshiba Satellite M60-139) of which I reported in
http://forum.tinycorelinux.net/index.php?topic=8981.0
BTW: The machine works perfectly. I use it every day for several hours with Firefox, Thunderbird, LibreOffice, freemind, gimp2, remmina, geany, vlc, FoxitReader ... - and all at the same time ... The only problem I have is: "shutdown" (Note: often needed from remote).
IMHO, if acpi on or off under certain circumstances could make the difference between a kernel panic or not, I would not boot with acpi at all.
hmm, this is a Catch-22 situation:
1.) I can not shutdown the machine without ACPI
2.) If I enable ACPI, I can not shutdown the machine if I used ramzswap during work
And thus the conclusion is:
a.) with functionality in mind: "disable ramzswap"
b.) with performance in mind: "disable ACPI"
Exception would be after a BIOS update as gerald_clark suggested, or when changing kernel to a different version.
There is no BIOS update for this machine.
Actually, ramzswap is often useful even if one has real swap. If the ramzswap doesn't get full (and so the swapping continues to the next device) the responsiveness is hugely better than with disk-based swap only.
That's how I understood it. I found a comparison "Comparing swap I/O latencies for hard-disk and ramzswap. " in the compcache Wiki with this results:
Comparing average R/W times:
disk ramzswap
read 168 ms 12 us
write 355 ms 7 us
These are factors between 14.000 and 50.000!
BTW: I also found a similar issue in the Bug Tracker of the compache site: "Swapoff ramzswap0 hard freezes system if utilized"
http://code.google.com/p/compcache/issues/detail?id=41&can=1
... unfortunately without a solution ...
But the fact ACPI affects things makes me wonder where the blame really is.
Me too.
But back to my general questions about ramzswap : "When does ramzswap make sense and how much RAM I use for it?"
Are the following thoughts right?
1.) RAM is much faster than ramzswap is much faster than swap paatition is much faster than file swaping.
2.) Optimal scenarios are:
a.) No or seldom need for swap --> disable ramzswap because it occupies valuable RAM.
b.) If swap is needed --> allocate as little as possible ramzswap so that as much as possible valuable RAM is available. The typical usage of ramzswap should lie at XX%.
In any case: To prevent system crashes, you should have additional partition- or file swap (fallback).
-
To swapoff, you would probably need more RAM than you have.
The blocks would have to be uncompressed and copied to real RAM before they
could be freed.
The solution may be to simply NOT swapoff during shutdown.
-
This is really a good idea!
But how can I achieve this? poweroff is an exe-file and I can not edit it. Maybe you mean the Option -f (Force (don't go through init)):
- sync
- /usr/bin/filetool.sh -b -s -p
- sudo poweroff -f
Is this method safe?
Edit: Okay, -f works. Wow, so fast my computer was never turned off ... But what important (shutdown) things are not happening with this method?
Edit2: hey, hey, hey ... i have edit the file "/etc/init.d/rc.shutdown". I commented out the following lines:
#if ! grep -q "noswap" /proc/cmdline; then
# echo "${BLUE}Disabling swap space.${NORMAL}"
# /sbin/swapoff -a 2>/dev/null
#fi
Now it works.
EDIT: Because it is not a good idea to edit the file /etc/init.d/rc.shutdown directly and put it in the backup (upgrade problems), here is an other solution which let the things done by the script /opt/bootlocal.sh at every boot time :
##
## disable swapoff command in /etc/init.d/rc.shutdown
##
# Search lines which contain "Disabling swap space" and place a notice
sed -i -r 's/Disabling swap space/Disabling swap space - WILL NOT BE EXECUTED/}' /etc/init.d/rc.shutdown
# Search lines which contain "swapoff -a" and.
# place a comment character at the beginning of those lines
sed -i -r '/^\s*#/!{/swapoff -a/s/(.*)/#\1/}' /etc/init.d/rc.shutdown
-
Are the following thoughts right?
1.) RAM is much faster than ramzswap is much faster than swap paatition is much faster than file swaping.
Last part is wrong since several years. Would be true only after removing the "much" and only for =< Linux 2.4. and possibly very early 2.6
-
Last part is wrong since several years. Would be true only after removing the "much" and only for =< Linux 2.4. and possibly very early 2.6
While the kernel limits on that are no longer, it's still one abstraction layer more. Adding layers can't exactly increase speed :)
-
Last part is wrong since several years. Would be true only after removing the "much" and only for =< Linux 2.4. and possibly very early 2.6
While the kernel limits on that are no longer, it's still one abstraction layer more. Adding layers can't exactly increase speed :)
http://lkml.org/lkml/2005/6/29/11
http://lkml.org/lkml/2005/7/7/326
-
Ah, thanks, that second link made it clear. Didn't know it could do that ;)