Commit Graph

263675 Commits

Author SHA1 Message Date
erj
63b49c2612 Fix compile error introduced in r353658
"adapter" doesn't exist in ixl.

Reported by:	O. Hartmann <ohartmann@walstatt.org>
2019-10-16 18:12:22 +00:00
brooks
1124ab66cf Install bsd.compat.mk.
Reported by:	glebius
2019-10-16 17:21:18 +00:00
erj
02fd9522cb ixl: report whether device received pause frames
From Jake:
When updating the device statistics, report whether or not we have
received any pause frames to the iflib stack. This allows the iflib
stack to avoid generating a Tx hang message while the device is paused.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>

Submitted by:	Jacob Keller <jacob.e.keller@intel.com>
Reviewed by:	gallatin@
Sponsored by:	Intel Corporation
Differential Revision:	https://reviews.freebsd.org/D21870
2019-10-16 17:19:17 +00:00
erj
9da68e5236 ix: report isc_pause_frames during stat update
From Jake:
Notify the iflib stack of whether we received any pause frames during
the timer window. This allows the stack to avoid reporting a Tx hang due
to the device being paused.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>

Submitted by:	Jacob Keller <jacob.e.keller@intel.com>
Reviewed by:	gallatin@
Sponsored by:	Intel Corporation
Differential Revision:	https://reviews.freebsd.org/D21869
2019-10-16 17:16:32 +00:00
erj
fe09f9c176 e1000: correctly set isc_pause_frames only when XOFF increases
From Jake:
The e1000 driver sets the iflib shared context isc_pause_frames value to
the number of received xoff frames. This is done so that the iflib
watchdog timer won't trigger a Tx Hang due to pause frames.

Unfortunately, the function simply sets it to the value of the xoffrxc
counter. Once the device has received a single XOFF packet, the driver
always reports that we received pause frames. This will prevent the Tx
hang detection entirely from that point on.

Fix this by assigning isc_pause_frames to a non-zero value if we
received any XOFF packets in the last timer interval.

We could attempt to calculate the total number of received packets by
doing a subtraction, but the iflib stack only seems to check if
isc_pause_frames is non-zero.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>

Submitted by:	Jacob Keller <jacob.e.keller@intel.com>
Reviewed by:	gallatin@
Sponsored by:	Intel Corporation
Differential Revision:	https://reviews.freebsd.org/D21868
2019-10-16 17:13:46 +00:00
dim
5132a69f56 Ensure lld respects the WITH/WITHOUT_SHARED_TOOLCHAIN option
Traditionally, toolchain components such as cc, as, and ld have been
built as static executables.  The WITH_SHARED_TOOLCHAIN option from
src.conf(5) is meant to link these as regular executables, e.g. using
shared libraries.

The build of ld.lld did not yet check this option.  Fix the Makefile so
it will do so now.

Reported by:	Mike Cui <cuicui@gmail.com>
PR:		241257
MFC after:	3 days
2019-10-16 17:11:18 +00:00
glebius
ec1d6a72a3 do_link_state_change() is executed in taskqueue context and in
general is allowed to sleep.  Don't enter the epoch for the
whole duration.  If some event handlers need the epoch, they
should handle that theirselves.

Discussed with:	hselasky
2019-10-16 16:32:58 +00:00
ian
7c87e295c8 Update some comments; no functional changes. Some historical old comments
in this driver indicate that the SD_CAPA register is write-once and after
being set one time the values in it cannot be changed.  That turns out not
to be the case -- the values written to it survive a reset, but they can
be rewritten/changed at any time.
2019-10-16 16:26:35 +00:00
ian
976e42830c Revert r351218 (by manu). While the changes in r351218 appear to be (and
should be) correct, they lead to the eMMC on a Beaglebone failing to work
in some situations.

The TI sdhci hardware is kind of strange.  The first device inherently
supports 1.8v and 3.3v and the abililty to switch between them, and the
other two devices must be set to 1.8v in the sdhci power control register to
operate correctly, but doing so actually makes them run at 3.3v (unless an
external level-shifter is present in the signal path).  Even the 1.8v on the
first device may actually be 3.3v (or any other value), depending on what
voltage is fed to the VDDS1-VDDS7 power supply pins on the am335x chip.

