Date: Fri, 25 Oct 2013 11:15:16 +0400 From: Sergey Nasonov <snasonov@bcc.ru> To: freebsd-current@freebsd.org Cc: Konstantin Belousov <kostikbel@gmail.com>, Outback Dingo <outbackdingo@gmail.com>, current@freebsd.org, Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@citrix.com> Subject: Re: CUREENT issue with ballon.c Message-ID: <2353358.uiOMYug52O@snasonovnbwxp.bcc> In-Reply-To: <52699C97.7070105@citrix.com> References: <CAKYr3zyVXxL9A9wEY_KL8sp1yivAUG2gpK8daUMu%2BbeyU2b8pw@mail.gmail.com> <20131024211507.GD10625@kib.kiev.ua> <52699C97.7070105@citrix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 24 October 2013 23:17:59 Roger Pau Monn=E9 wrote: > On 24/10/13 22:15, Konstantin Belousov wrote: > > On Thu, Oct 24, 2013 at 09:45:20PM +0100, Roger Pau Monn? wrote: > >> On 24/10/13 13:01, Outback Dingo wrote: > >>> On Thu, Oct 24, 2013 at 6:16 AM, Roger Pau Monn?=20 <roger.pau@citrix.com > >>>=20 > >>> <mailto:roger.pau@citrix.com>> wrote: > >>> On 24/10/13 03:02, Outback Dingo wrote: > >>> > --- trap 0, rip =3D 0, rsp =3D 0xfffffe00002c6b70, rbp =3D = 0 --- > >>> > uma_zalloc_arg: zone "16" with the following non-sleepable = locks > >>> > held: > >>> > exclusive sleep mutex balloon_lock (balloon_lock) r =3D 0 > >>> > (0xffffffff816e9c58) locked @ > >>> =20 > >>> /usr/src/sys/dev/xen/balloon/balloon.c:339 > >>> =20 > >>> > exclusive sleep mutex balloon_mutex (balloon_mutex) r =3D 0= > >>> > (0xffffffff816e9c38) locked @ > >>> =20 > >>> /usr/src/sys/dev/xen/balloon/balloon.c:373 > >>> =20 > >>> > KDB: stack backtrace: > >>> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame= > >>> > 0xfffffe00002c67c0 > >>> > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe00002c6= 870 > >>> > witness_warn() at witness_warn+0x4a8/frame 0xfffffe00002c69= 30 > >>> > uma_zalloc_arg() at uma_zalloc_arg+0x3b/frame 0xfffffe00002= c69a0 > >>> > malloc() at malloc+0x101/frame 0xfffffe00002c69f0 > >>> > balloon_process() at balloon_process+0x44a/frame > >>> > 0xfffffe00002c6a70 > >>> > fork_exit() at fork_exit+0x84/frame 0xfffffe00002c6ab0 > >>> > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0000= 2c6ab0 > >>> > --- trap 0, rip =3D 0, rsp =3D 0xfffffe00002c6b70, rbp =3D = 0 --- > >>> > uma_zalloc_arg: zone "16" with the following non-sleepable = locks > >>> > held: > >>> > exclusive sleep mutex balloon_lock (balloon_lock) r =3D 0 > >>> > (0xffffffff816e9c58) locked @ > >>> =20 > >>> /usr/src/sys/dev/xen/balloon/balloon.c:339 > >>> =20 > >>> > exclusive sleep mutex balloon_mutex (balloon_mutex) r =3D 0= > >>> > (0xffffffff816e9c38) locked @ > >>> =20 > >>> /usr/src/sys/dev/xen/balloon/balloon.c:373 > >>> =20 > >>> > KDB: stack backtrace: > >>> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame= > >>> > 0xfffffe00002c67c0 > >>> > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe00002c6= 870 > >>> > witness_warn() at witness_warn+0x4a8/frame 0xfffffe00002c69= 30 > >>> > uma_zalloc_arg() at uma_zalloc_arg+0x3b/frame 0xfffffe00002= c69a0 > >>> > malloc() at malloc+0x101/frame 0xfffffe00002c69f0 > >>> > balloon_process() at balloon_process+0x44a/frame > >>> > 0xfffffe00002c6a70 > >>> > fork_exit() at fork_exit+0x84/frame 0xfffffe00002c6ab0 > >>> > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0000= 2c6ab0 > >>> > --- trap 0, rip =3D 0, rsp =3D 0xfffffe00002c6b70, rbp =3D = 0 --- > >>> =20 > >>> > uma_zalloc_arg: zone "16" with the following non-sleepable = locks=20 held: > >>> Did you do anything specific to trigger the crash? Can you ex= plain > >>> the > >>> steps needed to reproduce it? > >>>=20 > >>> just recompiled a kernel, and booted it scrolls continuously acro= ss the > >>> screen > >>> doesnt seem to ever stop. > >>=20 > >> I've tried r257051 and it seems to work fine, could you please pos= t your > >> Xen version, the config file used to launch the VM and the toolsta= ck > >> used? > >=20 > > Do you have witness enabled in your kernel config ? >=20 > Yes, but I'm not touching balloon memory target. >=20 > > There is an obvious case of calling malloc(M_WAITOK) while holding = both > > balloon_lock and balloon_mutex: > > ballon_process->decrease_reservation->balloon_append. >=20 > Yes, I'm aware of that, it's just that it shouldn't happen unless you= > actually trigger a balloon memory decrease, which should not happen > automatically AFAIK, that's why I was asking if this was happening > without the user specifically requesting it. For me this problem appears when I try to migrate VM to another physica= l=20 XenServer 6.2. And only when this VM configured with dynamical memory.= Have=20 no problem with static memory configuration. You can find details here http://support.citrix.com/proddocs/topic/xencenter-61/xs-xc-dmc-about.h= tml >=20 > Anyway, this should be clearly fixed and pulled into 10 no matter wha= t > triggered it. I will send a patch as soon as possible. Thanks for that. >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd= .org" --=20 Best Regards, Nasonov Sergey
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2353358.uiOMYug52O>