does-not-exist error when no client interface module is installed instead
of dereferencing NULL pointers. This eases implementation of platforms
that may or may not have Open Firmware.
using an updated flex(1) binary.
Also ignore the changing $FreeBSD$ ID lines when doing the diff.
This needs additional obfuscation, to not upset the svn precommit
hooks :/
Convert the tests to the perl prove format.
Remove obsolete TEST.README (results of an old TEST.sh for some old Unices)
and TEST.csh (old tests without correct values, far less complete than
TEST.sh).
MFC after: 1 week
It seems RTL8169/RTL8168/RTL810xE has a kind of interrupt
moderation mechanism but it is not documented at all. The magic
value dramatically reduced number of interrupts without noticeable
performance drops so apply it to all RTL8169/RTL8169 controllers.
Vendor's FreeBSD driver also applies it to RTL810xE controllers but
their Linux driver explicitly cleared the register, so do not
enable interrupt moderation for RTL810xE controllers.
While I'm here sort 8169 specific registers.
Obtained from: RealTek FreeBSD driver
o) Fix enumeration of PHY addresses on the MR-955.
o) Parse link state for the MR-730 using the Broadcom PHY support in the SDK.
It's not clear that this is entirely-correct, but it seems to work. Since
this board uses a BCM5482S, this may mean that we work correctly for copper
but not SFI, which is untested.
- Register APIC enumerators at SI_SUB_TUNABLES - 1 instead of SI_SUB_CPU - 1.
- Probe CPUs at SI_SUB_TUNABLES - 1. This allows i386 to set a truly
accurate mp_maxid value rather than always setting it to MAXCPU - 1.
included in a kernel config. These stubs had existed previously so that
acpi.ko could always include the MADT parsing code and still link with a
kernel that did not include 'device apic'.
local APIC if those LVT entries are valid. This quiets spurious illegal
register local APIC errors during boot on a CPU that doesn't support those
vectors.
MFC after: 1 week
There were a couple of attempts in the past to reduce it since it
took more than 1ms. Because mii_tick() periodically polls link
status, waiting more than 1ms for each GMII register access was
overkill. Unfortunately all previous attempts were failed with
various ways on different controllers.
This time, add additional 20us dealy at the end of GMII register
access which seems to requirement of all RealTek controllers to
issue next GMII register access request. This is the same way what
Linux does.
numbers. bge(4) supports too many models such that it's
unreasonable to list all these controllers in one line description
of name. While I'm here mention that BCM590x/BCM5779x is Fast
Ethernet controller.
bge(4) still lacks support for some controllers but supporting
these controllers should be easy now and adding new controllers
do not require touching .Nd any more.
Obtained from: OpenBSD