Another strange quirk is that the convention for am335x sdhci drivers in
linux and uboot and the am335x boot ROM seems to be to set the voltage in
the sdhci capabilities register to 3.0v even though the actual voltage is
3.3v.  Why this is done is a complete mystery to me, but it seems to be
required for correct operation.

If we had complete modern support for the am335x chip we could get the
actual voltages from the FDT data and the regulator framework.  But our
am335x code currently doesn't have any regulator framework support.
Reverting to the prior code will get the popular Beaglebone boards working
again.

This is part of the fix for PR 241301, but also requires r353651 for a
complete fix.

PR:		241301
Discussed with: manu
2019-10-16 16:19:21 +00:00
ian
8eb4642025 Relax the sdhci(4) check that filters out the 1.8v voltage option unless
the slot is flagged as 'embedded'.

The features related to embedded and shared slots were added in v3.0 of
the sdhci spec.  Hardware prior to v3 sometimes supported 1.8v on non-
removable devices in embedded systems, but had no way to indicate that
via the standard sdhci registers (instead they use out of band metadata
such as FDT data).

This change adds the controller specification version to the check for
whether to filter out the 1.8v selection.  On older hardware, the 1.8v
option is allowed to remain.  On 3.0 or later it still requires the
embedded-slot flag to remain.

This is part of the fix for PR 241301 (eMMC not detected on Beaglebone).
Changes to the sdhci_ti driver are also needed for a full fix.

PR:		241301
2019-10-16 16:03:19 +00:00
markj
957cc17627 Clear PGA_WRITEABLE in moea_pvo_remove().
moea_pvo_remove() might remove the last mapping of a page, in which case
it is clearly no longer writeable.  This can happen via pmap_remove(),
or when a CoW fault removes the last mapping of the old page.

Reported and tested by:	bdragon
Reviewed by:	alc, bdragon, kib
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D22044
2019-10-16 15:50:12 +00:00
avg
722bbbddac fix section number in zfs-program.8
MFC after:	3 days
2019-10-16 15:21:05 +00:00
avg
423d2bf684 attach itwd to the module build on x86
MFC after:	19 days
X-MFC with:	r353647
2019-10-16 15:01:44 +00:00
avg
92d6de6711 itwd(4): driver for watchdog function in ITE Super I/O chips
The chips are commonly named with "IT" prefix.

