[Qemu-devel] Powerpc regressions?

[Qemu-devel] Powerpc regressions?

[Rob Landley]

If you grab this tarball:

http://impactlinux.com/fwl/downloads/binaries/system-image/system-image-powerpc.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).
2) The kernel panics running init:

Unable to handle kernel paging request for data at address 0x0000007c
Faulting instruction address: 0xc0125610
Oops: Kernel access of bad area, sig: 11 [#1]
PowerMac
NIP: c0125610 LR: c013ea9c CTR: c013ea88
REGS: c7827be0 TRAP: 0300   Not tainted  (2.6.29)
MSR: 00009032 <EE,ME,IR,DR>  CR: 42224022  XER: 00000000
DAR: 0000007c, DSISR: 40000000
TASK = c78257f0[1] 'init.sh' THREAD: c7826000
GPR00: c013ea9c c7827c90 c78257f0 00000000 c7825820 00000000 b2f34226 00000000 
GPR08: c7822ed8 00000001 c013ea88 00000000 58389c00 100834dc 28220022 10060000 
GPR16: 10080000 100852a8 00000000 10040000 00000000 c0310000 c031594c c0270000 
GPR24: 00000001 c0310000 0000000a c0310000 c02ee370 00000000 00000001 00000000 
NIP [c0125610] tty_wakeup+0x14/0xa0
LR [c013ea9c] uart_tasklet_action+0x14/0x24
Call Trace:
[c7827c90] [c0125630] tty_wakeup+0x34/0xa0 (unreliable)
[c7827ca0] [c013ea9c] uart_tasklet_action+0x14/0x24
[c7827cb0] [c00303c8] tasklet_action+0x88/0x104
[c7827cd0] [c00304d0] __do_softirq+0x8c/0x134
[c7827d10] [c0006ba0] do_softirq+0x58/0x5c
[c7827d20] [c003033c] irq_exit+0x94/0x98
[c7827d30] [c0006c40] do_IRQ+0x9c/0xc0
[c7827d50] [c0012778] ret_from_except+0x0/0x1c
--- Exception: 501 at uart_start+0x24/0x38
    LR = uart_start+0x20/0x38
[c7827e30] [c014043c] uart_write+0xc4/0xe8
[c7827e60] [c01293a0] n_tty_write+0x1d4/0x3c4
[c7827eb0] [c0126540] tty_write+0x180/0x268
[c7827ef0] [c007feec] vfs_write+0xc4/0x16c
[c7827f10] [c0080404] sys_write+0x4c/0x90
[c7827f40] [c00120ac] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0x4803a2dc
    LR = 0x4804c490
Instruction dump:
38c00000 4bf02255 80010024 bba10014 38210020 7c0803a6 4e800020 9421fff0 
7c0802a6 bfc10008 7c7f1b78 90010014 <8003007c> 70090020 4082002c 387f00d8 
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...

Suggestions?

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

Re: [Qemu-devel] Powerpc regressions?

[Alexander Graf]

Hi Rov,



On 08.07.2009, at 00:48, Rob Landley <rob@landley.net> wrote:

> If you grab this tarball:
>
> http://impactlinux.com/fwl/downloads/binaries/system-image/system-image-powerpc.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.

> 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
> Faulting instruction address: 0xc0125610
> Oops: Kernel access of bad area, sig: 11 [#1]
> PowerMac
> NIP: c0125610 LR: c013ea9c CTR: c013ea88
> REGS: c7827be0 TRAP: 0300   Not tainted  (2.6.29)
> MSR: 00009032 <EE,ME,IR,DR>  CR: 42224022  XER: 00000000
> DAR: 0000007c, DSISR: 40000000
> TASK = c78257f0[1] 'init.sh' THREAD: c7826000
> GPR00: c013ea9c c7827c90 c78257f0 00000000 c7825820 00000000  
> b2f34226 00000000
> GPR08: c7822ed8 00000001 c013ea88 00000000 58389c00 100834dc 28220022 10060000
> GPR16: 10080000 100852a8 00000000 10040000 00000000 c0310000  
> c031594c c0270000
> GPR24: 00000001 c0310000 0000000a c0310000 c02ee370 00000000 00000001 00000000
> NIP [c0125610] tty_wakeup+0x14/0xa0
> LR [c013ea9c] uart_tasklet_action+0x14/0x24
> Call Trace:
> [c7827c90] [c0125630] tty_wakeup+0x34/0xa0 (unreliable)
> [c7827ca0] [c013ea9c] uart_tasklet_action+0x14/0x24
> [c7827cb0] [c00303c8] tasklet_action+0x88/0x104
> [c7827cd0] [c00304d0] __do_softirq+0x8c/0x134
> [c7827d10] [c0006ba0] do_softirq+0x58/0x5c
> [c7827d20] [c003033c] irq_exit+0x94/0x98
> [c7827d30] [c0006c40] do_IRQ+0x9c/0xc0
> [c7827d50] [c0012778] ret_from_except+0x0/0x1c
> --- Exception: 501 at uart_start+0x24/0x38
>    LR = uart_start+0x20/0x38
> [c7827e30] [c014043c] uart_write+0xc4/0xe8
> [c7827e60] [c01293a0] n_tty_write+0x1d4/0x3c4
> [c7827eb0] [c0126540] tty_write+0x180/0x268
> [c7827ef0] [c007feec] vfs_write+0xc4/0x16c
> [c7827f10] [c0080404] sys_write+0x4c/0x90
> [c7827f40] [c00120ac] ret_from_syscall+0x0/0x40
> --- Exception: c01 at 0x4803a2dc
>    LR = 0x4804c490
> Instruction dump:
> 38c00000 4bf02255 80010024 bba10014 38210020 7c0803a6 4e800020  
> 9421fff0
> 7c0802a6 bfc10008 7c7f1b78 90010014 <8003007c> 70090020 4082002c  
> 387f00d8
> 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.

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.

Maybe you also have to do both :)

Good Luck!

Alex

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

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 <rob@landley.net> 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

Re: [Qemu-devel] Powerpc regressions?

[Lennart Sorensen]

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

It seems to me that qemu 0.9.x did it one way, then 0.10.x did it the
reverse, and now the current development version does it the 0.9.x
way again.  Does make things a bit annoying I must admit.

> 2) The kernel panics running init:
> 
> Unable to handle kernel paging request for data at address 0x0000007c
> Faulting instruction address: 0xc0125610
> Oops: Kernel access of bad area, sig: 11 [#1]
> PowerMac
> NIP: c0125610 LR: c013ea9c CTR: c013ea88
> REGS: c7827be0 TRAP: 0300   Not tainted  (2.6.29)
> MSR: 00009032 <EE,ME,IR,DR>  CR: 42224022  XER: 00000000
> DAR: 0000007c, DSISR: 40000000
> TASK = c78257f0[1] 'init.sh' THREAD: c7826000
> GPR00: c013ea9c c7827c90 c78257f0 00000000 c7825820 00000000 b2f34226 00000000 
> GPR08: c7822ed8 00000001 c013ea88 00000000 58389c00 100834dc 28220022 10060000 
> GPR16: 10080000 100852a8 00000000 10040000 00000000 c0310000 c031594c c0270000 
> GPR24: 00000001 c0310000 0000000a c0310000 c02ee370 00000000 00000001 00000000 
> NIP [c0125610] tty_wakeup+0x14/0xa0
> LR [c013ea9c] uart_tasklet_action+0x14/0x24
> Call Trace:
> [c7827c90] [c0125630] tty_wakeup+0x34/0xa0 (unreliable)
> [c7827ca0] [c013ea9c] uart_tasklet_action+0x14/0x24
> [c7827cb0] [c00303c8] tasklet_action+0x88/0x104
> [c7827cd0] [c00304d0] __do_softirq+0x8c/0x134
> [c7827d10] [c0006ba0] do_softirq+0x58/0x5c
> [c7827d20] [c003033c] irq_exit+0x94/0x98
> [c7827d30] [c0006c40] do_IRQ+0x9c/0xc0
> [c7827d50] [c0012778] ret_from_except+0x0/0x1c
> --- Exception: 501 at uart_start+0x24/0x38
>     LR = uart_start+0x20/0x38
> [c7827e30] [c014043c] uart_write+0xc4/0xe8
> [c7827e60] [c01293a0] n_tty_write+0x1d4/0x3c4
> [c7827eb0] [c0126540] tty_write+0x180/0x268
> [c7827ef0] [c007feec] vfs_write+0xc4/0x16c
> [c7827f10] [c0080404] sys_write+0x4c/0x90
> [c7827f40] [c00120ac] ret_from_syscall+0x0/0x40
> --- Exception: c01 at 0x4803a2dc
>     LR = 0x4804c490
> Instruction dump:
> 38c00000 4bf02255 80010024 bba10014 38210020 7c0803a6 4e800020 9421fff0 
> 7c0802a6 bfc10008 7c7f1b78 90010014 <8003007c> 70090020 4082002c 387f00d8 
> 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...
> 
> Suggestions?

Hmm, I haven't seen that.  Of course I am just running a debian lenny
install in qemu, while I believe you are booting with a kernel passed to
qemu from the outside (unless you have changed firmware-linux recently
to use bootloaders, which I doubt).

-- 
Len Sorensen

Re: [Qemu-devel] Powerpc regressions?

[Rob Landley]

On Wednesday 08 July 2009 08:24:56 Lennart Sorensen 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).
>
> It seems to me that qemu 0.9.x did it one way, then 0.10.x did it the
> reverse, and now the current development version does it the 0.9.x
> way again.

