overwriting $PATH, and find mknod $PATH instead of hardcoding /sbin so
that the copy of MAKEDEV on the fixit floppy is usable, since mknod and
expr live in /mnt2/stand when the fixit floppy is running.
Get rid of the sed invokation in release/Makefile that attempts to
delete the PATH setting stuff from MAKEDEV on the fixit floppy. This
hasn't worked since a long ago change to MAKEDEV caused the sed
expression to no longer match.
PR: misc/21241
The offset field in struct dirent was set to the offset of
the next dirent in rev 1.36. The offset was calculated from
the current offset and the record length. This offset does
not necessarily match the real offset when we are using
cookies. Therefore, also use the cookies to set the offset
field in struct dirent if we're using cookies to iterate
through the dirents.
circuit generates too much jitter to be used directly as xmit clock.
Don't miscount pending bytes in weird error conditions.
Drop the rest of a packet if we run out of tx-md's.
Trig the xmit-frame signal on rising edge, this fixed the one-bit-too-late
position of the HDLC frames in E1 mode.
wakeup all of the sleeping threads when we free only one buffer. This
avoids us having to needlessly try again (and fail, and go back to
sleep) for all the threads sleeping. We will now only wakeup the
thread we know will succeed.
Reviewed by: green
beta ISC DHCP version 3 offering.
In message http://www.isc.org/ml-archives/dhcp-client/2000/10/msg00001.html
author Ted Lemon stated "This will not be fixed in any 2.0 release - 2.0
is no longer being maintained." to a reported problem about an
interoperability problem against Microsoft servers. FreeBSD went with the
ISC client vs. the WIDE client because others convinced me it was better
supported. Sigh. I wonder if version 3 will get the same treatment after
its release...
Since FreeBSD generally uses only released contrib products and the ISC
version 3 offering is still in beta, our backs are up against the wall.
The common/options.c rev 1.65 work around for erroneous Microsoft DHCP
servers has been back ported to the version 2.0pl5 client. Since this
comes from a change in the vendor's own code (and would no doubt also be
committed to the version 2 client if the author were still supporting it),
we will consider this a vendor release and import this as such.
PR: 21658
Submitted by: Motomichi Matsuzaki <mzaki@e-mail.ne.jp>
only be checked if the system is currently performing New Reno style
fast recovery. However, this value was being checked regardless of the
NR state, with the end result being that the congestion window was never
opened.
Change the logic to check t_dupack instead; the only code path that
allows it to be nonzero at this point is NewReno, so if it is nonzero,
we are in fast recovery mode and should not touch the congestion window.
Tested by: phk
pollution in <sys/mutex.h>. This was half fixed in rev.1.3 of
midwayreg.h. The pollution exposed the bug that this driver was using
toy versions of the bus space macros under FreeBSD. Disabling the
toy versions made this driver compile but dependent on the pollution.
There was still a toy version of bus_space_read_1() in unreachable code.
namespace pollution in <sys/mutex.h>. This was half fixed in rev.1.3
of midwayreg.h. The pollution exposed the bug that this driver was
using toy versions of the bus space macros under FreeBSD. Disabling
the toy versions made this driver compile and maybe support PIO space,
but dependent on the pollution.
ufs_vnops.c:
1) i_ino was confused with i_number, so the inode number passed to
VFS_VGET() was usually wrong (usually 0U).
2) ip was dereferenced after vgone() freed it, so the inode number
passed to VFS_VGET() was sometimes not even wrong.
Bug (1) was usually fatal in ext2_mknod(), since ext2fs doesn't have
space for inode 0 on the disk; ino_to_fsba() subtracts 1 from the
inode number, so inode number 0U gives a way out of bounds array
index. Bug(1) was usually harmless in ufs_mknod(); ino_to_fsba()
doesn't subtract 1, and VFS_VGET() reads suitable garbage (all 0's?)
from the disk for the invalid inode number 0U; ufs_mknod() returns
a wrong vnode, but most callers just vput() it; the correct vnode is
eventually obtained by an implicit VFS_VGET() just like it used to be.
Bug (2) usually doesn't happen.
