of the /etc/radius.conf file. But the code contains hacks for
backward compatibility, so old files will continue to work.
I updated the man pages and made a couple of minor changes, but
everything else was submitted by Oleg.
PR: misc/14284
Submitted by: Oleg Semyonov <os@altavista.net>
should close all outstanding PRs on incorrect inet_aton behavior, and
since it has a decent parsing routine, doesn't allow some hysterically
working behavior.
PR: 13628
Submitted by: Adrian Chadd <adrian@FreeBSD.org>
camcontrol was setup to use the old scheme of going through the xpt(4)
device, which never worked properly (and has been disabled for a while).
camcontrol now sends BDRs through the pass(4) device, and XPT_RESET_DEV
CCBs are put on the device queue in the transport layer, as they should be.
Submitted by: luoqi
Reviewed by: ken
thank Jeroen and all who helped bring it about :)
Submitted by: Jeroen Ruigrok van der Werven <asmodai@wxs.nl>
Reviewed by: jdp, Gerald Hicks, the Doc Team
thank Jeroen and all who helped bring it about :)
Submitted by: Jeroen Ruigrok van der Werven <asmodai@wxs.nl>
Reviewed by: jdp, Gerald Hicks, the Doc Team
1. Get rid of the evilly bogus strdup(fstab) and free if (fstab == "")
as in umount.
2. Don't use /etc/fstab info if the mount instance does not exactly match
the fstab entry.
3. Reversed the mountpoint checking order in getmntpt().
4. Clarify the "not mounted" error message in mount -u. The previous
"unknown special file or file system" wasn't quite right.
5. Get rid of a 1-byte memory leak; this was reported by jhb.
Submitted by: Martin Blapp <mb@imp.ch>
If the ipl is lowered here, a machine can rapidly run out of stack
space when it is under heavy interrupt load. Without this fix,
my test machine would fall over within a few seconds when forwarding
14,000 packets/sec. With the patch, it has been up for over 24 hours
and has built the world at the same time.
submitted by: dfr@freebsd.org
the countdown register.
this should not be necessary but there are broken laptops that
do not restore the countdown register on resume.
when it happnes, it messes up the hardclock interval and system clock,
which leads to the infamous "calcru: negative time" problem.
Submitted by: kjc, iwasaki
Reviewed by: Steve O'Hara-Smith <steveo@eircom.net> and committers.
Obtained from: PAO3