I don't think 0.9.x had a g3beige, or at least I didn't get it to work.  I 
booted a patched prep kernel under that (with a custom boot rom feeding in a 
custom device tree).  I went to a vanilla unpatched kernel as soon as I was 
able.

> Does make things a bit annoying I must admit.

Device layout varying randomly between different qemu versions is kind of 
annoying, yes.  Especially since the linux kernel needs init=/dev/blah to boot 
directly from a filesystem image, so the kernel command line needed to boot now 
varies between qemu versions.

Also, if the argument wasn't called "-hda", or if the last version that 
actually worked hadn't associated -hda with /dev/hda, the change wouldn't be 
so obviously silly.

But that one's easy enough to work around.  The "panic shortly after init 
runs" isn't.

> > 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...
> >
> > Suggestions?
>
> Hmm, I haven't seen that.  Of course I am just running a debian lenny
> install in qemu, while I believe you are booting with a kernel passed to
> qemu from the outside (unless you have changed firmware-linux recently
> to use bootloaders, which I doubt).

Still using -kernel.  The tarball I pointed at includes the boot shell script, 
which calls qemu with:

qemu-system-ppc -M g3beige -nographic -no-reboot -kernel "zImage-powerpc" 
  -hdc "image-powerpc.ext2" -append "root=/dev/hda rw init=/usr/sbin/init.sh
  panic=1 PATH=/usr/bin console=ttyS0 $KERNEL_EXTRA"

