as a RealTek 8139
if_rlreg.h: use bus_space_read_X() in CSR_READ_X() macros instead of
directly calling inb()/outb() etc...
rl.4 + RELNOTES.TXT: mention that SMC EtherEZ PCI 1211-TX is supported
by the RealTek driver
apparently possible) event that the transmit start routine is
called with and empty if_snd queue, bail out instead of dereferencing
unilitialized transmit list pointers and panicking.
suggested compilation cleanups from Eklund. Wire down a hard loop id if we are
not on a platform that has the ability to get to a PCI BIOS (it still will
float to the ID it gets after a LIP but at least we can try). Clarify that the
expanded lun is based upon SCCLUN defines (in f/w).
for possible buffer overflow problems. Replaced most sprintf()'s
with snprintf(); for others cases, added terminating NUL bytes where
appropriate, replaced constants like "16" with sizeof(), etc.
These changes include several bug fixes, but most changes are for
maintainability's sake. Any instance where it wasn't "immediately
obvious" that a buffer overflow could not occur was made safer.
Reviewed by: Bruce Evans <bde@zeta.org.au>
Reviewed by: Matthew Dillon <dillon@apollo.backplane.com>
Reviewed by: Mike Spengler <mks@networkcs.com>
during a trek through RCS. The Macronix 98713 and 98713A both have the
same PCI device ID but different revision numbers, and we need to be
able to tell one from the other. The 98715 and 98715A chips have the
same device ID as the 98725 chip but different revision numbers, however
we lump them into the same category except when identifying them during
the PCI probe output.
The main reason we need tell the chips apart is that the Macronix app
notes say you have to write a special magic number into one of the
registers in order to put the chip in normal operating mode. The 98713
requires one magic value, while all the others require a different one.
PCI fast ethernet adapters, plus man pages.
if_pn.c: Netgear FA310TX model D1, LinkSys LNE100TX, Matrox FastNIC 10/100,
various other PNIC devices
if_mx.c: NDC Communications SOHOware SFA100 (Macronix 98713A), various
other boards based on the Macronix 98713, 98713A, 98715, 98715A
and 98725 chips
if_vr.c: D-Link DFE530-TX, other boards based on the VIA Rhine and
Rhine II chips (note: the D-Link and certain other cards
that actually use a Rhine II chip still return the PCI
device ID of the Rhine I. I don't know why, and it doesn't
really matter since the driver treats both chips the same
anyway.)
if_wb.c: Trendware TE100-PCIE and various other cards based on the
Winbond W89C840F chip (the Trendware card is identical to
the sample boards Winbond sent me, so who knows how many
clones there are running around)
All drivers include support for ifmedia, BPF and hardware multicast
filtering.
Also updated GENERIC, LINT, RELNOTES.TXT, userconfig and
sysinstall device list.
I also have a driver for the ASIX AX88140A in the works.
alpha, operations involving non-finite numbers or denormalised numbers
or operations which should generate such numbers will cause an arithmetic
exception. For programs which follow some strict code generation rules,
the kernel trap handler can then 'complete' the operation by emulating
the faulting instruction.
To use software completion, a program must be compiled with the arguments
'-mtrap-precision=i' and '-mfp-trap-mode=su' or '-mfp-trap-mode=sui'.
Programs compiled in this way can use non-finite and denormalised numbers
at the expense of slightly less efficient code generation of floating
point instructions. Programs not compiled with these options will receive
a SIGFPE signal when non-finite or denormalised numbers are used or
generated.
Reviewed by: John Polstra <jdp@polstra.com>
option not defined the sysctl int value is set to -1 and read-only.
#ifdef KERNEL's added appropriately to wall off visibility of kernel
routines from user code.
Add ICMP_BANDLIM option and 'net.inet.icmp.icmplim' sysctl. If option
is specified in kernel config, icmplim defaults to 100 pps. Setting it
to 0 will disable the feature. This feature limits ICMP error responses
for packets sent to bad tcp or udp ports, which does a lot to help the
machine handle network D.O.S. attacks.
The kernel will report packet rates that exceed the limit at a rate of
one kernel printf per second. There is one issue in regards to the
'tail end' of an attack... the kernel will not output the last report
until some unrelated and valid icmp error packet is return at some
point after the attack is over. This is a minor reporting issue only.
