search

mfrw / compcache

Automatically exported from code.google.com/p/compcache
0 stars 0 forks source link

Invalid opcode in ramzswap.c:1314 (v0.6) #44

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. sudo ./load_modules.sh
2. sudo ./rzscontrol  /dev/ramzswap0 --init -b /dev/sda2
3.

It appears to occur every time I use backing swap on Ubuntu 9.10.

What version of the product are you using? On what operating system?

Version 0.6 (problem also occurs in latest hg version control), with Ubuntu 
9.10 in a VirtualBox 32bit VM. (Host OS Ubuntu 9.04 64bit).

uname -r reports kernel version 2.6.31-14-generic

Please provide any additional information below.

"kernel BUG" reports for compcache-0.6 and compcache-hg attached (from 
/var/log/syslog).

Original issue reported on code.google.com by gma...@gmail.com on 2 Nov 2009 at 10:34

Attachments:

GoogleCodeExporter commented 9 years ago 
This could be related to Issue #42, as this only occurs when backing swap is 
used, but 
I get a kernel BUG report in syslog, and this was not reported in #42.

Original comment by gma...@gmail.com on 2 Nov 2009 at 10:37

GoogleCodeExporter commented 9 years ago 
Are you sure you have pulled latest hg version? for me, hg log shows:
[ngupta@vflare compcache]$ hg log | head

changeset:   91:65a5cd123d0e
tag:         tip
user:        Nitin Gupta <ngupta@vflare.org>
date:        Thu Oct 15 04:36:55 2009 +0530
summary:     Correct permissions for code files

changeset:   90:ce3d45b1cb38
parent:      83:abafa311d458
user:        ngupta@vmFedora11
date:        Thu Oct 15 04:24:33 2009 +0530

also make sure you are in "default" branch.

---

btw, I could not yet understand how it could happen on compcache-0.6 either. I 
tried
same thing with latest hg version on Fedora-x64 but could not repro the issue. 
I will
find some 32-bit machine and maybe I will be luckier.

Maybe on 32-bit system, disksize value is overflowing. Is your backing swap 
device
>=4G? Also, how much RAM do you have? Anyway, I should be changing it to 64-bit.

Original comment by nitingupta910@gmail.com on 2 Nov 2009 at 1:55

GoogleCodeExporter commented 9 years ago 
I found the trigger of the bug. /dev/sda2 isn't a swap partition, it is an 
"Extended" 
partition which contains my real swap partition (/dev/sda5). swapon handles 
this more 
gracefully, giving the following error:
    swapon: /dev/sda2: read swap header failed: Invalid argument
presumably rzscontrol should also handle this more gracefully.

If this helps "cat /dev/sda2 | wc -c" reports that /dev/sda2 is 1024 characters 
long.

FYI, with regards to hg, I just followed the instruction at  
   http://code.google.com/p/compcache/source/checkout
That is, I ran 
   hg clone https://compcache.googlecode.com/hg/ compcache

Original comment by gma...@gmail.com on 2 Nov 2009 at 3:02

GoogleCodeExporter commented 9 years ago 
> That is, I ran 
>    hg clone https://compcache.googlecode.com/hg/ compcache

To stay uptodate you need to run 'hg pull' to get latest changes.

---
In general, if you give non-swap partition as backing swap, ramzswap does not 
cause a
BUG() and you will get a graceful failure from swapon /dev/ramzswap0. However, 
in
this case -- i.e. with extended partition -- we get backing swap of zero
(i_size_read() returns 0). This fails ramzswap logic. I will fix this case.

Thanks,
Nitin

Original comment by nitingupta910@gmail.com on 3 Nov 2009 at 1:54

GoogleCodeExporter commented 9 years ago 
"hg pull" reports no new changes.

Original comment by gma...@gmail.com on 3 Nov 2009 at 3:24

GoogleCodeExporter commented 9 years ago 
Fixed in repository. hg pull should now get you the fix. You should now get an 
error
in kernel log when you try to do --init with extended partition as backing 
swap. Thanks.

Nitin

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