NFS_ROOT will produce kernel that cannot mount a UFS /.
Vfs type numbers must be distinct from VFS_GENERIC (and VFS_VFSCONF, but
that has the same value and should go away).
The problem happens because NFS is the first vfs (in sys/conf order) so it
gets type number 0 and conflicts harmfully with VFS_GENERIC which is also 0.
The conflict is apparently harmless in the usual case when another vfs
gets type number 0, because nfs is the only vfs that has sysctls.
Inital fix by: Dima <dima@tejblum.dnttm.rssi.ru>
Reason why it worked by: bde
memory mapped mode. There are some laptop docking stations with
built-in tlan chips where memory mapped mode doesn't work correctly.
Pointed out by: jmb
Allocate space for, and copy, NDOSPART slice entries from the
MBR, not just one. Add some extra debugging while we're at it.
elf_freebsd.c
Initialise the symbol table start/end pointers in case we don't
have them.
reported bug.
At using tcpdump for cs interface, tcpdump only dump packet which
src or dst MAC-address is cs interface. cs interface can't look up
packet between others.
Submitted by: MIHIRA "Sanpei" Yoshiro <sanpei@sanpei.org>
The problem is caused when a directory block is compacted. When this
occurs, softdep_change_directoryentry_offset() is called to relocate each
directory entry and adjust its matching diradd structure, if any, to match
the new location of the entry. The bug is that while
softdep_change_directoryentry_offset() correctly adjusts the offsets of
the diradd structures on the pd_diraddhd[] lists (which are not yet ready
to be committed to disk), it fails to adjust the offsets of the diradd
structures on the pd_pendinghd list (which are ready to be committed to
disk). This causes the dependency structures to be inconsistent with
the buf contents. Now, if the compaction has moved a directory entry to
the same offset as one of the diradd structures on the pd_pendinghd list
*and* a syscall is done that tries to remove this directory entry before
this directory block has been written to disk (which would empty
pd_pendinghd), a sanity check in newdirrem() will call panic() when it
notices that the inode number in the entry that it is to be removed doesn't
match the inode number in the diradd structure with that offset of that
entry.
Reviewed by: Kirk McKusick <mckusick@McKusick.COM>
Submitted by: Don Lewis <Don.Lewis@tsc.tdk.com>
