Re: [Qemu-devel] Powerpc regressions?

[Lennart Sorensen]

On Tue, Jul 07, 2009 at 05:48:02PM -0500, Rob Landley wrote:
> If you grab this tarball:
> 
> http://impactlinux.com/fwl/downloads/binaries/system-image/system-image-powerpc.tar.bz2
> 
> Extract it, and ./run-emulator.sh.
> 
> This ran fine under svn 6657 (which is git 2d18e637e5ec).  The next commit 
> screwed up openbios, but 
> reverting openbios worked for a while.
> 
> In the last couple months, two problems have cropped up:
> 
> 1) -hda sets /dev/hdc instead of /dev/hda (which is the cdrom).

It seems to me that qemu 0.9.x did it one way, then 0.10.x did it the
reverse, and now the current development version does it the 0.9.x
way again.  Does make things a bit annoying I must admit.

> 2) The kernel panics running init:
> 
> Unable to handle kernel paging request for data at address 0x0000007c
> Faulting instruction address: 0xc0125610
> Oops: Kernel access of bad area, sig: 11 [#1]
> PowerMac
> NIP: c0125610 LR: c013ea9c CTR: c013ea88
> REGS: c7827be0 TRAP: 0300   Not tainted  (2.6.29)
> MSR: 00009032 <EE,ME,IR,DR>  CR: 42224022  XER: 00000000
> DAR: 0000007c, DSISR: 40000000
> TASK = c78257f0[1] 'init.sh' THREAD: c7826000
> GPR00: c013ea9c c7827c90 c78257f0 00000000 c7825820 00000000 b2f34226 
> 00000000 
> GPR08: c7822ed8 00000001 c013ea88 00000000 58389c00 100834dc 28220022 
> 10060000 
> GPR16: 10080000 100852a8 00000000 10040000 00000000 c0310000 c031594c 
> c0270000 
> GPR24: 00000001 c0310000 0000000a c0310000 c02ee370 00000000 00000001 
> 00000000 
> NIP [c0125610] tty_wakeup+0x14/0xa0
> LR [c013ea9c] uart_tasklet_action+0x14/0x24
> Call Trace:
> [c7827c90] [c0125630] tty_wakeup+0x34/0xa0 (unreliable)
> [c7827ca0] [c013ea9c] uart_tasklet_action+0x14/0x24
> [c7827cb0] [c00303c8] tasklet_action+0x88/0x104
> [c7827cd0] [c00304d0] __do_softirq+0x8c/0x134
> [c7827d10] [c0006ba0] do_softirq+0x58/0x5c
> [c7827d20] [c003033c] irq_exit+0x94/0x98
> [c7827d30] [c0006c40] do_IRQ+0x9c/0xc0
> [c7827d50] [c0012778] ret_from_except+0x0/0x1c
> --- Exception: 501 at uart_start+0x24/0x38
>     LR = uart_start+0x20/0x38
> [c7827e30] [c014043c] uart_write+0xc4/0xe8
> [c7827e60] [c01293a0] n_tty_write+0x1d4/0x3c4
> [c7827eb0] [c0126540] tty_write+0x180/0x268
> [c7827ef0] [c007feec] vfs_write+0xc4/0x16c
> [c7827f10] [c0080404] sys_write+0x4c/0x90
> [c7827f40] [c00120ac] ret_from_syscall+0x0/0x40
> --- Exception: c01 at 0x4803a2dc
>     LR = 0x4804c490
> Instruction dump:
> 38c00000 4bf02255 80010024 bba10014 38210020 7c0803a6 4e800020 9421fff0 
> 7c0802a6 bfc10008 7c7f1b78 90010014 <8003007c> 70090020 4082002c 387f00d8 
> Kernel panic - not syncing: Fatal exception in interrupt
> 
> I note that this is the same kernel binary and same system image that used to 
> run fine, only qemu changed.  
> I can try to tweak the kernel .config to work around this, but I don't know 
> what the actual problem is...
> 
> Suggestions?

Hmm, I haven't seen that.  Of course I am just running a debian lenny
install in qemu, while I believe you are booting with a kernel passed to
qemu from the outside (unless you have changed firmware-linux recently
to use bootloaders, which I doubt).

-- 
Len Sorensen