MFC after:	19 days
2019-10-16 14:57:38 +00:00
kevans
2550d91204 bectl(8): destroy: use BE_DESTROY_AUTOORIGIN if -o is not specified
-o will force the origin to be destroyed unconditionally.
BE_DESTROY_AUTOORIGIN, on the other hand, will only destroy the origin if it
matches the format used by be_snapshot. This lets us clean up the snapshots
that are clearly not user-managed (because we're creating them) while
leaving user-created snapshots in place and warning that they're still
around when the BE created goes away.
2019-10-16 14:55:56 +00:00
avg
6e94de3ffa wbwd: move to superio(4) bus
This allows to remove a bunch of low level code.
Also, superio(4) provides safer interaction with other drivers
that work with Super I/O configuration registers.

Tested only on PCengines APU2:
superio0: <Nuvoton NCT5104D/NCT6102D/NCT6106D (rev. B+)> at port 0x2e-0x2f on isa0
wbwd0: <Nuvoton NCT6102 (0xc4/0x53) Watchdog Timer> at WDT ldn 0x08 on superio0

The watchdog output is incorrectly wired on that system and the watchdog
does not really do it its job, but the pulse can be seen with a signal
analyzer.

Reviewed by:	delphij, bcr (man page)
MFC after:	19 days
Differential Revision: https://reviews.freebsd.org/D21979
2019-10-16 14:46:04 +00:00
kevans
fb36ab356f libbe(3): add needed bits for be_destroy to auto-destroy some origins
New BEs can be created from either an existing snapshot or an existing BE.
If an existing BE is chosen (either implicitly via 'bectl create' or
explicitly via 'bectl create -e foo bar', for instance), then bectl will
create a snapshot of the current BE or "foo" with be_snapshot, with a name
formatted like: strftime("%F-%T") and a serial added to it.

This commit adds the needed bits for libbe or consumers to determine if a
snapshot names matches one of these auto-created snapshots (with some light
validation of the date/time/serial), and also a be_destroy flag to specify
that the origin should be automatically destroyed if possible.

A future commit to bectl will specify BE_DESTROY_AUTOORIGIN by default so we
clean up the origin in the most common case, non-user-managed snapshots.
2019-10-16 14:43:05 +00:00
avg
f5dd73c97a move nctgpio to superio(4) bus
This is where it logically belongs.
The change allows to drop a bunch of low lewel code.

Reviewed by:	gonzo
MFC after:	19 days
Differential Revision: https://reviews.freebsd.org/D21980
2019-10-16 14:42:49 +00:00
manu
7198b43642 dwc3: Use a pair of ()'s around arguments for some macros
Reported by:	hselasky
MFC after:	1 week
X-MFC-With:	r353533
2019-10-16 13:53:53 +00:00
andrew
53cf0bb146 Use tables to store the information to decode the arm64 ID registers.
Arm updates these with each new architecture revision. To help keep them
updated use a collection of tables to hold the needed information to
decode these registers.

Sponsored by:	DARPA, AFRL
Differential Revision:	https://reviews.freebsd.org/D22020
2019-10-16 13:30:28 +00:00
andrew
7052b2d00d Stop leaking information from the kernel through timespec
The timespec struct holds a seconds value in a time_t and a nanoseconds
value in a long. On most architectures these are the same size, however
on 32-bit architectures other than i386 time_t is 8 bytes and long is
4 bytes.

Most ABIs will then pad a struct holding an 8 byte and 4 byte value to
16 bytes with 4 bytes of padding. When copying one of these structs the
compiler is free to copy the padding if it wishes.

In this case the padding may contain kernel data that is then leaked to
userspace. Fix this by copying the timespec elements rather than the
entire struct.

This doesn't affect Tier-1 architectures so no SA is expected.

admbugs:	651
MFC after:	1 week
Sponsored by:	DARPA, AFRL
2019-10-16 13:21:01 +00:00
imp
59a743a27f bsd.compat.mk isn't setup to be included outside of Makefile.inc so comment it
out here until that's sorted out. Otherwise the build is broken. when
TARGET_ARCH isn't defined.
2019-10-16 13:20:36 +00:00
avg
d2dd33611e MFV r353637: 10844 Serialize ZTHR operations to eliminate races
illumos/illumos-gate@6a316e1f6d
6a316e1f6d

https://www.illumos.org/issues/10844
  ZoL 61c3391acc9 Serialize ZTHR operations to eliminate races

Portions contributed by: Jerry Jelinek <jerry.jelinek@joyent.com>
Author: Serapheim Dimitropoulos <serapheim@delphix.com>
Obtained from:	illumos, ZoL
MFC after:	3 weeks
2019-10-16 09:29:01 +00:00
avg
dee41b6cfc MFV r353630: 10809 Performance optimization of AVL tree comparator functions
illumos/illumos-gate@c4ab0d3f46
c4ab0d3f46

https://www.illumos.org/issues/10809
  Port ZoL ee36c709c3d Performance optimization of AVL tree comparator functions

This is a followup to r337567 that imported the ZoL commit directly into
FreeBSD.  It seems that at the time we did not have some of the earlier
changes, so some pieces of the ZoL change were not applicable.  Also,
the illumos version got a few style cleanups.  Some changes were missed
or incorrectly merged (e.g., vdev_cache_lastused_compare and
metaslab_rangesize_compare).

Obtained from:	ZoL, illumos
MFC after:	25 days
X-MFC after:	r353634
2019-10-16 09:20:08 +00:00
hselasky
94dc322ef6 Fix panic in network stack due to use after free when receiving
partial fragmented packets before a network interface is detached.

When sending IPv4 or IPv6 fragmented packets and a fragment is lost
before the network device is freed, the mbuf making up the fragment
will remain in the temporary hashed fragment list and cause a panic
when it times out due to accessing a freed network interface
structure.


1) Make sure the m_pkthdr.rcvif always points to a valid network
interface. Else the rcvif field should be set to NULL.

