committer filter by committer.
@path/to/ filter by path in repository.
committer@path/to/ filter by committer AND path in repository.
NNN or rNNN filter by revision.
NNN-MMM or rNNN-rMMM filter by revisions range (inclusive).
Multiple filters can be specified separated by spaces or comas in which case they'll be combined using OR operator.
|r353661||erj||Oct. 16, 2019, 6:12 p.m.||Fix compile error introduced in r353658|
|r353659||brooks||Oct. 16, 2019, 5:21 p.m.||Install bsd.compat.mk.
Reported by: glebiusViewVC
|r353658||erj||Oct. 16, 2019, 5:19 p.m.||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 <email@example.com> Submitted by: Jacob Keller <firstname.lastname@example.org> Reviewed by: gallatin@ Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D21870ViewVC
|r353657||erj||Oct. 16, 2019, 5:16 p.m.||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 <email@example.com> Submitted by: Jacob Keller <firstname.lastname@example.org> Reviewed by: gallatin@ Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D21869ViewVC
|r353656||erj||Oct. 16, 2019, 5:13 p.m.||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 <email@example.com> Submitted by: Jacob Keller <firstname.lastname@example.org> Reviewed by: gallatin@ Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D21868ViewVC
|r353655||dim||Oct. 16, 2019, 5:11 p.m.||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 <email@example.com> PR: 241257 MFC after: 3 daysViewVC
|r353654||glebius||Oct. 16, 2019, 4:32 p.m.||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: hselaskyViewVC
|r353653||ian||Oct. 16, 2019, 4:26 p.m.||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.ViewVC
|r353652||ian||Oct. 16, 2019, 4:19 p.m.||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: manuViewVC
|r353651||ian||Oct. 16, 2019, 4:03 p.m.||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: 241301ViewVC
|r353650||markj||Oct. 16, 2019, 3:50 p.m.||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/D22044ViewVC
|r353649||avg||Oct. 16, 2019, 3:21 p.m.||fix section number in zfs-program.8
MFC after: 3 daysViewVC
|r353648||avg||Oct. 16, 2019, 3:01 p.m.||attach itwd to the module build on x86
MFC after: 19 days X-MFC with: r353647ViewVC
|r353647||avg||Oct. 16, 2019, 2:57 p.m.||itwd(4): driver for watchdog function in ITE Super I/O chips
The chips are commonly named with "IT" prefix. MFC after: 19 daysViewVC
|r353646||kevans||Oct. 16, 2019, 2:55 p.m.||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.ViewVC