TLU event handler).
This used to be done as a side effect of SIOCAIFADDR'ing the interface,
but now that duplicate SIOCAIFADDRs are optimised out, we can't depend
on that behaviour.
KASSERT when vp->v_usecount is zero or negative. In this case, the
"v*: negative ref cnt" panic that follows is much more appropriate.
Reviewed by: mckusick
fail due to witness exhausting its internal resources and shutting down.
Reported by: Szilveszter Adam <sziszi@petra.hos.u-szeged.hu>
Tested by: David Wolfskill <david@catwhisker.org>
much more often that expected and negatively impact performance when
running at 100mbps. I need to figure out if there's a better way to
handle this, but for now this shouldn't hurt anything.
and DP83821 gigabit ethernet MAC chips and the NatSemi DP83861 10/100/1000
copper PHY. There are a whole bunch of very low cost cards available with
this chipset selling for $150USD or less. This includes the SMC9462TX,
D-Link DGE-500T, Asante GigaNIX 1000TA and 1000TPC, and a couple cards
from Addtron.
This chip supports TCP/IP checksum offload, VLAN tagging/insertion.
2048-bit multicast filter, jumbograms and has 8K TX and 32K RX FIFOs.
I have not done serious performance testing with this driver. I know
it works, and I want it under CVS control so I can keep tabs on it.
Note that there's no serious mutex stuff in here yet either: I need
to talk more with jhb to figure out the right way to do this. That
said, I don't think there will be any problems.
This driver should also work on the alpha. It's not turned on in
GENERIC.
fsck checking. Applying these changes (typically via mergemaster)
will cause your system to start running background checks on all
your soft update enabled filesystems (provided that you have
a kernel with the required functionality, e.g., one built since
the end of April). Please report any and all problems to
mckusick@mckusick.com (not mckusick@freebsd.org which I read
infrequently). See the comment above the fsck command in /etc/rc
for instructions on how to disable background checking should it
cause you too much trouble.
Several FAQs:
1) Can I reboot before the background checks are done?
Ans) Yes, when the system restarts the checks will pick up
where they left off.
2) Can a crash during checking corrupt my filesystem?
Ans) No, recovered resources are returned to the system using soft
updates which ensure that the freeing is done in a safe order.
3) How will I know if any background checks are being done?
Ans) Filesystems that are to be checked in background will be listed
as `DEFER FOR BACKGROUND CHECKING' at the usual fsck check time
during system startup.
4) What happens to the output of the background checks?
Ans) It is sent to syslog `daemon' facility log level `notice'.
5) When will this feature be available in the 4.X kernel?
Ans) Never. It is much too radical and extensive a change to be
MFC'ed. Besides, it needs many months of experience and
tuning before it is ready for widespread use.
6) What happens if a background fsck fails (i.e., fsck finds
errors that would normally require a manual fsck)?
Ans) The filesystem will be marked as needing a manual fsck.
At the next system reboot, the check will be done in
foreground and the usual actions taken (usually a failure
to go multi-user until fsck has been run by hand on the
affected filesystem).
freed by softupdates, ifconfig(8) accepts CIDR notation, rc(8) clean-out
of /var/run and /var/spool/lock, c89(1) is now a binary, pax(1)
enhancements and cpio(1)/tar(1) compatability, Ukranian language console
support.
Other: Update/make (more) consistent the list of WaveLAN devices
supported.
MFCs noted: ln(1) -h/-n, find(1) timestamp flags.
a LinkSys card here in the office where reading the station address
fails the first time, but works find afterwards. Without this, the
probe fails. I don't think this will negatively impact any existing
cards, but I want to confirm this before MFC'ing.
safe from preemption and concurrent access to the LDT.
- Move the prototype for i386_extend_pcb() to <machine/pcb_ext.h>.
Reviewed by: silence on -hackers