2) Use the rcvif of the last received fragment as m_pkthdr.rcvif for
the fully defragged packet, instead of the first received fragment.

Panic backtrace for IPv6:

panic()
icmp6_reflect() # tries to access rcvif->if_afdata[AF_INET6]->xxx
icmp6_error()
frag6_freef()
frag6_slowtimo()
pfslowtimo()
softclock_call_cc()
softclock()
ithread_loop()

Reviewed by:	bz
Differential Revision:	https://reviews.freebsd.org/D19622
MFC after:	1 week
Sponsored by:	Mellanox Technologies
2019-10-16 09:11:49 +00:00
avg
4cc84298dd MFV r348596: 9689 zfs range lock code should not be zpl-specific
illumos/illumos-gate@7931524763

FreeBSD note: some tweaking was needed to avoid a conflict with
sys/rangelock.h.

Author:	Matthew Ahrens <mahrens@delphix.com>
Obtained from:	illumos
MFC after:	3 weeks
2019-10-16 09:04:53 +00:00
hselasky
12434b0a36 VLAN_TRUNKDEV() requires epochification in ibcore after r353292.
Sponsored by:	Mellanox Technologies
2019-10-16 08:56:07 +00:00
hselasky
ae1053fff8 Replace rdma_is_upper_dev_rcu() with rdma_vlan_dev_real_dev() in ibcore.
This reduces the number of references to VLAN_TRUNKDEV() in ibcore.
Currently only VLAN is supported as a child interface in FreeBSD.
Remove superfluous RCU locking.

Sponsored by:	Mellanox Technologies
2019-10-16 08:55:29 +00:00
hselasky
a8aff284db VLAN_DEVAT() requires epochification in ipoib after r353292.
Sponsored by:	Mellanox Technologies
2019-10-16 08:40:58 +00:00
avg
5f53fd39c6 MFV r353628:
10842 Mutex leak in dsl_dataset_hold_obj()

illumos/illumos-gate@ad027c0ff9
ad027c0ff9

https://www.illumos.org/issues/10842
  ZoL d10b2f1d35b Mutex leak in dsl_dataset_hold_obj()

Portions contributed by: Jerry Jelinek <jerry.jelinek@joyent.com>
Author: Jorgen Lundman <lundman@lundman.net>
Obtained from:	illumos, ZoL
MFC after:	15 days
2019-10-16 07:57:58 +00:00
avg
fdf92df956 fix wording / typos in r353625
Reported by:	kib
MFC after:	4 weeks
X-MFC with:	r353625, r353618
2019-10-16 07:53:47 +00:00
avg
bdeb23c1eb zfs: add a lame emulation of cv_wait_sig(9) in userland to fix r353618
Not sure if we need anything better.
Maybe we should try to port illumos libfakekernel or provide something
similar natively.

MFC after:	4 weeks
X-MFC with:	r353618
2019-10-16 07:41:33 +00:00
avg
cc0089fc57 MFV r353623: 10473 zfs(1M) missing cross-reference to zfs-program(1M)
illumos/illumos-gate@736e670039
736e670039

https://www.illumos.org/issues/10473

Author: Jason King <jason.king@joyent.com>
Obtained from:	illumos
MFC after:	6 days
2019-10-16 07:20:59 +00:00
kib
ae3c37c2e4 Fix assert in PowerPC pmaps after introduction of object busy.
The VM_PAGE_OBJECT_BUSY_ASSERT() in pmap_enter() implementation should
be only asserted when the code is executed as result of pmap_enter(),
not when the same code is entered from e.g. pmap_enter_quick().  This
is relevant for all PowerPC pmap variants, because mmu_*_enter() is
used as the backend, and assert is located there.

Add a PowerPC private pmap_enter() PMAP_ENTER_QUICK_LOCKED flag to
indicate that the call is not from pmap_enter().  For non-quick-locked
calls, assert that the object is locked.

