Hi Michael, On Thu, Sep 05, 2013 at 09:40:38AM +0400, Michael Tokarev wrote: > 03.09.2013 20:12, Toni Mueller wrote: > >On Mon, Sep 02, 2013 at 08:50:11AM +0400, Michael Tokarev wrote: > >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.
ok... > >>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. Ok. The guest OS is Debian Wheezy (i386), as is the host OS. I tried with the stock 3.2 kernel, as well as the 3.10 kernel from unstable. For the host, I tried the 3.2, 3.9.1, and 3.10 kernels, of which the 3.9.1 kernel gives the least problems. > 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. I only switched the memory size between 1550 and 1024 MB back and forth. > 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. I never went close to 2GB. I only discovered the issue as I wanted to reduce the amount of memory in the guest when I saw that the machine should be able to run with less than 1550MB, and because it caused my laptop to swap. So I figured that allocating less memory would reduce the amount of swap consumed. > Ditto for your guest, -- if it uses a 32bit kernel, crossing > 2Gb might have issues (if it locks up completely -- not just I never went close to 2GB in the guest, either. The host has 4GB of (physical) RAM. > 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). The whole guest is locking up - I can only kill it externally. I would need to check extra if ping also stopped to work, but SSH is certainly impossible. > Also, you ignored another my question -- does this happen That was unintentionally (or I may have misread your question). > when running that devstack thing on a virtual machine initially > installed with larger amount of memory? Yes, that's what I thought I said all along: I initially installed the VM with 1550 MB, then tried to size it down to 1024MB, and that's when the problem occurred. > 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 :) Imho, you should _not_ "just close" it, but help me find the appropriate package towards which to report the bug, then reassign appropriately, if that package happens to not be qemu-kvm, or help figuring out the details and a fix, if it happens to be qemu-kvm. Cheers, --Toni++ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
