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

[Rob Landley]

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
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds