| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
- Remove OpenBSDisms, add FreeBSDisms.
|
|
|
|
|
|
|
| |
- Let panic() use _Noreturn and __printflike() instead of GCC-specific
attributes.
- Remove prototype from ffs_subr.c and let it include ffs_extern.h.
- Forward declare struct inode to make ffs_extern.h not depend on it.
|
|
|
|
| |
- Cover setting up interface between pf and pfsync with PF_LOCK().
|
|
|
|
|
| |
Sponsored by: iXsystems, Inc.
MFC after: 1 month
|
|
|
|
|
|
| |
Submitted by: Sergey Matveychuk <sem33@yandex-team.ru>
Approved by: ae (mentor)
MFC after: 2 weeks
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
print changes.
* Right now the delay is hard coded at 10uS. This is a bit long when doing lots
of periodic i2c transactions. So create a 'udelay' parameter and initialise it
to 10. This can be tuned later.
* Add a newline after a transaction finishes, so the debugging output isn't so
horrible.
|
| |
|
|
|
|
|
|
|
|
| |
- make analog input loopback work;
- get access to the mics boost controls.
Sponsored by: iXsystems, Inc.
MFC after: 1 month
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
performance issues.
* Access to the GPIO bus is already locked by requesting
and releasing the bus - thus the lock isn't really needed
for each GPIO pin change.
* Don't lock and unlock the GPIO bus for -each- i2c access -
the i2c bus code is already doing this by calling the upper
layer callback to request/release the bus. This thus locks
the bus for the entirety of the transaction.
TODO:
* Further verify that everything is correctly requesting/
releasing the GPIO bus.
* Look at how to lock the GPIO pin configuration stuff,
potentially by locking/unlocking the bus at the gpiobus
layer.
|
| |
|
|
|
|
|
| |
Suggested by: avg @
MFC after: 3 days
|
|
|
|
|
|
|
| |
to int, cast time_t to intmax_t, and use the corresponding printf length
modifier.
MFC after: 1 week
|
|
|
|
|
|
| |
not being literals.
MFC after: 1 week
|
|
|
|
|
| |
Pointy hat to: dim
MFC after: 1 week
|
|
|
|
|
|
|
| |
64-bit, so better cast time_t to intmax_t, and use the appropriate
printf format strings.
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the previous code, if the range of priorities for timeshare batch
threads was greater than RQ_NQS, then the threads with low priorities in
the part of the range above RQ_NQS would be scheduled to the run-queues
as if they had high priorities at the beginning of the range.
In other words, threads with a nice level of +N could be scheduled as
if they had a nice level of -M.
Reported by: George Mitchell <george@m5p.com>
Reviewed by: jhb
Tested by: George Mitchell <george@m5p.com> (earlier version)
MFC after: 1 week
|
|
|
|
| |
100us is not enough to ensure prefetch unit work.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the TCP header size calculation such that makes TSO engine
cache all header(ethernet/IP/TCP) bytes to its internal buffer.
While here, remove extra pull up for TCP payload. Unlike some
em(4) controllers, fxp(4) does not require such work around for
TSO.
The two limitations are ethernet/IP/TCP header size should be less
than or equal to the size of controller's internal buffer(80 bytes)
and these header information should be found in the first fragment
of a TSO frame.
|
|
|
|
|
|
|
| |
initialize a task structure.
Reviewed by: gj
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
| |
- Cast time_t's to long, and print them with %ld.
- Print ptrdiff_t's with %td.
- Print ssize_t's and size_t's with %zd and %zu.
- Print int32_t's with %d.
Also, replace some int variables with the more appropriate size_t.
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
against icmp6_hdr::icmp6_type is done incorrectly. (This fix has
already been applied upstream, but we do not have the latest version of
tcpdump.)
MFC after: 1 week
|
|
|
|
|
|
|
| |
warnings in sbin/hastd/lzf.c are only emitted for i386 and amd64, and
there they can be safely ignored.
MFC after: 1 week
|
|
|
|
|
|
| |
Add sysctl which can be used to skip this waiting.
MFC after: 3 days
|
|
|
|
|
|
|
| |
... instead of just a verbatim format string.
Reviewed by: pjd
MFC after: 1 week
|
|
|
|
|
|
|
| |
doing shutdown, suspend and resume.
Suggested by: avg @
MFC after: 3 days
|
|
|
|
|
|
|
| |
warnings.
Spotted by: arundel
MFC after: 1 week
|
|
|
|
|
|
|
| |
turned off yet. Since this is contrib code, and we don't really care
about the warnings, just turn make them non-fatal for now.
MFC after: 1 week
|
|
|
|
| |
Requested by: netchild, bz
|
|
|
|
| |
if the else belongs to.
|
|
|
|
|
|
|
|
|
| |
o Teach netstat(1) -z to reset these stats sysctls.
PR: bin/153206
Reviewed by: glebuis
Sponsored by: NGINX, Inc.
MFC after: 1 month
|
| |
|
|
|
|
| |
Pointy hat to: bapt
|
|
|
|
|
|
|
|
| |
thought the -g (mimic gnu) option
Reviewed by: cognet
Approved by: cognet
Discussed with: espie@OpenBSD.org (upstream)
|
|
|
|
|
| |
Inspired by: r228555
MFC after: 1 week
|
|
|
|
|
| |
Detected by: clang
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
of the rx_ring to bus_dmamap_sync(9). Given that netmap code tries to
obtain the bus addresses of netmap buffers via vtophys(9) instead of using
bus_dma(9) it currently has zero chance of actually working on sparc64
though (and for that matter f.e. also not with MACs limited to 32-bit DMA
on x86 machines with more than 4GB of RAM).
|
|
|
|
| |
MFC after: 1 week
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| | |
pam_end() already contains a NULL check, and it is not unreasonable to
call it with a NULL pamh in a cleanup / error-handling situation. Remove
OPENPAM_NONNULL, which may cause gcc to optimize away the NULL check.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Submitted by: geoffrey dot levand at mail dot ru
MFC after: 1 week
|
| | |
|
| |
| |
| |
| | |
Reviewed by: kib
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
(ss == NULL) on pool import. I had such a panic recently. With current version
of ZFS it is still possible to import the pool in readonly mode and backup
all the data, but in case it is impossible for some reason add tunable
vfs.zfs.space_map_last_hope, which when set to '1' will tell ZFS to remove
colliding range and retry. This seems to have worked for me, but I consider
it highly risky to use.
MFC after: 1 week
|
| |
| |
| |
| |
| |
| | |
if the 'sync' property is set to 'always', so replying them is not common.
MFC after: 1 month
|
| |
| |
| |
| | |
MFC after: 1 week
|