Re: [Qemu-devel] Powerpc regressions?

[Rob Landley]

On Wednesday 08 July 2009 04:32:23 Alexander Graf wrote:
> Hi Rov,
>
> On 08.07.2009, at 00:48, Rob Landley <address@hidden> wrote:
> > If you grab this tarball:
> >
> > http://impactlinux.com/fwl/downloads/binaries/system-image/system-image-p
> >owerpc.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.
>
> I don't think there's any _real_ ppc maintainer for qemu atm.

*shrug*  I'm happy to poke at it, but I really don't have the expertise to do 
more than flail about.

> > In the last couple months, two problems have cropped up:
> >
> > 1) -hda sets /dev/hdc instead of /dev/hda (which is the cdrom).
> > 2) The kernel panics running init:
> >
> > Unable to handle kernel paging request for data at address 0x0000007c
...
> > 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...
>
> Tty_wakeup tried to access data in a NULL pointer.
>
> You basically have two options how to debug this:
>
> 1) Find out which change in openbios broke things and figure out why.

I already bisected it and both problems were introduced by git 513f789f6b18, 
which switched from using hardwired data to querying openbios for both the 
hard drive and memory layouts.

Before that, you could revert to the old openbios image and get something that 
would boot.  Afterwards reverting openbios would say there was no secondary 
bootloader specified, so it never handed off control to the kernel.

So as far as I can tell, openbios never actually did it right, it just used to 
be hardwired so it didn't matter.

> 2) Add a lot of debug code to your guest kernel to find out where the
> null pointer comes from. Perhaps reading the source suffices already.

The kernel didn't change, qemu did.  It's literally the same binary that's 
been up on that website for over 3 months.

I can add debug code to the kernel to find out what data qemu is now passing in 
differently, although the fix isn't going to be in the kernel.  The fix is most 
likely in openbios, specifically the device tree stuff.  If I could find a way 
to 
pass in a device tree from the command line, I might be able to flail around at 
that until I came up with something that worked.  But the device tree seems to 
be hardwired in for everything except bamboo...

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