headers
Havard Eidnes | 20 Mar 2002 01:15
Picon

1.5.3_RC1 snapshot available

Hi,

I've placed a 1.5.3_RC1 snapshot available in

  pub/NetBSD/arch/sun3/snapshot/20020312-1.5.3_RC1/

on the ftp server; it'll spread to the mirrors over the next few
days.

Please note that this snapshot does not have the fix for the recently
discovered zlib problem, it will be in 1.5.3, though.

This snapshot also does not contain X11 binaries; for client-side you
can use the binaries from e.g. the hp300 snapshot, though.

I'll also have to apologize for the time it's taken to cut this one.

Regards,

- Håvard
Permalink | Reply | 0 comments |
headers
Rick Kelly | 26 Mar 2002 03:53

Sun 3/50 and -current


So I've been running -current on a Sun 3/50 with 12 megs.

Userland is from the most recent snapshot, and the kernel source is
from March 12, 2002.

I'm running a stripped kernel that I built myself, and I'm running rdate a
few times a day to my ntp server to keep the clock updated.

You can see here the rev of my kernel:

NetBSD slug 1.5ZB NetBSD 1.5ZB (SLUG) #0: Tue Mar 12 23:55:22 MST 2002    
rmk <at> slug:/usr/src/sys/arch/sun3/compile/SLUG sun3

The major application that I'm using, so far, is tinyfugue to connect to a
MUD.

I can use SSH1 with this machine, but SSH2 times out as the system frantically
pages.

Also, the first thing to do is to delete /var/db/locate.database. Rebuilding
that file caused the system to thrash and run into the next days cron jobs.
I had 50 processes pound the poor machine to death.

Below is the output of top -n:

/usr/local/home/rmk> top -n
load averages:  0.54,  0.21,  0.12    19:51:14
19 processes:  18 sleeping, 1 on processor
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Brownlee | 26 Mar 2002 23:17
Picon

Re: Sun 3/50 and -current

On Mon, 25 Mar 2002, Rick Kelly wrote:

> So I've been running -current on a Sun 3/50 with 12 megs.
>
> [...]
>
> I can use SSH1 with this machine, but SSH2 times out as the system
> frantically pages.
>
	ssh2 is really too heavy for a low end sparc, let alone a sun3 :/

> [...]
> I think that the days of NetBSD/sun3 will soon close for the Sun 3/50, of
> course their are earlier versions that run well.

	NetBSD has only just made it onto the acorn26 and sun2 platforms,
	so if anything the minimum spec is getting lower not higher...

	I agree the base system is getting larger - IPv6 was a large chunk
	in itself - and a GENERIC kernel is no longer bootable for many
	smaller machines, but if people are willing to spend the time to
	help better conditionalise the kernel it can benefit everyone.

	An obvious place to start would be to compile up a custom kernel,
	run size on *.o in the compile directory, and work out where a
	bunch os space is being used. Alternatively look at shrinking
	some of the hash tables and similar used in the kernel.
--

-- 
		David/absolute		-- www.netbsd.org: No hype required --
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg A. Woods | 26 Mar 2002 23:43
Favicon

Re: Sun 3/50 and -current

[ On Tuesday, March 26, 2002 at 22:17:24 (+0000), David Brownlee wrote: ]
> Subject: Re: Sun 3/50 and -current
>
> 	ssh2 is really too heavy for a low end sparc, let alone a sun3 :/

I dunno about that -- I tested it from my SS1.  I wouldn't want to run
the client regularly with the X11 server and an xterm, but just an xterm
and the client, should be "usable" (or just the daemon and a shell session).

> 	An obvious place to start would be to compile up a custom kernel,
> 	run size on *.o in the compile directory, and work out where a
> 	bunch os space is being used. Alternatively look at shrinking
> 	some of the hash tables and similar used in the kernel.

Yes, of course -- GENERIC kernels on old/small machines are not really
usable for more than the install and build of a custom kernel (and
sometimes even the build needs to be done elsewhere!  :-)

--

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods <at> acm.org>;  <g.a.woods <at> ieee.org>;  <woods <at> robohack.ca>
Planix, Inc. <woods <at> planix.com>; VE3TCP; Secrets of the Weird <woods <at> weird.com>
Permalink | Reply | 0 comments |
headers
Toby Thain | 26 Mar 2002 23:47
Picon

Re: Sun 3/50 and -current


David Brownlee wrote:
> 
> On Mon, 25 Mar 2002, Rick Kelly wrote:
> 
> > So I've been running -current on a Sun 3/50 with 12 megs.
> >
> > [...]
> >
> > I can use SSH1 with this machine, but SSH2 times out as the system
> > frantically pages.
> >
>         ssh2 is really too heavy for a low end sparc, let alone a sun3 :/

To add to Greg's comment, ssh2 is OK on my SS1+ - just the connect time
is annoying. But it's also a bit annoying (if shorter) with ssh1.

> 
> > [...]
> > I think that the days of NetBSD/sun3 will soon close for the Sun 3/50, of
> > course their are earlier versions that run well.
> 
>         NetBSD has only just made it onto the acorn26 and sun2 platforms,
>         so if anything the minimum spec is getting lower not higher...

That's more a matter of coincidence, I'd say; the older, leaner kernels
are arguably better suited to the bottom end. When can I run NetBSD on
my PDP-11 :) ?

Toby
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rick Kelly | 27 Mar 2002 00:29

Re: Sun 3/50 and -current

David Brownlee said:

>	NetBSD has only just made it onto the acorn26 and sun2 platforms,
>	so if anything the minimum spec is getting lower not higher...

