Add support for reading i2c SFP/SFP+ data from NIC driver and
presenting most interesting fields via ifconfig -v.
This version supports Intel ixgbe driver only.
Tested on: Cisco,Intel,Mellanox,ModuleTech,Molex transceivers
* Add new net/sff8436.h containing constants used to access
QSFP+ data via i2c inteface. These constants has been taken
from SFF-8436 "QSFP+ 10 Gbs 4X PLUGGABLE TRANSCEIVER" standard
rev 4.8.
* Add support for printing QSFP+ information from 40G NICs
such as Chelsio T5.
edwin [Thu, 13 Aug 2015 23:59:53 +0000 (23:59 +0000)]
MFC of 286750,tzdata10:
Update to tzdata2015f:
Changes affecting future time stamps
North Korea switches to +0830 on 2015-08-15. (Thanks to Steffen Thorsen.)
The abbreviation remains "KST". (Thanks to Robert Elz.)
Uruguay no longer observes DST. (Thanks to Steffen Thorsen and Pablo Camargo.)
Changes affecting past and future time stamps
Moldova starts and ends DST at 00:00 UTC, not at 01:00 UTC. (Thanks to Roman Tudos.)
pfg [Thu, 13 Aug 2015 01:02:57 +0000 (01:02 +0000)]
MFC r286074:
GCC: Add a new option "-fstack-protector-strong"
This includes additional functions to be protected: those that
have local array definitions, or have references to local frame
addresses. This is a new option in GCC-4.9 that was relicensed
by Han Shen from Google under GPLv2.
imp [Wed, 12 Aug 2015 16:53:37 +0000 (16:53 +0000)]
Direct commit
When compiling on -current from r284356 to r285986, the host's
crunchgen can't be used because builds of rescue break when STRIP= was
used to prevent stripping of binaries. Direct commit because -current
code is different. Building 10 on current is common enough to warrnat
a safety belt since this has been broken for two months. The offending
change was never in stable/10.
rmacklem [Sat, 8 Aug 2015 22:06:07 +0000 (22:06 +0000)]
MFC: r285260
Since the case where secflavor < 0 indicates the security flavor is
to be negotiated, it could be a Kerberized mount. As such, filling
in the "principal" argument using the canonized host name makes sense.
If it is negotiated as AUTH_SYS, the "principal" argument is meaningless
but harmless.
pfg [Wed, 5 Aug 2015 18:52:40 +0000 (18:52 +0000)]
MFC r285720:
libusb: Fix minor warning.
Fix a warning triggered by the gcc + FORTIFY_SOURCE patches:
In function 'libusb20_parse_config_desc': lib/libusb/libusb20_desc.c:141:
warning: passing argument 1 of 'memcpy' discards qualifiers from pointer
target type
MFC r285888:
Build debug version of rmlock's methods only when LOCK_DEBUG > 0.
Currently LOCK_DEBUG is always defined in sys/lock.h (0 or 1).
This means that debugging code always built. In addition the kernel
modules have always defined LOCK_DEBUG as 1. So, debugging rmlock code
is always used by kernel modules.
kib [Wed, 5 Aug 2015 08:17:10 +0000 (08:17 +0000)]
Implement x86 ptrace(2) requests PT_{GET,SET}{FS,GS}BASE.
MFC r284918:
Add helper fill_based_sd(9).
MFC r284919:
Add x86 PT_GETFSBASE, PT_GETGSBASE machine-depended ptrace requests to
obtain the thread %fs and %gs bases. Add x86 PT_SETFSBASE and
PT_SETGSBASE requests to set the bases from debuggers. The set
requests, similarly to the sysarch({I386,AMD64}_SET_FSBASE), override
the corresponding segment registers.
MFC r284965:
Document x86 machine-specific ptrace(2) requests.
MFC r285011:
Disallow a debugger on 64bit system to set fs/gs bases of the 32bit
process beyond the end of the process address space.
davidcs [Wed, 5 Aug 2015 00:00:06 +0000 (00:00 +0000)]
MFC r285973
- Avoid lock contention in the if_transmit callback by using trylock and
enqueueing the frames when it fails. This way there is some latency
removed from the transmitting path.
- If IFF_DRV_OACTIVE is set (and also if IFF_DRV_RUNNING is not) just
enqueue the desired frames and return successful transmit. This way we
avoid to return errors on transmit side and resulting in
possible out-of-order frames. Please note that IFF_DRV_OACTIVE is set
everytime we get the threshold ring hit, so this can be happening quite
often.
emaste [Tue, 4 Aug 2015 15:15:06 +0000 (15:15 +0000)]
MFC r281581: vidcontrol: make size argument optional again for syscons
r273544 (MFC in r273921) changed the -f option allow no arguments in vt
mode (used to reset the font back to the default), but broke the
optionality of the size argument for syscons. Drop the required argument
from syscons' optstring for -f so the optional argument handler works
the same way for both syscons and vt.
r284988:
cxgbe(4): request an automatic tx update when a netmap tx queue idles.
The NIC tx queues already do this.
r285220:
cxgbe(4): Do not override the the global defaults for congestion drops.
The hw.cxgbe.cong_drop knob is not affected by this change because the
driver sets up congestion drop on a per-queue basis.
r285221:
cxgbe(4): Add a new knob that controls the congestion response of netmap
rx queues. The default is to drop rather than backpressure.
This decouples the congestion settings of NIC and netmap rx queues.
r284445:
cxgbe(4): Add the ability to dump mailbox commands and replies. It is
enabled/disabled via bit 0 of adapter->debug_flags (which is available
at dev.t5nex.<n>.debug_flags).
r286107:
cxgbe(4): initialize debug_flags from the kernel environment.
trasz [Mon, 3 Aug 2015 08:04:31 +0000 (08:04 +0000)]
MFC r282086:
Make setproctitle(3) work in Capsicum capability mode. This makes
ctld(8) child processes to indicate initiator address and name in
their titles, similar to what iscsid(8) child processes do.
trasz [Sun, 2 Aug 2015 10:08:57 +0000 (10:08 +0000)]
MFC r284582:
Fix off-by-one error in fstyp(8) and geom_label(4) that made them use
a single space (" ") as a CD9660 label name when no label was present.
Similar problem was also present in msdosfs label recognition.
rmacklem [Sat, 1 Aug 2015 22:56:42 +0000 (22:56 +0000)]
MFC: r286046
This patch fixes a problem where, if the NFSv4 server has a previous
unconfirmed clientid structure for the same client on the last hash list,
this old entry would not be removed/deleted. I do not think this bug would have
caused serious problems, since the new entry would have been before the old one
on the list. This old entry would have eventually been scavenged/removed.
kib [Sat, 1 Aug 2015 03:37:00 +0000 (03:37 +0000)]
MFC r285878:
Revert r173708's modifications to vm_object_page_remove().
This fixes inconsistencies encountered by vm_object_unwire() or
by the buffer cache when the file is truncated.
MFC: r285113
If a "principal" argument isn't provided for a Kerberized NFS mount,
the kernel would generate a bogus one with a ":/<path>" suffix.
This would only occur for the case where there was no explicit
"principal" argument and the getaddrinfo() call in mount_nfs.c failed to a
return a cannonical name for the server.
This patch fixes this unusual case.
Since the IETF has redefined the meaning of the tos field to accommodate
a set of differentiated services, set IPTOS_PREC_* macros using
IPTOS_DSCP_* macro definitions.
While here, add IPTOS_DSCP_VA macro according to RFC 5865.
When we allocate the struct pf_fragment in pf_fillup_fragment() we
forgot to initialise the fr_flags field. As a result we sometimes
mistakenly thought the fragment to not be a buffered fragment.
This resulted in panics because we'd end up freeing the pf_fragment
but not removing it from V_pf_fragqueue (believing it to be part of
V_pf_cachequeue). The next time we iterated V_pf_fragqueue we'd use
a freed object and panic.
While here also fix a pf_fragment use after free in pf_normalize_ip().
pf_reassemble() frees the pf_fragment, so we can't use it any more.
X-MFS-To: releng/10.2
Sponsored by: The FreeBSD Foundation
Run a shell in the jail when no command is specified.
Add a new flag, -l, for a clean environment, same as jail(8) exec.clean.
Change the GET_USER_INFO macro into a function.
marius [Thu, 30 Jul 2015 02:23:09 +0000 (02:23 +0000)]
MFC: r285843
- Since r253161, uart_intr() abuses FILTER_SCHEDULE_THREAD for signaling
uart_bus_attach() during its test that 20 iterations weren't sufficient
for clearing all pending interrupts, assuming this means that hardware
is broken and doesn't deassert interrupts. However, under pressure, 20
iterations also can be insufficient for clearing all pending interrupts,
leading to a panic as intr_event_handle() tries to schedule an interrupt
handler not registered. Solve this by introducing a flag that is set in
test mode and otherwise restores pre-r253161 behavior of uart_intr(). The
approach of additionally registering uart_intr() as handler as suggested
in PR 194979 is not taken as that in turn would abuse special pccard and
pccbb handling code of intr_event_handle(). [1]
- Const'ify uart_driver_name.
- Fix some minor style bugs.
marius [Thu, 30 Jul 2015 02:06:29 +0000 (02:06 +0000)]
MFC: r285839
o Revert the other functional half of r239864, i. e. the merge of r134227
from x86 to use smp_ipi_mtx spin lock not only for smp_rendezvous_cpus()
but also for the MD cache invalidation, TLB demapping and remote register
reading IPIs due to the following reasons:
- The cross-IPI SMP deadlock x86 otherwise is subject to can't happen on
sparc64. That's because on sparc64, spin locks don't disable interrupts
completely but only raise the processor interrupt level to PIL_TICK. This
means that IPIs still get delivered and direct dispatch IPIs such as the
cache invalidation etc. IPIs in question are still executed.
- In smp_rendezvous_cpus(), smp_ipi_mtx is held not only while sending an
IPI_RENDEZVOUS, but until all CPUs have processed smp_rendezvous_action().
Consequently, smp_ipi_mtx may be locked for an extended amount of time as
queued IPIs (as opposed to the direct ones) such as IPI_RENDEZVOUS are
scheduled via a soft interrupt. Moreover, given that this soft interrupt
is only delivered at PIL_RENDEZVOUS, processing of smp_rendezvous_action()
on a target may be interrupted by f. e. a tick interrupt at PIL_TICK, in
turn leading to the target in question trying to send an IPI by itself
while IPI_RENDEZVOUS isn't fully handled, yet, and, thus, resulting in a
deadlock.
o As mentioned in the commit message of r245850, on least some sun4u platforms
concurrent sending of IPIs by different CPUs is fatal. Therefore, hold the
reintroduced MD ipi_mtx also while delivering cross-traps via MI helpers,
i. e. ipi_{all_but_self,cpu,selected}().
o Akin to x86, let the last CPU to process cpu_mp_bootstrap() set smp_started
instead of the BSP in cpu_mp_unleash(). This ensures that all APs actually
are started, when smp_started is no longer 0.
o In all MD and MI IPI helpers, check for smp_started == 1 rather than for
smp_cpus > 1 or nothing at all. This avoids races during boot causing IPIs
trying to be delivered to APs that in fact aren't up and running, yet.
While at it, move setting of the cpu_ipi_{selected,single}() pointers to
the appropriate delivery functions from mp_init() to cpu_mp_start() where
it's better suited and allows to get rid of the global isjbus variable.
o Given that now concurrent IPI delivery no longer is possible, also nuke
the delays before completely disabling interrupts again in the CPU-specific
cross-trap delivery functions, previously giving other CPUs a window for
sending IPIs on their part. Actually, we now should be able to entirely get
rid of completely disabling interrupts in these functions. Such a change
needs more testing, though.
o In {s,}tick_get_timecount_mp(), make the {s,}tick variable static. While not
necessary for correctness, this avoids page faults when accessing the stack
of a foreign CPU as {s,}tick now is locked into the TLBs as part of static
kernel data. Hence, {s,}tick_get_timecount_mp() always execute as fast as
possible, avoiding jitter.
marius [Thu, 30 Jul 2015 00:28:27 +0000 (00:28 +0000)]
MFC: r284447, r284552
Merge from NetBSD:
o rev. 1.10: Nuke trailing whitespace.
o rev. 1.15: Fix typo in comment.
o rev. 1.16: Add the following registers from IEEE 802.3-2009 Clause 22:
- PSE control register (0x0b)
- PSE status register (0x0c)
- MMD access control register (0x0d)
- MMD access address data register (0x0e)
o rev. 1.17 (comments only): The bit location of link ability is different
between 1000Base-X and others (see Annex 28B.2 and 28D).
o rev. 1.18: Nuke dupe word.
dim [Wed, 29 Jul 2015 19:25:28 +0000 (19:25 +0000)]
Reapply r286007, modified to compile with pre-C++11 compilers:
Pull in r219009 from upstream llvm trunk (by Adam Nemet):
[ISel] Keep matching state consistent when folding during X86 address match
In the X86 backend, matching an address is initiated by the 'addr' complex
pattern and its friends. During this process we may reassociate and-of-shift
into shift-of-and (FoldMaskedShiftToScaledMask) to allow folding of the
shift into the scale of the address.
However as demonstrated by the testcase, this can trigger CSE of not only the
shift and the AND which the code is prepared for but also the underlying load
node. In the testcase this node is sitting in the RecordedNode and MatchScope
data structures of the matcher and becomes a deleted node upon CSE. Returning
from the complex pattern function, we try to access it again hitting an assert
because the node is no longer a load even though this was checked before.
Now obviously changing the DAG this late is bending the rules but I think it
makes sense somewhat. Outside of addresses we prefer and-of-shift because it
may lead to smaller immediates (FoldMaskAndShiftToScale is an even better
example because it create a non-canonical node). We currently don't recognize
addresses during DAGCombiner where arguably this canonicalization should be
performed. On the other hand, having this in the matcher allows us to cover
all the cases where an address can be used in an instruction.
I've also talked a little bit to Dan Gohman on llvm-dev who added the RAUW for
the new shift node in FoldMaskedShiftToScaledMask. This RAUW is responsible
for initiating the recursive CSE on users
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-September/076903.html) but it
is not strictly necessary since the shift is hooked into the visited user. Of
course it's safer to keep the DAG consistent at all times (e.g. for accurate
number of uses, etc.).
So rather than changing the fundamentals, I've decided to continue along the
previous patches and detect the CSE. This patch installs a very targeted
DAGUpdateListener for the duration of a complex-pattern match and updates the
matching state accordingly. (Previous patches used HandleSDNode to detect the
CSE but that's not practical here). The listener is only installed on X86.
I tested that there is no measurable overhead due to this while running
through the spec2k BC files with llc. The only thing we pay for is the
creation of the listener. The callback never ever triggers in spec2k since
this is a corner case.
projects / FreeBSD / stable / 10.git / log