Hi,
Do we know if the patch will make it into qemu-traditional? xen_disk.c appears to have been updated since the patch was released - or it’s simply because I can’t take patch from upstream on qemu-xen, giving me:
niklas@unstable:~/xen/qemu-xen-4.1-testing$ patch -p1 < patch
patching file hw/xen_disk.c
Hunk #1 succeeded at 116 (offset 3 lines).
Hunk #2 FAILED at 155.
Hunk #3 FAILED at 179.
2 out of 3 hunks FAILED -- saving rejects to file hw/xen_disk.c.rej
When I apply the patch manually, I get (on xen-setup or make dist-tools):
CC i386-dm/xen_disk.o /home/niklas/xen/xen/tools/ioemu-dir/hw/xen_disk.c: In function ‘ioreq_reset’:
/home/niklas/xen/xen/tools/ioemu-dir/hw/xen_disk.c:126:10: error: ‘struct ioreq’ has no member named ‘mapped’
/home/niklas/xen/xen/tools/ioemu-dir/hw/xen_disk.c:139:18: error: ‘struct ioreq’ has no member named ‘acct’
/home/niklas/xen/xen/tools/ioemu-dir/hw/xen_disk.c:139:41: error: ‘struct ioreq’ has no member named ‘acct’
make[4]: *** [xen_disk.o] Error 1
make[4]: Leaving directory `/home/niklas/xen/xen/tools/ioemu-remote/i386-dm'
make[3]: *** [subdir-i386-dm] Error 2
make[3]: Leaving directory `/home/niklas/xen/xen/tools/ioemu-remote'
make[2]: *** [subdir-install-ioemu-dir] Error 2
make[2]: Leaving directory `/home/niklas/xen/xen/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/home/niklas/xen/xen/tools'
make: *** [install-tools] Error 2
I can successfully build xen tools if I don’t use the patched xen_disk.c
Regards, Niklas
On Thu, Nov 21, 2013 at 3:57 AM, Niklas Bivald < niklas@xxxxxxxxxx> wrote: Hi,
Me and another sysadmin has independently been researching a problem where
DomU randomly locks (Can’t reach it via xl console, no ping / SSH
connection, shown as stuck in running-state in xentop) on two of our
separate machines (installed completely independently):
Dom0:
Debian 7.0 with Xen version: 4.1.4 and xen-utils 4.1.4-3+deb7u1
Debian 7.1 with Xen version: 4.1
DomU:
Debian 7.0
Debian 7.1(.3)
Common denominator appears to be qemu-dm consuming (leaking?) memory until
the Dom0 swaps. When the Dom0 swap is full, the domU appears to be locked
(see above) Dom0, at which time a hard reboot a.ka. xl destroy + xl create
is the only way to get it back. This *could* be related to "[Xen-devel]
qemu-system-i386: memory leak?"
http://xen.markmail.org/message/chqpifrj46lxdxx2
It would seem that the issue Roger fixed in upstream Qemu with the patch linked in his reply ( http://lists.nongnu.org/archive/html/qemu-devel/2012-12/msg03677.html) could indeed be the problem here. Either way, that patch never made it into qemu-traditional, which still suffers the same original problem (see http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=blob;f=hw/xen_disk.c;h=ee8d36f9dbf3c754232d528485cbeff1fd66504e;hb=HEAD#l159). I'm not certain what the status of -traditional is, but surely it should be backported in? - Matthew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxhttp://lists.xen.org/xen-devel
|
