resulted in deadcode, as 'error' could never be 0. What this logic
was originally meant to handle is not clear -- it's been this way
(broken) since at least RELENG_4.
Found with: Coverity Prevent(tm)
MFC after: 3 days
restored when its removed from the bridge.
At the moment we only clear IFCAP_TXCSUM. Since a locally generated packet on
the bridge may be sent out any one or more interfaces it cant be assumed that
every card does hardware csums. Most bridges don't generate a lot of traffic
themselves so turning off offloading won't hurt, bridged packets are
unaffected.
Tested by: Bruce Walker (bmw borderware.com)
MFC after: 5 days
taskqueue_start_threads(struct taskqueue **, int count, int pri,
const char *name, ...);
This allows the creation of 1 or more threads that will service a single
taskqueue. Also rework the taskqueue_create() API to remove the API change
that was introduced a while back. Creating a taskqueue doesn't rely on
the presence of a process structure, and the proc mechanics are much better
encapsulated in taskqueue_start_threads(). Also clean up the
taskqueue_terminate() and taskqueue_free() functions to safely drain
pending tasks and remove all associated threads.
The TASKQUEUE_DEFINE and TASKQUEUE_DEFINE_THREAD macros have been changed
to use the new API, but drivers compiled against the old definitions will
still work. Thus, recompiling drivers is not a strict requirement.
- Add support for adjusting the fan speed if the fan control mode is manual
Documentation for the relevant embedded controller register was obtained from
http://www.thinkwiki.org/wiki/Patch_for_controlling_fan_speed
Tested on: R51 by Fabian Keil
T41p by markus
Requested by: many
Approved by: philip
MFC after: 1 week
ipxpcb is NULL or not: in attach it will be, and on detach it won't be.
If for any reason these invariants don't hold true, panicking is a good
idea.
Noticed by: Coverity Prevent analysis tool
MFC after: 3 days
may be a stale pointer at this point, and we're interested in whether or
not m_pulldown() failed.
Noticed by: Coverity Prevent analysis tool
MFC after: 3 days
are the contents of the forwarded mbuf ever copied into mcopy, so there's
no need to have mcopy, conditionally look at mcopy, or conditionally free
it.
Noticed by: Coverity Prevent analysis tool
MFC after: 3 days
ef_clone(); we were testing the original ifnet, not the one allocated.
When aborting ef_clone() due to if_alloc() failing, free the allocated
efnet structure rather than leaking it.
Noticed by: Coverity Prevent analysis tool
MFC after: 3 days
SLIST_FOREACH_SAFE() rather than SLIST_FOREACH(), as elements are
freed on each iteration of the loop. This prevents use-after-free.
Noticed by: Coverity Prevent analysis tool
MFC after: 3 days
intended for use solely with atomic datagram socket types, and relies
on the previous break-out of sosend_copyin(). Changes to allow UDP to
optionally use this instead of sosend() will be committed as a
follow-up.
2) use more robust way of link state handling for BCM5700 rev.B2 chip
3) workaround bug of some BCM570x chips which cause spurious "link up" messages
4) fix bug: some BCM570x chips was unable to detect link state changes after
ifconfig down/up sequence until any 'non-link related' interrupt generated.
(this happened due to pending internal link state attention which blocked
interrupt generation)
Approved by: glebius (mentor)
MFC after: 1 week
the the interface has been configured. I'm not sure how this could ever
have worked before, but it should be fixed now. Also break out the interrupt
degresitration function into it's own step.
in flags. When sending export datagram from expiry thread, then
use default zero flags. This removes unpleasant contention of the
interrupt thread on mutexes (usually ng_ksocket's socket buffer
mutex).
before. The symptom is that the battery inform us its charge and discharge
at the same time...
* fix bst.rate to correctly output the (dis)charging rate. We'll use
the current average over one minute command and not the at_rate command.
Note that this method is not correct if the capacity_mode is set, but
since we don't set it ourself, it is not a problem.
The at_rate do not give the actual rate but is used to compute the
estimated time for (dis)charging a battery. We should actually
write an estimation of the actual rate using at_rate cmd and then
perform a read to the various estimators.
Approved by: njl
MFC after: 2 days
had been replied, the reply was always delivered to the originator
synchronously.
With introduction of netgraph item callbacks and a wait channel with
mutex in ng_socket(4), we have fixed the problem with ngctl(8) returning
earlier than the command has been proceeded by target node. But still
ngctl(8) can return prior to the reply has arrived to its node.
To fix this:
- Introduce a new flag for netgraph(4) messages - NGM_HASREPLY.
This flag is or'ed with message like NGM_READONLY.
- In netgraph userland library if we have sent a message with
NGM_HASREPLY flag, then select(2) until reply comes.
- Mark appropriate generic commands with NGM_HASREPLY flag,
gathering them into one enum {}. Bump generic cookie.
when checking whether it's greater than a struct stat st_size in order
to also catch the case when st_size is -1. Previously this check didn't
trigger on sparc64 when st_size is -1 (as it's the case for a file on
a bzipfs, TFTP server etc.), causing the content of the linker hints
file to be copied to memory referenced by a null-pointer.
PR: 91231
MFC after: 1 week
operands are consumed so use the appropriate constraint modifier.
Before this change GCC used one register for both an input and an
unrelated output operand of in_addword(), causing the input to be
overwritten before it was consumed and thus breaking in_addword().
For in_cksum_hdr() and in_pseudo() this change is more or less
cosmetic.
- Fix a misspelling in a nearby comment.
Reported & tested by: yongari
MFC after: 1 week
The minimum / maximum speed was way too low / high!
minspeed = 2000 - is this for real ?
maxspeed = 767999 - is this for real ?????
Wrap everything into 8000 - 48000 boundary, just to be safe.
MFC after: 3 days
Correct insecure temporary file usage in ee. [06:02]
Correct a race condition when setting file permissions, sanitize file
names by default, and fix a buffer overflow when handling files
larger than 4GB in cpio. [06:03]
Fix an error in the handling of IP fragments in ipfw which can cause
a kernel panic. [06:04]
Security: FreeBSD-SA-06:01.texindex
Security: FreeBSD-SA-06:02.ee
Security: FreeBSD-SA-06:03.cpio
Security: FreeBSD-SA-06:04.ipfw
- Mark MPSAFE since most of the locking procedures already implemented.
- Turn on inverted external amplifier sense flag for selected boards.
Tested by: bland
MFC after: 1 week
attempted to cast a struct ifnet to a struct fw_com which resulted in
data corruption.
PR: kern/91307
Submitted by: Alex Semenyaka <alex at semenyaka do ru>
MFC After: 6 days
operations before returning. Point the bus at a dummy cam_sim
structure so that any CCBs will complete immediately with a
CAM_DEV_NOT_THERE status, and ensure that any xpt_schedule() calls
on the bus's devices will immediately call the peripheral's
periph_start() routine. Also repeat the async messages because
devices that were part of the way through being probed may appear
after the original AC_LOST_DEVICE was sent, and would otherwise
never go away.
These changes make it possible to deregister a bus and free the SIM
at most stages during bus probing without the usual crashes in
camisr(). In particular, plugging in a umass device and then
unplugging it as soon as the first probe messages appeared would
almost always result in a crash. Now the device just goes away with
a few CAM errors and all references to the CAM bus, target and
device are dropped correctly.
- Only update the rx ring consumer pointer after running through the rx loop,
not with each iteration through the loop.
- If possible, use a fast interupt handler instead of an ithread handler. Use
the interrupt handler to check and squelch the interrupt, then schedule a
taskqueue to do the actual work. This has three benefits:
- Eliminates the 'interrupt aliasing' problem found in many chipsets by
allowing the driver to mask the interrupt in the NIC instead of the
OS masking the interrupt in the APIC.
- Allows the driver to control the amount of work done in the interrupt
handler. This results in what I call 'adaptive polling', where you get
the latency benefits of a quick response to interrupts with the
interrupt mitigation and work partitioning of polling. Polling is still
an option in the driver, but I consider it orthogonal to this work.
- Don't hold the driver lock in the RX handler. The handler and all data
associated is effectively serialized already. This eliminates the cost of
dropping and reaquiring the lock for every receieved packet. The result
is much lower contention for the driver lock, resulting in lower CPU usage
and lower latency for interactive workloads.
The amount of work done in the taskqueue is controlled by the sysctl
dev.em.N.rx_processing_limit
and tunable
hw.em.rx_process_limit
Setting these to -1 effectively removes the limit.
The fast interrupt and taskqueue can be disabled by defining NO_EM_FASTINTR.
This work has been shown to increase fast-forwarding from ~570 kpps to
~750 kpps (note that the same NIC hardware seems unable to transmit more than
800 kpps, so this increase appears to be limited almost solely by the
hardware). Gains have been shown in other workloads, ranging from better
performance to elimination of over-saturation livelocks.
Thanks to Andre Opperman for his time and resources from his network
performance project in performing much of the testing. Thanks to Gleb
Smirnoff and Danny Braniss for their help in testing also.
