Expanded stdin/stdout definitions.
Ordered the SEE ALSO references.
Moved some chat from the BUGS section to freebsd-chat@.
Removed ``cvs log'' material from the HISTORY section.
packets coming out of a GIF tunnel are re-processed by ipfw, et. al.
By default they are not reprocessed. With the option they are.
This reverts 1.214. Prior to that change packets were not re-processed.
After they were which caused problems because packets do not have
distinguishing characteristics (like a special network if) that allows
them to be filtered specially.
This is really a stopgap measure designed for immediate MFC so that
4.8 has consistent handling to what was in 4.7.
PR: 48159
Reviewed by: Guido van Rooij <guido@gvr.org>
MFC after: 1 day
* use correct error detection of realloc failure
* strtol negative return check
* use strtol to validate string instead of rolling our own
validation code
* terminate the command sequence correctly
o Make DXS3 the primary playback channel. It may be the only
universally supported channel with the assorted revisions of this
chipset.
o Add sysctl and handler for enabling s/pdif output from DXS3.
as opposed to one after the other. This is faster in both -CURRENT
and -STABLE. Additionally, there is less code duplication for
error-checking.
One thing to note is that this code seems to return(1) when no buffers
are available; perhaps ENOBUFS should be the correct return value?
Partially submitted & tested by: Hiten Pandya <hiten@unixdaemons.com>
MFC after: 1 week
and enable it by default, with a limit of 16.
At the same time, tweak maxfragpackets downward so that in the worst
possible case, IP reassembly can use only 1/2 of all mbuf clusters.
MFC after: 3 days
Reviewed by: hsu
Liked by: bmah
a snapshot. As part of taking a snapshot of a filesystem, the kernel
builds up a list of the filesystem metadata (such as the cylinder
group bitmaps) that are contained in the snapshot. When doing a
copy-on-write check, the list is first consulted. If the block being
written is found on the list, then the full snapshot lookup can be
avoided. Besides providing an important performance speedup this
check also avoids a potential deadlock between the code creating
the snapshot and the bufdaemon trying to cleanup snapshot related
buffers. This fix creates a temporary list containing the key
metadata blocks that can cause the deadlock. This temporary list
is used between the time that the snapshot is first enabled and the
time that the fully complete list is built.
Reported by: Attila Nagy <bra@fsn.hu>
Sponsored by: DARPA & NAI Labs.
is being taken from panicing with either "freeing free block" or
"freeing free inode". The problem arises when the snapshot code
is scanning the filesystem looking for inodes with a reference
count of zero (e.g., unlinked but still open) so that it can
expunge them from its view. If it encounters a reclaimed vnode
and has to restart its scan, then it will panic if it encounters
and tries to free an inode that it has already processed. The fix
is to check each candidate inode to see if it has already been
processed before trying to delete it from the snapshot image.
Sponsored by: DARPA & NAI Labs.
that they convert to 64-bit values before shifting rather than
afterwards. Once fixed, they can be used rather than inline expanded.
Sponsored by: DARPA & NAI Labs.
Retire the "d_dump_t" and use the "dumper_t" type instead.
Dumper_t takes a void * as first arg which is more general than the
dev_t taken by d_dump_t. (Remember: we could have net-dumpers if
somebody wrote us one!)
Define the convention for GEOM controlled disk devices to be that the
first argument to the dumper function is the struct disk pointer.
Change device drivers accordingly.
If we have no UFS_ACL kernel, users who already uses UFS1/2 attributes
get confused since no access control is performed for an update install.
Still, pc98 and alpha doesn't have UFS_ACL since I don't know about them.
Nyan-san, if kern.flp on tatsu has enough spaces (4k or more spaces),
please back UFS_ACL for pc98 also.
Data collected from: 5.0-CURRENT-20030221-JPSNAP on snapshots.jp.FreeBSD.org
