part of the PCI block for the 2300- not software convention usage
of the mailbox registers- so we macrosize in/out pointer usage.
Only report that a LIP destroyed commands if it actually destroyed
commands. Get the chan/tgt/lun order correct. Fix a longstanding
stupid bug that caused us to try and issue a command with a tag on
Channel B because we were checking the tagged capability for the
target against Channel A.
A firmware crash is now vectored out to platform specific code
as an async event.
Some minor formatting tweaks.
reading variable sized blocks of data every second. This should be
more efficient.
Suggested & tested by: se
* Add a syntax for excluding CD-ROM drives etc.
Suggested by: des, se, many others...
Manual page updates coming soon.
(this commit is just the first stage). Also add various GIANT_ macros to
formalize the removal of Giant, making it easy to test in a more piecemeal
fashion. These macros will allow us to test fine-grained locks to a degree
before removing Giant, and also after, and to remove Giant in a piecemeal
fashion via sysctl's on those subsystems which the authors believe can
operate without Giant.
- Move the lance_probe function to if_lnc.c.
- Support C-NET(98)S again.
Submitted by: chi@bd.mbn.or.jp (Chiharu Shibata) and nyan
No response from: Paul Richards
best router again. In particular, when the neighbor entry is newly
created, it might affect the selection policy.
Obtained from: KAME
MFC after: 1 week
underlying CAM device. This needs to be checked not only in
the open routine, but the device->fd has to be initialized
as well.
PR: 28688
Submitted (partially) by: T. William Wells <bill@twwells.com>
MFC after: 2 weeks
envoked -- don't use them (as return values from open()), then
(say) close(STDIN_FILENO) when daemonising.
This is done by grabbing 3 descriptors to /dev/null at startup and
releasing them after we've daemonised.
MFC after: 1 week
These take an additional mutex argument, which is dropped before any
processes are made runnable. This can avoid contention on the mutex
if the processes would immediately acquire it, and is done in such a
way that wakeups will not be lost.
Reviewed by: jhb
This is necessary because MPPE will combine the protocol id with the
payload received on the tun interface, encrypt it, then prepend its
own protocol id, effectively increasing the payload by two bytes.