(Feeding in the ext2 image file as -hdc is the workaround for qemu being unable 
to keep hda and hdc straight on powerpc anymore.  On debian, I expect it boots 
to an initramfs that fires up HAL to look at all partitions on all devices and 
would happily mount a USB flash key as hda if it had the right UUID.  Which 
somebody's going to exploit one of these days, but oh well.)

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

Re: [Qemu-devel] Powerpc regressions?

[Lennart Sorensen]

On Thu, Jul 09, 2009 at 06:49:47AM -0500, Rob Landley wrote:
> I don't think 0.9.x had a g3beige, or at least I didn't get it to work.  I 
> booted a patched prep kernel under that (with a custom boot rom feeding in a 
> custom device tree).  I went to a vanilla unpatched kernel as soon as I was 
> able.

Hmm, well I think 0.9.1 worked OK when I used the debian lenny kernel
(never worked with 2.6.18 from etch though).  Of course I might be
remembering a development snapshot from between 0.9.1 and 0.10.0.  I do
remember the drive order changing at some point and having to change hda
to hdc to boot my images, and now with 0.10.50 (git checkout) having to
change it back again.

> Device layout varying randomly between different qemu versions is kind of 
> annoying, yes.  Especially since the linux kernel needs init=/dev/blah to boot 
> directly from a filesystem image, so the kernel command line needed to boot now 
> varies between qemu versions.

Bad enough that some linux kernel versions changed the order of devices
at times.

> Also, if the argument wasn't called "-hda", or if the last version that 
> actually worked hadn't associated -hda with /dev/hda, the change wouldn't be 
> so obviously silly.

Yeah I am not sure who is changing it.

> But that one's easy enough to work around.  The "panic shortly after init 
> runs" isn't.

No that would be much worse.

> Still using -kernel.  The tarball I pointed at includes the boot shell script, 
> which calls qemu with:
> 
> qemu-system-ppc -M g3beige -nographic -no-reboot -kernel "zImage-powerpc" 
>   -hdc "image-powerpc.ext2" -append "root=/dev/hda rw init=/usr/sbin/init.sh
>   panic=1 PATH=/usr/bin console=ttyS0 $KERNEL_EXTRA"
> 
> (Feeding in the ext2 image file as -hdc is the workaround for qemu being unable 
> to keep hda and hdc straight on powerpc anymore.  On debian, I expect it boots 
> to an initramfs that fires up HAL to look at all partitions on all devices and 
> would happily mount a USB flash key as hda if it had the right UUID.  Which 
> somebody's going to exploit one of these days, but oh well.)

Well if I was using UUIDs then yes it would probably not mind, but I am
not at the moment.  Still need to know which /dev/hd* to install the
boot loader to of course.

-- 
Len Sorensen

Re: [Qemu-devel] Powerpc regressions?

[Rob Landley]

On Thursday 09 July 2009 08:46:48 Lennart Sorensen wrote:
> On Thu, Jul 09, 2009 at 06:49:47AM -0500, Rob Landley wrote:
> > I don't think 0.9.x had a g3beige, or at least I didn't get it to work. 
> > I booted a patched prep kernel under that (with a custom boot rom feeding
> > in a custom device tree).  I went to a vanilla unpatched kernel as soon
> > as I was able.
>
> Hmm, well I think 0.9.1 worked OK when I used the debian lenny kernel
> (never worked with 2.6.18 from etch though).  Of course I might be
> remembering a development snapshot from between 0.9.1 and 0.10.0.  I do
> remember the drive order changing at some point and having to change hda
> to hdc to boot my images, and now with 0.10.50 (git checkout) having to
> change it back again.

The 0.9.x series used Open Hackware, not Open Bios.

Among its many limitations was the refusal to allow -kernel to boot a kernel 
if you didn't feed in a _partitioned_ hda so it could set the "boot partition" 
field.  (Thus if your -hda was an ext2 image created by genext2fs, and thus 
didn't _have_ a partition table, every other qemu target could boot that but 
powerpc couldn't due to open hackware limitations.)

> > Device layout varying randomly between different qemu versions is kind of
> > annoying, yes.  Especially since the linux kernel needs init=/dev/blah to
> > boot directly from a filesystem image, so the kernel command line needed
> > to boot now varies between qemu versions.
>
> Bad enough that some linux kernel versions changed the order of devices
> at times.

The Linux SCSI layer does have a regrettable tendency to throw all devices of 
all transport types asynchronously into the same bucket and give it a stir, so 
your USB devices get mixed in with your SATA devices and the order they show 
up in depends on module load order and a couple of fun race conditions.

According to Ted Tso, this is to force the "Linux on the desktop" people to 
confront and hopefully solve the device enumeration problems of IBM mainframes 
with thousands of devices.  Apparently, if desktop linux users feel the pain 
of mainframe users, they'll buy macintoshes and this will solve the problem 
somehow.

However, since you generally have to rebuild to trigger random changes in scsi 
enumeration behavior, and you can control it by only HAVING one type of 
transport in the system you're emulating, it doesn't break existing binary 
images.  Moving the hardware addresses around under the covers does.

> > Also, if the argument wasn't called "-hda", or if the last version that
> > actually worked hadn't associated -hda with /dev/hda, the change wouldn't
> > be so obviously silly.
>
> Yeah I am not sure who is changing it.

Most recently it changed when they moved from hardwired built-in device tree 
to querying openbios for this information.  Apparently, the device tree 
openbios provides is not the same device tree that qemu was synthesizing when 
it was hardwired in.

That's what I get from a very cursory read of the patch that changed it, 
anyway.  I can't really say I have a deep understanding of any of this, it's 
really not my area.

> > But that one's easy enough to work around.  The "panic shortly after init
> > runs" isn't.
>
> No that would be much worse.

It is, yeah.

> > Still using -kernel.  The tarball I pointed at includes the boot shell
> > script, which calls qemu with:
> >
> > qemu-system-ppc -M g3beige -nographic -no-reboot -kernel "zImage-powerpc"
> >   -hdc "image-powerpc.ext2" -append "root=/dev/hda rw
> > init=/usr/sbin/init.sh panic=1 PATH=/usr/bin console=ttyS0 $KERNEL_EXTRA"
> >
> > (Feeding in the ext2 image file as -hdc is the workaround for qemu being
> > unable to keep hda and hdc straight on powerpc anymore.  On debian, I
> > expect it boots to an initramfs that fires up HAL to look at all
> > partitions on all devices and would happily mount a USB flash key as hda
> > if it had the right UUID.  Which somebody's going to exploit one of these
> > days, but oh well.)
>
> Well if I was using UUIDs then yes it would probably not mind, but I am
> not at the moment.  Still need to know which /dev/hd* to install the
> boot loader to of course.

Using uuids requires using initramfs, in which case having a root partition is 
sort of optional.  It also requires feeding the virtual machine a bit more 
than the default 128 megs of ram.

Mainly, what I'm trying to do is get an arm system, a mips system, an x86-64 
system, an sh4 system, and so on that all work in the same way.  Building the 
same kernel and same root filesystem from the same source, using the same build 
scripts, just for different targets.

Considering that a mips system _can't_ have more than 256 megs of physical 
memory (due to the top 3 bits of their addresses being used for some kind of 
strange mode flags and half the rest kept for I/O memory mappings), I need an 
actual block device that can mount an ext2 root filesystem image to fit a useful 
native toolchain and enough space to build anything.  Initramfs just doesn't 
give me enough space on that target.

I note that lots of other targets have size limitations in how big a kernel 
image they'll load and decompress before falling off the end of one of their 
memory mappings.  An initramfs with 40 megs of files in it wasn't really the 
intent of initramfs, and is not that well tested.

So yeah, root=/dev/hda isn't actually obsolete.  Some of us find it very 
useful.

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

Re: [Qemu-devel] Powerpc regressions?

[Aurelien Jarno]

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

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.

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

You listed commit 6657 as the culprit, but is it only for both 1) and/or
2). It would be nice to know the first bad commit for 2).

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

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

