(I skipped those in contrib/, gnu/ and crypto/)
While I was at it, fixed a lot more found by ispell that I
could identify with certainty to be errors. All of these
were in comments or text, not in actual code.
Suggested by: bde
MFC after: 3 days
- Make getvfsbyname() take a struct xvfsconf *.
- Convert several consumers of getvfsbyname() to use struct xvfsconf.
- Correct the getvfsbyname.3 manpage.
- Create a new vfs.conflist sysctl to dump all the struct xvfsconf in the
kernel, and rewrite getvfsbyname() to use this instead of the weird
existing API.
- Convert some {set,get,end}vfsent() consumers to use the new vfs.conflist
sysctl.
- Convert a vfsload() call in nfsiod.c to kldload() and remove the useless
vfsisloadable() and endvfsent() calls.
- Add a warning printf() in vfs_sysctl() to tell people they are using
an old userland.
After these changes, it's possible to modify struct vfsconf without
breaking the binary compatibility. Please note that these changes don't
break this compatibility either.
When bp will have updated mount_smbfs(8) with the patch I sent him, there
will be no more consumers of the {set,get,end}vfsent(), vfsisloadable()
and vfsload() API, and I will promptly delete it.
sysctl_sysctl_next() to skip this sysctl. The sysctl is
still available, but doesn't appear in a "sysctl -a".
This is especially useful when you want to deprecate a sysctl,
and add a warning into it to warn users that they are using
an old interface. Without this flag, the warning would get
echoed when running "sysctl -a" (which happens at boot).
code to do it when the bios doesn't do it for us, flag it. Then, when
we dealloc, do an equal kludge to get rid of the address. This should
address the can't get IRQ and panic bug in a more graceful way.
# really should write a dealloc routine and just call it instead, since
# this might not fix things in the kldunload case.
The bugfix (ipfw2.c) makes the handling of port numbers with
a dash in the name, e.g. ftp-data, consistent with old ipfw:
use \\ before the - to consider it as part of the name and not
a range separator.
The new feature (all this description will go in the manpage):
each rule now belongs to one of 32 different sets, which can
be optionally specified in the following form:
ipfw add 100 set 23 allow ip from any to any
If "set N" is not specified, the rule belongs to set 0.
Individual sets can be disabled, enabled, and deleted with the commands:
ipfw disable set N
ipfw enable set N
ipfw delete set N
Enabling/disabling of a set is atomic. Rules belonging to a disabled
set are skipped during packet matching, and they are not listed
unless you use the '-S' flag in the show/list commands.
Note that dynamic rules, once created, are always active until
they expire or their parent rule is deleted.
Set 31 is reserved for the default rule and cannot be disabled.
All sets are enabled by default. The enable/disable status of the sets
can be shown with the command
ipfw show sets
Hopefully, this feature will make life easier to those who want to
have atomic ruleset addition/deletion/tests. Examples:
To add a set of rules atomically:
ipfw disable set 18
ipfw add ... set 18 ... # repeat as needed
ipfw enable set 18
To delete a set of rules atomically
ipfw disable set 18
ipfw delete set 18
ipfw enable set 18
To test a ruleset and disable it and regain control if something
goes wrong:
ipfw disable set 18
ipfw add ... set 18 ... # repeat as needed
ipfw enable set 18 ; echo "done "; sleep 30 && ipfw disable set 18
here if everything goes well, you press control-C before
the "sleep" terminates, and your ruleset will be left
active. Otherwise, e.g. if you cannot access your box,
the ruleset will be disabled after the sleep terminates.
I think there is only one more thing that one might want, namely
a command to assign all rules in set X to set Y, so one can
test a ruleset using the above mechanisms, and once it is
considered acceptable, make it part of an existing ruleset.
The CAM<>ATAPI layer was submitted by "Thomas Quinot <thomas@cuivre.fr.eu.org>"
changes form the version on the net by me (formatting, ability to be used
alone without the ATAPI native device driver, proper speed reporting...)
See /sys/conf/NOTES for usage.
Submitted by: Thomas Quinot <thomas@cuivre.fr.eu.org>
#define EDOFUS 88 /* Programming error */
This can be used to signal error situations which indicate that the
program logic or assumptions is deficient.
appologize to those of you who may have been seeing crashes in
code that uses sendfile(2) or other types of external buffers
with mbufs.
Pointed out by, and provided trace:
Niels Chr. Bank-Pedersen <ncbp at bank-pedersen.dk>
VOP wrapper is called from within file systems so can result in odd
loopback effects when MAC enforcement is use with the active (as
opposed to saved) credential. These checks will be moved elsewhere.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, NAI Labs
PR40430 by "Peter Haight <peterh@sapros.com>" that has semilar patches
included and which I merged with my own work.
HW sponsored by: FreeBSD Foundation & FreeBSD Mall Inc
Enjoy!
I'm not sure what happenned to the original setting of the P_CONTINUED
flag. it appears to have been lost in the paper shuffling...
Submitted by: David Xu <bsddiy@yahoo.com>
This is pretty much fixes any issue I can find:
- Watchdog timeouts were due to starting the TX DMA engine
before we had a packet ready for it. So the first packet
sent never got out only if we sent more then one packet
at a time did the others make it out and not blow up.
Of course reseting the chip then caused us not to transmit
the first packet again ie. catch-22. This required logic changes.
- Combine interrupts on TX packets being queued up.
- Don't keep running around the RX ring since we might get
out of sync so only go around once per receive
- Let the RX engine recover via the poll interface which is
similar to the TX interface. This way the chip wakes
up with no effort when we read enough packets.
- Do better hand-shaking on RX & TX packets so they don't
start of to soon.
- Force a duplex setting when the link comes up after
an ste_init or it will default to half-duplex and be
really slow. This only happens on subsequent ste_init.
The first one worked.
- Don't call stat_update for every overflow. We only monitor
the collisions so the tick interval is good enough for that.
Just read in the collision stats to minimize bus reads.
- Don't read the miibus every tick since it uses delays and
delays are not good for performance.
- Tie link events directly to the miibus code so the port
gets set correctly if someone changes the port settings.
- Reduce the extreme number of {R,T}FD's. They would consume
130K of kernel memory for each NIC.
- Set the TX_THRESH to wait for the DMA engine to complete
before running the TX FIFO. This hurts peak TX performance
but under bi-directional load the DMA engine can't keep up
with the FIFO. Testing shows that we end up in the case
anyways (a la dc(4) issues but worse since the RX engine hogs
everything).
- When stopping the card do a reset since the reset verifies the
card has stopped. Otherwise on heavy RX load the RX DMA engine
is still stuffing packets into memory. If that happens after
we free the DMA area memory bits get scribled in memory and
bad things happen.
This card still has seemingly unfixable issues under heavy RX load in
which the card takes over the PCI bus.
Sponsored by: Vernier Networks
MFC after: 1 week
