committer filter by committer.
@path/to/ filter by path in repository.
committer@path/to/ filter by committer AND path in repository.
abdef0123 filter by commit's SHA hash.
rNNN filter by SVN revision.
rNNN-rMMM filter by SVN revisions range (inclusive).
Multiple filters can be specified separated by spaces or comas in which case they'll be combined using OR operator.
6aee0bfa | zec | June 19, 2019, 8:39 a.m. | Evaluating htons() at compile time is more efficient than doing ntohs() | |
da761f3b | scottl | June 19, 2019, 6:41 a.m. | Implement VT-d capability detection on chipsets that have multiple
translation units with differing capabilities From the author via Bugzilla: --- When an attempt is made to passthrough a PCI device to a bhyve VM (causing initialisation of IOMMU) on certain Intel chipsets using VT-d the PCI bus stops working entirely. This issue occurs on the E3-1275 v5 processor on C236 chipset and has also been encountered by others on the forums with different hardware in the Skylake series. The chipset has two VT-d translation units. The issue is caused by an attempt to use the VT-d device-IOTLB capability that is supported by only the first unit for devices attached to the second unit which lacks that capability. Only the capabilities of the first unit are checked and are assumed to be the same for all units. Attached is a patch to rectify this issue by determining which unit is responsible for the device being added to a domain and then checking that unit's device-IOTLB capability. In addition to this a few fixes have been made to other instances where the first unit's capabilities are assumed for all units for domains they share. In these cases a mutual set of capabilities is determined. The patch should hopefully fix any bugs for current/future hardware with multiple translation units supporting different capabilities. A description is on the forums at https://forums.freebsd.org/threads/pci-passthrough-bhyve-usb-xhci.65235 The thread includes observations by other users of the bug occurring, and description as well as confirmation of the fix. I'd also like to thank Ordoban for their help. --- Personally tested on a Skylake laptop, Skylake Xeon server, and a Xeon-D-1541, passing through XHCI and NVMe functions. Passthru is hit-or-miss to the point of being unusable without this patch. PR: 229852 Submitted by: callum@aitchison.org MFC after: 1 weekcgit ViewVC |
|
0b3c5f1b | alc | June 19, 2019, 3:33 a.m. | Correct an error in r349122. pmap_unwire() should update the pmap's wired | |
46dea205 | bdrewery | June 18, 2019, 10 p.m. | Rework r349061: Don't apply guessed dependencies if there is a custom target.
This is still targeting bin/sh cyclic dependency issues. Only apply guessed dependencies that are explicitly set for an object (which gnu/lib/cc/cc_tools needs) and if no custom target exists with its own dependencies. This was manifesting as a missing yacc.h in usr.bin/mkesdb_static when built without -j (or -B). No actual yacc.h dependency ordering was defined but with -j it got lucky and built fine. Before r349061 the behavior was different for META_MODE but that logic difference isn't needed. X-MFC-With: r349061 Sponsored by: DellEMCcgit ViewVC |
|
5c32e9fc | mav | June 18, 2019, 9:05 p.m. | Optimize kern.geom.conf* sysctls.
On large systems those sysctls may generate megabytes of output. Before this change sbuf(9) code was resizing buffer by 4KB each time many times, generating tons of TLB shootdowns. Unfortunately in this case existing sbuf_new_for_sysctl() mechanism, supposed to help with this issue, is not applicable, since all the sbuf writes are done in different kernel thread. This change improves situation in two ways: - on first sysctl call, not providing any output buffer, it sets special sbuf drain function, just counting the data and so not needing big buffer; - on second sysctl call it uses as initial buffer size value saved on previous call, so that in most cases there will be no reallocation, unless GEOM topology changed significantly. MFC after: 1 week Sponsored by: iXsystems, Inc.cgit ViewVC |
|
cfdcc8c7 | sevan | June 18, 2019, 9:02 p.m. | Mark NetBSD branch points | |
22eedc97 | cem | June 18, 2019, 6:50 p.m. | random(4): Fix a regression in short AES mode reads
In r349154, random device reads of size < 16 bytes (AES block size) were accidentally broken to loop forever. Correct the loop condition for small reads. Reported by: pho Reviewed by: delphij Approved by: secteam(delphij) Differential Revision: https://reviews.freebsd.org/D20686cgit ViewVC |
|
5c2b348a | vmaffione | June 18, 2019, 5:51 p.m. | bhyve: vtnet: fix locking on receive
The vsc_rx_ready and the RX virtqueue is protected by the rx_mtx lock. However, pci_vtnet_ping_rxq() (currently called only once after each device reset) accesses those without acquiring the lock. Reviewed by: markj MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D20609cgit ViewVC |
|
edd96b9f | ian | June 18, 2019, 5:05 p.m. | Handle labels specified with hints even on FDT systems. Hints are the | |
05918954 | emaste | June 18, 2019, 2:13 p.m. | Remove sys/capability.h for the third time
In all supported (and most unsupported) FreeBSD versions the appropriate header for Capsicum is sys/capsicum.h. Software including sys/capability.h is most likely looking for Linux capabilities based on the withdrawn POSIX.1e draft. This header was previously removed in r334929 and r340156, but reverted each time due to ports failures. These issues have now (broadly) been addressed. PR: 228878 [exp-run] Submitted by: eadler (r334929) Relnotes: Yes Sponsored by: The FreeBSD Foundationcgit ViewVC |
|
a161bab8 | ian | June 18, 2019, 4:32 a.m. | Add a pwmc(4) manpage. | |
0309916a | ian | June 18, 2019, 2:27 a.m. | Oops, it seems I left out the word 'cycle', fix it. | |
26f3ca61 | ian | June 18, 2019, 1:15 a.m. | Rearrange the argument checking and processing so that enable and disable | |
123570fb | ian | June 18, 2019, 12:17 a.m. | Explain the relationship between PWM hardware channels being controlled and | |
780c3de8 | ian | June 18, 2019, 12:11 a.m. | Remove everything related to channels from the pwmc public interface, now |