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

[Rob Landley <rob@landley.net>]

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