This gets rid of the per-cpu SWIs.
Submitted by: Jun Su <junsu microsoft com>
Reviewed by: Dexuan Cui <decui microsoft com>, sephe
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D5215
Using the same message slot as the other types of the messages has
the side effect that the event timer message could be deferred to
the swi threads to run (lacking of trapframe and the original code
didn't even handle that, so the event timer was actually broken).
As of this commit we use an independent message slot for event timer,
so that we could handle all of event timer messages in the interrupt
handler directly. Note, the message slot for event timer is still
bind to the same interrupt vector as the other types of messages.
Submitted by: Jun Su <junsu microsoft com>
Reviewed by: sephe
Discussed with: Jun Su <junsu microsoft com>, Dexuan Cui <decui microsoft com>
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D5696
This is a pretty good reference for teaching an almost-11n-capable
driver about 11n.
It enables HT20 operation, A-MPDU/A-MSDU RX, but no aggregate support
for transmit. That'll come later. This means that receive throughput
should be higher, but transmit throughput won't have changed much.
* Disable bgscan - for now, bgscan will interfere with AMPDU TX/RX,
so until we correctly handle it in software driven scans, disable.
* Add null 11n methods for channel width / ampdu_enable.
the firmware can apparently handle ampdu tx (and hopefully block-ack
handling and retransmission) so I'll go review the linux code and
figure it out.
* Set the number of tx/rx streams. I /hope/ that nchains == nstreams
here.
* Add 11n channels in the call to ieee80211_init_channels().
* Don't enable HT40 for now - I'll have to verify the channel set command
and tidy it up a bit first.
* Teach the RX path about M_AMPDU for 11n nodes. Kinda wonder why
we aren't just doing this in net80211 already, this is the fourth
driver I've had to do this to.
* Teach rate2ridx() about MCS rates and what hardware rates to use.
* Teach the urtwn_tx_data() routine about MCS/11ng transmission.
It doesn't know about short-gi and 40MHz modes yet; that'll come
later.
* For 8192CU firmware, teach the rate table code about MCS rates.
* Ensure that the fixed rate transmit sets the right transmit flag
so the firmware obeys the driver transmit path.
* Set the default transmit rate to MCS4 if no rate control is available.
* Add HT protection (RTS-CTS exchange) support.
* Add appropriate XXX TODO entries.
TODO:
* 40MHz, short-gi, etc - channel tuning, TX, RX;
* teach urtwn_tx_raw() about (more) 11n stuff;
* A-MPDU TX would be nice!
Thanks to Andriy (avos@) for reviewing the code and testing it on IRC.
Tested:
* RTL8188EU - STA (me)
* RTL8192CU - STA (me)
* RTL8188EU - hostap (avos)
* RTL8192CU - STA (avos)
Reviewed by: avos
- Replace sc_reinittask() by ieee80211_restart_all() (mostly the same).
- Revert r282377 (seems to be unneeded now).
Tested with Intel 3945BG, STA mode.
Differential Revision: https://reviews.freebsd.org/D5056
First, update the return types of aio_return() and aio_waitcomplete() to
ssize_t.
POSIX requires aio_return() to return a ssize_t so that it can represent
all return values from read() and write(). aio_waitcomplete() should use
ssize_t for the same reason.
aio_return() has used ssize_t in <aio.h> since r31620 but the manpage and
system call entry were not updated. aio_waitcomplete() has always
returned int.
Note that this does not require new system call stubs as this is
effectively only an API change in how the compiler interprets the return
value.
Second, allow aio_nbytes values up to IOSIZE_MAX instead of just INT_MAX.
aio_read/write should now honor the same length limits as normal read/write.
Third, use longs instead of ints in the aio_return() and aio_waitcomplete()
system call functions so that the 64-bit size_t in the in-kernel aiocb
isn't truncated to 32-bits before being copied out to userland or
being returned.
Finally, a simple test has been added to verify the bounds checking on the
maximum read size from a file.
None of lstat(2), fstat(2), fstatat(2) were tracked either.
The other filemon implementations also do not track stat(2), nor
does bmake utilize it. The act of opening a file for read should
be enough to decide that a file is a dependency. There could be
rare cases where just having a file would cause a dependency but it
is unlikely.
MFC after: 2 weeks
Also noted by: sjg
Sponsored by: EMC / Isilon Storage Division
- proc.p_filemon is added which is protected by PROC_LOCK. This improves
performance and avoids double-fork issues, taking allproc_lock
while in syscalls, and walking the process tree in syscalls. A
particular proc.p_filemon can only be changed to NULL or another
filemon, or the filemon inherited, while the filemon->lock is held.
- Filemon are reference counted. On the last reference the log will be closed.
- When closing the devfs file handle, the filemon will be detached from all
processes and inheritance prevented.
- Disallow attaching to a process already being traced since filemon is
typically intended to be used on children only. This is allowed for
curproc as bmake relies on this behavior for rare cases when combining
.MAKE with .META.
- Detach any previously tracked process on ioctl(FILEMON_SET_PID).
- Handle error from devfs_set_cdevpriv() in filemon_open().
- The global filemon lock and lists are removed.
- A free list is no longer kept. Previously this list was
forever-expanding and never garbage cleaned.
- No longer loses track of double-forks. If the process holding the filemon
handle closes it will close the log rather than wait on a daemonized process,
but it will log all activity until it closes its handle. The filemon
will be removed from the process and not inherited.
- A separate process count is kept only as an optimization for
forced detachment to avoid taking allproc_lock and walking the entire
process tree.
- struct filemon access is protected by sx(9) filemon->lock as it was before.
- Add more comments and KASSERTS.
MFC after: 2 weeks
Reviewed by: kib, mjg, markj (all on previous versions)
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D5520
to the boot.netif.mtu env var, which will be picked up by pre-existing code
in nfs_mountroot() and used to configure the interface accordingly.
This should bring the same functionality when the bootp/dhcp work is done
by loader(8) as r297150 does for the in-kernel BOOTP case.
the value in a new global intf_mtu for use by the application.
These changes were inspired by the patch provided by Robert Blayzor in
PR 187094, and will allow loader(8) to propagate the value to the kernel
along with the other nfs_diskless parms delivered via environment vars.
set that mtu on the interface.
These changes are based on the patch submitted by Robert Blayzor in the
PR, but I changed things around a bit, so the blame for any mistakes
belongs to me.
PR: 187094
wrapped in an i386 ifdef with a comment questioning their usefulness even
there. It turns out they aren't referenced anywhere, but their presence
prevents using sys/endian.h in libstand code.
These days, sys/endian.h provides much better support for such things, using
compiler builtins and inline functions (and creating connections between
libstand code and header files from sys/ would not be breaking new ground).
Submitted by: Ju Sun <junsu microsoft com>
Reviewed by: Dexuan Cui <decui microsoft com>, sephe
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D5651
of the pshared hash in child is consistent and can be safely used.
Reported and tested by: "Oleg V. Nauman" <oleg@opentransfer.com>
Sponsored by: The FreeBSD Foundation
control terminal, activated when running with pid 1. It is
application duty to handle this, and unsuspecting init replacements
which are linked with libthr would be broken by this.
The pre-resolving of getpid() is restored, just in case.
Reviewed by: jilles
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
This write came from Linux commit b4ae3f22d238 which has been implicated
in Sandy Bridge power consumption issues (albeit under different
conditions on Linux). Disabling it restores normal power consumption on
my Sandy Bridge laptop (Thinkpad X220).
PR: 207889
Reviewed by: cem, dumbbell
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D5665
a DRIVER_MODULE() referencing mmc_driver has a MODULE_DEPEND() on mmc. This
is because the kernel linker only searches for symbols in dependent modules,
so loading sdhci_pci (and other bus-flavors of sdhci) would fail when mmc
was not compiled into the kernel (even if you hand-loaded mmc first).
(Thanks to jilles@ for providing the vital clue about the kernel linker.)
