Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Problems booting miniroot for upgrade to 5.1

11 views
Skip to first unread message

Dirk Heinrichs

unread,
Dec 23, 2010, 12:08:14 PM12/23/10
to
Hi,

I'm running 5.0.1 on Amiga and wanted to upgrade to 5.1. So I
transferred miniroot.fs to the swap partition using dd and rebooted from
it. I enter "netbsd -b" at the bootloader prompt, but after a few
moments, I get a message:

"kernel symbol table missing"

and

"unable to allocate space in parent map"

followed by a "db>" prompt.

Any hints what could be wrong?

System is Amiga 3000 with Cyberstorm MKII (060) and CyberGFX 64/3D.

Thanks...

Dirk

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de

John Klos

unread,
Dec 23, 2010, 12:20:56 PM12/23/10
to
Hi,

> I'm running 5.0.1 on Amiga and wanted to upgrade to 5.1. So I
> transferred miniroot.fs to the swap partition using dd and rebooted from
> it. I enter "netbsd -b" at the bootloader prompt, but after a few
> moments, I get a message:

While this doesn't directly address your immediate problem, you can
upgrade by untargzipping the 5.1 kernel, rebooting, then untargzipping all
of the other sets except etc.tgz (so you don't blow away your
configuration files).

JOhn

Frank Wille

unread,
Dec 23, 2010, 1:08:22 PM12/23/10
to
Dirk Heinrichs wrote:

> "unable to allocate space in parent map"

> [...]


> System is Amiga 3000 with Cyberstorm MKII (060) and CyberGFX 64/3D.

Probably this has something to do with the page table limitation in pmap,
which Ignatios mentioned a few hours ago? While current (5.99.x) switched
to a common m68k pmap module, 5.1 still uses the old, amiga-specific one.

The CV64/3D is known to allocate a huge memory window. Maybe there are not
enough page tables for it.

You may want to confirm my assumption by disabling the CV64/3D with the
shutdown-tool before booting NetBSD. Or remove the card for a test.

As I understand you, 5.0 worked. So maybe it helps to boot a smaller 5.1
kernel. Maybe you can compile a customized kernel yourself. Or try to boot
the normal generic kernel, instead of the installation kernel, which also
is a bit smaller. You can simply do that by renaming your current kernel
and copy the 5.1 one to /netbsd (a newer kernel will have no problems with
your old files). Then reboot the system.

When this works, then you're lucky and can do the update manually by
extracting the sets with "tar xzfp ..." in single-user mode, as John
mentioned. Do not forget the etcupdate(8) when done.

As a last option you can try a current kernel or wait for 6.0.

--
Frank Wille

Frank Wille

unread,
Dec 23, 2010, 4:14:46 PM12/23/10
to
Michael L. Hitch wrote:

>> Probably this has something to do with the page table limitation in
>> pmap, which Ignatios mentioned a few hours ago? While current (5.99.x)
>> switched to a common m68k pmap module, 5.1 still uses the old,
>> amiga-specific one.
>

> Eh?
>
> $ ident
>
../OBJ/amiga060/home/mhitch/NetBSD-5/src/sys/arch/amiga/compile/GENERIC/netbsd|grep
> pmap $NetBSD: pmap_bootstrap.c,v 1.2 2008/04/28 20:23:12 martin
> Exp $ $NetBSD: pmap_motorola.c,v 1.39 2008/06/28 13:22:14 tsutsui
> Exp $
>
> That sure looks like the common m68k pmap to me.

Indeed, you're right! I was fooled by the fact that the old
src/sys/arch/amiga/amiga/pmap.c still lives in the netbsd-5 branch and was
not removed.

That's bad news. So we have a problem somewhere.

Michael L. Hitch

unread,
Dec 24, 2010, 1:04:08 AM12/24/10
to

On Thu, 23 Dec 2010, Dirk Heinrichs wrote:

> I'm running 5.0.1 on Amiga and wanted to upgrade to 5.1. So I
> transferred miniroot.fs to the swap partition using dd and rebooted from
> it. I enter "netbsd -b" at the bootloader prompt, but after a few
> moments, I get a message:
>
> "kernel symbol table missing"

That's because you didn't tell the boot loader to include the kernel
symbol table with the -S option.

> "unable to allocate space in parent map"

Would that be "panic: uvm_km_suballoc: unable to allocate space in
parent map"?

> followed by a "db>" prompt.

If you include the -S option on the boot command, you can get a stack
backtrace at this point with the 'trace' (or 'bt') command. It will also
work without kernel symbols, but it makes it harder to determine the
functions that were called. This should show who called uvm_km_suballoc()
and narrow where the problem is. I can't remember if the m68k stack trace
includes arguments, but if it does, it would be nice to determine the size
of the request.

Mike

0 new messages