Re: [Qemu-devel] Powerpc regressions?

[Aurelien Jarno]

On Sat, Jul 11, 2009 at 01:42:52AM +0200, 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-powerpc.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.
> 
> 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.
> 
> > 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. 
> 
> You listed commit 6657 as the culprit, but is it only for both 1) and/or
> 2). It would be nice to know the first bad commit for 2).
> 
> If the problem lies in OpenBIOS, then the solution is to bisect on the
> OpenBIOS side.
> 

After some more tries, I am able to reproduce a similar problem using my
Debian image. The problem has been caused by this commit, which is not 
directly related to PowerPC. Something is wrong with the irq handling
there.

10c4c98ab7dc18169b37b76f6ea5e60ebe65222b is first bad commit
commit 10c4c98ab7dc18169b37b76f6ea5e60ebe65222b
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Tue Jun 30 14:12:08 2009 +0200

    qdev: replace bus_type enum with bus_info struct.

    BusInfo is filled with name and size (pretty much like I did for
    DeviceInfo as well).  There is also a function pointer to print
    bus-specific device information to the monitor.  sysbus is hooked
    up there, I've also added a print function for PCI.

    Device creation is slightly modified as well:  The device type search
    loop now also checks the bus type while scanning the list instead of
    complaining thereafter in case of a mismatch.  This effectively gives
    each bus a private namespace for device names.

    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Signed-off-by: Paul Brook <paul@codesourcery.com>

:040000 040000 10e33f4d7e538e49ef5de43c1a519b374e2f8678 69eaad1e16e461a411a69d4ed2b5d97e7633adff M      hw


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

Re: [Qemu-devel] Powerpc regressions?

[Paul Brook]

> After some more tries, I am able to reproduce a similar problem using my
> Debian image. The problem has been caused by this commit, which is not
> directly related to PowerPC. Something is wrong with the irq handling
> there.

Should be fixed by 616cbc7.

Paul

Re: [Qemu-devel] Powerpc regressions?

[Aurelien Jarno]

On Sat, Jul 11, 2009 at 10:49:18PM +0100, Paul Brook wrote:
> > After some more tries, I am able to reproduce a similar problem using my
> > Debian image. The problem has been caused by this commit, which is not
> > directly related to PowerPC. Something is wrong with the irq handling
> > there.
> 
> Should be fixed by 616cbc7.
> 

I confirm it works, thanks!

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

Re: [Qemu-devel] Powerpc regressions?

[Rob Landley]

On Saturday 11 July 2009 18:35:30 Aurelien Jarno wrote:
> On Sat, Jul 11, 2009 at 10:49:18PM +0100, Paul Brook wrote:
> > > After some more tries, I am able to reproduce a similar problem using
> > > my Debian image. The problem has been caused by this commit, which is
> > > not directly related to PowerPC. Something is wrong with the irq
> > > handling there.
> >
> > Should be fixed by 616cbc7.
>
> I confirm it works, thanks!

Darn it, that sounded really promising, but I just built git f40782361609 and 
tried to boot that same kernel image with it (known working under previous 
qemu), and:

