Re: [Qemu-devel] Powerpc regressions?

[Rob Landley]

On Friday 10 July 2009 18:42:52 Aurelien Jarno wrote:
> On Tue, Jul 07, 2009 at 05:48:02PM -0500, Rob Landley 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.
> >
> > In the last couple months, two problems have cropped up:
> >
> > 1) -hda sets /dev/hdc instead of /dev/hda (which is the cdrom).
>
> Wrong. -hda sets the first hard drive, that is on the internal PowerMAC
> controller. -hdc sets the first drive of the add-on IDE card that is
> used in this emulation to connect the CD-ROM, as the PowerMAC IDE
> controller emulation has still some bugs.

*shrug*  It used to work fine.

> Then the Linux kernel decide to call the cdrom hda and the hard-disk
> hdc. You will get exactly the same result if you put an add-on card
> on a real PowerMAC machine. If you consider that a bug, you should
> report the bug to the Linux kernel.

I can probably toggle CONFIG_BLK_DEV_OFFBOARD to swap 'em in the Linux kernel 
(or just supply -hdc and ignore the fact that used to set /dev/hdc but now 
sets /dev/hda and it wasn't the kernel that changed).

But the point is that qemu used to do it one way, and now qemu does it 
another, and if I change my kernel configuration to do it differently how do I 
know a future qemu version won't change it again?  It's easy to workaround, 
but will the workaround be _stable_?

> > 2) The kernel panics running init:
>
> This is a bug I don't reproduce with my Debian installation, but that I
> am able to reproduce with your image.

I'd rather I didn't reproduce it.  Could you post the kernel .config you're 
using that doesn't show this problem?

> You listed commit 6657 as the culprit,

No, svn 6657 (git 2d18e637e5ec) was the last one that worked unmodified.

The next commit after that introduced a buggy openbios that faulted before the 
kernel ever got control when using --kernel with --nographic, but that was an 
unrelated change and Blue Swirl and I already had a long thread tracking down 
the problem and confirming it was an openbios bug back in may:

  http://lists.gnu.org/archive/html/qemu-devel/2009-03/msg00887.html

Unfortunately, before the fixed openbios could be merged into qemu, the qemu 
code changed again, git 513f789f6b18, which made qemu start querying openbios 
(instead of emulated nvram) to assemble a device tree.  Unfortunately, that 
new procedure produced a different device tree which was incompatible with the 
old one, and that's the source of both the swapped hda/hdc and whatever other 
change is causing the panic.  (Somebody implied it was an incompletely setup 
irq controller?)

Supplying the old openbios image after that didn't work because it said there 
was no secondary bootloader.  The old openbios image wasn't providing data the 
new qemu expected.

Then git 9d479c119 updated openbios again, and the symptoms changed again.  (I 
forget to what, I could re-bisect if it helps.)

> but is it only for both 1) and/or
> 2). It would be nice to know the first bad commit for 2).

git 2d18e637e5ec was the last one that ran out of the box.  git 513f789f6b18 
was the last one that worked if I reverted to the other one's openbios binary.  
The ones since then have failed to boot for various different reasons, but 
that's not necessarily useful information.

> If the problem lies in OpenBIOS, then the solution is to bisect on the
> OpenBIOS side.

Both qemu and openbios changed at the same time.  QEMU switched from using the 
old nvram api to the new openbios device querying API, and if openbios never 
provided the same info (which we know to be the case at least somewhat because 
hda/hdc changed) a bisect isn't going to help here.  As far as I can tell, 
openbios never provided the same information through the new API as the old 
one had provided.

If changing my kernel .config so I build a new kernel that works with the new 
qemu is my only alternative, I'm happy to do that.  But I don't currently have 
a working kernel .config, and don't understand why the old one broke or how to 
avoid being hit by similar changes in future.

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