Reported and tested by:	bdragon
Reviewed by:	alc, bdragon, markj
Sponsored by:	The FreeBSD Foundation
Differential revision:	https://reviews.freebsd.org/D22041
2019-10-16 07:09:15 +00:00
avg
8db35e8374 MFV r353619: 9691 fat zap should prefetch when iterating
illumos/illumos-gate@52abb70e07
52abb70e07

https://www.illumos.org/issues/9691
  When iterating over a ZAP object, we're almost always certain to
  iterate over the entire object. If there are multiple leaf blocks, we
  can realize a performance win by issuing reads for all the leaf blocks
  in parallel when the iteration begins.
  For example, if we have 10,000 snapshots, "zfs destroy -nv
  pool/fs@1%9999" can take 30 minutes when the cache is cold. This
  change provides a >3x performance improvement, by issuing the reads
  for all ~64 blocks of each ZAP object in parallel.

Author: Matthew Ahrens <mahrens@delphix.com>
Obtained from:	illumos
MFC after:	2 weeks
2019-10-16 07:09:00 +00:00
avg
b5daec7303 MFV r353617: 9425 allow channel programs to be stopped via signals
illumos/illumos-gate@d0cb1fb926
d0cb1fb926

https://www.illumos.org/issues/9425
  Problem Statement
  ZFS Channel program scripts currently require a timeout, so that hung
  or long-running scripts return a timeout error instead of causing ZFS
  to get wedged.  This limit can currently be set up to 100 million Lua
  instructions. Even with a limit in place, it would be desirable to
  have a sys admin (support engineer) be able to cancel a script that is
  taking a long time.

  Proposed Solution
  Make it possible to abort a channel program by sending an interrupt
  signal.In the underlying txg_wait_sync function, switch the cv_wait to
  a cv_wait_sig to catch the signal. Once a signal is encountered, the
  dsl_sync_task function can install a Lua hook that will get called
  before the Lua interpreter executes a new line of code. The
  dsl_sync_task can resume with a standard txg_wait_sync call and wait
  for the txg to complete. Meanwhile, the hook will abort the script and
  indicate that the channel program was canceled. The kernel returns a
  EINTR to indicate that the channel program run was canceled.

FreeBSD note: the return value of cv_wait_sig() has inverted meaning
between us and illumos.

Author: Don Brady <don.brady@delphix.com>
Obtained from:	illumos
MFC after:	4 weeks
2019-10-16 07:00:18 +00:00
avg
935d5ee530 MFV r353615: 9485 Optimize possible split block search space
illumos/illumos-gate@a21fe34979
a21fe34979

https://www.illumos.org/issues/9485
  Port this commit from ZoL:
  4589f3ae4c

Author: Brian Behlendorf <behlendorf1@llnl.gov>
Obtained from:	illumos, ZoL
MFC after:	3 weeks
2019-10-16 06:43:22 +00:00
avg
18f0d2ac42 MFV r353613: 10731 zfs: NULL pointer errors
FreeBSD already had these changes locally.
This commit removes a small formatting difference.

MFC after:	1 week
2019-10-16 06:38:05 +00:00
avg
e7993b34fd MFC r353611: 10330 merge recent ZoL vdev and metaslab changes
illumos/illumos-gate@a0b03b161c
a0b03b161c

https://www.illumos.org/issues/10330
  3 recent ZoL changes in the vdev and metaslab code which we can pull over:
  PR 8324 c853f382db 8324 Change target size of metaslabs from 256GB to 16GB
  PR 8290 b194fab0fb 8290 Factor metaslab_load_wait() in metaslab_load()
  PR 8286 419ba59145 8286 Update vdev_is_spacemap_addressable() for new spacemap
  encoding

Author: Serapheim Dimitropoulos <serapheimd@gmail.com>
Obtained from:	illumos, ZoL
MFC after:	2 weeks
2019-10-16 06:26:51 +00:00
avg
3f51508cfe MFV r353608: 10165 libzpool: passing argument 1 to restrict-qualified parameter
illumos/illumos-gate@f91fcf59ac
f91fcf59ac

