Fix regression issue in the USB file system interface.
- Use cdev_privdata pointer as indicator of correct file handle.
- Remove redundant FIFO opened flags.
Don't send ZLP at close for ulpt and uscanner devices as this causes some
models to stop working. This reverts back to the USB1 behaviour.
Submitted by: Hans Petter Selasky
This code is heavily inspired by Takanori Watanabe's experimental SMP patch
for i386 and large portion was shamelessly cut and pasted from Peter Wemm's
AP boot code.
1. fix nointr check in intsmb_start, matters only if ENABLE_ALART is
defined (by default, it is not);
2. drop unnecessary inspection/reporting of power-management io registers
base address;
3. in verbose mode report errors from SMBus host controller and their
mapping to smbus(4) errors;
Approved by: jhb (mentor)
implement CD input in hardware, while unconditional showing it confuse users.
Also it was made in the way that sometimes improper with present driver.
Add patch for ALC268 based Acer TM5320 to make headphones jack sensing work.
Default configuration defines two separate playback associations, which
current driver unable to trace properly due to order they are defined and
limited codec uniformity.
Submitted by: G. Mirov <g.mirov AT gmail.com>
the "nbufkv" sleep.
First, ffs background cg group block write requests a new buffer for
the shadow copy. When ffs_bufwrite() is called from the bufdaemon due
to buffers shortage, requesting the buffer deadlock bufdaemon.
Introduce a new flag for getnewbuf(), GB_NOWAIT_BD, to request getblk
to not block while allocating the buffer, and return failure
instead. Add a flag argument to the geteblk to allow to pass the flags
to getblk(). Do not repeat the getnewbuf() call from geteblk if buffer
allocation failed and either GB_NOWAIT_BD is specified, or geteblk()
is called from bufdaemon (or its helper, see below). In
ffs_bufwrite(), fall back to synchronous cg block write if shadow
block allocation failed.
Since r107847, buffer write assumes that vnode owning the buffer is
locked. The second problem is that buffer cache may accumulate many
buffers belonging to limited number of vnodes. With such workload,
quite often threads that own the mentioned vnodes locks are trying to
read another block from the vnodes, and, due to buffer cache
exhaustion, are asking bufdaemon for help. Bufdaemon is unable to make
any substantial progress because the vnodes are locked.
Allow the threads owning vnode locks to help the bufdaemon by doing
the flush pass over the buffer cache before getnewbuf() is going to
uninterruptible sleep. Move the flushing code from buf_daemon() to new
helper function buf_do_flush(), that is called from getnewbuf(). The
number of buffers flushed by single call to buf_do_flush() from
getnewbuf() is limited by new sysctl vfs.flushbufqtarget. Prevent
recursive calls to buf_do_flush() by marking the bufdaemon and threads
that temporarily help bufdaemon by TDP_BUFNEED flag.
In collaboration with: pho
Reviewed by: tegge (previous version)
Tested by: glebius, yandex ...
MFC after: 3 weeks
LO_CSUM_FEATURES - a bitmask of supported transmit offload features, which
will be stored in if_hwassist if IFCAP_TXCSUM is enabled, and be cleared
from mbuf packet header csum flags on transmit. (1)
LO_CSUM_SET - a bitmask of supported receive offload features, which will
be set on the mbuf packet header csum flags on transmit if IFCAP_RXCSUM
is enabled.
While here, fix SCTP offload for loopback: offer generation on the
transmit side, don't just skip validation on the receive side.
Obtained from: DragonflyBSD (1)
MFC after: 1 week
have its MTU set higher than 1500 (ETHERMTU). Its new limit is now
65535 as enforced by ifhwioctl() in if.c
This allows a tap(4) device to be added to a bridge, which requires all
interface members to have the same MTU, with an interface configured for
jumbo frames. QEMU may now connect to a network via tap(4) without
requiring the real interface to have its MTU set to 1500 or lower.
Reviewed by: rpaulo, bms
MFC after: 1 week
avoidance:
- Enable setting the RXCSUM and TXCSUM flags for loopback interfaces;
set both by default.
- When RXCSUM is set, flag packets sent over the loopback interface as
having checked and valid IP, UDP, TCP checksums so that higher
protocol layers won't check them.
- Always clear CSUM_{IP,UDP_TCP} checksum required flags on transmit,
as they will have gotten there as a result of TXCSUM being set.
This is done only for packets explicitly sent over the loopback, not
simulated loopback via if_simloop() due to !SIMPLEX interfaces, etc.
Note that enabling TXCSUM but not RXCSUM will lead to unhappiness, as
checksums won't be generated but will be validated.
Kris reports that this leads to significant performance improvements
in loopback benchmarking with TCP and UDP for throughput:
RXCSUM RXCSUM+TXCSUM
TCP 15% 37%
UDP 10% 74%
Update man page.
Reviewed by: sam
Tested by: kris
MFC after: 1 week
in FreeBSD 5.x to allow network device drivers to run with Giant
despite the network stack being Giant-free. This significantly
simplifies calls into ioctl() on network interfaces, especially
in the multicast code, as well as eliminates deferred invocation
of interface if_start routines.
Disable the build on device drivers still depending on
IFF_NEEDSGIANT as they no longer compile. They will be removed
in a few weeks if they haven't been made MPSAFE in that time.
Disabled drivers:
if_ar
if_axe
if_aue
if_cdce
if_cue
if_kue
if_ray
if_rue
if_rum
if_sr
if_udav
if_ural
if_zyd
Drivers that were already disabled because of tty changes:
if_ppp
if_sl
Discussed on: arch@
certain flags that should have been in inp_flags ended up in inp_vflag,
meaning that they were inconsistently locked, and in one case,
interpreted. Move the following flags from inp_vflag to gaps in the
inp_flags space (and clean up the inp_flags constants to make gaps
more obvious to future takers):
INP_TIMEWAIT
INP_SOCKREF
INP_ONESBCAST
INP_DROPPED
Some aspects of this change have no effect on kernel ABI at all, as these
are UDP/TCP/IP-internal uses; however, netstat and sockstat detect
INP_TIMEWAIT when listing TCP sockets, so any MFC will need to take this
into account.
MFC after: 1 week (or after dependencies are MFC'd)
Reviewed by: bz
guarantee that all cpus have acknowledged the cleared enable int by
scheduling the resetting thread on each cpu in succession. Since all
lock profiling happens within a critical section this guarantees that
all cpus have left lock profiling before we clear the datastructures.
- Assert that the per-thread queue of locks lock profiling is aware of
is clear on thread exit. There were several cases where this was not
true that slows lock profiling and leaks information.
- Remove all objects from all lists before clearing any per-cpu
information in reset. Lock profiling objects can migrate between
per-cpu caches and previously these migrated objects could be zero'd
before they'd been removed
Discussed with: attilio
Sponsored by: Nokia
C-NET(PC) has a cfe at location 1 that has both an odd irq mask (it
matches pc98 machines, so maybe it was a flag for pc98 operation) as
well as a memory map. Since this driver doesn't know how to cope, we
start with cfe2, which is purely an I/O space mapped and that seems to
make it work. I say 'seems' here, because the card I have doesn't
seem to have the right dongle for full testing...
when someone is passing new rules, not when he only want to read them.
Because of this bug, even if the given rules were incorrect, they
ended up in rule_string.
- Add missing protection for rule_string when coping it.
Reviewed by: rwatson
MFC after: 1 week
pthread_sigmask() to signal.h. In principle, this shouldn't break anything,
since they're already in signal.h on other systems, and the FreeBSD
manpage says that both pthread.h and signal.h need to be included to
get these functions.
Add a hack to declare pthread_t in the P1003.1-2008 namespace
in signal.h.
in the POSIX namespace, and hiding eaccess() and setproctitle().
Also move mknodat() from unistd.h to sys/stat.h where it belongs.
The *at() syscalls are only in CURRENT, so this shouldn't cause
problems.
improve performance:
- Eliminate custom reference count and condition variable to monitor
threads entering the framework, as this had both significant overhead
and behaved badly in the face of contention.
- Replace reference count with two locks: an rwlock and an sx lock,
which will be read-acquired by threads entering the framework
depending on whether a give policy entry point is permitted to sleep
or not.
- Replace previous mutex locking of the reference count for exclusive
access with write acquiring of both the policy list sx and rw locks,
which occurs only when policies are attached or detached.
- Do a lockless read of the dynamic policy list head before acquiring
any locks in order to reduce overhead when no dynamic policies are
loaded; this a race we can afford to lose.
- For every policy entry point invocation, decide whether sleeping is
permitted, and if not, use a _NOSLEEP() variant of the composition
macros, which will use the rwlock instead of the sxlock. In some
cases, we decide which to use based on allocation flags passed to the
MAC Framework entry point.
As with the move to rwlocks/rmlocks in pfil, this may trigger witness
warnings, but these should (generally) be false positives as all
acquisition of the locks is for read with two very narrow exceptions
for policy load/unload, and those code blocks should never acquire
other locks.
Sponsored by: Google, Inc.
Obtained from: TrustedBSD Project
Discussed with: csjp (idea, not specific patch)
(1) Fix pcib_read/write_config prototypes.
(2) When contrainting a resource request for a 'subtractive' bridge,
it is important to select a range outside the base/limit
registers, since those are the only values known to not
possibly work. On my HP laptop, the base bridge excludes I/O
ports 0xa000-0xafff, however that was the range we were passing
up the tree. Instead, when a range spans the "hole" we now
arbitrarily pick the range just above the hole to allocate from.
All of my rl and xl cards, at a minimum, started working again on this
laptop with those fixes.
- When sending large PR-SCTP messages over a
lossy link we would incorrectly calculate the fwd-tsn
- When receiving large multipart pr-sctp packets we would
incorrectly send back a SACK that would renege improperly
on already received packets thus causing unneeded retransmissions.
is calculated as 0 which causes errors elsewhere.
Submitted by: KOIE Hidetaka <koie@suri.co.jp>
- When sched_affinity() is called with a thread that is not curthread we
need to handle the ON_RUNQ() case by adding the thread to the correct
run queue.
Submitted by: Justin Teller <justin.teller@gmail.com>
MFC after: 1 Week
