* [Qemu-devel] Powerpc regressions?
@ 2009-07-07 22:48 Rob Landley
2009-07-08 9:32 ` Alexander Graf
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: Rob Landley @ 2009-07-07 22:48 UTC (permalink / raw)
To: qemu-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-07-07 22:48 [Qemu-devel] Powerpc regressions? Rob Landley
@ 2009-07-08 9:32 ` Alexander Graf
2009-07-08 18:21 ` Rob Landley
2009-07-08 13:24 ` Lennart Sorensen
2009-07-10 23:42 ` Aurelien Jarno
2 siblings, 1 reply; 22+ messages in thread
From: Alexander Graf @ 2009-07-08 9:32 UTC (permalink / raw)
To: Rob Landley; +Cc: qemu-devel
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
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-07-07 22:48 [Qemu-devel] Powerpc regressions? Rob Landley
2009-07-08 9:32 ` Alexander Graf
@ 2009-07-08 13:24 ` Lennart Sorensen
2009-07-09 11:49 ` Rob Landley
2009-07-10 23:42 ` Aurelien Jarno
2 siblings, 1 reply; 22+ messages in thread
From: Lennart Sorensen @ 2009-07-08 13:24 UTC (permalink / raw)
To: Rob Landley; +Cc: qemu-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-07-08 9:32 ` Alexander Graf
@ 2009-07-08 18:21 ` Rob Landley
0 siblings, 0 replies; 22+ messages in thread
From: Rob Landley @ 2009-07-08 18:21 UTC (permalink / raw)
To: Alexander Graf; +Cc: qemu-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-07-08 13:24 ` Lennart Sorensen
@ 2009-07-09 11:49 ` Rob Landley
2009-07-09 13:46 ` Lennart Sorensen
0 siblings, 1 reply; 22+ messages in thread
From: Rob Landley @ 2009-07-09 11:49 UTC (permalink / raw)
To: Lennart Sorensen; +Cc: qemu-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-07-09 11:49 ` Rob Landley
@ 2009-07-09 13:46 ` Lennart Sorensen
2009-07-10 3:55 ` Rob Landley
0 siblings, 1 reply; 22+ messages in thread
From: Lennart Sorensen @ 2009-07-09 13:46 UTC (permalink / raw)
To: Rob Landley; +Cc: qemu-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-07-09 13:46 ` Lennart Sorensen
@ 2009-07-10 3:55 ` Rob Landley
0 siblings, 0 replies; 22+ messages in thread
From: Rob Landley @ 2009-07-10 3:55 UTC (permalink / raw)
To: Lennart Sorensen; +Cc: qemu-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-07-07 22:48 [Qemu-devel] Powerpc regressions? Rob Landley
2009-07-08 9:32 ` Alexander Graf
2009-07-08 13:24 ` Lennart Sorensen
@ 2009-07-10 23:42 ` Aurelien Jarno
2009-07-11 2:09 ` Aurelien Jarno
2009-07-13 3:24 ` Rob Landley
2 siblings, 2 replies; 22+ messages in thread
From: Aurelien Jarno @ 2009-07-10 23:42 UTC (permalink / raw)
To: Rob Landley; +Cc: qemu-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-07-10 23:42 ` Aurelien Jarno
@ 2009-07-11 2:09 ` Aurelien Jarno
2009-07-11 21:49 ` Paul Brook
2009-07-13 3:24 ` Rob Landley
1 sibling, 1 reply; 22+ messages in thread
From: Aurelien Jarno @ 2009-07-11 2:09 UTC (permalink / raw)
To: Rob Landley, Gerd Hoffmann, Paul Brook; +Cc: qemu-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-07-11 2:09 ` Aurelien Jarno
@ 2009-07-11 21:49 ` Paul Brook
2009-07-11 23:35 ` Aurelien Jarno
0 siblings, 1 reply; 22+ messages in thread
From: Paul Brook @ 2009-07-11 21:49 UTC (permalink / raw)
To: qemu-devel; +Cc: Aurelien Jarno, Gerd Hoffmann
> 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-07-11 21:49 ` Paul Brook
@ 2009-07-11 23:35 ` Aurelien Jarno
2009-07-13 3:29 ` Rob Landley
0 siblings, 1 reply; 22+ messages in thread
From: Aurelien Jarno @ 2009-07-11 23:35 UTC (permalink / raw)
To: Paul Brook; +Cc: qemu-devel, Gerd Hoffmann
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-07-10 23:42 ` Aurelien Jarno
2009-07-11 2:09 ` Aurelien Jarno
@ 2009-07-13 3:24 ` Rob Landley
2009-07-13 12:25 ` Aurelien Jarno
1 sibling, 1 reply; 22+ messages in thread
From: Rob Landley @ 2009-07-13 3:24 UTC (permalink / raw)
To: Aurelien Jarno; +Cc: qemu-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-07-11 23:35 ` Aurelien Jarno
@ 2009-07-13 3:29 ` Rob Landley
0 siblings, 0 replies; 22+ messages in thread
From: Rob Landley @ 2009-07-13 3:29 UTC (permalink / raw)
To: Aurelien Jarno; +Cc: Gerd Hoffmann, Paul Brook, qemu-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-07-13 3:24 ` Rob Landley
@ 2009-07-13 12:25 ` Aurelien Jarno
2009-07-13 15:55 ` Rob Landley
2009-08-02 5:40 ` Rob Landley
0 siblings, 2 replies; 22+ messages in thread
From: Aurelien Jarno @ 2009-07-13 12:25 UTC (permalink / raw)
To: Rob Landley; +Cc: qemu-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-07-13 12:25 ` Aurelien Jarno
@ 2009-07-13 15:55 ` Rob Landley
2009-07-13 16:13 ` Paul Brook
2009-08-02 5:40 ` Rob Landley
1 sibling, 1 reply; 22+ messages in thread
From: Rob Landley @ 2009-07-13 15:55 UTC (permalink / raw)
To: Aurelien Jarno; +Cc: qemu-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-07-13 15:55 ` Rob Landley
@ 2009-07-13 16:13 ` Paul Brook
2009-07-13 17:42 ` Rob Landley
0 siblings, 1 reply; 22+ messages in thread
From: Paul Brook @ 2009-07-13 16:13 UTC (permalink / raw)
To: qemu-devel; +Cc: Aurelien Jarno
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-07-13 16:13 ` Paul Brook
@ 2009-07-13 17:42 ` Rob Landley
0 siblings, 0 replies; 22+ messages in thread
From: Rob Landley @ 2009-07-13 17:42 UTC (permalink / raw)
To: Paul Brook; +Cc: qemu-devel, Aurelien Jarno
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-07-13 12:25 ` Aurelien Jarno
2009-07-13 15:55 ` Rob Landley
@ 2009-08-02 5:40 ` Rob Landley
2009-08-02 10:04 ` Aurelien Jarno
1 sibling, 1 reply; 22+ messages in thread
From: Rob Landley @ 2009-08-02 5:40 UTC (permalink / raw)
To: Aurelien Jarno; +Cc: qemu-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-08-02 5:40 ` Rob Landley
@ 2009-08-02 10:04 ` Aurelien Jarno
2009-08-02 12:25 ` Alexander Graf
0 siblings, 1 reply; 22+ messages in thread
From: Aurelien Jarno @ 2009-08-02 10:04 UTC (permalink / raw)
To: Rob Landley; +Cc: qemu-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-08-02 10:04 ` Aurelien Jarno
@ 2009-08-02 12:25 ` Alexander Graf
2009-08-05 2:05 ` Rob Landley
0 siblings, 1 reply; 22+ messages in thread
From: Alexander Graf @ 2009-08-02 12:25 UTC (permalink / raw)
To: Aurelien Jarno; +Cc: qemu-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-08-02 12:25 ` Alexander Graf
@ 2009-08-05 2:05 ` Rob Landley
2009-08-05 23:55 ` Hollis Blanchard
0 siblings, 1 reply; 22+ messages in thread
From: Rob Landley @ 2009-08-05 2:05 UTC (permalink / raw)
To: Alexander Graf; +Cc: qemu-devel, Aurelien Jarno
[-- 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 --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Qemu-devel] Powerpc regressions?
2009-08-05 2:05 ` Rob Landley
@ 2009-08-05 23:55 ` Hollis Blanchard
0 siblings, 0 replies; 22+ messages in thread
From: Hollis Blanchard @ 2009-08-05 23:55 UTC (permalink / raw)
To: Rob Landley; +Cc: Alexander Graf, Aurelien Jarno, qemu-devel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2009-08-05 23:55 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-07-07 22:48 [Qemu-devel] Powerpc regressions? Rob Landley
2009-07-08 9:32 ` Alexander Graf
2009-07-08 18:21 ` Rob Landley
2009-07-08 13:24 ` Lennart Sorensen
2009-07-09 11:49 ` Rob Landley
2009-07-09 13:46 ` Lennart Sorensen
2009-07-10 3:55 ` Rob Landley
2009-07-10 23:42 ` Aurelien Jarno
2009-07-11 2:09 ` Aurelien Jarno
2009-07-11 21:49 ` Paul Brook
2009-07-11 23:35 ` Aurelien Jarno
2009-07-13 3:29 ` Rob Landley
2009-07-13 3:24 ` Rob Landley
2009-07-13 12:25 ` Aurelien Jarno
2009-07-13 15:55 ` Rob Landley
2009-07-13 16:13 ` Paul Brook
2009-07-13 17:42 ` Rob Landley
2009-08-02 5:40 ` Rob Landley
2009-08-02 10:04 ` Aurelien Jarno
2009-08-02 12:25 ` Alexander Graf
2009-08-05 2:05 ` Rob Landley
2009-08-05 23:55 ` Hollis Blanchard
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.