| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
should be killed or not.
This fixes killing pdfork(2)ed process on last close of the corresponding
process descriptor.
Reviewed by: rwatson
MFC after: 1 month
|
|
|
|
|
|
|
|
|
|
|
|
| |
On success we have to drop one after procdesc_finit() and on failure
we have to close allocated slot with fdclose(), which also drops one
reference for us and drop the remaining reference with fdrop().
Without this change closing process descriptor didn't result in killing
pdfork(2)ed child.
Reviewed by: rwatson
MFC after: 1 month
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, extend the changes in r230782 to better handle the common case
of using NOREUSE with sequential reads. A NOREUSE file descriptor
will now track the last implicit DONTNEED request it made as a result
of a NOREUSE read. If a subsequent NOREUSE read is adjacent to the
previous range, it will apply the DONTNEED request to the entire range
of both the previous read and the current read. The effect is that
each read of a file accessed sequentially will apply the DONTNEED
request to the entire range that has been read. This allows NOREUSE
to properly handle misaligned reads by flushing each buffer to cache
once it has been completely read.
Second, apply the same changes made to read(2) by r230782 and this
change to writes. This provides much better performance in the
sequential write case as it allows writes to still be clustered. It
also provides much better performance for misaligned writes. It does
mean that NOREUSE will be generally ineffective for non-sequential
writes as the current implementation relies on a future NOREUSE
write's implicit DONTNEED request to flush the dirty buffer from the
current write.
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Setting strict causes a validation of the requested
value vs the value currently running after a frequency
change is requested.
Change applicability to be single core not i386.
Thanks to mav@ for reviewing and commenting on my
lack of understanding.
MFC after: 2 weeks
|
|
|
|
|
|
|
| |
pcib_grow_window(). This makes the code slightly easier to read and
prevents the type of bug fixed in r237271.
MFC after: 3 days
|
|
|
|
|
| |
address is properly aligned. While here, use a simpler expression to
align the new end address that we use elsewhere for aligning the end.
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
| |
for example)
get the username information from old_pw structures to still allow renaming of a
user.
Reported by: Claude Buisson <clbuisson@orange.fr>
Approved by: des (mentor)
MFC after: 3 weeks
|
|
|
|
|
|
|
| |
pv_entry_count is purely informational. It does not serve any functional
purpose.
Add PV chunk locking to get_pv_entry().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Stateful TCP offload drivers for Terminator 3 and 4 (T3 and T4) ASICs.
These are available as t3_tom and t4_tom modules that augment cxgb(4)
and cxgbe(4) respectively. The cxgb/cxgbe drivers continue to work as
usual with or without these extra features.
- iWARP driver for Terminator 3 ASIC (kernel verbs). T4 iWARP in the
works and will follow soon.
Build-tested with make universe.
30s overview
============
What interfaces support TCP offload? Look for TOE4 and/or TOE6 in the
capabilities of an interface:
# ifconfig -m | grep TOE
Enable/disable TCP offload on an interface (just like any other ifnet
capability):
# ifconfig cxgbe0 toe
# ifconfig cxgbe0 -toe
Which connections are offloaded? Look for toe4 and/or toe6 in the
output of netstat and sockstat:
# netstat -np tcp | grep toe
# sockstat -46c | grep toe
Reviewed by: bz, gnn
Sponsored by: Chelsio communications.
MFC after: ~3 months (after 9.1, and after ensuring MFC is feasible)
|
|
|
|
|
|
|
| |
with WARNS=6 on base gcc, gcc46, and clang
Approved by: cperciva
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
PR: bin/167302
Submitted by: markham breitbach <markham@ssimicro.com>
Discussed with: pjd (briefly)
Approved by: cperciva
MFC after: 1 week
|
|
|
|
|
|
|
| |
gcc46 warning
Approved by: cperciva
MFC After: 3 days
|
|
|
|
|
|
|
| |
gcc46 warning
Approved by: cperciva
MFC After: 3 days
|
|
|
|
|
|
|
| |
gcc46 warning
Approved by: cperciva
MFC After: 3 days
|
|
|
|
|
|
|
| |
gcc46 warning
Approved by: cperciva
MFC After: 3 days
|
|
|
|
|
|
|
| |
gcc46 warning
Approved by: cperciva
MFC After: 3 days
|
|
|
|
|
|
|
| |
gcc46 warning
Approved by: cperciva
MFC After: 3 days
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of cpufreq(4) via a new man page est(4)
Document the two exposed tuneables of est(4).
I'd appreciate more reviews of content if possible. I gleaned
the information contained herein from sys/x86/cpufreq/est.c and
the Intel reference documentation
Reviewed by: wblock hrs gjb
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
written, but not msync'd by a process. A VOP_PUTPAGES()
called when VOP_RECLAIM() happens will usually fail, since
the NFSv4 Open has already been closed by VOP_INACTIVE().
Add a vm_object_page_clean() call to the NFSv4 client's
VOP_INACTIVE(), so that the write happens before the NFSv4
Open is closed. kib@ suggested using vgone() instead and
I will explore this, but this patch fixes things in the
meantime. For some reason, the VOP_PUTPAGES() is still
attaempted in VOP_RECLAIM(), but having this fail doesn't
cause any problems except a "stateid0 in write" being logged.
Reviewed by: kib
MFC after: 1 week
|
|
|
|
|
|
|
|
|
| |
performing the return to usermode using full return path. This
consolidates the handling of exceptional situations in less number of
places, and is less code as well.
Reviewed by: jhb
MFC after: 1 week
|
|
|
|
|
| |
the underlying problem was dealt with in r237239 (in fact, disabling
verification also actually only made the problem less likely to occur).
|
|
|
|
|
|
|
|
|
|
|
|
| |
for TX transfer completion as for reasons unknown this occasionally
causes SPI_SR_RXBUFF and SPI_SR_ENDRX to not rise.
In any case, once the RX part of the transfer is done it's obvious
that the preceding TX part had finished and checking of SPI_SR_TXEMPTY
was introduced to rule out a possible cause for the data corruption
mentioned in r236495 but which didn't turn out to be the problem
anyway.
MFC after: 3 days
|
| |
|
| |
|
|
|
|
|
|
|
| |
- Anounce JTAG interfaces deliberately skipped.
- Bring back empty lines too eagerly removed.
MFC after: 3 days
|
|
|
|
|
|
| |
ataahci(4) and atanvidia(4).
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
| |
pmap_page_is_mapped(), and pmap_remove_pages(). These functions
are no longer serialized by the pvh global lock.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and configurable on per-interface basis.
Remove __inline__ for several functions being called once per
flow (e.g once per 10-20 packets on common traffic flows).
Update manual page to simplify search for BPF data link types.
Sponsored by Yandex LLC
Reviewed by: glebius
Approved by: ae(mentor)
MFC after: 2 weeks
|
|
|
|
|
|
| |
Reviewed by: glebius (previous version)
Approved by: ae(mentor)
MFC after: 2 weeks
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
|
|
| |
twice as much.
Spotted by: Taku YAMAMOTO
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dev = make_dev_cred();
dev->si_drv1 = tp;
leaves a small window where the newly created device may be opened
and si_drv1 is NULL.
As this is a vary rare situation, using a lock to close the window
seems overkill. Instead just wait for the assignment of si_drv1.
Suggested by: kib
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bitmaps that may occur.
The way this works is:
* the beginning of the radiotap frame has a 32 bit "radiotap" namespace
bitmap;
* if the vendor bitmap bit is set, then the next bitmap will be interpreted
as a vendor bitmap;
* this can keep going on and on (ie, more vendor and radiotap namespace
bitmaps can be added) until the last bitmap with no "more bitmaps" set.
Now, the radiotap code gets its grubby fingers into the supplied
radiotap rx/tx buffer and replaces the channel configuration
for each frame. I don't know why it's not up to the drivers themselves
to do this, but I digress. So, if a vendor bitmap (or two, etc) exists,
the offset calculations will be all completely wrong.
This particular patch introduces ieee80211_radiotap_attachv(), which
includes the number of vendor bitmaps (well, any other bitmaps, vendor
or otherwise) between the end of the bitmap/header and the start of the
actual radiotap field entries. This makes the radiotap calculations
"right", so it correctly calculates where to overwrite the channel
configuration.
The long term fix is to go through and make each driver update the channel
configuration, as some of the fields are already being updated.
That, however, is a longer term fix that will need each driver fixed.
I leave that as an exercise to someone in the future.
|
|
|
|
|
|
|
| |
website.
Sponsored by: Spectralogic
MFC after: 1 week
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and crosschecks against firmware documentation. We now check and report
FC firmware attributes and at least are now prepared for the upper 48 bits
of f/w attributes (which are probably for the 8100 or later cards). This
involed changing how inbits and outbits are calculated for varios commands,
hopefully clearer and cleaner. This also caused me to clean up the actual
mailbox register usage. Finally, we are now unconditionally using a CRN
for initiator mode.
A longstanding issue with the 2400/2500 is that they do *not* support
a "Prefer PTP followed by loop", which explains why enabling that
caused the f/w to crash.
A slightly more invasive change is to let the firmware load entirely
drive whether multi_id support is enabled or not.
Sponsored by: Spectralogic
MFC after: 1 week
|
|
|
|
|
|
|
| |
can do when such a race occurs). This saves lock/unlock cycle for the filedesc
lock for every advisory unlock operation.
MFC after: 1 month
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
D2500CC which I have, syscons in text-mode fails to show the expected
contents due to write errors into video-memory.
At least one of the causes is that we copy from syscons internal buffer
to the video memory with optimized bcopy(9) which uses >16bit operations.
Until now, 32bit and wider operations have always worked on the video
memory, but since I cannot find a single source which says that this
SHALL work, and since these chipsets/bugs are now out there, this
commit changes syscons to always use 16bit copies on i386 & amd64.
This may be relevevant for PR's:
166262
166639
and various other bug reports floating elsewhere on the net, but
I lack hardware to test those.
|
|
|
|
|
|
|
|
| |
to below the vnode_destroy_vobject() call, since that is where
writes are flushed.
Suggested by: kib
MFC after: 1 week
|
|
|
|
|
|
|
| |
it is done and why we don't return an error in such case.
Discussed with: kib
MFC after: 1 month
|
|
|
|
|
|
|
| |
close, because even if we had a race there is nothing to unlock.
Discussed with: kib
MFC after: 1 month
|
|
|
|
| |
MFC after: 3 days
|