The downside of the Sun 3/50 is the memory hole between the onboard
4 megs and the 8 meg third-party card. Also, the cycle stealing video
doesn't help either. I could probably get a little improvement by 
using a serial console.

>	I agree the base system is getting larger - IPv6 was a large chunk
>	in itself - and a GENERIC kernel is no longer bootable for many
>	smaller machines, but if people are willing to spend the time to
>	help better conditionalise the kernel it can benefit everyone.

You can't actually boot a GENERIC kernel on a Sun 3/50. :-)

You can even see the INSTALL kernel leaking into video memory. The kernel
that I'm using now is:

-rwxr-xr-x   1 root  wheel  819494 Mar 13 09:34 netbsd

I could make it even smaller.

>	An obvious place to start would be to compile up a custom kernel,
>	run size on *.o in the compile directory, and work out where a
>	bunch os space is being used. Alternatively look at shrinking
>	some of the hash tables and similar used in the kernel.

I have maxusers set to 2, and a look at "sysctl -a" shows that resources
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rick Kelly | 27 Mar 2002 00:38

Re: Sun 3/50 and -current

Toby Thain said:

>To add to Greg's comment, ssh2 is OK on my SS1+ - just the connect time
>is annoying. But it's also a bit annoying (if shorter) with ssh1.

Yes, I use ssh2 on my SS1. Slow connect but otherwise it works fine.

>That's more a matter of coincidence, I'd say; the older, leaner kernels
>are arguably better suited to the bottom end. When can I run NetBSD on
>my PDP-11 :) ?

Back at NetBSD 1.2 I was able to use X and Mosaic on a 3/60 with 24megs.

--

-- 
Rick Kelly  rmk <at> rmkhome.com  www.rmkhome.com
Permalink | Reply | 0 comments |
headers
Rick Kelly | 27 Mar 2002 00:52

Re: Sun 3/50 and -current

Greg A. Woods said:

>I dunno about that -- I tested it from my SS1.  I wouldn't want to run
>the client regularly with the X11 server and an xterm, but just an xterm
>and the client, should be "usable" (or just the daemon and a shell session).

Yes, I use ssh2 to get into my headless SS1. The box is mainly used as a
small mailinglist machine, but I've also been chasing 1.5.3 on it. Takes
about 5 days or so to do a "make build".

>Yes, of course -- GENERIC kernels on old/small machines are not really
>usable for more than the install and build of a custom kernel (and
>sometimes even the build needs to be done elsewhere!  :-)

Yup, GENERIC doesn't even boot on the 3/50.

--

-- 
Rick Kelly  rmk <at> rmkhome.com  www.rmkhome.com
Permalink | Reply | 0 comments |
headers
negapluck | 27 Mar 2002 02:21
X-Face
Picon
Favicon

new install dmesg

NetBSD 1.5.3_RC1 (DISKLESS) #10: Sun Mar 17 11:11:51 CET 2002
    he <at> gjok.urc.uninett.no:/usr/src/sys/arch/sun3/compile/DISKLESS
Model: sun3 50
fpu: mc68881
total memory = 8192 KB
avail memory = 6520 KB
using 64 buffers containing 512 KB of memory
mainbus0 (root)
obio0 at mainbus0
zsc0 at obio0 addr 0x0 ipl 6: (softpri 3)
kbd0 at zsc0 channel 0
ms0 at zsc0 channel 1
zsc1 at obio0 addr 0x20000 ipl 6: (softpri 3)
zstty0 at zsc1 channel 0 (console i/o)
zstty1 at zsc1 channel 1
eeprom0 at obio0 addr 0x40000
clock0 at obio0 addr 0x60000 ipl 5
memerr0 at obio0 addr 0x80000 ipl 7: (Parity memory)
intreg0 at obio0 addr 0xa0000
le0 at obio0 addr 0x120000 ipl 3: address 08:00:20:00:2b:e5
le0: 8 receive buffers, 2 transmit buffers
obmem0 at mainbus0
bwtwo0 at obmem0 addr 0x100000 (1152x900)
enabling interrupts
boot device: le0
root on le0
nfs_boot: trying RARP (and RPC/bootparam)
nfs_boot: client_addr=192.168.69.180 (RARP from 192.168.69.170)
nfs_boot: server_addr=192.168.69.170
nfs_boot: hostname=sun3
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Brownlee | 27 Mar 2002 16:35
Picon

Re: Sun 3/50 and -current

On Tue, 26 Mar 2002, Rick Kelly wrote:

> The downside of the Sun 3/50 is the memory hole between the onboard
> 4 megs and the 8 meg third-party card. Also, the cycle stealing video
> doesn't help either. I could probably get a little improvement by
> using a serial console.
>
	A little, but its not going to set the world alight :)

> >	I agree the base system is getting larger - IPv6 was a large chunk
> >	in itself - and a GENERIC kernel is no longer bootable for many
> >	smaller machines, but if people are willing to spend the time to
> >	help better conditionalise the kernel it can benefit everyone.
>
> You can't actually boot a GENERIC kernel on a Sun 3/50. :-)
>
> You can even see the INSTALL kernel leaking into video memory. The kernel
> that I'm using now is:
>
> -rwxr-xr-x   1 root  wheel  819494 Mar 13 09:34 netbsd
>
> I could make it even smaller.

	Because of the specific hardware limitations we should probably
	have {GENERIC,INSTALL}_3_50 configurations.

> >	An obvious place to start would be to compile up a custom kernel,
> >	run size on *.o in the compile directory, and work out where a
> >	bunch os space is being used. Alternatively look at shrinking
> >	some of the hash tables and similar used in the kernel.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane