From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mx47W-0007OZ-B6 for qemu-devel@nongnu.org; Sun, 11 Oct 2009 15:30:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mx47U-0007ON-Qa for qemu-devel@nongnu.org; Sun, 11 Oct 2009 15:30:17 -0400 Received: from [199.232.76.173] (port=41875 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mx47U-0007OK-LK for qemu-devel@nongnu.org; Sun, 11 Oct 2009 15:30:16 -0400 Received: from hall.aurel32.net ([88.191.82.174]:37286) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mx47U-0006MD-1j for qemu-devel@nongnu.org; Sun, 11 Oct 2009 15:30:16 -0400 Date: Sun, 11 Oct 2009 21:30:12 +0200 From: Aurelien Jarno Subject: Re: [Qemu-devel] Does qemu-system-ppc still work for anybody in 0.11.0? Message-ID: <20091011193012.GA19201@volta.aurel32.net> References: <200910101448.49628.rob@landley.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <200910101448.49628.rob@landley.net> 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 Sat, Oct 10, 2009 at 02:48:49PM -0500, Rob Landley wrote: > Back under svn 6657 (I.E. git 2d18e637e5ec), powerpc -M g3beige worked great. > I could boot to a shell prompt and even build stuff with gcc. It was a > reasonably solid emulation under which I could boot Linux and build software > under the emulator. It Worked For Me. > > The current version doesn't work at all. The first thing I notice is that > hda/hdc are flipped (and hdb/hdd). Every other target, -hda sets what the > Linux kernel detects as hda, but this target is "special". Right... As already explained, this is a bug is actually a bug of the Linux kernel which see the controllers in the reverse order. This has nothing to do with the emulation, and adding an IDE card on a real Mac would result in the same inversion. > Ignoring that and hand-hacking my scripts to feed the root filesystem in as - > hdc for this one magic target only, we then get this problem: > > mice: PS/2 mouse device common for all mice > TCP cubic registered > NET: Registered protocol family 17 > VFS: Mounted root (squashfs filesystem) readonly on device 3:0. > Freeing unused kernel memory: 168k init > Type exit when done.Unable to handle kernel paging request for data at address > 0x00000084 > Faulting instruction address: 0xc012dc08 > Oops: Kernel access of bad area, sig: 11 [#1] > PowerMac > NIP: c012dc08 LR: c014664c CTR: c0146638 > REGS: c7827be0 TRAP: 0300 Not tainted (2.6.31) > MSR: 00009032 CR: 42224022 XER: 00000000 > DAR: 00000084, DSISR: 40000000 > TASK = c78258f0[1] 'init.sh' THREAD: c7826000 > GPR00: c014664c c7827c90 c78258f0 00000000 c7825920 c7828e40 88dccd97 00000000 > GPR08: 00000001 00000001 c0146638 00000000 87aba097 100834dc 0127e658 1005b940 > GPR16: 1008582c 00000000 1007d074 100429a4 00000000 c02dc614 c0281638 c02dc498 > GPR24: 0000000a c7826000 c0321e00 00000005 00000014 c0321e00 c02dc638 00000000 > NIP [c012dc08] tty_wakeup+0x14/0xa0 > LR [c014664c] uart_tasklet_action+0x14/0x24 > Call Trace: > [c7827c90] [c012dc28] tty_wakeup+0x34/0xa0 (unreliable) > [c7827ca0] [c014664c] uart_tasklet_action+0x14/0x24 > [c7827cb0] [c0031234] tasklet_action+0x80/0x104 > [c7827cd0] [c0031360] __do_softirq+0xa8/0x120 > [c7827d10] [c0006ea4] do_softirq+0x58/0x5c > [c7827d20] [c00311b0] irq_exit+0x98/0x9c > [c7827d30] [c0006f44] do_IRQ+0x9c/0xb4 > [c7827d50] [c0012b60] ret_from_except+0x0/0x1c > --- Exception: 501 at uart_start+0x24/0x38 > LR = uart_start+0x20/0x38 > [c7827e20] [c0147fbc] uart_write+0xc0/0xe4 > [c7827e50] [c0130b2c] n_tty_write+0x1d4/0x430 > [c7827eb0] [c012da9c] tty_write+0x188/0x268 > [c7827ef0] [c00822ac] vfs_write+0xb4/0x188 > [c7827f10] [c0082814] sys_write+0x4c/0x90 > [c7827f40] [c0012494] ret_from_syscall+0x0/0x40 > > And so on for several more pages. It's odd that the serial console was > spitting out data just fine, until it got to userspace and it all went pear > shaped (with what looks like a null pointer dereference, according to the data > address, except that uart_write seems like it's the serial code...?) It's something I am not able to reproduce here, probably due to different kernel version/options. > I don't suppose there's some way to put the old svn 6657 board emulation back > under some "-M actuallyworks" label and let this fun random experimentation > happen off to the side? I'm aware this target is "unstable", but it _used_ to > work, and now it doesn't. If svn 6657 works for you, stick to it and please stop complaining, there is not need to create a target specially for you. Alternatively we can fix the real problem if you are a bit more cooperative. That starts by providing us a way to reproduce the problem, that includes an image, the .config you used to build your kernel and the corresponding kernel sources (or a pointer to it). > I'd download and check the qemu sample image, but there isn't one for powerpc. > > Oddly, -g3beige is still better than most of the other board emulations: > > $ qemu-system-ppc -M mac99 > Segmentation fault > This is fixed in git, and will be in the next stable release. For your information it was triggered to a change in the common PCI code, and was not due a change in the PPC code. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net