From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcFWw-0000ZA-2f for qemu-devel@nongnu.org; Sun, 29 Mar 2015 11:53:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YcFWs-00074f-TA for qemu-devel@nongnu.org; Sun, 29 Mar 2015 11:53:42 -0400 Received: from [2a03:4000:1::4e2f:c7ac:d] (port=50756 helo=v220110690675601.yourvserver.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcFWs-00074L-NZ for qemu-devel@nongnu.org; Sun, 29 Mar 2015 11:53:38 -0400 Message-ID: <55181FF4.6040808@weilnetz.de> Date: Sun, 29 Mar 2015 17:53:24 +0200 From: Stefan Weil MIME-Version: 1.0 References: <20150328160709.GA2551@waldemar-brodkorb.de> <5516DEDC.8080608@weilnetz.de> <20150329134706.GA28330@waldemar-brodkorb.de> In-Reply-To: <20150329134706.GA28330@waldemar-brodkorb.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] qemu-m68k: add support for interrupt masking/unmasking List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Waldemar Brodkorb Cc: Thomas Petazzoni , Peter Maydell , qemu-devel@nongnu.org Am 29.03.2015 um 15:47 schrieb Waldemar Brodkorb: > Hi Stefan, > Stefan Weil wrote, > >> You can debug the kernel panic by attaching a cross debugger to the >> running kernel. >> If you have a kernel image with debug symbols, this is very comfortable. > How would I do this? > Tried to start qemu with -s -S and then attach with my cross-gdb > using the kernel with debug symbols. But gdb does not recognize the > panic: > Command: mdev -s > Command: ifconfig lo 127.0.0.1 up > Execution Finished, Exiting > > Sash command shell (version 1.1.1) > /> Kernel panic - not syncing: Attempted to kill init! > exitcode=0x0000000b > > ---[ end Kernel panic - not syncing: Attempted to kill init! > exitcode=0x0000000b > Yes, the cross gdb won't recognize a kernel panic. But you can set a breakpoint on the kernel code which handles such panics, on one of the functions shown in the kernel panic backtrace, or on printk. Regards Stefan