03.09.2013 20:12, Toni Mueller wrote:
Hi Michael,
Hello!
On Mon, Sep 02, 2013 at 08:50:11AM +0400, Michael Tokarev wrote:
[]
Hmm. Are you saying that the lockup happens when you _restart_
the VM with the new settings, instead of changing the amount of
memory dynamically?
when I change the amount of memory, I get a message that I need to
restart the VM for the change to take effect. Then I restart the VM, log
in and then run rejoin-stack.sh, and then the problem happens.
Ok. So you actually start the "virtual PC" after shutting it down
and adding anohter DIMM module. As I mentioned before, this smells
pretty much like a guest OS issue.
Also, you haven't provided any details about the VM you're using.
The VM has originally 1550MB of RAM, usese virtio for disk and
networking, and has some 50GB of disk space (mostly empty).
What I meant here is the guest OS details - what is running there?
Amount of disk space is really irrelevant here.
But.. how much memory you've added? Initially you had 1.5Gb (or
something near that). If you cross 2Gb, things actually might
be interesting if anything there is using 32bit numbers, because
2Gb is where 32bit address space ends. For one, 32-bit qemu
userspace process can't allocate more than 2Gb to a guest,
and it _might_ fail somewhere if the amount of memory requested
is somewhere near 2Gb.
Ditto for your guest, -- if it uses a 32bit kernel, crossing
2Gb might have issues (if it locks up completely -- not just
a single app but whole guest -- it must be either qemu or
guest kernel issue, but guest kernel issue might be triggerable
by a guest userspace code).
I remember seeing an Oracle RDBMS bug - rdbms tried to read
/proc/meminfo (or /proc/self/stats, i don't remember) to
determine amount of memory available, and when I tried to
run 32bit rdbms under 64bit kernel, rdbms, which used 32bit
numbers to read the memory info, had an integer overflow
somewhere, which, under certain circumstances, resulted in
it trying to allocate huge amount of >2Gb chunks of shared
memory, thus filling up whole RAM and next swap, and the
system become basically locked up (but actually it were
just swapping all the time).
Also, you ignored another my question -- does this happen
when running that devstack thing on a virtual machine initially
installed with larger amount of memory?
So the `moreinfo' tag stays.
But the more I look at this bug, the more I think I should
just close it, because it is very unlikely to be anything
to do with qemu... Please prove that I'm wrong :)
Thanks,
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
