From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MwhxQ-0000oK-C2 for qemu-devel@nongnu.org; Sat, 10 Oct 2009 15:50:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MwhxP-0000no-7E for qemu-devel@nongnu.org; Sat, 10 Oct 2009 15:50:23 -0400 Received: from [199.232.76.173] (port=39214 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MwhxO-0000nl-T8 for qemu-devel@nongnu.org; Sat, 10 Oct 2009 15:50:22 -0400 Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:53106 helo=grelber.thyrsus.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MwhxO-0001Wl-Gn for qemu-devel@nongnu.org; Sat, 10 Oct 2009 15:50:22 -0400 Received: from landley.net (localhost [127.0.0.1]) by grelber.thyrsus.com (Postfix) with ESMTP id 7558F9F01CA for ; Sat, 10 Oct 2009 15:55:37 -0400 (EDT) From: Rob Landley Date: Sat, 10 Oct 2009 14:48:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910101448.49628.rob@landley.net> Subject: [Qemu-devel] Does qemu-system-ppc still work for anybody in 0.11.0? List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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... 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...?) 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. 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 Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds