From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: hypervisor crash with latest xen-unstable Date: Fri, 26 Nov 2010 06:32:57 +0100 Message-ID: <4CEF4689.10500@ts.fujitsu.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 11/25/10 18:14, Keir Fraser wrote: > On 25/11/2010 10:27, "Juergen Gross" wrote: > >> (XEN) Xen call trace: >> (XEN) [] do_softirq+0x51/0x7a >> (XEN) >> >> I suspect the waitqueue stuff broke the continue_hypercall_on_cpu() stuff. > > Then please bisect to confirm that. Removing the ASSERT(!in_atomic()) in do_softirq() and schedule() makes it work again. And these assertions were added with cs22395. The question now is, whether these assertions are wrong or if it is just working by chance without them. It seems to be necessary to be able to call schedule() in this case, as adding if (in_atomic()) return; to do_softirq() made the hypercall hang. Juergen -- Juergen Gross Principal Developer Operating Systems TSP ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html