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.
freelist. Should now be thread-friendly, in part.
Note: More work is needed in uipc_syscalls.c, but it will have to wait until
the socket locking issues are at least 80% implemented and committed.
CDs.
With audio CDs, you can't just do a READ(10) call on most drives without
first setting the blocksize with a mode select command. The disklabel code
does a read of the first sector of the media to find a label if it exists.
This caused drives to return an error when an audio CD was in the drive,
due to the problem described above.
The solution is to read the table of contents on the CD, and only attempt
to read the disklabel if the first track is a data track.
This works on all the various CD and DVD media I have tried, but further
testing (especially with Video CDs and other mode 2 media) will be
needed to determine if this is a universal solution.
When this feature is enabled, mke2fs doesn't necessarily allocate a
super block and its associated descriptor blocks for every group.
The (non-)allocations are reflected in the block bitmap. Since the
filesystem code doesn't write to these blocks except for the first
superblock, all it has to do to support them is to not count them in
ext2_statfs() and not attempt to check them at mount time in
ext2_check_blocks_bitmap() (the check has never been enabled in
FreeBSD anyway).
a per program basis.
This has now been added in the following way:
* Harness the make header file that's specified with the -h argument:
- Allow the user to define $(OPTS) to specify make arguments that should
be added to every program target.
- Allow the user to define $(prog_OPTS) to specify make arguments that
should just be added to the build of 'prog'.
* Make sure that $(OPTS) and $(prog_OPTS) are defined when looking through
each program's make file to determine which object files to crunch.
* When building the crunchgen makefile add $(OPTS) and $(prog_OPTS)
to the depend and build rules for $(prog_OBJS).
o cvs 1.11
o /dev/random
o sendmail
o password default change
Please look at these entries and let me know if I've forgotten anything,
or if my understanding doesn't match reality.
