From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mwm2H-0003cr-4r for qemu-devel@nongnu.org; Sat, 10 Oct 2009 20:11:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mwm2C-0003Uj-9k for qemu-devel@nongnu.org; Sat, 10 Oct 2009 20:11:40 -0400 Received: from [199.232.76.173] (port=41681 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mwm2C-0003UT-32 for qemu-devel@nongnu.org; Sat, 10 Oct 2009 20:11:36 -0400 Received: from moutng.kundenserver.de ([212.227.17.8]:60948) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mwm2B-0001dk-FC for qemu-devel@nongnu.org; Sat, 10 Oct 2009 20:11:35 -0400 Subject: Re: [Qemu-devel] Does qemu-system-ppc still work for anybody in 0.11.0? From: Laurent Vivier In-Reply-To: <200910101448.49628.rob@landley.net> References: <200910101448.49628.rob@landley.net> Content-Type: text/plain; charset=utf-8 Date: Sun, 11 Oct 2009 02:11:30 +0200 Message-Id: <1255219890.8978.4.camel@Quad> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rob Landley Cc: qemu-devel@nongnu.org Hi, qemu git HEAD (218951e) seems to work fine: I've tested some ISOs (debian 4.0r6, debian 5.0.0, Fedora 10, Fedora 11 Preview and OpenSUSE 11.1[1]) without problem. I've also booted a disk image of a previously installed debian etch (4.0). Aur=C3=A9lien provides also some disk images you can use: http://people.debian.org/~aurel32/qemu/powerpc/ Regards, Laurent [1] you need to boot using "boot cd:,\suseboot\yaboot" Le samedi 10 octobre 2009 =C3=A0 14:48 -0500, Rob Landley a =C3=A9crit : > Back under svn 6657 (I.E. git 2d18e637e5ec), powerpc -M g3beige worked gr= eat. =20 > I could boot to a shell prompt and even build stuff with gcc. It was a=20 > reasonably solid emulation under which I could boot Linux and build softw= are=20 > under the emulator. It Worked For Me. >=20 > The current version doesn't work at all. The first thing I notice is tha= t=20 > hda/hdc are flipped (and hdb/hdd). Every other target, -hda sets what th= e=20 > Linux kernel detects as hda, but this target is "special". Right... >=20 > 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: >=20 > 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 ad= dress=20 > 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 =3D c78258f0[1] 'init.sh' THREAD: c7826000 > GPR00: c014664c c7827c90 c78258f0 00000000 c7825920 c7828e40 88dccd97 000= 00000=20 > GPR08: 00000001 00000001 c0146638 00000000 87aba097 100834dc 0127e658 100= 5b940=20 > GPR16: 1008582c 00000000 1007d074 100429a4 00000000 c02dc614 c0281638 c02= dc498=20 > GPR24: 0000000a c7826000 c0321e00 00000005 00000014 c0321e00 c02dc638 000= 00000=20 > 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 =3D 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 >=20 > And so on for several more pages. It's odd that the serial console was=20 > spitting out data just fine, until it got to userspace and it all went pe= ar=20 > shaped (with what looks like a null pointer dereference, according to the= data=20 > address, except that uart_write seems like it's the serial code...?) >=20 > I don't suppose there's some way to put the old svn 6657 board emulation = back=20 > under some "-M actuallyworks" label and let this fun random experimentati= on=20 > happen off to the side? I'm aware this target is "unstable", but it _use= d_ to=20 > work, and now it doesn't. >=20 > I'd download and check the qemu sample image, but there isn't one for pow= erpc. >=20 > Oddly, -g3beige is still better than most of the other board emulations: >=20 > $ qemu-system-ppc -M mac99 > Segmentation fault >=20 > Rob --=20 --------------------- laurent@vivier.eu ---------------------- "Tout ce qui est impossible reste =C3=A0 accomplir" Jules Verne "Things are only impossible until they're not" Jean-Luc Picard