From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MOrwk-0003Cp-J2 for qemu-devel@nongnu.org; Thu, 09 Jul 2009 07:37:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MOrwh-0003BQ-W0 for qemu-devel@nongnu.org; Thu, 09 Jul 2009 07:37:49 -0400 Received: from [199.232.76.173] (port=49122 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MOrwh-0003BM-D7 for qemu-devel@nongnu.org; Thu, 09 Jul 2009 07:37:47 -0400 Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:38123 helo=grelber.thyrsus.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MOrwg-0003kD-UU for qemu-devel@nongnu.org; Thu, 09 Jul 2009 07:37:47 -0400 From: Rob Landley Subject: Re: [Qemu-devel] Powerpc regressions? Date: Wed, 8 Jul 2009 13:21:12 -0500 References: <200907071748.03623.rob@landley.net> <44FC27A4-AD21-4C47-961D-FAE755ADBD33@suse.de> In-Reply-To: <44FC27A4-AD21-4C47-961D-FAE755ADBD33@suse.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907081321.13029.rob@landley.net> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "qemu-devel@nongnu.org" On Wednesday 08 July 2009 04:32:23 Alexander Graf wrote: > Hi Rov, > > On 08.07.2009, at 00:48, Rob Landley wrote: > > If you grab this tarball: > > > > http://impactlinux.com/fwl/downloads/binaries/system-image/system-image-p > >owerpc.tar.bz2 > > > > Extract it, and ./run-emulator.sh. > > > > This ran fine under svn 6657 (which is git 2d18e637e5ec). The next > > commit screwed up openbios, but > > reverting openbios worked for a while. > > I don't think there's any _real_ ppc maintainer for qemu atm. *shrug* I'm happy to poke at it, but I really don't have the expertise to do more than flail about. > > In the last couple months, two problems have cropped up: > > > > 1) -hda sets /dev/hdc instead of /dev/hda (which is the cdrom). > > 2) The kernel panics running init: > > > > Unable to handle kernel paging request for data at address 0x0000007c ... > > Kernel panic - not syncing: Fatal exception in interrupt > > > > I note that this is the same kernel binary and same system image > > that used to run fine, only qemu changed. > > I can try to tweak the kernel .config to work around this, but I > > don't know what the actual problem is... > > Tty_wakeup tried to access data in a NULL pointer. > > You basically have two options how to debug this: > > 1) Find out which change in openbios broke things and figure out why. I already bisected it and both problems were introduced by git 513f789f6b18, which switched from using hardwired data to querying openbios for both the hard drive and memory layouts. Before that, you could revert to the old openbios image and get something that would boot. Afterwards reverting openbios would say there was no secondary bootloader specified, so it never handed off control to the kernel. So as far as I can tell, openbios never actually did it right, it just used to be hardwired so it didn't matter. > 2) Add a lot of debug code to your guest kernel to find out where the > null pointer comes from. Perhaps reading the source suffices already. The kernel didn't change, qemu did. It's literally the same binary that's been up on that website for over 3 months. I can add debug code to the kernel to find out what data qemu is now passing in differently, although the fix isn't going to be in the kernel. The fix is most likely in openbios, specifically the device tree stuff. If I could find a way to pass in a device tree from the command line, I might be able to flail around at that until I came up with something that worked. But the device tree seems to be hardwired in for everything except bamboo... Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds