Subject: more sun3 booting trouble
To: None <port-sun3@NetBSD.ORG>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
List: port-sun3
Date: 04/21/1995 22:47:44
I'm having trouble booting NetBSD/sun3 diskless.  Something inside the
kernel seems to be returning ENOBUFS.

In the below, 132.206.82.2 is another Sun running SunOS 3.5; I'm using
it as rarp and tftp server for the boot (it has a SunOS 4.x bootblock
in its tftp area).  132.206.82.1 is collatz, a NeXT (which does not
support rarp as far as I can tell, or I'd be using it for everything),
which I am using as NFS server.  132.206.82.4 is the machine I'm trying
to boot.  I had to write my own bootparamd, since neither NeXT nor
SunOS 3.5 provides one; it's rudimentary (eg, the tables are hardcoded
at present rather than reading a config file), but it does seem to
return correct packets.  At least, all the stuff that should come from
the bootparam server and gets printed shows up as what I want it to be.
Logging from the bootparamd indicates that three queries arrive during
the boot process: a WHOAMI, and a GETFILE for "root", when the diskless
bootblock has control, and a WHOAMI once the kernel takes over.  The
kernel apparently never gets far enough to do any GETFILE queries.

Incidentally, the model number is wrong: it's a -3/150, not /160.  But
as far as I know the only differences are mechanical (for example, the
VME cage has only six slots instead of 12), so it's not surprising it
gets it wrong.

ftp://ftp.netbsd.org/pub/NetBSD/arch/sun3/netbsd-gen.gz is where I got
the kernel, and I just now checked and the date reported by sun-lamp is
over a week older than the date on the kernel file I have, and the size
of the .gz file is identical, so I expect it's the same one.  (My
netlink is sufficiently slow I'd rather not fetch it just for a
compare.  The md5 checksum of the gunzipped kernel I'm using is
6b9a54935a7c05155e7dd669a6226098.)

Here's what happens when I try to boot.  (This is a ten-finger copy, so
please forgive any obvious typos.)  Any advice on stuff to try would be
welcomed.  As far as I know the open and short reported by TDR are
lies; the number of clocks in the open report varies from boot to boot,
but the short is always 0 clocks away.

> b ie()netbsd -s
Boot: ie(0,0,0)netbsd -s
Using IP Address 132.206.82.4 = 84CE5204
Booting from tftp server at 132.206.82.2 = 84CE5202
Downloaded 101800 bytes from tftp server.

Using IP Address 132.206.82.4 = 84CE5204
hostname: Daily-Planet.Rodents.Montreal.QC.CA
domainname: a4d0e0f1bb28e8e6db9dc68b26197e20
server name 'collatz'
root pathname '/export/root/daily-planet'
root on collatz:/export/root/daily-planet fstype nfs
Size: 583904+125864+81248 bytes
console on zs0 (ttya)
DDB: found symbols [46944 + 50408 bytes]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.

NetBSD 1.0A (GENERIC) #208: Sat Apr  8 00:13:12 EDT 1995
    gwr@saturn2:/home/gwr/netbsd/src/sys/arch/sun3/compile/GENERIC
Model: Sun 3/160
real mem  = 8372224
avail mem = 6979584
using 51 buffers contaning 417792 bytes of memory
mainbus0 (root)
obctl0 at mainbus0
idprom0 at obctl0 hostid 0x11007895
fpu0 at mainbus0 (mc68881)
obmem0 at mainbus0
bwtwo0 at obmem0 addr 0xff000000 (1152x900)
obio0 at mainbus0
zs0 at obio0 addr 0x20000 level 6 softpr 3
zs1 at obio0 addr 0x0 level 6 softpri 3
eeprom0 at obio0 addr 0x40000
clock0 at obio0 addr 0x60000 level 5
ie0 at obio0 addr 0xc0000 level 3 hwaddr 08:00:20:06:c8:a9
vmes0 at mainbus0
si0 at vmes0 addr 0xff200000 level 2 vector 0x40
scsibus0 at si0
vmel0 at mainbus0
root on ie0
swap on ie0
dump on ie0
nfs_boot: using network interface 'ie0'
ie0: TDR detected an open 53 clocks away
nfs_boot: client_addr=0x84ce5204
ie0: TDR detected a short 0 clocks away
panic: nfs_boot: bootparam whoami, error=55
Stopped at      _Debugger+0x6:  unlk    a6
db>

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu