From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MOX8w-0007N9-9b for qemu-devel@nongnu.org; Wed, 08 Jul 2009 09:25:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MOX8r-0007Kv-I1 for qemu-devel@nongnu.org; Wed, 08 Jul 2009 09:25:01 -0400 Received: from [199.232.76.173] (port=55199 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MOX8r-0007Ks-Dt for qemu-devel@nongnu.org; Wed, 08 Jul 2009 09:24:57 -0400 Received: from caffeine.csclub.uwaterloo.ca ([129.97.134.17]:34919) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MOX8r-0007WD-4g for qemu-devel@nongnu.org; Wed, 08 Jul 2009 09:24:57 -0400 Date: Wed, 8 Jul 2009 09:24:56 -0400 Subject: Re: [Qemu-devel] Powerpc regressions? Message-ID: <20090708132456.GP15751@csclub.uwaterloo.ca> References: <200907071748.03623.rob@landley.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907071748.03623.rob@landley.net> From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen) List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rob Landley Cc: qemu-devel@nongnu.org On Tue, Jul 07, 2009 at 05:48:02PM -0500, Rob Landley wrote: > If you grab this tarball: > > http://impactlinux.com/fwl/downloads/binaries/system-image/system-image-powerpc.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. > > In the last couple months, two problems have cropped up: > > 1) -hda sets /dev/hdc instead of /dev/hda (which is the cdrom). It seems to me that qemu 0.9.x did it one way, then 0.10.x did it the reverse, and now the current development version does it the 0.9.x way again. Does make things a bit annoying I must admit. > 2) The kernel panics running init: > > Unable to handle kernel paging request for data at address 0x0000007c > Faulting instruction address: 0xc0125610 > Oops: Kernel access of bad area, sig: 11 [#1] > PowerMac > NIP: c0125610 LR: c013ea9c CTR: c013ea88 > REGS: c7827be0 TRAP: 0300 Not tainted (2.6.29) > MSR: 00009032 CR: 42224022 XER: 00000000 > DAR: 0000007c, DSISR: 40000000 > TASK = c78257f0[1] 'init.sh' THREAD: c7826000 > GPR00: c013ea9c c7827c90 c78257f0 00000000 c7825820 00000000 b2f34226 00000000 > GPR08: c7822ed8 00000001 c013ea88 00000000 58389c00 100834dc 28220022 10060000 > GPR16: 10080000 100852a8 00000000 10040000 00000000 c0310000 c031594c c0270000 > GPR24: 00000001 c0310000 0000000a c0310000 c02ee370 00000000 00000001 00000000 > NIP [c0125610] tty_wakeup+0x14/0xa0 > LR [c013ea9c] uart_tasklet_action+0x14/0x24 > Call Trace: > [c7827c90] [c0125630] tty_wakeup+0x34/0xa0 (unreliable) > [c7827ca0] [c013ea9c] uart_tasklet_action+0x14/0x24 > [c7827cb0] [c00303c8] tasklet_action+0x88/0x104 > [c7827cd0] [c00304d0] __do_softirq+0x8c/0x134 > [c7827d10] [c0006ba0] do_softirq+0x58/0x5c > [c7827d20] [c003033c] irq_exit+0x94/0x98 > [c7827d30] [c0006c40] do_IRQ+0x9c/0xc0 > [c7827d50] [c0012778] ret_from_except+0x0/0x1c > --- Exception: 501 at uart_start+0x24/0x38 > LR = uart_start+0x20/0x38 > [c7827e30] [c014043c] uart_write+0xc4/0xe8 > [c7827e60] [c01293a0] n_tty_write+0x1d4/0x3c4 > [c7827eb0] [c0126540] tty_write+0x180/0x268 > [c7827ef0] [c007feec] vfs_write+0xc4/0x16c > [c7827f10] [c0080404] sys_write+0x4c/0x90 > [c7827f40] [c00120ac] ret_from_syscall+0x0/0x40 > --- Exception: c01 at 0x4803a2dc > LR = 0x4804c490 > Instruction dump: > 38c00000 4bf02255 80010024 bba10014 38210020 7c0803a6 4e800020 9421fff0 > 7c0802a6 bfc10008 7c7f1b78 90010014 <8003007c> 70090020 4082002c 387f00d8 > 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... > > Suggestions? Hmm, I haven't seen that. Of course I am just running a debian lenny install in qemu, while I believe you are booting with a kernel passed to qemu from the outside (unless you have changed firmware-linux recently to use bootloaders, which I doubt). -- Len Sorensen