Gordon,

I think, I have NetBSD/sun3 almost running :-)

> This is most likely caused by using an old config program that still
> thinks dev_t is a short (it recently became a long).  This could cause
> the code at nfs_vfsopt.c:258 to think swap is already configured.
> Other places that care about dev_t could have similar problems...
> (Look out for dev_t pitfalls!)

I don't think this was the cause of my problem!
I was using, and still are, 'config.new' that is dated Feb. 4 1994.
This program was part of Adam's binary distribution
and still it can be found on 'sun-lamp'. It's runs without any problems
on my sun 3/E ( SUNOS 4.1.1_U1 ).

I also tried a newer config program, but that gave me some problems!
It didn't like the line:

    config  netbsd swap nfs

It gave the following error messages:

    HILTON:44:  netbsd: no root device specified
    HILTON has no configurations!
    *** stop

The swapping problem disappeared when I replaced
some files by newer ones:

                    current ver.    previous ver.
                    
    Makefile.sun3   ver. 1.20.2.1   ( ver. 1.20 )
    delay.s         ver. 1.1.2.1    ( ver. 1.1  )
    pmap.c          ver. 1.28.2.3   ( ver. 1.28 )
    trap.c          ver. 1.25.2.2   ( ver. 1.25 )
    nfs_bio.c       ver. 1.15.2.2   ( ver. 1.13 )
    nfs_boot.c      ver. 1.6.2.2    ( ver. 1.4  )
    vm_swap.c       ver. 1.23.2.1   ( ver. 1.20 )

This cured the 'swstrategy' panic.

But, I think I found another problem. I'am not sure
what is happening. It has something to do with 
the value of the option SYMTAB_SPACE in the config file.

This is what I get with SYMTAB_SPACE set to 85000:

    Boot: vmunix
    Size: 535440+111752+62832 bytes
    console on zs0 (ttya)
    DDB: found symbols [38724 + 41209 bytes]
    Stopped at  _Debugger+0x6:  unlk    a6
    db> cont
    Copyright (c) ....
    ...
    Model: Sun 3/50
    real mem  = 4145152
    avail mem = 3088384
    using 25 buffers containing 204800 bytes of memory
    ...
    kd0 at mainbus0
    nfs_boot: using network interface 'le0'
    nfs_boot: client=0x86bc4514, server=0x86bc450b
    nfs_boot: hostname=hilton
    root on tempest:/mnt/export/hilton/root
    swap on tempest:/mnt/export/hilton/swap
    WARNING: real-time clock reports a time earlier than last
         write to root filesystem. Trusting filesystem...
    Enter pathname of shell or RETURN for sh:
    sh: warning: running as root with dot in PATH
    # mount -u /
    # mount /usr
    # exit
    pa_to_pvp: bad pa=0x3f4000
    Stopped at  _Debugger+0x6:  unlk    a6
    db> cont
    panic: save_modified_bits: bad pa=3f4000
    Stopped at  _Debugger+0x6:  unlk    a6
    db> 


Setting SYMTAB_SPACE to 00001 does give the following:

    Boot: vmunix
    Size: 535440+26760+62832 bytes
    console on zs0 (ttya)
    DDB: no symbols
    Stopped at  0xe0711aa:  unlk    a6
    db> cont
    Copyright (c) ....
    ...
    Model: Sun 3/50
    real mem  = 4145152
    avail mem = 31662112
    using 25 buffers containing 204800 bytes of memory
    ...
    kd0 at mainbus0
    nfs_boot: using network interface 'le0'
    nfs_boot: client=0x86bc4514, server=0x86bc450b
    nfs_boot: hostname=hilton
    root on tempest:/mnt/export/hilton/root
    swap on tempest:/mnt/export/hilton/swap
    WARNING: real-time clock reports a time earlier than last
         write to root filesystem. Trusting filesystem...
    Enter pathname of shell or RETURN for sh:
    sh: warning: running as root with dot in PATH
    # mount -u /
    # mount /usr
    # exit
    setting tty flags
    starting network
    add host hilton.oce.nl: gateway localhost
    starting rpc daemons: portmap.
    starting system logger, time daemon.
    checking for core dump...
     done.
    building databases...
    clearing /tmp
    standard daemons: update cron.
    starting network daemons: routed printer inetd.
>>> Process got killing signal b
    starting local daemon:.
    runtime link editor directory cache
>>> Process got killing signal b
    Fri Jul 22 12:50:12  1994
    Jul 22 12:50:14 hilton init: kernel security level changed from 0 to 1
    NetBSD/sun3 (hilton.oce.nl) (console)

    login: 
>>> Jul 22 12:52:01 hilton inetd[69]: pmap_set: 10001 1 17 1041: Address
        already in use
>>> Jul 22 12:54:01 hilton inetd[69]: pmap_set: 10001 2 17 1041: Address
        already in use
>>> Jul 22 12:56:01 hilton inetd[69]: pmap_set: 10001 3 17 1041: Address
        already in use
>>> Jul 22 12:58:01 hilton inetd[69]: pmap_set: 10002 2 17 1042: Address
        already in use
>>> Jul 22 13:00:01 hilton inetd[69]: pmap_set: 10002 3 17 1042: Address
        already in use
>>> Jul 22 13:02:01 hilton inetd[69]: pmap_set: 10008 1 17 1043: Address
        already in use

Question 1: Why does the value of SYMTAB_SPACE has such an influence?

Question 2: Where are these signals coming from?

Question 3: What's inetd trying to say?

Question 4: What should go into my `config' file to satisfy newer
            config.new executables? 

Question 5: The login message appears garbled on the console. Where
            can I tell 'login' to use 8 bits, no parity. Remember that
            getty isn't running at that moment, so /etc/ttys isn't of
            any use!

I almost forgot to tell you, that I succesfully used gcc-2.6.0 to cross-
compile the sun3 kernel sources.

By the way, instead of typing "mount -u /" I once typed
"mount u /". I must admit this wasn't what I wanted to type. 
But after this the system was completely f... up ;-)

    # mount u /
    Bus error
    # mount /usr
    mount: error 43
    # ps
    ps: error 43
    # sh
    sh: error 43

Members of the Core-Team, are you listening? This doesn't seem OK
to me!

Kind Regards,

Harry


------------------------------------------------------------------------------
H.L Schreurs                                            Email: hls@oce.nl
Business Unit Printing Systems                          Phone: +31 77 593775
Oce Nederland B.V.                                      Fax:   +31 77 595434
The Netherlands
------------------------------------------------------------------------------

      ###########################################################
      #  This note does not necessarily represent the position  #
      #     of Oce-Nederland B.V. Therefore no liability or     #
      #      responsibility for whatever will be accepted.      #
      ###########################################################

------------------------------------------------------------------------------