Subject: rehash(?) of silly NFS errors and similar issues....
To: NetBSD Networking Technical Discussion List <tech-net@NetBSD.ORG>
From: Greg A. Woods <woods@weird.com>
List: tech-net
Date: 07/27/2001 20:14:54
Another thing that happened to annoy me greatly while I was fiddling
with different cards were ongoing silly complaints and sickages with
NFS.

For example:


	Jul 26 23:18:47 proven /netbsd: nfs_timer: ignoring error 50
	Jul 26 23:19:18 proven last message repeated 2442 times

or:

	Jul 26 23:32:54 proven /netbsd: nfs_timer: ignoring error 65
	Jul 26 23:33:25 proven last message repeated 1894 times
	Jul 26 23:35:26 proven last message repeated 8040 times
	Jul 26 23:45:27 proven last message repeated 39996 times
	Jul 26 23:55:28 proven last message repeated 39974 times
	Jul 27 00:00:02 proven last message repeated 18259 times

or:

	Jul 27 00:11:07 proven /netbsd: nfs_timer: ignoring error 64
	Jul 27 00:11:16 proven last message repeated 597 times

(that's just a small sample showing the different error numbers and one
of the most extensive repeats)

I don't suppose I have to go into the horrid details of just how hard it
is to use the console while this kind of nonsense is going on!

(obviously I had to be logged in on the console in order to effect the
addressing and interface option changes since you can't very well do
that over the network while it's down and since this machine has only a
single serial console and that was the only non-network login prompt
available at the time, with the other serial port being used for the UPS)

I thought there was a PR some time ago that was resolved by simply
removing some of these error printfs from the kernel.  Am I mistaken?
If I am then I humbly submit that far too few "error" messages were
removed!


One of these was more lengthy and harder to get out of as a result
because I accidentally typed "df" in the process and that of course got
very very very stuck.  I finally managed to get a DDB to stick (normally
because of weird interaction with the spewing error message a break was
either ignored or something would cause DDB to effectively see a <CR>
and go back to running).  Then I was able to kill not the frozen 'df',
but rather the parent shell (after which I got a login prompt again and
was, slowly through all the ongoing spewing noise, to login again).

Why oh why can't the likes of 'df' be at least put into the background
when the NFS server is stuck?  Why must almost all TTY interrupts be
completely ignored?  I'd prefer if SIGQUIT and SIGHUP at worked too!  (I
think I agree SIGINT shouldn't have any effect unless the mount was done
with the '-i' option, though I'm not even convinced about that --
according to strict reading of the manual only SIGTERM should be blocked.)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>