https://www.illumos.org/issues/10165

Author: Toomas Soome <tsoome@me.com>
MFC after:	10 days
2019-10-16 06:09:00 +00:00
avg
9c1ef2e58d MFV r353606: 10067 Miscellaneous man page typos
https://www.illumos.org/issues/10067
  fileystem - man1m/zfs.1m man1m/boot.1m

Author: Peter Tribble <peter.tribble@gmail.com>
Obtained from:	illumos
MFC after:	1 week
2019-10-16 06:05:18 +00:00
jhibbits
1537de8003 powerpc/mpc85xx: Fix function type for fsl_pcib_error_intr()
Since it's only called as an interrupt handler, fsl_pcib_eror_intr() should just
match the driver_intr_t type.

Reported by:	bdragon
2019-10-16 03:03:59 +00:00
jhibbits
cf6db46977 powerpc: Add AmigaOne platform, a subclass of MPC85xx
Summary:
The AmigaOne platform, encompassing the X5000 and A1222 at this time, is
based on the mpc85xx platform, but includes some things not listed in
the device tree.  Some custom devices, like CPLD, could be added to the
device tree with an overlay, or other means.  However, some cannot
easily be done, such as the power button interrupt.

The directory will also become a location to add AmigaOne platform drivers,
such as the aforementioned CPLD, and its children.

Reviewed by:	bdragon
Differential Revision:	https://reviews.freebsd.org/D21829
2019-10-16 00:38:50 +00:00
brooks
42d4179cbe Fix including bsd.compat.mk outside Makefile.libcompat on mips64.
Reported by:	jhb, jenkins
2019-10-15 23:54:51 +00:00
kp
038f82f772 Generalize ARM specific comments in devmap
The comments in devmap are very ARM specific, this generalizes them for other
architectures.

Submitted by:	Nicholas O'Brien <nickisobrien_gmail.com>
Reviewed by:	manu, philip
Sponsored by:	Axiado
Differential Revision:	https://reviews.freebsd.org/D22035
2019-10-15 23:21:52 +00:00
erj
31482d73c4 ixgbe: Disable EEE for backplane X550EM_X
From Zach:
Intel documentation indicates that backplane X550EM_X KR devices do not
support Energy Efficient Ethernet. Prior to this patch, X552 devices
(device ID 0x15AB) will crash the system when transitioning EEE state
via sysctl.

Signed-off-by: Zach Vargas <zvargas@xes-inc.com>

PR:		240320
Submitted by:	Zach Vargas <zvargas@xes-inc.com>
Reviewed by:	erj@
MFC after:	3 days
Differential Revision:	https://reviews.freebsd.org/D21673
2019-10-15 21:56:19 +00:00
glebius
9101a0b1d1 Missing from r353596. 2019-10-15 21:32:38 +00:00
brooks
c55688dac7 Add the ability to link programs against a compat ABI.
Linkage is controlled by two make knobs:
	WANT_COMPAT - Prefer to link against the compat ABI.
	NEED_COMPAT - Link against the compat ABI or fail to build.

Supported values are "32", "soft", and "any".  The latter meaning pick
the first[0] supported compat ABI.

This can be used to provide test binaries for compat ABIs or to link
ABI-specific programs.

[0] We currently support only one compat ABI at a time, but this may
change in the future and some code in this commit is structured to ease
that change.

Reviewed by:	bdrewery, jhb
Obtained from:	CheriBSD (in concept)
Sponsored by:	DARPA, AFRL
Differential Revision:	https://reviews.freebsd.org/D22023
2019-10-15 21:27:06 +00:00
glebius
072472d2fc When assertion for a thread not being in an epoch fails also print all
entered epochs. Works with EPOCH_TRACE only.

Reviewed by:	hselasky
Differential Revision:	https://reviews.freebsd.org/D22017
2019-10-15 21:24:25 +00:00
brooks
99568ae41e Build compat libraries before "everything".
This is required for us to link programs against compat versions of
libraries.

Reviewed by:	bdrewery, jhb
Sponsored by:	DARPA, AFRL
2019-10-15 21:22:13 +00:00