Prevents a lockup when queried a deliberately constructed combination
of records. [CVE-2012-5166]
For more information: https://kb.isc.org/article/AA-00801
division by zero later if event timer's minimal period is above one second.
For now it is just a theoretical possibility.
Found by: Clang Static Analyzer
returns zero while request status is not CAM_REQ_CMP. That could cause
partial device attach or other unexpected results.
Found by: Clang Static Analyzer
enabled. This eliminates one mtx_lock() per each routing lookup thus improving
performance in several cases (routing to directly connected interface or routing
to default gateway).
Icmp redirects should not be used to provide routing direction nowadays, even
for end hosts. Routers should not use them too (and this is explicitly restricted
in IPv6, see RFC 4861, clause 8.2).
Current commit changes rnh_machaddr function to 'stock' rn_match (and back) for every
AF_INET routing table in given VNET instance on drop_redirect sysctl change.
This change is part of bigger patch eliminating rte locking.
Sponsored by: Yandex LLC
MFC after: 2 weeks
While here, change ISCI_LED to ISCI_PHY since conceptually the hardware
ties the LEDs to a phy and the LEDs for a given phy cannot be controlled
independently.
Submitted by: Paul Maulberger <Paul.Maulberger at gmx.de> (with modifications)
information from the transceivers connected to the ports of a
cxgbe(4) based card.
# cxgbetool t4nex0 i2c <port_id> <dev_addr> <addr> [<count>]
For example:
# cxgbetool t4nex0 i2c 0 0xa0 3
0x10 [16]
(As per SFF-8472 the SFP+ module is at 0xa0 and bit 4 in the value at
address 3 indicates it's a 10Gbase-SR module, which it is.)
This lets userspace read arbitrary information from the SFP+ modules
etc. on this bus.
Reading multiple bytes in the same transaction isn't possible right now.
I'll update the driver once the chip's firmware supports this.
MFC after: 3 days
reference a missing dependency rather than a missing compile command.
- Don't append a newline to the auto-generated compile command. The
compile command has a newline appended when it is later output to the
Makefile.
MFC after: 2 weeks
that requires 10ms delay after device reset. Because that code was
there from day 1, I guess it was added to give enough settlement
time after updating BGE_MAC_MODE register.
The recommended delay time for BGE_MAC_MODE after updating is 40us
and it was already done in r241219.
The VCPU(Virtual CPU) of BCM5906 is used to provide a mechanism to
control the bootcode execution and to pick up configuration data
stored inside the EEPROM.
The bootcode of BCM5906 will check the BGE_VCPU_STATUS_DRV_RESET
bit to decide which booting procedure to choose.
Data sheet indicates the VCPU of BCM5906 should set
BGE_VCPU_STATUS_DRV_RESET bit *before* VCPU reset or global reset.
water mark to 256 bytes. Otherwise controller will encounter DMA
write under run errors and would result in RX DMA hang. If the
maximum payload size is 128 bytes, the water mark is set to 128
bytes as usual.
While here, set maximum read request size to 2048 for BCM5719/BCM5720.
For other PCIe devices, use 4096. And reprogram the maximum read
request size whenever device reset is performed.
make analog input loopback and dual-stream playback work by enabling
signal mixing by nid 22, as it should be according to info returned by
the CODEC. Otherwise pin nid 28 receives only signal from DAC nid 16.
PR: kern/169124
MFC after: 1 week
instruction loads/stores at its will.
The macro __compiler_membar() is currently supported for both gcc and
clang, but kernel compilation will fail otherwise.
Reviewed by: bde, kib
Discussed with: dim, theraven
MFC after: 2 weeks
srandomdev(). This doesn't actually work
with any modern C compiler:
In particular, both clang and modern gcc
verisons silently elide any xor operation
with 'junk'.
Approved by: secteam
MFC after: 3 days
r234247.
Use, instead, the static intializer introduced in r239923 for x86 and
sparc64 intr_cpus, unwinding the code to the initial version.
Reviewed by: marius
executed to better differentiate between loader-specific errors and kernel-
specific errors (if ever any of either).
This type of functionality hasn't been required before the introduction of the
advanced menu system (r222417). Adding this functionality will help different-
iate errors at the loader-level such as a BTX halt caused by heap exhaustion
and errors that may be involved with executing the kernel (wrong architecture
for example). A user can learn that messages before "Booting..." are related to
the loader(8) environment and it's Forth-ilk, while those after are not
related to loader(8) -- the point that loader(8) has ``left the building''.
This patch also includes a man-page update to color.4th(8) as the color logic
moves to a lower-level (from being included by beastie.4th to being included
by loader.4th).
After noticing a delay between execution of the overloaded "boot" FICL word and
the display of text on-screen, gcooper confirmed that the introduction of a
builtin memory test (disabled by adding hw.memtest.tests="0" to loader.conf(5))
was the cause of the delay.
This patch adds an echo to produce "Booting..." when the overloaded "boot" word
is executed (this includes from the interactive command-prompt on all arches,
from the menu system on arches that run the beastie menu, and even those arches
that run the menu but disable it by setting beastie_disable="YES" in
loader.conf(5)). When loader_color="YES" in loader.conf(5), the same message is
produced but in white text on a blue background (only the letters produced have
this background -- opposed to perhaps the entire line).
upon pmap_enter() to create a mapping within a different address space,
i.e., not the thread's own address space. On i386, this entails the
creation of a temporary mapping to the affected page table page (PTP). In
general, pmap_enter() will read from this PTP, allocate a PV entry, and
write to this PTP. The trouble comes when the system is short of memory.
In order to allocate a new PV entry, an older PV entry has to be
reclaimed. Reclaiming a PV entry involves destroying a mapping, which
requires access to the affected PTP. Thus, the PTP mapped at the
beginning of pmap_enter() is no longer mapped at the end of pmap_enter(),
which leads to pmap_enter() modifying the wrong PTP. To address this
problem, pmap_pv_reclaim() is changed to use an alternate method of
mapping PTPs.
Update a related comment.
Reported by: pho
Diagnosed by: kib
MFC after: 5 days
host byte order, was sometimes called with net byte order. Since we are
moving towards net byte order throughout the stack, the function was
converted to expect net byte order, and its consumers fixed appropriately:
- ip_output(), ipfilter(4) not changed, since already call
in_delayed_cksum() with header in net byte order.
- divert(4), ng_nat(4), ipfw_nat(4) now don't need to swap byte order
there and back.
- mrouting code and IPv6 ipsec now need to switch byte order there and
back, but I hope, this is temporary solution.
- In ipsec(4) shifted switch to net byte order prior to in_delayed_cksum().
- pf_route() catches up on r241245 changes to ip_output().
the ATH_TXQ_* macros.
* Introduce the new macros;
* rename the TID queue and TID filtered frame queue so the compiler
tells me I'm using the wrong macro.
These should correspond 1:1 to the existing code.
