[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Powerpc regressions?

From: Rob Landley
Subject: Re: [Qemu-devel] Powerpc regressions?
Date: Sun, 12 Jul 2009 22:29:53 -0500
User-agent: KMail/1.11.2 (Linux/2.6.28-13-generic; KDE/4.2.2; x86_64; ; )

On Saturday 11 July 2009 18:35:30 Aurelien Jarno wrote:
> On Sat, Jul 11, 2009 at 10:49:18PM +0100, Paul Brook wrote:
> > > After some more tries, I am able to reproduce a similar problem using
> > > my Debian image. The problem has been caused by this commit, which is
> > > not directly related to PowerPC. Something is wrong with the irq
> > > handling there.
> >
> > Should be fixed by 616cbc7.
> I confirm it works, thanks!

Darn it, that sounded really promising, but I just built git f40782361609 and 
tried to boot that same kernel image with it (known working under previous 
qemu), and:

$ ~landley/qemu/git/ppc-softmmu/qemu-system-ppc -M g3beige -nographic -no-
reboot -kernel zImage-powerpc -hdc image-powerpc.ext2 -append "root=/dev/hda 
init=/usr/sbin/init.sh panic=1 PATH=/usr/bin console=ttyS0"
video1394: Installed video1394 module
ieee1394: raw1394: /dev/raw1394 device initialized
mice: PS/2 mouse device common for all mice
TCP cubic registered
NET: Registered protocol family 17
VFS: Mounted root (ext2 filesystem) readonly on device 3:0.
Freeing unused kernel memory: 164k init
/usr/sbin/init.sh: line 40: /etc/resolv.conf: Read-only file systemUnable to 
handle kernel paging request for data at address 0x0000007c
Faulting instruction address: 0xc0125610
Oops: Kernel access of bad area, sig: 11 [#1]
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 6f282d37 00000000 
GPR08: c7822ed8 00000001 c013ea88 00000000 2f3a5680 100834dc 28220022 10060000 
GPR16: 10080000 10085628 00000000 10080000 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

Still unhappy, dunno why.  I can try building a different kernel .config and 
give the old one up as a loss if it's no longer supported.

Latency is more important than throughput. It's that simple. - Linus Torvalds

reply via email to

[Prev in Thread] Current Thread [Next in Thread]