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

[Rob Landley <rob@landley.net>]

[-- Attachment #1: Type: text/plain, Size: 7352 bytes --]

On Saturday 10 October 2009 19:11:30 Laurent Vivier wrote:
> 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/

Cool.  Thanks.

The "lenny" image does indeed boot (in graphics mode).  And it mostly works, 
except for the occasional:

[ 7469.044092] ide-pmac lost interrupt, dma status: 8000
[ 7469.058433] hda: lost interrupt

However, if I grab the boot/config*, oldconfig it up to 2.6.31, and then point 
it at my squashfs root filesystem, it has the same panic in tty_wakeup as soon 
as userspace takes over.  Writing to the serial console from userspace makes 
it Unhappy.  Lemme make sure it's not something with my squashfs image 
(although userspace still shouldn't cause a kernel panic...)

Hmmm, it's not liking being pointed at the qcow image with -kernel... because 
this .config has ext3 is compiled as a module, of course.  Ok, fix that...

Ha!  Same bug:

[    2.902657] NET: Registered protocol family 17
[    2.908443] registered taskstats version 1
[    2.917350] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[    2.950166] EXT3-fs: INFO: recovery required on readonly filesystem.
[    2.950483] EXT3-fs: write access will be enabled during recovery.
[    3.466649] kjournald starting.  Commit interval 5 seconds
[    3.474746] EXT3-fs: recovery complete.
[    3.489066] EXT3-fs: mounted filesystem with writeback data mode.
[    3.497697] VFS: Mounted root (ext3 filesystem) readonly on device 3:3.
[    3.501690] Freeing unused kernel memory: 232k init
modprobe: FATAL: Could not load /lib/modules/2.6.31/modules.dep: No such file 
or directory[    4.037935] Unable to handle kernel paging request for data at 
address 0x00000084
[    4.039226] Faulting instruction address: 0xc0220ecc
[    4.044975] Oops: Kernel access of bad area, sig: 11 [#1]
[    4.047432] PowerMac
[    4.048430] Modules linked in:
[    4.049909] NIP: c0220ecc LR: c0238f7c CTR: c0238f68
[    4.052086] REGS: c799dbf0 TRAP: 0300   Not tainted  (2.6.31)
[    4.053920] MSR: 00009032 <EE,ME,IR,DR>  CR: 42200442  XER: 00000000
[    4.054427] DAR: 00000084, DSISR: 40000000
[    4.054665] TASK = c7846070[291] 'modprobe' THREAD: c799c000
[    4.054878] GPR00: c0238f7c c799dca0 c7846070 00000000 00000001 00000000 
00000004 00000000 
[    4.055315] GPR08: 00000001 00000001 00000000 c0238f68 62aa7900 10020390 
0ffc92dd bfd4997c 
[    4.055730] GPR16: bfd49c38 c0463898 c0463a18 c03beed8 00000000 00000000 
0000000a c0491e60 
[    4.056174] GPR24: c799c000 c04c7f00 00000009 00000005 00000100 c0463acc 
c04c7f00 00000000 
[    4.057739] NIP [c0220ecc] tty_wakeup+0x14/0x78
[    4.058038] LR [c0238f7c] uart_tasklet_action+0x14/0x24
[    4.058415] Call Trace:
[    4.058729] [c799dca0] [c0220f1c] tty_wakeup+0x64/0x78 (unreliable)
[    4.059364] [c799dcb0] [c0238f7c] uart_tasklet_action+0x14/0x24
[    4.059704] [c799dcc0] [c0045174] tasklet_action+0x9c/0xf8
[    4.060001] [c799dce0] [c00452b4] __do_softirq+0xe4/0x198
[    4.060350] [c799dd30] [c0006b88] do_softirq+0x40/0x58
[    4.063498] [c799dd40] [c0045094] irq_exit+0x38/0x7c
[    4.065646] [c799dd50] [c0006c24] do_IRQ+0x84/0xa0
[    4.067652] [c799dd60] [c0015870] ret_from_except+0x0/0x1c
[    4.068242] --- Exception: 501 at uart_start+0x24/0x38
[    4.068273]     LR = uart_start+0x20/0x38
[    4.068825] [c799de30] [c023a780] uart_write+0xc8/0xe0
[    4.069070] [c799de60] [c0223c34] n_tty_write+0x250/0x3b4
[    4.069326] [c799deb0] [c0220d90] tty_write+0x1bc/0x26c
[    4.069680] [c799def0] [c00cc0a4] vfs_write+0xb8/0x1b8
[    4.070015] [c799df10] [c00cc64c] sys_write+0x4c/0x8c
[    4.070351] [c799df40] [c00151a4] ret_from_syscall+0x0/0x40
[    4.070795] --- Exception: c01 at 0xff51034
[    4.070823]     LR = 0xfef4624
[    4.071124] Instruction dump:
[    4.071522] 4beac2ad 80010024 7fa3eb78 bba10014 38210020 7c0803a6 4e800020 
9421fff0 
[    4.071975] 7c0802a6 bfc10008 7c7f1b78 90010014 <80030084> 70090020 
41820034 48006099 
[    4.073571] Kernel panic - not syncing: Fatal exception in interrupt
[    4.074175] Call Trace:
[    4.074355] [c799db20] [c00088b0] show_stack+0x58/0x154 (unreliable)
[    4.074668] [c799db60] [c003e7f4] panic+0x8c/0x16c
[    4.074908] [c799dbb0] [c0012bd0] die+0x228/0x24c
[    4.075149] [c799dbd0] [c0019048] bad_page_fault+0xb8/0xcc
[    4.075408] [c799dbe0] [c001565c] handle_page_fault+0x7c/0x80
[    4.075730] --- Exception: 300 at tty_wakeup+0x14/0x78
[    4.075757]     LR = uart_tasklet_action+0x14/0x24
[    4.076226] [c799dca0] [c0220f1c] tty_wakeup+0x64/0x78 (unreliable)
[    4.076592] [c799dcb0] [c0238f7c] uart_tasklet_action+0x14/0x24
[    4.076927] [c799dcc0] [c0045174] tasklet_action+0x9c/0xf8
[    4.077236] [c799dce0] [c00452b4] __do_softirq+0xe4/0x198
[    4.077546] [c799dd30] [c0006b88] do_softirq+0x40/0x58
[    4.078032] [c799dd40] [c0045094] irq_exit+0x38/0x7c
[    4.078347] [c799dd50] [c0006c24] do_IRQ+0x84/0xa0
[    4.078607] [c799dd60] [c0015870] ret_from_except+0x0/0x1c
[    4.078907] --- Exception: 501 at uart_start+0x24/0x38
[    4.078970]     LR = uart_start+0x20/0x38
[    4.079433] [c799de30] [c023a780] uart_write+0xc8/0xe0
[    4.079730] [c799de60] [c0223c34] n_tty_write+0x250/0x3b4
[    4.080013] [c799deb0] [c0220d90] tty_write+0x1bc/0x26c
[    4.080260] [c799def0] [c00cc0a4] vfs_write+0xb8/0x1b8
[    4.080515] [c799df10] [c00cc64c] sys_write+0x4c/0x8c
[    4.080803] [c799df40] [c00151a4] ret_from_syscall+0x0/0x40
[    4.081091] --- Exception: c01 at 0xff51034
[    4.081115]     LR = 0xfef4624
[    4.081591] Rebooting in 1 seconds..landley@driftwood:~/linux-2.6.31$

That's booting with the attached kernel .config (derived from the lenny one), 
and this qemu command line:

$ qemu-system-ppc -kernel vmlinux -nographic -append \
  "console=ttyPZ0 root=/dev/hda3 ro panic=1 rootfstype=ext3" -hda \
  ~/qemu/images/debian_lenny_powerpc_small.qcow -no-reboot

As soon as userspace tries to write anything to the serial console, the kernel 
panics.

But if I instead do:

$ qemu-system-ppc -kernel vmlinux -append \
  "root=/dev/hda3 ro panic=1 rootfstype=ext3" -hda \
  ~/qemu/images/debian_lenny_powerpc_small.qcow -no-reboot

It fires up the graphics window and boots up just fine, running through the init 
scripts and getting me all the way to the debian login prompt.  Exact same 
kernel, exact same qemu, just not using the serial console.

I'm not sure if this is a Linux kernel bug, something wrong with the device 
tree qemu is sending in via open firmware, or something wrong with the actual 
device emulation.  Whatever it is, a null pointer is being dereferenced if 
userspace tries to talk to the serial console, even with as close as I can get 
to building Debian's kernel.

And I kinda need a serial console for what I'm doing.  You can't drive the 
emulator from the host via "expect" through a graphical interface...

Thanks,

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



[-- Attachment #2: .config.zip --]
[-- Type: application/zip, Size: 18919 bytes --]