Swapoff ramzswap0 hard freezes system if utilized

[GoogleCodeExporter]

What steps will reproduce the problem?
1. swapon /dev/ramzswap0
2. stress --vm 7 --vm-keep
3. wait mere seconds for /dev/ramzswap0 to be utilized
4. swapoff /dev/ramzswap0

What version of the product are you using? On what operating system?
Both 0.6 and the latest source checkout (as of Oct. 12, 11:00) have this 
issue. Linux source 2.6.31.2 in Karmic, compiled with Ubuntu patches 10.34, 
autoiso_xorg, BFS 303, and swap_free_notify.

Please provide any additional information below.
This problem does not occur until the ramzswap0 device has been utilized, 
nor does it occur when using just a standard linux swap partition.

I am using an Asus Eee PC 1000H (Best Buy's custom version).

rzscontrol /dev/ramzswap0  --memlimit_kb=998400 --backing_swap=/dev/sda5 --
init

Attached is a portion of a log salvaged from /var/log/kern.log after a 
magic SysRq reboot. This was salvaged the first time the problem occurred. 
memlimit_kb had been set to 1.5gb at the time, higher than the recommended 
limit of ram/2. I have since reproduced this error many times with the 
above stated --memlimit_kb=998400.

Original issue reported on code.google.com by cjh...@gmail.com on 12 Oct 2009 at 5:59

• Blocked on: #45

Attachments:

• kern.log.cut

[GoogleCodeExporter]

I see curious messages in your log snippet:
Oct  9 01:36:42 Karmicode kernel: [  871.298670] ramzswap: Disk size set to 1 KB

Disk size 1KB? If you use rzscontrol with parameters you specified, you should 
never
get this message anyways. In my testing I never had problem with reset, swapoff 
etc.

Can you please provide your full kernel log?

Original comment by nitingupta910@gmail.com on 13 Oct 2009 at 3:07

[GoogleCodeExporter]

Sure, no problem. It's got a few days worth of logs in there.

I'm not entirely sure why it would set the disk size to 1 KB, as I did not do 
that 
myself. Is there a way to reliably get a crash dumped to a log after triggering 
this 
problem? There could be a chance the problem in the log and the problem I've 
reproduced is not the same.

I have been unable to reproduce these log findings. I would ideally like to 
reproduce 
the crash with a log specifically for that reproduced crash.

Original comment by cjh...@gmail.com on 13 Oct 2009 at 1:23

Attachments:

• kern.log.1

[GoogleCodeExporter]

I just recompiled my kernel with all the latest patches. Ubuntu's 14.46, 
autoiso_xorg, 
BFS-303, and then I came to swap_free_notify and realized there's a new one in 
that 
last checkout I did, so I pushed that on into the kernel.

In a minute here, I will attempt to reproduce the problem. Just freshly built 
compcache from my last source checkout.

Let's see what happens, shall we?

Original comment by cjh...@gmail.com on 14 Oct 2009 at 1:53

[GoogleCodeExporter]

I'm back. No success, and no log dump. I waited a while between each letter in 
REISUB 
to make sure I wasn't getting trigger happy, in case the log wasn't dumped fast 
enough 
before I forced the system to reboot.

Original comment by cjh...@gmail.com on 14 Oct 2009 at 2:03

[GoogleCodeExporter]

Original comment by nitingupta910@gmail.com on 12 Nov 2009 at 1:42

[GoogleCodeExporter]

how can I get that 'stress' utility you mentioned in step 2:
 > 2. stress --vm 7 --vm-keep

Original comment by nitingupta910@gmail.com on 12 Dec 2009 at 2:03

[GoogleCodeExporter]

I found it in Ubuntu's universe repo. It's described as "a tool that imposes a 
configurable amount of CPU, memory, I/O, or disk stress on a POSIX-compliant 
operating system and reports any errors it detects."

I think my problem may have had something to do with the swap_free_notify 
patch, as 
I've since recompiled my kernel without it and compiled Compcache from rev. 
1ea72b25ba (latest revision last I pulled it), and after several stress tests 
I've 
been unable to reproduce the problem.

Original comment by cjh...@gmail.com on 12 Dec 2009 at 4:38

[GoogleCodeExporter]

Thanks for the update.

> I think my problem may have had something to do with the swap_free_notify 
patch, as
I've since recompiled my kernel without it and compiled Compcache from rev.
1ea72b25ba (latest revision last I pulled it), and after several stress tests 
I've 
been unable to reproduce the problem.

Ok, then I will close it for now.

Original comment by nitingupta910@gmail.com on 13 Dec 2009 at 12:59

[GoogleCodeExporter]

Original comment by nitingupta910@gmail.com on 13 Dec 2009 at 1:00

• Changed state: Done

[GoogleCodeExporter]

I have exactly the same phenomenon.

I use :
* Tiny Core Linux 3.5.1
* Linux box 2.6.33.3-tinycore #1 SMP Sun Mar 27 03:48:53 CEST 2011 i686 
GNU/Linux
* compcache 0.6.2

Note: When I start the computer without ACPI (boot code acpi=off), the problem 
does not occur.

Original comment by taotepu...@googlemail.com on 14 Apr 2011 at 5:53