I couldn't find the ID for the EG1064 anywhere in our sources
so I removed the reference for now.
Pointed out by: Robert Huff <roberthuffi at rcn dot com> [1]
Reviewed by: simon
an application to upon a tape (yea, even the non-control device) even if
it cannot establish a mount session. If the open cannot establish a mount
session and O_NONBLOCK was specified, the tape becomes 'open pending mount'.
All I/O operations that would require access to a tape thereafter until
a close attempt to initiate the mount session. If the mount session succeeds,
the tape driver transitions to full open state, else returns an appropriate
I/O error (ENXIO).
At the same time, add a change that remembers whether tape is being opened
read-only. If so, disallow 'write' operations like writing filemarks that
bypass the normal read-only filtering operations that happen in the write(2)
syscall.
Reviewed by: ken, justin, grog
MFC after: 2 weeks
Suggested by: The Bacula Team
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.
