lock_success/lock_failure, introduced in r228424, by directly skipping
in dtrace_probe.
This mainly helps in avoiding namespace pollution and thus lockstat.h
dependency by systm.h.
As an added bonus, this also helps in MFC case.
Reviewed by: avg
MFC after: 3 months (or never)
X-MFC: r228424
typedef bool. Due to macro expansion it seemed better to use a
typedef for kernel consumers (specifically ofed won't compile
without more changes if a define is used).
- <stdbool.h> should also not re-define bool/true/false if they are
defined by <sys/types.h>. It would probably be a programming error
to define _KERNEL for user-space code, but downstream consumers
like Isilon have already been including <stdbool.h> in kernel
sources, and this protects that usage.
- sizeof(_Bool) is not necessarily the same as sizeof(int), so kernel
modules should be rebuild with this change. Bump __FreeBSD_version.
MFC after: 2 weeks
Sponsored by: Isilon Systems, LLC
- Two struct members eee_disable are used in a function that expects
an int *, so declare them int, not bool.
- igb_tx_ctx_setup() returns a boolean value, so declare it bool, not int.
- igb_header_split is passed to TUNABLE_INT, so delcare it int, not bool.
- igb_tso_setup() returns a bool, so declare it bool, not boolean_t.
- Do not re-define bool/true/false if the symbols already exist.
MFC after: 2 weeks
Sponsored by: Isilon Systems, LLC
- {ixgbe,ixv}_header_split is passed to TUNABLE_INT, so delcare it
int, not bool.
- {ixgbe,ixv}_tx_ctx_setup() returns a boolean value, so declare it
bool, not int.
- {ixgbe,ixv}_tso_setup() returns a bool, so declare it bool, not boolean_t.
- {ixgbe,ixv}_txeof() returns a bool, so declare it bool, not boolean_t.
- Do not re-define bool if the symbol already exists.
MFC after: 2 weeks
Sponsored by: Isilon Systems, LLC
processors with CPUID signature 06_1AH, 06_1EH, and 06_1FH.
Refuse to allocate them on unsupported model.
Submitted by: Davide Italiano <davide.italiano@gmail.com>
MFC after: 1 month
Historical behavior of letting other CPUs merily go on is a default for
time being. The new behavior can be switched on via
kern.stop_scheduler_on_panic tunable and sysctl.
Stopping of the CPUs has (at least) the following benefits:
- more of the system state at panic time is preserved intact
- threads and interrupts do not interfere with dumping of the system
state
Only one thread runs uninterrupted after panic if stop_scheduler_on_panic
is set. That thread might call code that is also used in normal context
and that code might use locks to prevent concurrent execution of certain
parts. Those locks might be held by the stopped threads and would never
be released. To work around this issue, it was decided that instead of
explicit checks for panic context, we would rather put those checks
inside the locking primitives.
This change has substantial portions written and re-written by attilio
and kib at various times. Other changes are heavily based on the ideas
and patches submitted by jhb and mdf. bde has provided many insights
into the details and history of the current code.
The new behavior may cause problems for systems that use a USB keyboard
for interfacing with system console. This is because of some unusual
locking patterns in the ukbd code which have to be used because on one
hand ukbd is below syscons, but on the other hand it has to interface
with other usb code that uses regular mutexes/Giant for its concurrency
protection. Dumping to USB-connected disks may also be affected.
PR: amd64/139614 (at least)
In cooperation with: attilio, jhb, kib, mdf
Discussed with: arch@, bde
Tested by: Eugene Grosbein <eugen@grosbein.net>,
gnn,
Steven Hartland <killing@multiplay.co.uk>,
glebius,
Andrew Boyer <aboyer@averesystems.com>
(various versions of the patch)
MFC after: 3 months (or never)
AIM systems to 4 GB on 32-bit systems and 2^64 bytes on 64-bit systems.
VM_MAXUSER_ADDRESS remains at 2 GB on pending Book-E, pending review of
an increase to 3 GB by those more familiar with Book-E.
pmap_remove() for large sparse requests. This can prevent pmap_remove()
operations on 64-bit process destruction or swapout that would take
several hundred times the lifetime of the universe to complete. This
behavior is largely indistinguishable from a hang.
VM_KMEM_SIZE_MAX. Specifically, if the user/kernel address space split
was changed such that the kernel address space was greater than or equal
to 2 GB, then overflow would occur.
PR: 161721
MFC after: 3 weeks
There have still been intermittent problems with apparent TX
hangs for some customers. These have been problematic to reproduce
but I believe these changes will address them. Testing on a number
of fronts have been positive.
EM: there is an important 'chicken bit' fix for 82574 in the shared
code this is supported in the core here.
- The TX path has been tightened up to improve performance. In
particular UDP with jumbo frames was having problems, and the
changes here have improved that.
- OACTIVE has been used more carefully on the theory that some
hangs may be due to a problem in this interaction
- Problems with the RX init code, the "lazy" allocation and
ring initialization has been found to cause problems in some
newer client systems, and as it really is not that big a win
(its not in a hot path) it seems best to remove it.
- HWTSO was broken when VLAN HWTAGGING or HWFILTER is used, I
found this was due to an error in setting up the descriptors
in em_xmit.
IGB:
- TX is also improved here. With multiqueue I realized its very
important to handle OACTIVE only under the CORE lock so there
are no races between the queues.
- Flow Control handling was broken in a couple ways, I have changed
and I hope improved that in this delta.
- UDP also had a problem in the TX path here, it was change to
improve that.
- On some hardware, with the driver static, a weird stray interrupt
seems to sometimes fire and cause a panic in the RX mbuf refresh
code. This is addressed by setting interrupts late in the init
path, and also to set all interrupts bits off at the start of that.
support of new deltas for both em and igb drivers.
Note that I am not able to track all the bugs fixed in
this code, I am a consumer of it as a component of my
core drivers. It is important to keep the FreeBSD drivers
up to date with it however.
One important note is there is a key fix for 82574 in this
update. Also, there are lots of white space changes, I am
not happy about them but have no control over it :)
control. Controller does not automatically generate pause frames
based on number of available RX buffers so it's very hard to
know when driver should generate XON frame in time. The only
mechanism driver can detect low number of RX buffer condition is
ET_INTR_RXRING0_LOW or ET_INTR_RXRING1_LOW interrupt. This
interrupt is generated whenever controller notices the number of
available RX buffers are lower than pre-programmed value(
ET_RX_RING0_MINCNT and ET_RX_RING1_MINCNT register). This scheme
does not provide a way to detect when controller sees enough number
of RX buffers again such that efficient generation of XON/XOFF
frame is not easy.
While here, add more flow control related register definition.
interrupt is ours. Note, interrupts are automatically ACKed when
the status register is read.
Add RX/TX DMA error to interrupt handler and do full controller
reset if driver happen to encounter these errors. There is no way
to recover from these DMA errors without controller reset.
Rename local variable name intrs with status to enhance
readability.
While I'm here, rename ET_INTR_TXEOF and ET_INTR_RXEOF to
ET_INTR_TXDMA and ET_INTR_RXDMA respectively. These interrupts
indicate that a frame is successfully DMAed to controller's
internal FIFO and they have nothing to do with EOF(end of frame).
Driver does not need to wait actual end of TX/RX of a frame(e.g.
no need to wait the end signal of TX which is generated when a
frame in TX FIFO is emptied by MAC). Previous names were somewhat
confusing.
of a devfs file descriptor in devfs_close_f(). The passed in td argument
may be NULL if the close was invoked by garbage collection of open
file descriptors in pending control messages in the socket buffer of a
UNIX domain socket after it was closed.
PR: kern/151758
Submitted by: Andrey Shidakov andrey shidakov ru
Submitted by: Ruben van Staveren ruben verweg com
Reviewed by: kib
MFC after: 2 weeks
thread_free(newtd). This to avoid a possible page fault in
cpu_thread_clean() as seen on amd64 with syscall fuzzing.
Reviewed by: kib
MFC after: 1 week
suspend state. This will save more power.
On resume, make sure to enable all clocks. While I'm here, if
controller is not fast ethernet, enable gigabit PHY.
Don't blindly re-initialize controller whenever MTU is changed.
Now, reinitializing is done only when driver is running.
While here, remove unnecessary assignment of error value since it
was already initialized to 0.
o Do not report link status if driver is not running.
o TX/RX MAC configuration should be done with resolved speed,
duplex and flow control after establishing a link so it can't
be done in driver initialization routine.
Move the configuration to miibus_statchg callback which will be
called whenever any link state change is detected.
At this moment, flow-control is not enabled yet mainly because
I was not able to set correct flow control parameters to
generate TX pause frames.
o Now TX/RX MAC is enabled only when a valid link is detected.
Rearragnge hardware initialization routine a bit to leave
enabling MAC to miibus_statchg callback. In order to that,
TX/RX DMA engine is enabled in et_init_locked().
o Introduce ET_FLAG_LINK flag to track current link state.
o Introduce ET_FLAG_FASTETHER flag to mark whether controller is
fast ethernet. This flag is checked in miibus_statchg callback
to know whether PHY established a valid link.
o In et_stop(), TX/RX MAC is explicitly disabled instead of
relying on et_reset(). And move et_reset() from et_stop() to
controller initialization. Controler reset is not required here
and it would also clear critial registers(i.e station address,
RX filter configuration, WOL etc) that are required to make WOL
work.
o Switching to current media is done in et_init_locked() after
setting IFF_DRV_RUNNING flag. This should ensure reliable
auto-negotiation/manual link establishment.
o In et_start_locked(), check whether driver got a valid link
before trying to send frames.
o Remove checking a link in et_tick() as this is done by
miibus_statchg callback.
identifier reserved for the implementation in C99 and earlier so there is
no sensible reason for introducing yet another reserved identifier when we
could just use the one C1x uses.
Approved by: brooks (mentor)
manipulation of interrupt register access is done through
CSR_WRITE_4 macro. Also add disabling interrupt into et_reset()
because we want interrupt disabled state after controller reset.
While I'm here slightly change interrupt handler to be more
readable one.
send a single TX command after setting up all TX frames. This
removes unnecessary register accesses and bus_dmamap_sync(9) calls.
et(4) uses TX interrupt moderation so it's possible to have TX
buffers that were already transmitted but waiting for TX completion
interrupt. If the number of available TX descriptor is less then
1/3 of total TX descriptor, try reclaiming first to get enough free
TX descriptors before setting up TX descriptors.
After r228325, et_txeof() no longer tries to send frames after
reclaiming TX buffers. That change was made to give more chance
to transmit frames in main interrupt handler since we can still
send frames in interrupt handler with RX interrupt. So right
before exiting interrupt hander, after enabling interrupt, try to
send more frames. This gives slightly better performance numbers.
While I'm here reduce number of spare TX descriptors from 8 to 4.
Controller does not require reserved TX descriptors, it was just to
reduce TX overhead. After r228325, driver has much lower TX
overhead so it does not make sense to reserve 8 TX descriptors.
change should make et(4) work on any architectures.
o Remove m_getl inline function and replace it with stanard mbuf
interfaces. Previous code tried to minimize code duplication
but this came from incorrect use of common DMA tag.
Driver may be still use a common RX allocation handler with
additional structure changes but I don't see much point to do
that it would make it hard to understand the code.
o Remove DragonflyBSD specific constant EVL_ENCAPLEN, use
ETHER_VLAN_ENCAP_LEN instead.
o Add bunch of new RX status definition. It seems controller
supports RX checksum offloading but I was not able to make the
feature work yet. Currently driver checks whether recevied
frame is good one or not.
o Avoid a typedef ending in '_t' as style(9) says.
o Controller has no restriction on DMA address space, so there
is no reason to limit the DMA address to 32bit. Descriptor
rings, status blocks and TX/RX buffers now use full 64bit DMA
addressing.
o Allocate DMA memory shared between host and controller as
coherent.
o Create 3 separate DMA tags to be used as TX, mini RX ring and
stanard RX ring. Previously it created a single DMA tag and it
was used to all three rings.
o et(4) does not support jumbo frame at this moment and I still
don't quite understand how jumbo frame works on this controller
so use two RX rings to handle small sized frame and normal sized
frame respectively. The mini RX ring will be used to receive
frames that are less than or equal to 127 bytes. The second RX
ring is used to receive frames that are not handled by the first
RX ring.
If jumbo frame support is implemented, driver may have to choose
better RX scheme by letting the second RX ring handle jumbo
frames. This scheme will mimic Broadcom's efficient jumbo frame
handling feature. However RAM buffer size(16KB) of the
controller is too small to hold 2 jumbo frames, if 9KB
jumbo frame is used, I'm not sure how good performance would it
have.
o In et_rxeof(), make sure to check whether controller received
good frame or not. Passing corrupted frame to upper layer is
bad idea.
o If driver receives a bad frame or driver fails to allocate RX
buffer due to resource shortage condition, reuse previously
loaded DMA map for RX buffer instead of unloading/loading RX
buffer again.
o et_init_tx_ring() never fails so change return type to void.
o In watchdog handler, show TX DMA write back status of errored
frame which could be used as a clue to debug watchdog timeout.
o Add missing bus_dmamap_sync() in various places such that et(4)
should work with bounce buffers(e.g. PAE).
o TX side bus_dmamap_load_mbuf_sg(9) support.
o RX side bus_dmamap_load_mbuf_sg(9) support.
o Controller has no DMA alignment limit in RX buffer so use
m_adj(9) in RX buffer allocation to make IP header align on 2
bytes boundary. Otherwise it would trigger unaligned access
error in upper layer on strict alignment architectures.
One of down side of controller is it provides limited set of RX
buffer length like most Intel controllers. This is not problem
at this moment because driver does not support jumbo frame yet
but it may require alignment fixup code to support jumbo frame
on strict alignment architectures.
o In et_txeof(), don't zero TX descriptors for transmitted frames.
TX descriptors don't need write access after transmission.
Driver sets IFF_DRV_OACTIVE when the number of available TX
descriptors are less than or equal to ET_NSEG_SPARE. Make sure
to clear IFF_DRV_OACTIVE only when the number of available TX
descriptor is greater than ET_NSEG_SPARE.
