Re: [Qemu-devel] Does qemu-system-ppc still work for anybody in 0.11.0?

[Laurent Vivier <Laurent@vivier.eu>]

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élien 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 à 14:48 -0500, Rob Landley a écrit :
> 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 <EE,ME,IR,DR>  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
-- 
--------------------- laurent@vivier.eu ----------------------
"Tout ce qui est impossible reste à accomplir"    Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard