From mboxrd@z Thu Jan 1 00:00:00 1970 From: Charles Duffy Subject: Re: Oops in xen 3.0.2 dequeue_signal [was: Re: DomU Oopsing on xen-3.0-testing changeset 8259] Date: Mon, 26 Jun 2006 16:15:24 -0500 Message-ID: <44A04E6C.9020501@spamcop.net> References: <49d22db6cf52e95faf921257860e9a0a@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <49d22db6cf52e95faf921257860e9a0a@cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > Does it always crash in __dequeue_signal()? Yes. > You might have to add some tracing in there to find out exactly which > part of the function it is crashing in. Any way to do that with less performance impact than adding printks to what I presume is a quite-commonly-called method? This system is used by internal personnel; while its performance and uptime aren't critical, it would be a good thing if they weren't impacted more than necessary. > Also, try upgrading to 3.0-testing tip and see if you still get the problem. Should it be adequate to upgrade this DomU only, or is there cause to also upgrade the hypervisor and Dom0? (I'm also building a kernel with debug symbols; I anticipate that this will let me get an annotated disassembled copy of the source in question, and thus figure out which line of source maps to the instruction offset from the top of the method we're in... at least, in theory).