Date: Fri, 31 Mar 2000 11:37:50 -0800 From: Fred Gilham <gilham@snapdragon.csl.sri.com> To: freebsd-stable@FreeBSD.ORG Subject: A few STABLE problems Message-ID: <200003311937.LAA25957@csla.csl.sri.com>
next in thread | raw e-mail | index | archive | help
I installed 4.0-STABLE --- works at least as well as 3.4 did (which is
VERY WELL). Great job.
There are a few persistent problems I thought I'd mention. By
persistent I mean on-going over many releases (one is from 2.2). I
have workarounds for all of them but I kind of hate carrying patches
around either in file form or in my PFS (protoplasmic file system).
They tend to get lost or forgotten.
1) AMD with dual-networked file servers
For some time the stock AMD hasn't worked with our dual homed file
servers. There appears to be an nfsv2 vs nfsv3 issue. At some
point there were some incompatible changes made to the map options
and I never got the explanation of how to change our maps to make
things work again.
Currently I have an old AMD that I've patched to use the nvsv2
compatibility mode. Perhaps some people will recognize this. It
causes AMD to print
found compatiblity option "nfsv2": set options vers=2, proto=udp for host sofia
to the syslog. However, I have to install this custom AMD every
time. This problem (of not working with dual-homed servers) has
been around (on and off) since 2.2. If there's a definitive answer
to this, I still haven't heard it. Perhaps I wasn't paying
attention?
2) Our site manages the group file with NIS. We manage the `wheel'
group. As a result, there's no `wheel' entry in the group file
until after NIS comes up. But in /etc/rc there's the following:
# Whack the pty perms back into shape.
#
chflags 0 /dev/tty[pqrsPQRS]*
chmod 666 /dev/tty[pqrsPQRS]*
chown root:wheel /dev/tty[pqrsPQRS]*
This won't work (i.e. it hangs) on my machine because it comes
before NIS is started. I have to move this after network_pass2.
I submitted a PR on this. Admittedly it's not a big problem, but
nothing was ever done about it, and the fix would take 30 seconds.
Perhaps there's a better way of dealing with this, but I don't know
what it is.
3) I use CMU Lisp. The version I use has a `threading' system that
requires the USER_LDT option in the kernel. There's also a patch
to the kernel that's required to get this thing to work---some time
in the 3.X series, someone made some change that caused things to
hang under certain circumstances. I have a small patch that I
apply to the kernel to un-wedge this. The patch has changed from
3.4 to 4.0 but it's still necessary.
In /sys/i386/i386/machdep.c, lines 604 and 605 are commented out.
These two lines are as follows:
regs->tf_fs = _udatasel;
load_gs(_udatasel);
Apparently smashing these registers is wrong. I don't know the
details. If anyone is interested, there's someone on the CMUCL
core group that knows about this.
I would appreciate it if I could know what to do about these problems
so I wouldn't have to carry patches around with me.
-Fred Gilham gilham@csl.sri.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003311937.LAA25957>