r353661 erj Oct. 16, 2019, 6:12 p.m.
"adapter" doesn't exist in ixl.

Reported by:	O. Hartmann <ohartmann@walstatt.org>
ViewVC
r353659 brooks Oct. 16, 2019, 5:21 p.m.
Reported by:	glebius
ViewVC
r353658 erj Oct. 16, 2019, 5:19 p.m.
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
ViewVC
r353657 erj Oct. 16, 2019, 5:16 p.m.
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
ViewVC
r353656 erj Oct. 16, 2019, 5:13 p.m.
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
ViewVC
r353655 dim Oct. 16, 2019, 5:11 p.m.
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
ViewVC
r353654 glebius Oct. 16, 2019, 4:32 p.m.
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
ViewVC
r353653 ian Oct. 16, 2019, 4:26 p.m.
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.
ViewVC
r353652 ian Oct. 16, 2019, 4:19 p.m.
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
ViewVC
r353651 ian Oct. 16, 2019, 4:03 p.m.
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
ViewVC
r353650 markj Oct. 16, 2019, 3:50 p.m.
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
ViewVC
r353649 avg Oct. 16, 2019, 3:21 p.m.
MFC after:	3 days
ViewVC
r353648 avg Oct. 16, 2019, 3:01 p.m.
MFC after:	19 days
X-MFC with:	r353647
ViewVC
r353647 avg Oct. 16, 2019, 2:57 p.m.
The chips are commonly named with "IT" prefix.

MFC after:	19 days
ViewVC
r353646 kevans Oct. 16, 2019, 2:55 p.m.
-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.
ViewVC