Teach the MAC policies which utilize mbuf labeling the new syncache
entry points. Properly initialize the mbuf label based on the label
we copy from the PCB. This fixes an LOR between the PCB and syncache
code.
Fix LOR between the syncache and inpcb locks when MAC is present in the
kernel. This LOR snuck in with some of the recent syncache changes. To
fix this, the inpcb handling was changed:
- Hang a MAC label off the syncache object
- When the syncache entry is initially created, we pickup the PCB lock
is held because we extract information from it while initializing the
syncache entry. While we do this, copy the MAC label associated with
the PCB and use it for the syncache entry.
- When the packet is transmitted, copy the label from the syncache entry
to the mbuf so it can be processed by security policies which analyze
mbuf labels.
This change required that the MAC framework be extended to support the
label copy operations from the PCB to the syncache entry, and then from
the syncache entry to the mbuf.
These functions really should be referencing the syncache structure instead
of the label. However, due to some of the complexities associated with
exposing this syncache structure we operate directly on it's label pointer.
This should be OK since we aren't making any access control decisions within
this code directly, we are merely allocating and copying label storage so
we can properly initialize mbuf labels for any packets the syncache code
might create.
This also has a nice side effect of caching. Prior to this change, the
PCB would be looked up/locked for each packet transmitted. Now the label
is cached at the time the syncache entry is initialized.
Pyun YongHyeon [Wed, 13 Dec 2006 02:30:11 +0000 (02:30 +0000)]
Add msk(4), a driver for Marvell/SysKonnect Yukon II Gigabit Ethernet
controller. Due to lack of documentation, this driver is based on the
code from sk(4) and Marvell's myk(4) driver for FreeBSD. I've also
adopted the OpenBSD interface name, msk(4) in order to reduce naming
differences between BSDs.
The msk(4) driver supports the following Gigabit Ethernet adapters.
o SysKonnect SK-9Sxx Gigabit Ethernet
o SysKonnect SK-9Exx Gigabit Ethernet
o Marvell Yukon 88E8021CU Gigabit Ethernet
o Marvell Yukon 88E8021 SX/LX Gigabit Ethernet
o Marvell Yukon 88E8022CU Gigabit Ethernet
o Marvell Yukon 88E8022 SX/LX Gigabit Ethernet
o Marvell Yukon 88E8061CU Gigabit Ethernet
o Marvell Yukon 88E8061 SX/LX Gigabit Ethernet
o Marvell Yukon 88E8062CU Gigabit Ethernet
o Marvell Yukon 88E8062 SX/LX Gigabit Ethernet
o Marvell Yukon 88E8035 Gigabit Ethernet
o Marvell Yukon 88E8036 Gigabit Ethernet
o Marvell Yukon 88E8038 Gigabit Ethernet
o Marvell Yukon 88E8050 Gigabit Ethernet
o Marvell Yukon 88E8052 Gigabit Ethernet
o Marvell Yukon 88E8053 Gigabit Ethernet
o Marvell Yukon 88E8055 Gigabit Ethernet
o Marvell Yukon 88E8056 Gigabit Ethernet
o D-Link 550SX Gigabit Ethernet
o D-Link 560T Gigabit Ethernet
Unlike OpenBSD/NetBSD msk(4), the msk(4) driver supports all hardware
features including TCP/UDP checksum offload for transmit, MSI, TCP
segmentation offload(TSO), hardware VLAN tag stripping/insertion,
and jumbo frames(up to 9022 bytes). The only unsupported hardware
feature except RLMT is Rx checksum offload which I don't know how to
make it work reliably.
Known Issues:
It seems msk(4) does not work on the second port of dual port NIC.
(The first port works without problems.)
Thanks to Marvell for releasing the BSD licensed myk(4) driver and
thanks to all users helped fixing bugs.
Tested by: bz, philip, bms,
YAMAMOTO Shigeru < shigeru AT iij DOT ad DOT jp >,
Dmitry Pryanishnikov < dmitry AT atlantis DOT dp DOT ua >,
Jia-Shiun Li < jiashiun AT gmail DOT com >,
David Duchscher < daved AT tamu DOT edu >,
Arno J. Klaassen < arno AT heho DOT snv DOT jussieu DOT fr>,
Nicolae Namolovan < adrenalinup AT gmail DOT com>,
Andre Guibert de Bruet < andy AT siliconlandmark DOT com >
current ML
Tested on: i386, amd64
John Baldwin [Tue, 12 Dec 2006 19:33:25 +0000 (19:33 +0000)]
- Add constants for HT PCI capability registers including the various
subtypes of HT capabilities.
- Add constants for the MSI mapping window HT PCI capability.
- On i386 and amd64, enable the MSI mapping window on any HT bridges we
encounter and report any non-standard mapping window addresses.
John Baldwin [Tue, 12 Dec 2006 19:27:01 +0000 (19:27 +0000)]
Give Host-PCI bridge drivers their own pcib_alloc_msi() and
pcib_alloc_msix() methods instead of using the method from the generic
PCI-PCI bridge driver as the PCI-PCI methods will be gaining some PCI-PCI
specific logic soon.
John Baldwin [Tue, 12 Dec 2006 19:20:19 +0000 (19:20 +0000)]
Add a function to return the MD interrupt source cookie associated with
an interrupt event. Use this in the x86 code to fixup the intrcnt names
when an interrupt handler is removed.
Bjoern A. Zeeb [Tue, 12 Dec 2006 17:44:46 +0000 (17:44 +0000)]
In ip6_sprintf no longer use and return one of eight static buffers
for printing/logging ipv6 addresses.
The caller now has to hand in a sufficiently large buffer as first
argument.
This is the "+ one more change" missed in the original commit.
Bjoern A. Zeeb [Tue, 12 Dec 2006 12:17:58 +0000 (12:17 +0000)]
MFp4: 92972, 98913 + one more change
In ip6_sprintf no longer use and return one of eight static buffers
for printing/logging ipv6 addresses.
The caller now has to hand in a sufficiently large buffer as first
argument.
Scott Long [Tue, 12 Dec 2006 05:11:12 +0000 (05:11 +0000)]
Fix support for certain 575x/578x chips. This consists of the following:
- Use the appropriate register writing method when reseting the chip
- Program the descriptor DMA engine correctly.
- More reliably detect certain chips and their features.
Also add some low-level debugging tools to help future work on this driver.
Submitted by: David Christenson (proof of concept changes)
Sponsored by: www.UIA.net
Kip Macy [Tue, 12 Dec 2006 03:50:06 +0000 (03:50 +0000)]
workaround kernel malloc's brittleness
- don't shuffle phys_avail following kernel to the beginning if the
range is less than what would remain in a 256MB page (248MB)
David E. O'Brien [Tue, 12 Dec 2006 03:20:36 +0000 (03:20 +0000)]
Add the '-n' option which is the opposite of '-N', "Do not list tags."
The '-n' option is needed when one has "log -N" in their ~/.cvsrc, but
wishes to see tags for a particular invocation.
David Xu [Tue, 12 Dec 2006 03:08:49 +0000 (03:08 +0000)]
Move checking for c_has_waiters into low level _thr_ucond_signal and
_thr_ucond_broadcast, clear condition variable pointer in cancellation
info after returing from _thr_ucond_wait, since kernel has already
dropped the internal lock, so we don't need to unlock it in cancellation
handler again.
Kip Macy [Tue, 12 Dec 2006 01:16:17 +0000 (01:16 +0000)]
- remove vestigial reference to mra[i]
- partition phys_avail along 4GB boundaries as possible workaround for hardware
problems causing watchdog panics
Andrew Thompson [Mon, 11 Dec 2006 23:46:40 +0000 (23:46 +0000)]
These days P2P means peer-2-peer (also well known from serveral filesharing
protocols) while PointToPoint has been PtP links. Change the variables
accordingly while the code is still fresh and undocumented.
Mohan Srinivasan [Mon, 11 Dec 2006 19:54:25 +0000 (19:54 +0000)]
NetApp filers return corrupt post op attrs in the wcc on NFS error responses.
This is easy to reproduce for EROFS. I am not sure if the attrs can be corrupt
for other NFS error responses. For now, disabling wcc pre-op attr checks and
post-op attr loads on NFS errors (sysctl'ed).
Reported by: Kris Kennaway
Jung-uk Kim [Mon, 11 Dec 2006 18:00:34 +0000 (18:00 +0000)]
- Correct collision counter for BCM5705+. This register is read/clear.
- Correct RX packet drop counter for BCM5705+. This register is read/clear
and it wraps very quickly under heavy packet drops because only the lower
ten bits are valid according to the documentation. However, it seems few
more bits are actually valid and the rest bits are always zeros[1].
Therefore, we don't mask them off here. To get accurate packet drop count,
we need to check the register from bge_rxeof(). It is commented out for now,
not to penalize normal operation. Actual performance impact should be
measured later.
- Correct integer casting from u_long to uint32_t. Casting is not really
needed for all supported platforms but we better do this correctly[2].
Pyun YongHyeon [Mon, 11 Dec 2006 11:09:48 +0000 (11:09 +0000)]
o Add support code for newer Marvell PHYs.
o Remove unused static global variable e1000phy_debug.
o Take advantage of mii_phy_dev_probe().
o Use MII_ANEGTICKS/MII_ANEGTICKS_GIGE instead of magic number 5.
o Add IFM_NONE as e1000phy(4) supports it without issues.
o Nuke magic PHY programming sequence in PHY reset and follow correct
reset sequence. [1]
o Make manual media selection work for all supported media types.
o Don't set MIIF_NOISOLATE so e1000phy(4) can be used in
configurations with multiple PHYs.
o In 1000baseT, when setting the link manually, one side must be the
master and the other the slave. If LINK0 is set, program the PHY
to be a master, otherwise it's a slave.
o When we lost a link, reset mii_ticks immediately so it correctly
check number of seconds elapsed in autonegotiation phase.
o Announce link loss right after it happens.
o After kicking autonegotiation, report PHY status instead of
returning immediatly.
o When link state check is in progress, check auto negotiation
completion bit only when auto negotiation is enbaled.
o When PHY is resolved to a master, show it with IFM_FLAG2.
Special thanks to marius who fixed several nits in original patch.
In half-duplex mode, nfe(4) fails to send packets. I think it's a bug
in nfe(4) as the same PHY works without problems on msk(4).
Obtained from: em(4) [1]
Reviewed by: marius
Tested by: bz
Kip Macy [Sun, 10 Dec 2006 04:18:03 +0000 (04:18 +0000)]
Do explicit bounds checking as a function of the actual size of the
reloc_target_bitmask array as opposed to the (known) index of the last value.
This change fixes CID 691.
Matt Jacob [Sun, 10 Dec 2006 03:41:48 +0000 (03:41 +0000)]
Remove dependency on ispfw and firmware as modules.
Either they're there early and the ispfw sets have
registered themselves, or they're not.
The module dependency stuff isn't quite what we want
anyway. If the user doesn't want the load placed on
system memory by loading the firmware, they don't
specify it to be loaded (either by being linked in
or via being a module to be loaded and then hooked
in with firmware(9)). It doesn't then make sense to
then override what they want by pulling it in anyway.
This might be able to work if we were able to pull in
just exactly what we needed for the card we have- but
that's an optimization left for the future.
Kip Macy [Sun, 10 Dec 2006 01:52:46 +0000 (01:52 +0000)]
Add hw.physmemstart loader variable to enable the user to specify the address
at which the kernel should start allocating physical memory. The primary
purpose of this is to test 64-bit cleanness of the data path by setting
hw.physmemstart=4G so that all physical allocations are above 4GB. AMD64
and i386/PAE could also benefit from having this option.
Warner Losh [Sun, 10 Dec 2006 01:10:08 +0000 (01:10 +0000)]
As Bernd Walter points out, the rlphy is used for more things than
just the intenral phy on parts supported by the rl and re drivers, the
RTL8201BL for example. He also sent me a nice picture of hundreds of
these chips in a tray to boulder his claim. :-) Therefore remove a
comment that suggested that they were...