mirror of
https://github.com/freebsd/freebsd-src.git
synced 2024-11-29 06:42:45 +00:00
163 lines
5.8 KiB
Plaintext
163 lines
5.8 KiB
Plaintext
# -*- text -*-
|
|
|
|
LIST OF KNOWN BUGS IN AM-UTILS OR OPERATING SYSTEMS
|
|
|
|
|
|
(1) mips-sgi-irix*
|
|
|
|
[1A] known to have flaky NFS V.3 and TCP. Amd tends to hang or spin
|
|
infinitely after a few hours or days of use. Users must install recommended
|
|
patches from vendor. Patches help, but not all the time. Otherwise avoid
|
|
using NFS V.3 and TCP on these systems, by setting
|
|
|
|
/defaults opts:=vers=2,proto=udp
|
|
|
|
[1B] yp_all() leaks a file descriptor. Eventually amd runs out of file
|
|
descriptors and hangs. Am-utils circumvents this by using its own version
|
|
of yp_all which uses udp and iterates over NIS maps. The latter isn't as
|
|
reliable as yp_all() which uses TCP, but it is better than hanging.
|
|
|
|
(I have some reports that older version of hpux-9, with older libc, also
|
|
leak file descriptors.)
|
|
|
|
|
|
(2) alpha-unknown-linux-gnu (RedHat Linux 4.2)
|
|
|
|
hasmntopt(mnt, opt) can goes into an infinite loop if opt is any substring
|
|
of mnt->mnt_opts. Redhat 5.0 does not have this libc bug. Here is an
|
|
example program:
|
|
|
|
#include <stdio.h>
|
|
#include <mntent.h>
|
|
main()
|
|
{
|
|
struct mntent mnt;
|
|
char *cp;
|
|
mnt.mnt_opts = "intr,rw,port=1023,timeo=8,foo=br,retrans=110,indirect,map=/usr/local/AMD/etc/amd.proj,boo";
|
|
cp = hasmntopt(&mnt, "ro");
|
|
printf("cp = %s\n", cp);
|
|
exit(0);
|
|
}
|
|
|
|
It is possible that sufficiently newer version of libc for RH4.2 fix this
|
|
problem.
|
|
|
|
|
|
(3) mips-dec-ultrix4.3
|
|
|
|
Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> reports
|
|
|
|
[3A] One needs the Kernel Config Files (UDTBIN430) subset installed to
|
|
compile am-utils, otherwise essential header files (net/if.h, net/route.h,
|
|
rpcsvc/mount.h, rpcsvc/yp_prot.h, rpcsvc/ypclnt.h, sys/proc.h) are
|
|
missing.
|
|
|
|
[3B] It's probably impossible to build am-utils with DEC C on Ultrix V4.3.
|
|
This compiler is pseudo-ANSI only. Maybe the new ANSI C compiler in V4.3A
|
|
and beyond will do. I successfully used gcc 2.8.1.
|
|
|
|
[3C] You need to build against a recent libhesiod (I used 3.0.2) and
|
|
libresolv/lib44bsd (I used BIND 4.9.5-P1). The resolver routines in
|
|
libc seem to cause random memory corruption. It is necessary to specify
|
|
LIBS=-l44bsd. lib44bsd is a helper library of libresolv used to supply
|
|
functions like strdup which are missing on the host system. This isn't
|
|
currently autoconfiscated.
|
|
|
|
[3D] You need to configure with CONFIG_SHELL=/bin/sh5 /bin/sh5 buildall;
|
|
/bin/sh cannot handle the shell functions used in buildall and is both
|
|
buggy and slow.
|
|
|
|
[3E] At least the gcc 2.7.0 fixincludes-mangled <sys/utsname.h> needs a
|
|
forward declaration of struct utsname to avoid lots of gcc warnings:
|
|
|
|
RCS file: RCS/utsname.h,v
|
|
retrieving revision 1.1
|
|
diff -u -r1.1 utsname.h
|
|
--- utsname.h 1995/06/19 13:07:01 1.1
|
|
+++ utsname.h 1998/01/27 12:34:26
|
|
@@ -59,6 +59,7 @@
|
|
#ifdef KERNEL
|
|
#include "../h/limits.h"
|
|
#else /* user mode */
|
|
+struct utsname;
|
|
extern int uname _PARAMS((struct utsname *));
|
|
#endif
|
|
#define __SYS_NMLN 32
|
|
|
|
|
|
(4) powerpc-ibm-aix4.2.1.0
|
|
|
|
[4A] "Randall S. Winchester" <rsw@Glue.umd.edu> reports that for amd to
|
|
start, you need to kill and restart rpc.mountd and possibly also make sure
|
|
that nfsd is running. Normally these are not required.
|
|
|
|
[4B] "Stefan Vogel" <vogel@physik.unizh.ch> reports that if your amq
|
|
executable dump core unexpectedly, then it may be a bug in gcc 2.7.x.
|
|
Upgrade to gcc 2.8.x or use IBM's xlC compiler.
|
|
|
|
[C] Do not link amd with libnsl. It is buggy and causes amd to core dump
|
|
in strlen inside strdup inside svc_register().
|
|
|
|
|
|
(5) *-linux-gnu (RedHat Linux 5.1)
|
|
|
|
There's a UDP file descriptor leak in libnsl in RedHat Linux 5.1. This
|
|
library part of glibc2. Am-utils currently declares redhat 5.1 systems as
|
|
having a "broken yp_all" and using an internal, slower, leak-free version.
|
|
The leak is known to the glibc maintainers and a fix from them is due soon,
|
|
but it is not yet in the glibc-2.0.7-19 RPM.
|
|
|
|
|
|
(6) rs6000-ibm-aix4.1.x
|
|
|
|
A bug in libc results in an amq binary that doesn't work; amq -v dumps core
|
|
in xdr_string. There is no known fix (source code or vendor patch) at this
|
|
time. (Please let amd-dev know if you know of a fix.)
|
|
|
|
|
|
(7) *-aix4.3.2.0
|
|
|
|
The plock() function will pre-reserve all of the memory up to the maximum
|
|
listed in the ulimit. If the ulimit is infinite, plock() will try to take
|
|
all of the system's memory, and fail with ENOMEM (Not Enough Space).
|
|
Normally ulimit may be set to a few gigs of max memory usage, but even that
|
|
is too much; Amd doesn't need more than a few megs of resident memory size
|
|
(depending on the particular usage, number of maps, etc.) Solution: lower
|
|
your ulimit before starting amd. This can be done inside the ctl-amd
|
|
script, but be careful not to limit it too low. Alternatively, don't use
|
|
plock on aix-4.3: set it to plock=no in amd.conf (which is the default if
|
|
you do nothing).
|
|
|
|
|
|
(8) *-linux-gnu (systems using glibc 2.1, such as RedHat-6.1)
|
|
|
|
There's a UDP file descriptor leak in the nis routines in glibc, especially
|
|
those that do yp_bind. Until this is bug fixed, do not set nis_domain in
|
|
amd.conf, but let the system pick up the default domain name as set by your
|
|
system. That would avoid using the buggy yp_bind routines in libc.
|
|
|
|
|
|
(9) *-linux-gnu (SuSE systems using unfsd)
|
|
|
|
The user-level nfsd (2.2beta44) on SuSE Linux systems (and possibly others)
|
|
dies with a SEGV when amd tries to contact it for access to a volume that
|
|
does not exist, or one for which there is no permission to mount.
|
|
|
|
|
|
(10) *-*-hpux11
|
|
|
|
If you're using NFSv3, you must install HP patches PHNE_20344 and
|
|
PHNE_20371. If you don't, and you try to use amd with NFSv3 over TCP, your
|
|
kernel will panic.
|
|
|
|
(11) *-linux* (any system using a 2.2.18+ kernel)
|
|
|
|
The Linux kernels don't support Amd's direct mounts very well, leading to
|
|
erratic behavior: shares that don't get remounted after the first timeout,
|
|
inability to restart Amd because its mount points cannot be unmounted,
|
|
etc. There are some kernel patches on the am-utils Web site, which solve
|
|
these problems.
|
|
|
|
|
|
Erez.
|