This was triggering when using it as an AP bridge rather than an ethernet
bridge.
The code is unclear but it works; I'll fix it to be clearer and test
performance at a later stage.
The existing code meets the "alignment" requirement for the l3 payload
by offsetting the mbuf by uint64_t and then calling an rx fixup routine
to copy the frame backwards by 2 bytes. This DWORD aligns the
L3 payload so tcp, etc doesn't panic on unaligned access.
This is .. slow.
For arge MACs that support 1 byte TX/RX address alignment, we can do
the "other" hack: offset the RX address of the mbuf so the L3 payload
again is hopefully DWORD aligned.
This is much cheaper - since TX/RX is both 1 byte align ready (thanks
to the previous commit) there's no bounce buffering going on and there
is no rx fixup copying.
This gets bridging performance up from 180mbit/sec -> 410mbit/sec.
There's around 10% of CPU cycles spent in _bus_dmamap_sync(); I'll
investigate that later.
Tested:
* QCA955x SoC (AP135 reference board), bridging arge0/arge1
by programming the switch to have two vlangroups in dot1q mode:
# ifconfig bridge0 inet 192.168.2.20/24
# etherswitchcfg config vlan_mode dot1q
# etherswitchcfg vlangroup0 members 0,1,2,3,4
# etherswitchcfg vlangroup1 vlan 2 members 5,6
# etherswitchcfg port5 pvid 2
# etherswitchcfg port6 pvid 2
# ifconfig arge1 up
# ifconfig bridge0 addm arge1
The SUBDIR_PARALLEL feature uses a .for dir in ${SUBDIR} loop. The old code
here for recursing was setting SUBDIR= as a make *argument*. The SUBDIR=
replacement was not actually handled until after the .for loop was unrolled.
This could be seen with a '.info ${SUBDIR} ${dir}' inside of the loop which
showed an empty ${SUBDIR} and a set ${dir}. Setting NO_SUBIDR= before calling
${MAKE} as an *environment* variable handles the case fine and is a more
proper mechanism for disabling subdir handling.
This could be seen with 'make -C tests/sys/kern -j15 SUBDIR_PARALLEL=yes'.
MFC after: 2 weeks
Sponsored by: EMC / Isilon Storage Division
I messed up when doing the reset_vlans method - setting vid[0] = 1 here
was making it 'hidden' from configuration (as it needed ETHERSWITCH_VID_VALID
as well) and so there was no way to configure vlangroup0.
In per-port VLAN mode, vlangroup0 is for the CPU port (port0).
Now, it normally wouldn't really matter - the CPU port thus sees
all other ports. However there are two CPU ports on the AR8327 and
so port0 (arge0) was seeing all traffic on port6 (arge1).
If you thus tried to use arge1/port6 for anything (eg a WAN port)
in a bridge group then things would very upset very quickly.
Whilst here, add a comment to remind myself that yes, it'd be nice
if we could specify a boot-time switch config.
Tested:
* AP135 reference platform w/ AR8327N switch
r289660:
Do not allow to execute ptrace(PT_TRACE_ME) when the process is
already traced.
Do not allow to execute ptrace(PT_TRACE_ME) when there is no parent
which can trace the process, i.e. when the parent is already init.
Note that after the PT_TRACE_ME request the process is unkillable and
non-continuable until a debugger is attached, or parent is killed, the
later clears P_TRACED state. Since init clearly would not debug the
caller, and cannot be killed, disallow creation of unkillable
processes.
Reviewed by: jhb, pho
Reported and tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D3908
variables are already set. This should cover odd cases such as the
COMPILER_TYPE override in lib/csu/powerpc64.
X-MFC-With: r289659
MFC after: 3 weeks
Sponsored by: EMC / Isilon Storage Division
Extend OptionalObsoleteFiles.inc to delete all lib32 files when MK_LIB32 is
set to no on a system that previously had lib32 libraries installed.
Also, to prevent "make delete-old-dirs" from always deleting lib32 directories
after an installworld, move the lib32 subtree to its own mtree file that only
gets applied when MK_LIB32=yes.
Test: Ran "make delete-old" and "make delete-old-libs" on a system that never
had MK_LIB32 enabled, and on a system where MK_LIB32 was enabled and later
disabled. Did this both on amd64 and powerpc64.
Test: Ran "make tinderbox" without errors.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D3923
When establishing the locking state for several lock types (including
blockable mutexes and sx) failed, locking primitives try to spin while
the owner thread is running. The spinning loop performs the test for
running condition by dereferencing the owner->td_state field of the
owner thread. If the owner thread exited while spinner was put off
the processor, it is harmless to access reused struct thread owner,
since in some near future the current processor would notice the owner
change and make appropriate progress. But it could be that the page
which carried the freed struct thread was unmapped, then we fault
(this cannot happen on amd64).
For now, disallowing free of the struct thread seems to be good
enough, and tests which create a lot of threads once, did not
demonstrated regressions.
Reviewed by: jhb, pho
Reported and tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D3908
lookups.
This uses a special variable name based on a hash of ${CC}, ${PATH}, and
${MACHINE} to ensure that a cached value is not used if any of these
values changes to use a new compiler.
Before this there were 34,620 fork/exec from bsd.compiler.mk during a buildworld.
After this there are 608. More improvement is needed to cache a value from
the top-level before descending into subdirs in the various build phases.
Reviewed by: brooks (earlier version)
MFC after: 3 weeks
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D3898
If the bus is detached and deleted by a call to device_delete_child() or
device_delete_children() on a device higher in the tree, I²C children
were already detached and deleted. So the device_t pointer stored in sc
points to freed memory: we must not try to delete it again.
By using device_delete_children(), we let subr_bus.c figure out if there
are children to take care of.
While here, make sure iicbus_detach() and iicoc_detach() call
device_delete_children() too, to be safe.
Reviewed by: jhb, imp
Approved by: jhb, imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D3926
Add ntb_q_idx_t so it is more clear which struct members are of the same
type (some bogus uint64_ts snuck in that should have been unsigned int).
Add tx_err_no_buf and s/ENOMEM/EBUSY/ in tx_enqueue to match Linux.
Sponsored by: EMC / Isilon Storage Division
A plain 32 bit integer will overflow for values over 4GiB.
Change the plain integer size to the appropriate size type in
ntb_set_mw. Change the type of the size parameter and two local
variables used for size.
Even if there is no overflow, a size of zero is invalid here.
Authored by: Allen Hubbe
Reported by: Juyoung Jung
Obtained from: Linux (Dual BSD/GPL driver)
Sponsored by: EMC / Isilon Storage Division
It was possible for a synchronous update of the RX index in the error
case to get ahead of the asynchronous RX index update in the normal
case. Change the RX processing to preserve an RX completion order.
There were two error cases. First, if a buffer is not present to
receive data, there would be no queue entry to preserve the RX
completion order. Instead of dropping the RX frame, leave the RX frame
in the ring. Schedule RX processing when RX entries are enqueued, in
case there are RX frames waiting in the ring to be received.
Second, if a buffer is too small to receive data, drop the frame in the
ring, mark the RX entry as done, and indicate the error in the RX entry
length. Check for a negative length in the receive callback in
ntb_netdev, and count occurrences as rx_length_errors.
Authored by: Allen Hubbe
Obtained from: Linux (Dual BSD/GPL driver)
Sponsored by: EMC / Isilon Storage Division
Mechanically replace "SOC" with "ATOM" to match Linux. No functional
change. Original Linux commit log follows:
Instead of using the platform code names, use the correct platform names
to identify the respective Intel NTB hardware.
Authored by: Dave Jiang
Obtained from: Linux (Dual BSD/GPL driver)
Sponsored by: EMC / Isilon Storage Division
Prints driver name to indicate what is being loaded.
Authored by: Dave Jiang
Obtained from: Linux (Dual BSD/GPL driver)
Sponsored by: EMC / Isilon Storage Division
Normally this routine is supposed to loop until the PIC returns a "no more
interrupts pending" indication. I had commented that out to do just one
interrupt per invokation to do some timing tests.
Spotted by: Svata Kraus
Pointy Hat: ian
