Re: [Qemu-devel] Powerpc regressions?

[Aurelien Jarno]

On Sun, Jul 12, 2009 at 10:24:24PM -0500, Rob Landley wrote:
> 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_?

This will probably will change again when we are able to get the CD-ROM
working on the PowerMac IDE controller. The current emulated machine is
a big hack and uses the fact that the Linux kernel supports different
hardware than the Apple one. The goal is to emulate a machine as close
as possible to the original hardware.


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

I am using the Debian kernel and it works fine, please find attached the
.config attached.

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

config-2.6.26-2-powerpc.gz
Description: Binary data