Re: config(5) break down
Aaron J. Grier
> I *do* think it's a useful datapoint to note that sun2, pmax, algor,
> etc. are never, ever downloaded any more.
anybody tried netbsd-5 on pmax recently?
I am slowly combing through my pile of aging hardware looking for
reasons to keep older machines, or at least give them a "last harrah"
opportunity to build the world.
--
Aaron J. Grier | "Not your ordinary poofy goof." | agr...@poofygoof.com
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Erik Bertelsen
> On Thu, Mar 18, 2010 at 08:47:50PM -0400, Thor Lancelot Simon wrote:
>> I *do* think it's a useful datapoint to note that sun2, pmax, algor,
>> etc. are never, ever downloaded any more.
>
> anybody tried netbsd-5 on pmax recently?
>
> I am slowly combing through my pile of aging hardware looking for
> reasons to keep older machines, or at least give them a "last harrah"
> opportunity to build the world.
Well, that's why I turn on my DECStation 5000 from time to time and
let it rebuild NetBSD-current (which typically takes at least a week).
I had a successful build last November but now it fails when the new
libc is installed (described a separate mail a few minutes ago).
- Erik
Matthias Drochner
Having a stack of DECstations myself (one of those being in
serious production use as DHCP server and IPv6 router) I
wouldn't consider the pmax port a good candidate for removal.
We're having mips support anyway, we need tc for alpha
as well, and zs tty drivers are used by other ports too.
There isn't a lot of port specific code.
Didn't try NetBSD-5 yet. The router box is rock-solid as is,
so I didn't have much motivation for experiments so far.
Can you make sense of the coredumps you are getting?
best regards
Matthias
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Aaron J. Grier
> Didn't try NetBSD-5 yet.
I'm cross-compiling up NetBSD-4, and will try it on my 5000/200. I
think I had NetBSD-3 on it last, and that was able to self-host. I
still get a kick out of having 480MB of RAM in a 25MHz machine, but
sadly have no practical application for it.
Michael L. Hitch
> On Tue, Apr 27, 2010 at 06:05:16PM +0200, Matthias Drochner wrote:
>> Didn't try NetBSD-5 yet.
>
> I'm cross-compiling up NetBSD-4, and will try it on my 5000/200. I
> think I had NetBSD-3 on it last, and that was able to self-host. I
> still get a kick out of having 480MB of RAM in a 25MHz machine, but
> sadly have no practical application for it.
I've been running NetBSD 4.0_BETA on a 5000/150 for some time, and
wanted to update to NetBSD-5.0_STABLE so I could get WAPBL and RaidFrame
parity map [a 6GB raid5 volumne takes quite a while to rewrite parity].
I've been able to boot a kernel, but have problems going to multiuser.
It's a mail machine and runs clamd, which takes more and more memory.
It kind of looks like possibly a problem in bt_insbusy() called from
vmem_xalloc() when memory gets tight. I haven't had much time to try
to debug this yet (the RaidFrame parity really hurts here). I also
tried a NetBSD-4.0_STABLE kernel, with the same results. I noticed there
were a number of changes in subr_vmem.c between my 4.0_BETA and
4.0_STABLE.
--
Michael L. Hitch mhi...@montana.edu
Computer Consultant
Information Technology Center
Montana State University Bozeman, MT USA
Michael L. Hitch
> It kind of looks like possibly a problem in bt_insbusy() called from
> vmem_xalloc() when memory gets tight. I haven't had much time to try
> to debug this yet (the RaidFrame parity really hurts here). I also
> tried a NetBSD-4.0_STABLE kernel, with the same results. I noticed there
> were a number of changes in subr_vmem.c between my 4.0_BETA and 4.0_STABLE.
An update....
I copied this system to a 5000/260 with 180M of memory, and it was able
to boot up to multiuser with the NetBSD-4.0_STABLE. A 5.0.1 kernel, and
an older NetBSD-5.0_STABLE kernel both hang when clamd is starting. and
the only thing I've been able to determine so far is that it's in the trap
handling when I halt it. I'd guess it's looping with memory exceptions at
a high IPL. If I disable the clamd startup, then 5.0_STABLE boots fine
and seems to run OK.