Some of you may recall that a day or two ago I sent a note to port-sun3
saying that

> I'm having trouble booting NetBSD/sun3 diskless.  Something inside
> the kernel seems to be returning ENOBUFS.
[...]
> panic: nfs_boot: bootparam whoami, error=55

I got a couple of suggestions; one of them said that this was because
the kernel was assuming the RPC reply fit into a single mbuf.  This
meant I had to shrink either the hostname or the domainname in the
WHOAMI reply.  I shrank both, changing the hostname from
Daily-Planet.Rodents.Montreal.QC.CA to D-P and the domainname from
a4d0e0f1bb28e8e6db9dc68b26197e20 to a4d0e0f1.  And the problem
magically evaporated.

Well, _that_ problem, at least.  As you've probably guessed, I now have
another one.  Now, I get this.  ("b -s" works because I symlinked
vmunix->netbsd in the NFS root area, for ease of booting.)

>b -s
[...]
root on collatz:/export/root/daily-planet
WARNING: bad date in battery clock -- CHECK AND RESET THE DATE!
swap on collatz:/export/root/daily-planet

Then it would normally prompt with "Enter pathname of shell or RETURN
for sh", take my response, and fire up a shell.  This almost happens.
Indeed, it tries to happen, but at some indeterminate point, output
freezes.  Typing ^Q resumes it for one or two characters, then it
freezes again.  This repeats several times; eventually it freezes hard
enough that ^Q won't restart it, and at this point, nothing but the
reset button on the back of the CPU card will get its attention - not
even BREAK on the serial line works.

It usually freezes for the first time within a couple of characters of
echoing the RETURN I type to the prompt.  Once it froze after the E of
the prompt.  Only once did it survive long enough for me to actually
issue a command to the single-user shell and get a response back, and
that time, it locked up for good after echoing the first character of
the second command.

Yes, I'm sure it's not the terminal.  Flow control is completely turned
off, and that terminal normally takes full-bore 9600 output without
ever needing flow control.

Anyone have any further ideas, or should I start digging around in
driver source and see what's weirding out?  BREAK not working makes it
sound as though it's getting stuck at high IPL...makes me wish I had a
kernel build environment available.  Perhaps trying to set one up
should be my next step.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu