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

[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

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

[Laurent Vivier]

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

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

[Aurelien Jarno]

On Sun, Oct 11, 2009 at 02:11:30AM +0200, 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/
> 

They works fine for me with both HEAD and version 0.11.0.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

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

[Rob Landley]

[-- 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 --]

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

[Aurelien Jarno]

On Sat, Oct 10, 2009 at 02:48:49PM -0500, Rob Landley wrote:
> 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...

As already explained, this is a bug is actually a bug of the Linux
kernel which see the controllers in the reverse order. This has nothing
to do with the emulation, and adding an IDE card on a real Mac would
result in the same inversion.

> 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...?)

It's something I am not able to reproduce here, probably due to
different kernel version/options.

> 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.

If svn 6657 works for you, stick to it and please stop complaining,
there is not need to create a target specially for you.

Alternatively we can fix the real problem if you are a bit more
cooperative. That starts by providing us a way to reproduce the problem,
that includes an image, the .config you used to build your kernel and
the corresponding kernel sources (or a pointer to it).

> 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
> 

This is fixed in git, and will be in the next stable release. For your
information it was triggered to a change in the common PCI code, and was
not due a change in the PPC code.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

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

[Rob Landley]

On Sunday 11 October 2009 14:30:12 Aurelien Jarno wrote:
> > 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...
>
> As already explained, this is a bug is actually a bug of the Linux
> kernel which see the controllers in the reverse order. This has nothing
> to do with the emulation, and adding an IDE card on a real Mac would
> result in the same inversion.

The debian kernel is not having this problem, so it's apparently possible to 
.config your way around this one, thus I'm happy.

> > 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...?)
>
> It's something I am not able to reproduce here, probably due to
> different kernel version/options.

You've gotten Linux userspace to write to a serial console?  I'd love to know 
how.

The bootloader can write to serial just fine, and the kernel init messages go 
to the serial console just fine, but as soon as userspace tries to write to 
/dev/console it dereferences a null pointer and you get the above dump.

I tried to reproduce this with the debian lenny kernel from 
http://people.debian.org/~aurel32/qemu/powerpc/ but the "boot:" prompt is 
completely undocumented so I dunno how to add console=ttyPZ0 to its kernel 
command line, when I scp the /boot/vmlinux out it won't work with 
root=/dev/hda3 because it has ext3 as a module instead of built in statically, 
and when I copy out the initrd as well qemu says the kernel is too old to 
support an initrd (either 2.6.26==ancient or the ELF loader and initrd don't 
mix).

However, in my previous message to this list I grabbed their kernel .config and 
oldconfiged it to 2.6.31, switched ext3 from modular to static, built it, and 
_that_ one reproduced the problem.   (With -nographic and console=ttyPZ0 it 
dies as soon as userspace writes to /dev/console, without those it boots to a 
login prompt just fine.)

> Alternatively we can fix the real problem if you are a bit more
> cooperative. That starts by providing us a way to reproduce the problem,
> that includes an image, the .config you used to build your kernel and
> the corresponding kernel sources (or a pointer to it).

Sorry, when I posted links to the image I was using back in July nobody really 
seemed to care because it wasn't a major distro:

http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg00513.html

You did track down what you thought was the issue:

http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg00874.html

And Paul Brook checked in a fix:

http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg00892.html

But when I pointed out that it didn't actually fix the problem I was seeing 
there was no reply:

http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg00920.html

In another branch of the thread you suggested that the fact you could no 
longer reproduce it on Debian meant it wasn't a real problem:

http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg00946.html

And Paul Brook said that powerpc was unstable and not really supported yet 
anyway:

http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg01007.html

So I waited until the next qemu release version before banging on it again.

Now I've got the panic reproduced using the debian kernel .config, if not the 
actual debian kernel binary, as detailed last message.  I'm not sure what that 
means, though.  It's still entirely possible I'm doing something wrong, but I 
don't know what.  I'd write this off as a kernel bug instead of qemu issue, 
except that it worked fine under the older qemu version.  (Mostly likely it's 
some sort of device tree subtlety, but I'm out of my depth there.)

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