$ ~landley/qemu/git/ppc-softmmu/qemu-system-ppc -M g3beige -nographic -no-
reboot -kernel zImage-powerpc -hdc image-powerpc.ext2 -append "root=/dev/hda 
init=/usr/sbin/init.sh panic=1 PATH=/usr/bin console=ttyS0"
...
video1394: Installed video1394 module
ieee1394: raw1394: /dev/raw1394 device initialized
mice: PS/2 mouse device common for all mice
TCP cubic registered
NET: Registered protocol family 17
VFS: Mounted root (ext2 filesystem) readonly on device 3:0.
Freeing unused kernel memory: 164k init
/usr/sbin/init.sh: line 40: /etc/resolv.conf: Read-only file systemUnable to 
handle kernel paging request for data at address 0x0000007c
Faulting instruction address: 0xc0125610
Oops: Kernel access of bad area, sig: 11 [#1]
PowerMac
NIP: c0125610 LR: c013ea9c CTR: c013ea88
REGS: c7827be0 TRAP: 0300   Not tainted  (2.6.29)
MSR: 00009032 <EE,ME,IR,DR>  CR: 42224022  XER: 00000000
DAR: 0000007c, DSISR: 40000000
TASK = c78257f0[1] 'init.sh' THREAD: c7826000
GPR00: c013ea9c c7827c90 c78257f0 00000000 c7825820 00000000 6f282d37 00000000 
GPR08: c7822ed8 00000001 c013ea88 00000000 2f3a5680 100834dc 28220022 10060000 
GPR16: 10080000 10085628 00000000 10080000 00000000 c0310000 c031594c c0270000 
GPR24: 00000001 c0310000 0000000a c0310000 c02ee370 00000000 00000001 00000000 
NIP [c0125610] tty_wakeup+0x14/0xa0
LR [c013ea9c] uart_tasklet_action+0x14/0x24
Call Trace:
[c7827c90] [c0125630] tty_wakeup+0x34/0xa0 (unreliable)
[c7827ca0] [c013ea9c] uart_tasklet_action+0x14/0x24
[c7827cb0] [c00303c8] tasklet_action+0x88/0x104
[c7827cd0] [c00304d0] __do_softirq+0x8c/0x134
[c7827d10] [c0006ba0] do_softirq+0x58/0x5c
[c7827d20] [c003033c] irq_exit+0x94/0x98
[c7827d30] [c0006c40] do_IRQ+0x9c/0xc0
[c7827d50] [c0012778] ret_from_except+0x0/0x1c
--- Exception: 501 at uart_start+0x24/0x38
    LR = uart_start+0x20/0x38
[c7827e30] [c014043c] uart_write+0xc4/0xe8
[c7827e60] [c01293a0] n_tty_write+0x1d4/0x3c4
[c7827eb0] [c0126540] tty_write+0x180/0x268
[c7827ef0] [c007feec] vfs_write+0xc4/0x16c
[c7827f10] [c0080404] sys_write+0x4c/0x90
[c7827f40] [c00120ac] ret_from_syscall+0x0/0x40
--- Exception: c01 at 0x4803a2dc
    LR = 0x4804c490
Instruction dump:
38c00000 4bf02255 80010024 bba10014 38210020 7c0803a6 4e800020 9421fff0 
7c0802a6 bfc10008 7c7f1b78 90010014 <8003007c> 70090020 4082002c 387f00d8 
Kernel panic - not syncing: Fatal exception in interrupt

Still unhappy, dunno why.  I can try building a different kernel .config and 
give the old one up as a loss if it's no longer supported.

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

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

Re: [Qemu-devel] Powerpc regressions?

[Aurelien Jarno]

[-- Attachment #1: Type: text/plain, Size: 5104 bytes --]

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
aurelien@aurel32.net                 http://www.aurel32.net

[-- Attachment #2: config-2.6.26-2-powerpc.gz --]
[-- Type: application/octet-stream, Size: 19480 bytes --]

Re: [Qemu-devel] Powerpc regressions?

[Rob Landley]

On Monday 13 July 2009 07:25:45 Aurelien Jarno wrote:
> 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.

Just confirming: juggling the hardware locations around randomly on any given 
checkin is ok, so each system image we make is specific to a given qemu version 
and only expected to run on that one unless we make a big system with an 
initramfs that probes the hardware on each boot to find its root filesystem?

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

Thanks.  I'll try this out when I get back from my trip to Michigan.

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

Re: [Qemu-devel] Powerpc regressions?

[Paul Brook]

On Monday 13 July 2009, Rob Landley wrote:
> On Monday 13 July 2009 07:25:45 Aurelien Jarno wrote:
> > 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.
>
> Just confirming: juggling the hardware locations around randomly on any
> given checkin is ok, so each system image we make is specific to a given
> qemu version and only expected to run on that one unless we make a big
> system with an initramfs that probes the hardware on each boot to find its
> root filesystem?

For things like macs emulation that are still under significant development, 
yes. If you want a stable machine then you first have to fix all the 
differences between qemu and the reference hardware we're attempting to 
emulate.

Paul

Re: [Qemu-devel] Powerpc regressions?

[Rob Landley]

On Monday 13 July 2009 11:13:57 Paul Brook wrote:
> On Monday 13 July 2009, Rob Landley wrote:
> > On Monday 13 July 2009 07:25:45 Aurelien Jarno wrote:
> > > 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.
> >
> > Just confirming: juggling the hardware locations around randomly on any
> > given checkin is ok, so each system image we make is specific to a given
> > qemu version and only expected to run on that one unless we make a big
> > system with an initramfs that probes the hardware on each boot to find
> > its root filesystem?
>
> For things like macs emulation that are still under significant
> development, yes. If you want a stable machine then you first have to fix
> all the differences between qemu and the reference hardware we're
> attempting to emulate.

I take it http://www.qemu.org/status.html is the best stable vs unstable 
indicator for emulations?  So mips, m68k, arm, sparc, and the x86es are the 
only stable ones, and "testing" is still subject to change without notice?

> Paul

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

Re: [Qemu-devel] Powerpc regressions?

[Rob Landley]

[-- Attachment #1: Type: text/plain, Size: 3108 bytes --]

On Monday 13 July 2009 07:25:45 Aurelien Jarno wrote:
> > 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.

Finally got back in a position to spend some more time on this.  Sorry for the 
delay.

Ok, I'm trying just to boot to a command prompt with a serial console and IDE 
/dev/hda.  (Or funky scsi IDE /dev/sda in a pinch.)

Your .config is for a 2.6.26 kernel and I'm building 2.6.30, so I have to run 
make oldconfig against it (and just hit enter on everything to take the 
defaults).  Also, I'm not using an initramfs at the moment, so presumably 
anything that's in a module can go because it won't get loaded before I get a 
shell prompt anyway, so I can yank anything config =m, and the module 
infrastructure itself, to simplify things a bit.

That gave me the (much smaller) attached .config, which _should_ work the same 
as yours, I hope?  Note that CONFIG_SERIAL_8250_CONSOLE is on, so I should be 
able to get a serial console, which is my first target: get boot messages from 
this kernel.

I built a kernel using the attached .config and my existing powerpc toolchain 
(which built a kernel that booted under older qemu), and attempted to boot the 
result under current git (28e738dcb81d):

qemu-system-ppc -M g3beige -nographic -no-reboot -kernel zImage-powerpc
-hda image-powerpc.sqf -append "root=/dev/hda rw init=/usr/sbin/init.sh 
panic=1 PATH=/usr/bin console=ttyS0 "

>> =============================================================
>> OpenBIOS 1.0 [Jul 5 2009 17:36]
>> Configuration device id QEMU version 1 machine id 2
>> CPUs: 1
>> Memory: 128M
>> UUID: 00000000-0000-0000-0000-000000000000
>> CPU type PowerPC,750
Welcome to OpenBIOS v1.0 built on Jul 5 2009 17:36

>> [ppc] Kernel already loaded (0x01000000 + 0x0039bef0) (initrd 0x00000000 + 
0x00000000)
>> [ppc] Kernel command line: root=/dev/hda rw init=/usr/sbin/init.sh panic=1 
PATH=/usr/bin console=ttyS0 
OF stdout device is: /pci@80000000/mac-io@4/escc@13000/ch-b@13000
Preparing to boot Linux version 2.6.30 (landley@driftwood) (gcc version 4.2.1) 
#1 Sat Aug 1 17:35:12 CDT 2009
command line: root=/dev/hda rw init=/usr/sbin/init.sh panic=1 PATH=/usr/bin 
console=ttyS0 
memory layout at init:
  alloc_bottom : 013a0000
  alloc_top    : 08000000
  alloc_top_hi : 08000000
  rmo_top      : 08000000
  ram_top      : 08000000
found display   : /pci@80000000/QEMU,VGA@1, opening... done
copying OF device tree...
Building dt strings...
Building dt structure...
Device tree strings 0x013a1000 -> 0x013a1383
Device tree struct  0x013a2000 -> 0x013a4000
Calling quiesce...
returning from prom_init

At which point it exits and I get the prompt back.

Any idea what I'm doing wrong?

Thanks,

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

[-- Attachment #2: .config.zip --]
[-- Type: application/zip, Size: 8851 bytes --]

Re: [Qemu-devel] Powerpc regressions?

[Aurelien Jarno]

On Sun, Aug 02, 2009 at 12:40:53AM -0500, Rob Landley wrote:
> On Monday 13 July 2009 07:25:45 Aurelien Jarno wrote:
> > > 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.
> 
> Finally got back in a position to spend some more time on this.  Sorry for the 
> delay.
> 
> Ok, I'm trying just to boot to a command prompt with a serial console and IDE 
> /dev/hda.  (Or funky scsi IDE /dev/sda in a pinch.)
> 
> Your .config is for a 2.6.26 kernel and I'm building 2.6.30, so I have to run 
> make oldconfig against it (and just hit enter on everything to take the 
> defaults).  Also, I'm not using an initramfs at the moment, so presumably 
> anything that's in a module can go because it won't get loaded before I get a 
> shell prompt anyway, so I can yank anything config =m, and the module 
> infrastructure itself, to simplify things a bit.
> 
> That gave me the (much smaller) attached .config, which _should_ work the same 
> as yours, I hope?  Note that CONFIG_SERIAL_8250_CONSOLE is on, so I should be 
> able to get a serial console, which is my first target: get boot messages from 
> this kernel.
> 
> I built a kernel using the attached .config and my existing powerpc toolchain 
> (which built a kernel that booted under older qemu), and attempted to boot the 
> result under current git (28e738dcb81d):
> 
> qemu-system-ppc -M g3beige -nographic -no-reboot -kernel zImage-powerpc
> -hda image-powerpc.sqf -append "root=/dev/hda rw init=/usr/sbin/init.sh 
> panic=1 PATH=/usr/bin console=ttyS0 "
> 
> >> =============================================================
> >> OpenBIOS 1.0 [Jul 5 2009 17:36]
> >> Configuration device id QEMU version 1 machine id 2
> >> CPUs: 1
> >> Memory: 128M
> >> UUID: 00000000-0000-0000-0000-000000000000
> >> CPU type PowerPC,750
> Welcome to OpenBIOS v1.0 built on Jul 5 2009 17:36
> 
> >> [ppc] Kernel already loaded (0x01000000 + 0x0039bef0) (initrd 0x00000000 + 
> 0x00000000)
> >> [ppc] Kernel command line: root=/dev/hda rw init=/usr/sbin/init.sh panic=1 
> PATH=/usr/bin console=ttyS0 
> OF stdout device is: /pci@80000000/mac-io@4/escc@13000/ch-b@13000
> Preparing to boot Linux version 2.6.30 (landley@driftwood) (gcc version 4.2.1) 
> #1 Sat Aug 1 17:35:12 CDT 2009
> command line: root=/dev/hda rw init=/usr/sbin/init.sh panic=1 PATH=/usr/bin 
> console=ttyS0 
> memory layout at init:
>   alloc_bottom : 013a0000
>   alloc_top    : 08000000
>   alloc_top_hi : 08000000
>   rmo_top      : 08000000
>   ram_top      : 08000000
> found display   : /pci@80000000/QEMU,VGA@1, opening... done
> copying OF device tree...
> Building dt strings...
> Building dt structure...
> Device tree strings 0x013a1000 -> 0x013a1383
> Device tree struct  0x013a2000 -> 0x013a4000
> Calling quiesce...
> returning from prom_init
> 
> At which point it exits and I get the prompt back.
> 

I think using console=ttyPZ0 which is the serial port name on PowerPC
will give you more details.

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

Re: [Qemu-devel] Powerpc regressions?

[Alexander Graf]

On 02.08.2009, at 12:04, Aurelien Jarno wrote:

> On Sun, Aug 02, 2009 at 12:40:53AM -0500, Rob Landley wrote:
>> On Monday 13 July 2009 07:25:45 Aurelien Jarno wrote:
>>>> 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.
>>
>> Finally got back in a position to spend some more time on this.   
>> Sorry for the
>> delay.
>>
>> Ok, I'm trying just to boot to a command prompt with a serial  
>> console and IDE
>> /dev/hda.  (Or funky scsi IDE /dev/sda in a pinch.)
>>
>> Your .config is for a 2.6.26 kernel and I'm building 2.6.30, so I  
>> have to run
>> make oldconfig against it (and just hit enter on everything to take  
>> the
>> defaults).  Also, I'm not using an initramfs at the moment, so  
>> presumably
>> anything that's in a module can go because it won't get loaded  
>> before I get a
>> shell prompt anyway, so I can yank anything config =m, and the module
>> infrastructure itself, to simplify things a bit.
>>
>> That gave me the (much smaller) attached .config, which _should_  
>> work the same
>> as yours, I hope?  Note that CONFIG_SERIAL_8250_CONSOLE is on, so I  
>> should be
>> able to get a serial console, which is my first target: get boot  
>> messages from
>> this kernel.
>>
>> I built a kernel using the attached .config and my existing powerpc  
>> toolchain
>> (which built a kernel that booted under older qemu), and attempted  
>> to boot the
>> result under current git (28e738dcb81d):
>>
>> qemu-system-ppc -M g3beige -nographic -no-reboot -kernel zImage- 
>> powerpc
>> -hda image-powerpc.sqf -append "root=/dev/hda rw init=/usr/sbin/ 
>> init.sh
>> panic=1 PATH=/usr/bin console=ttyS0 "
>>
>>>> =============================================================
>>>> OpenBIOS 1.0 [Jul 5 2009 17:36]
>>>> Configuration device id QEMU version 1 machine id 2
>>>> CPUs: 1
>>>> Memory: 128M
>>>> UUID: 00000000-0000-0000-0000-000000000000
>>>> CPU type PowerPC,750
>> Welcome to OpenBIOS v1.0 built on Jul 5 2009 17:36
>>
>>>> [ppc] Kernel already loaded (0x01000000 + 0x0039bef0) (initrd  
>>>> 0x00000000 +
>> 0x00000000)
>>>> [ppc] Kernel command line: root=/dev/hda rw init=/usr/sbin/ 
>>>> init.sh panic=1
>> PATH=/usr/bin console=ttyS0
>> OF stdout device is: /pci@80000000/mac-io@4/escc@13000/ch-b@13000
>> Preparing to boot Linux version 2.6.30 (landley@driftwood) (gcc  
>> version 4.2.1)
>> #1 Sat Aug 1 17:35:12 CDT 2009
>> command line: root=/dev/hda rw init=/usr/sbin/init.sh panic=1 PATH=/ 
>> usr/bin
>> console=ttyS0
>> memory layout at init:
>>  alloc_bottom : 013a0000
>>  alloc_top    : 08000000
>>  alloc_top_hi : 08000000
>>  rmo_top      : 08000000
>>  ram_top      : 08000000
>> found display   : /pci@80000000/QEMU,VGA@1, opening... done
>> copying OF device tree...
>> Building dt strings...
>> Building dt structure...
>> Device tree strings 0x013a1000 -> 0x013a1383
>> Device tree struct  0x013a2000 -> 0x013a4000
>> Calling quiesce...
>> returning from prom_init
>>
>> At which point it exits and I get the prompt back.
>>
>
> I think using console=ttyPZ0 which is the serial port name on PowerPC
> will give you more details.

Also try "-vnc :5 -serial mon:stdio" instead of -nographic.

Alex

Re: [Qemu-devel] Powerpc regressions?

[Rob Landley]

[-- Attachment #1: Type: text/plain, Size: 5374 bytes --]

On Sunday 02 August 2009 07:25:45 Alexander Graf wrote:
> On 02.08.2009, at 12:04, Aurelien Jarno wrote:
> > On Sun, Aug 02, 2009 at 12:40:53AM -0500, Rob Landley wrote:
> >> On Monday 13 July 2009 07:25:45 Aurelien Jarno wrote:
> >>>> 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.
> >>
> >> Finally got back in a position to spend some more time on this.
> >> Sorry for the
> >> delay.
> >>
> >> Ok, I'm trying just to boot to a command prompt with a serial
> >> console and IDE
> >> /dev/hda.  (Or funky scsi IDE /dev/sda in a pinch.)
> >>
> >> Your .config is for a 2.6.26 kernel and I'm building 2.6.30, so I
> >> have to run
> >> make oldconfig against it (and just hit enter on everything to take
> >> the
> >> defaults).  Also, I'm not using an initramfs at the moment, so
> >> presumably
> >> anything that's in a module can go because it won't get loaded
> >> before I get a
> >> shell prompt anyway, so I can yank anything config =m, and the module
> >> infrastructure itself, to simplify things a bit.
> >>
> >> That gave me the (much smaller) attached .config, which _should_
> >> work the same
> >> as yours, I hope?  Note that CONFIG_SERIAL_8250_CONSOLE is on, so I
> >> should be
> >> able to get a serial console, which is my first target: get boot
> >> messages from
> >> this kernel.
> >>
> >> I built a kernel using the attached .config and my existing powerpc
> >> toolchain
> >> (which built a kernel that booted under older qemu), and attempted
> >> to boot the
> >> result under current git (28e738dcb81d):
> >>
> >> qemu-system-ppc -M g3beige -nographic -no-reboot -kernel zImage-
> >> powerpc
> >> -hda image-powerpc.sqf -append "root=/dev/hda rw init=/usr/sbin/
> >> init.sh
> >> panic=1 PATH=/usr/bin console=ttyS0 "
> >>
> >>>> =============================================================
> >>>> OpenBIOS 1.0 [Jul 5 2009 17:36]
> >>>> Configuration device id QEMU version 1 machine id 2
> >>>> CPUs: 1
> >>>> Memory: 128M
> >>>> UUID: 00000000-0000-0000-0000-000000000000
> >>>> CPU type PowerPC,750
> >>
> >> Welcome to OpenBIOS v1.0 built on Jul 5 2009 17:36
> >>
> >>>> [ppc] Kernel already loaded (0x01000000 + 0x0039bef0) (initrd
> >>>> 0x00000000 +
> >>
> >> 0x00000000)
> >>
> >>>> [ppc] Kernel command line: root=/dev/hda rw init=/usr/sbin/
> >>>> init.sh panic=1
> >>
> >> PATH=/usr/bin console=ttyS0
> >> OF stdout device is: /pci@80000000/mac-io@4/escc@13000/ch-b@13000
> >> Preparing to boot Linux version 2.6.30 (landley@driftwood) (gcc
> >> version 4.2.1)
> >> #1 Sat Aug 1 17:35:12 CDT 2009
> >> command line: root=/dev/hda rw init=/usr/sbin/init.sh panic=1 PATH=/
> >> usr/bin
> >> console=ttyS0
> >> memory layout at init:
> >>  alloc_bottom : 013a0000
> >>  alloc_top    : 08000000
> >>  alloc_top_hi : 08000000
> >>  rmo_top      : 08000000
> >>  ram_top      : 08000000
> >> found display   : /pci@80000000/QEMU,VGA@1, opening... done
> >> copying OF device tree...
> >> Building dt strings...
> >> Building dt structure...
> >> Device tree strings 0x013a1000 -> 0x013a1383
> >> Device tree struct  0x013a2000 -> 0x013a4000
> >> Calling quiesce...
> >> returning from prom_init
> >>
> >> At which point it exits and I get the prompt back.
> >
> > I think using console=ttyPZ0 which is the serial port name on PowerPC
> > will give you more details.

Yup, that gave me boot messages.  Thanks.

Huh.  It used ttyS0 with the other .config (I at least got boot messages), I 
wonder why that changed?  (Just confirmed that this .config has the driver for a 
16550a built in.  And the name "ttyS0" for the first serial device is 
presumably about as genric as using eth1 for the first wired ethernet 
device...)

Ok, switch on squashfs, boot with:

qemu-system-c -M g3beige -nographic -no-reboot -kernel zImage-powerpc -hda 
image-powerpc.sqf -append "root=/dev/hda rw init=/usr/bin/hello-static panic=1 
PATH=/usr/bin console=ttyPZ0"

And it hangs.

I'm using a statically linked "hello world" program linked against uClibc as 
my init (attached), and it hangs after printing the first two characters of 
"hello world".

Well, I suppose that's progress.

Any suggestions?

> Also try "-vnc :5 -serial mon:stdio" instead of -nographic.

When I get these targets working, I drive builds on them with things like:

./run-from-build.sh $1 << 'EOF'
                #
# Smoke test for the compiler
gcc -s /usr/src/thread-hello2.c -lpthread -o /tmp/hello &&
/tmp/hello
sync
exit
EOF

(The first line of spaces is because linux kernel 16550a serial chip 
initialization flushes the queue, eating anywhere up to the first 16 bytes of 
input data.)

Therefore, I prefer to test what I'd like to actually _use_.  The -nographic 
option can make qemu act like a normal, more or less scriptable process.  
Other display options don't, they all expect to interact with a human (unless 
you want to do something fancy with the virtual network to work around it).

> Alex

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


[-- Attachment #2: .config.zip --]
[-- Type: application/zip, Size: 8759 bytes --]

[-- Attachment #3: hello-static --]
[-- Type: application/x-executable, Size: 10328 bytes --]

Re: [Qemu-devel] Powerpc regressions?

[Hollis Blanchard]

On Tue, Aug 4, 2009 at 7:05 PM, Rob Landley<rob@landley.net> wrote:
> On Sunday 02 August 2009 07:25:45 Alexander Graf wrote:
>> On 02.08.2009, at 12:04, Aurelien Jarno wrote:
>> >
>> > I think using console=ttyPZ0 which is the serial port name on PowerPC
>> > will give you more details.
>
> Yup, that gave me boot messages.  Thanks.
>
> Huh.  It used ttyS0 with the other .config (I at least got boot messages), I
> wonder why that changed?  (Just confirmed that this .config has the driver for a
> 16550a built in.  And the name "ttyS0" for the first serial device is
> presumably about as genric as using eth1 for the first wired ethernet
> device...)

Sadly no. This was a subject of much debate, but Russel King insisted
that ttyS would be used only for NS16550-style UARTs. In the past, the
pmac_zilog driver hijacked that major/minor anyways, but it was later
changed to use its own major/minor (and ttyPZ). (I don't remember when
that change occurred, but it should be pretty easy for you to find out
if you care.)

-Hollis