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.
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.
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.
c162516
Remove vtblk_sector_size
c162515
Wrap long license lines
c162514
Remove vtblk_unit
c162513
Wrap long lines in the license.
c162512
Remove verbose messages when link goes up/down.
A similar message is printed elsewhere as a result of
if_link_state_change().
c162511
Explicity compare pointer to NULL
c162510
Allocate the mac filter table at attach time.
c162509
Add real BSD licenses to the header files copied from Linux.
The chases upstream changes made in Linux awhile ago.
c162508
Only notify if we actually dequeued something.
c162507
Change a couple of if () { KASSERT(...) } to just KASSERTs.
In non-debug kernels, the if() { } probably get optomized
away, but I guess this is clearer.
c162506
Remove VIRTIO_BLK_F_TOPOLOGY fields in the config.
TOPOLOGY has since been removed from the spec, and the FreeBSD
didn't really do anything with the fields anyways.
c162505
Move vtblk_enqueue_request() outside the locks when getting the ident.
c162504
Remove soon to be uneeded trylock during dump [1].
http://lists.freebsd.org/pipermail/freebsd-current/2011-November/029226.html
c162503
Remove emtpy line
c162502
Drop frame if cannot allocate a vtnet_tx_header.
If we don't, we set OACTIVE, but if there are no
other frames in flight, vtnet_txeof() will never
be called to unset OACTIVE. The interface would
have to be down/up'ed in order to become usable.
We could be cuter here and only do this if the
virtqueue is emtpy, but its probably not worth
the complication.
c162501
Start mbuf replacement loop at 1 for clarity
Obtained from: Bryan Venteicher bryanv at daemoninthecloset dot org
driver that has high precedence for the controller override et(4).
Add missing callout_drain(9) in device detach and rework detach
routine. While I'm here use rman_get_rid(9) instead of using
cached resource id because bus methods are free to change the
id.
While I'm here remove initializing if_mtu, it is set by
ether_ifattach(9). Also move callout_init_mtx(9) to the right below
driver lock initialization.
descriptors before trying to send frames. If we're not able to
send a frame, make sure to prepend it to if_snd queue such that
alt(4) should work.
While I'm here prefer ETHER_BPF_MTAP to BPF_MTAP. ETHER_BPF_MTAP
should be used for controllers that support VLAN hardware tag
insertion. The controller supports VLAN tag insertion but lacks
VLAN tag stripping in RX path though.
before calling bus_enumerate_hinted_children(9) (which is the minimum for
this to work) instead of fully probing it so later on we can just call
bus_generic_attach(9) on the parent of the miibus(4) instance. The latter
is necessary in order to work around what seems to be a bzzarre race in
newbus affecting a few machines since r227687, causing no driver being
probed for the newly added miibus(4) instance. Presumably this is the
same race that was the motivation for the work around done in r215348.
Reported and tested by: yongari
- Revert the removal of a static in r221913 in order to help compilers to
produce more optimal code.
On my hardware, "em" in netmap mode does about 1.388 Mpps
on one card (on an Asus motherboard), and 1.1 Mpps on another
card (PCIe bus). Both seem to be NIC-limited, because
i have the same rate even with the CPU running at 150 MHz.
On the "re" driver the tx throughput is around 420-450 Kpps
on various (8111C and the like) chipsets. On the Rx side
performance seems much better, and i can receive the full
load generated by the "em" cards.
"igb" is untested as i don't have the hardware.
A link reset now is completely transparent for the netmap client:
even if the NIC resets its own ring (e.g. restarting from 0),
the client will not see any change in the current rx/tx positions,
because the driver will keep track of the offset between the two.
2. make the device-specific code more uniform across different drivers
There were some inconsistencies in the implementation of the netmap
support routines, now drivers have been aligned to a common
code structure.
3. import netmap support for ixgbe . This is implemented as a very
small patch for ixgbe.c (233 lines, 11 chunks, mostly comments:
in total the patch has only 54 lines of new code) , as most of
the code is in an external file sys/dev/netmap/ixgbe_netmap.h ,
following some initial comments from Jack Vogel about making
changes less intrusive.
(Note, i have emailed Jack multiple times asking if he had
comments on this structure of the code; i got no reply so
i assume he is fine with it).
Support for other drivers (em, lem, re, igb) will come later.
"ixgbe" is now the reference driver for netmap support. Both the
external file (sys/dev/netmap/ixgbe_netmap.h) and the device-specific
patches (in sys/dev/ixgbe/ixgbe.c) are heavily commented and should
serve as a reference for other device drivers.
Tested on i386 and amd64 with the pkt-gen program in tools/tools/netmap,
the sender does 14.88 Mpps at 1050 Mhz and 14.2 Mpps at 900 MHz
on an i7-860 with 4 cores and 82599 card. Haven't tried yet more
aggressive optimizations such as adding 'prefetch' instructions
in the time-critical parts of the code.
pins, rather than defaulting to 0 and 1.
This way the pin order can be reversed. It is reversed with the
TP-Link TL-WR1043nd.
Submitted by: Stefan Bethke <stb@lassitu.de>
These realtek switch PHYs speak a variant of i2c with some slightly
modified handling.
From the submitter, slightly modified now that some further digging
has been done:
The I2C framework makes a assumption that the read/not-write bit of the first
byte (the address) indicates whether reads or writes are to follow.
The RTL8366 family uses the bus: after sending the address+read/not-write byte,
two register address bytes are sent, then the 16-bit register value is sent
or received. While the register write access can be performed as a 4-byte
write, the read access requires the read bit to be set, but the first two bytes
for the register address then need to be transmitted.
This patch maintains the i2c protocol behaviour but allows it to be relaxed
(for these kinds of switch PHYs, and whatever else Realtek may do with this
almost-but-not-quite i2c bus) - by setting the "strict" hint to 0.
The "strict" hint defaults to 1.
Submitted by: Stefan Bethke <stb@lassitu.de>
It appears this device fails if sent a SYNCHRONIZE_CACHE command, so add
quirk to avoid sending it.
I will follow up with Micron on this issue, and will adjust the quirk if
necessary based on their feedback.
Reviewed by: hselasky@
According to the open firmware standard, finddevice call has to return
a phandle with value of -1 in case of error.
This commit is to:
- Fix the FDT implementation of this interface (ofw_fdt_finddevice) to
return (phandle_t)-1 in case of error, instead of 0 as it does now.
- Fix up the callers of OF_finddevice() to compare the return value with
-1 instead of 0 to check for errors.
- Since phandle_t is unsigned, the return value of OF_finddevice should
be checked with '== -1' rather than '<= 0' or '> 0', fix up these cases
as well.
Reported by: nwhitehorn
Reviewed by: raj
Approved by: raj, nwhitehorn
to known AHCI-capable chips (AMD/NVIDIA), configured for legacy emulation.
Enabled by default to get additional performance and functionality of AHCI
when it can't be enabled by BIOS. Can be disabled to honor BIOS settings if
needed for some reason.
MFC after: 1 month
control for all vr(4) controllers that support it. It's known that
old vr(4) controllers(Rhine II) does not support TX pause but Rhine
III supports both TX and RX pause.
Make TX pause really work on Rhine III by letting controller know
available RX buffers.
While here, adjust XON/XOFF parameters to get better performance
with flow control.
using member variables in softc.
While I'm here change media after setting IFF_DRV_RUNNING. This
will remove unnecessary link state handling in vr_tick() if
controller established a link immediately.
transfer statemachine. This work is about using a single
state variable instead of multiple state bits as input
for the USB statemachine to determine what to do in the
various parts of the code. No APIs towards USB device
drivers or USB host controller drivers will be changed.
MFC after: 1 month
put into suspend/shutdown. Old PCI controllers performed that
operation in firmware but for RTL8111C or newer controllers, it's
responsibility of driver. It's not clear whether the firmware of
RTL8111B still downgrades its speed to 10/100Mbps so leave it as it
was.
issues probably needing workarounds in bge(4) when brgphy(4) handles this
PHY. Letting ukphy(4) handle it instead results in a working configuration,
although likely with performance penalties.
The calibrate callout is done with the sc lock held.
This only showed up when using an older NIC (AR5212) whose
radio/phy requires the rfgain adjustment.
Pointy-hat-to: adrian
Sponsored by: Hobnob, Inc.
* Failall is now named just that.
* Add TX ok and TX fail, for aggregate frame sub-frames.
This will break athstats; a followup commit wil resolve this.
Sponsored by: Hobnob, Inc.
Because there is no reliable way to know whether RX MAC is in
stopped state, rejecting all frames would be the only way to
minimize possible races.
Otherwise it's possible to receive frames while stop command
execution is in progress and controller can DMA the frame to freed
RX buffer during that period.
This was observed on recent PCIe controllers(i.e. RTL8111F).
While this change may not be required on old controllers it
wouldn't make negative effects on old controllers. One side effect
of this change is disabling receive so driver reprograms RL_RXCFG
to receive WOL frames when it is put into suspend or shutdown.
This should address occasional 'memory modified free' errors seen
on recent RealTek controllers.
driver would ignore the first link state update if controller
already established a link such that it would have to take
additional link state handling in re_tick().
access.
While I'm here, enable WOL through magic packet but disable waking
up system via unicast, multicast and broadcast frames. Otherwise,
multicast or unicast frame(e.g. ICMP echo request) can wake up
system which is not probably wanted behavior on most environments.
This was not known as problem because RL_CFG5 register access had
not effect until this change.
The capability to wake up system with unicast/multicast frames
are still set in driver, default off, so users who need that
feature can still activate it with ifconfig(8).
one. Interestingly, these are actually the default for quite some time
(bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9)
since r52045) but even recently added device drivers do this unnecessarily.
Discussed with: jhb, marcel
- While at it, use DEVMETHOD_END.
Discussed with: jhb
- Also while at it, use __FBSDID.
bit should not affect link establishment process of auto-negotiation
if manual configuration is not used, which is true in auto-negotiation.
However it seems setting this bit interfere with IP1001 PHY's
down-shifting feature such that establishing a 10/100Mbps link failed
when 1000baseT link is not available during auto-negotiation process.
Tested by: Andrey Smagin <samspeed <> mail dot ru >
Pause timer value is initialized to 0xFFFF. Controller allows just
4 different TX pause thresholds. The lowest possible threshold
value looks too aggressive so use next available threshold value.
- Remove MIIBUS statchg callback and program VGE_DIAGCTL before
initiating link establishment. Previously driver used to
program VGE_DIAGCTL after getting a link in statchg callback.
It seems the VGE_DIAGCTL register works like a kind of MII
register such that it requires setting a 'to be' mode in advance
rather than relying on resolved speed/duplex of established link.
This means the statchg callback is not needed in driver. In
addition, if there was no link at the time of media change, this
was not called at all.
- Introduce vge_ifmedia_upd_locked() to change current media to
configured one. Actual media change is performed only after PHY
reset and VGE_DIAGCTL setup.
- In WOL configuration, make sure to clear forced mode such that
controller can rely on auto-negotiation.
- Unlike most other drivers that use miibus(4), vge(4) used
controller's auto-polling feature for link state tracking via
interrupt. This came from controller's inefficient mechanism to
access MII registers. On link state change interrupt, vge(4)
used to get current link state with series of MII register
accesses. Because vge(4) already enabled auto polling, read PHY
status register to resolved speed/duplex/flow control parameters.
vge(4) still does not drive MII_TICK to reduce number of MII
register accesses which in turn means the driver does not know the
status of auto-negotiation. This was a one of long standing
issue of vge(4). Probably driver may be able to implement a timer
that keeps track of auto-negotiation state and restart
auto-negotiation when driver couldn't establish a link within a
specified period. However the controller does not provide a
reliable way to detect auto-negotiation failure so I'm not sure
whether it's worth to implement it in driver.
Alternatively driver can completely disable MII auto-polling and
let miibus(4) poll link state by driving MII_TICK. This may reduce
unnecessary overhead of stopping/restarting MII auto-polling of
controller. Unfortunately it was known that some variants of
controller does not work correctly if MII auto-polling is disabled.
This fixes panics that users have been seeing when operating in station mode,
where the interface undergoes a lot more resets then in hostap mode (ie whilst
doing channel scanning.)
Reported by: arundel, wblock@wonkity.com
Sponsored by: Hobnob, Inc.
passed over to the runtime firmware on 6050 devices. Instead let
the runtime firmware do the calibration itself. This fixes support
for the 6050 series devices.
Obtained from: OpenBSD
Submitted by: kevlo
Tested by: lx, Tz-Huan Huang(earlier version)
defined and will allow consumers, willing to provide options, file and
line to locking requests, to not worry about options redefining the
interfaces.
This is typically useful when there is the need to build another
locking interface on top of the mutex one.
The introduced functions that consumers can use are:
- mtx_lock_flags_
- mtx_unlock_flags_
- mtx_lock_spin_flags_
- mtx_unlock_spin_flags_
- mtx_assert_
- thread_lock_flags_
Spare notes:
- Likely we can get rid of all the 'INVARIANTS' specification in the
ppbus code by using the same macro as done in this patch (but this is
left to the ppbus maintainer)
- all the other locking interfaces may require a similar cleanup, where
the most notable case is sx which will allow a further cleanup of
vm_map locking facilities
- The patch should be fully compatible with older branches, thus a MFC
is previewed (infact it uses all the underlying mechanisms already
present).
Comments review by: eadler, Ben Kaduk
Discussed with: kib, jhb
MFC after: 1 month
mode configuration registers. This is apparently required for correct
behaviour, but also requires the chip to actually officially support it.
Sponsored by: Hobnob, Inc.
"correct" handling of frames in the RX pending queue during interface
transitions.
* ath_stoprecv() doesn't blank out the descriptor list - that's what
ath_startrecv() does. So, change a comment to reflect that.
* ath_stoprecv() does include a large (3ms) delay to let pending DMA
complete. However, I'm under the impression that the stopdma hal
method does check for a bit in the PCU to indicate DMA has stopped.
So, to help with fast abort and restart, modify ath_stoprecv() to take
a flag which indicates whether this is needed.
* Modify the uses of ath_stoprecv() to pass in a flag to support the
existing behaviour (ie, do the delay.)
* Remove some duplicate PCU teardown code (which wasn't shutting down DMA,
so it wasn't entirely correct..) and replace it with a call to
ath_stoprecv(sc, 0) - which disables the DELAY call.
The upshoot of this is now channel change doesn't simply drop completed
frames on the floor, but instead it cleanly handles those frames.
It still discards pending TX frames in the software and hardware queues
as there's no (current) logic which forcibly recalculates the rate control
information (or whether they're appropriate to be on the TX queue after
a channel change), that'll come later.
This still doesn't stop all the sources of queue stalls but it does
tidy up some of the code duplication.
To be complete, queue stalls now occur during normal behaviour -
they only occur after some kind of broken behaviour causes an interface
or node flush, upsetting the TX/RX BAW. Subsequent commits will
incrementally fix these and other related issues.
Sponsored by: Hobnob, Inc.
to the kernel's pause() function. The pause() function can now be used
when cold != 0. Also assert that the timeout in system ticks must be
positive.
Suggested by: Bruce Evans
MFC after: 1 week
to kern/subr_bus.c. Simplify this function so that it no longer
depends on malloc() to execute. Identify a few other places where
it makes sense to use device_delete_all_children().
MFC after: 1 week
It's not currently used; it didn't build on 32-bit and the previous build fix
is incorrect. If we really implement self-tests we can do this again
properly.
Submitted by: Ben Hutchings <bwh -at- solarflare.com>
MFC after: 3 weeks
This field is supposed to be set to the interface bit rate, but for some
reason I thought it was denominated in kilobits. Multiply the values up
accordingly, taking care to saturate rather than overflow on 32-bit
architectures.
Submitted by: Ben Hutchings <bwh -at- solarflare.com>
MFC after: 3 weeks
addresses from being probed and attaching something including ukphy(4)
to it. This is mainly necessarily for PHY switches that create duplicate
or fake PHYs on the bus that can corrupt the PHY state when accessed or
simply cause problems when ukphy(4) isolates the additional instances.
- Change miibus(4) to be a hinted bus, allowing to add child devices via
hints and to set their attach arguments (including for automatically
probed PHYs). This is mainly needed for PHY switches that violate IEEE
802.3 and don't even implement the basic register set so we can't probe
them automatically. However, the ability to alter the attach arguments
for automatically probed PHYs is also useful as for example it allows
to test (or tell a user to test) new variant of a PHY with a specific
driver by letting an existing driver attach to it via manipulating the
IDs without the need to touch the source code or to limit a Gigabit
Ethernet PHY to only announce up to Fast Ethernet in order to save
energy by limiting the capability mask. Generally, a driver has to
be hinted via hint.phydrv.X.at="miibusY" and hint.phydrv.X.phyno="Z"
(which already is sufficient to add phydrvX at miibusY at PHY address
Z). Then optionally the following attach arguments additionally can
be configured:
hint.phydrv.X.id1
hint.phydrv.X.id2
hint.phydrv.X.capmask
- Some minor cleanup.
Reviewed by: adrian, ray
dcphy(4) (CID 9283).
- In dc_detach(), check whether ifp is NULL as dc_attach() may call the
former without ifp being allocated (CID 4288).
Found with: Coverity Prevent(tm)
!DC_IS_ADMTEK in dc_miibus_statchg(). This change broke link
establishment of Intel 21143 with dcphy(4) where it stuck in
"ability detect" state without completing auto-negotiation.
Also nuke dc_if_media as it's not actually used.
Submitted by: marius
Tested on Qemu/KVM, VirtualBox, and BHyVe.
Currently built as modules-only on i386/amd64. Man pages not yet hooked
up, pending review.
Submitted by: Bryan Venteicher bryanv at daemoninthecloset dot org
Reviewed by: bz
MFC after: 4 weeks or so
for the ath(4) driver.
Currently, there's nothing stopping reset, channel change and general
TX/RX from overlapping with each other. This wasn't a big deal with
pre-11n traffic as it just results in some dropped frames.
It's possible this may have also caused some inconsistencies and
badly-setup hardware.
Since locks can't be held across all of this (the Linux solution)
due to LORs with the network stack locks, some state counter
variables are used to track what parts of the code the driver is
currently in.
When the hardware is being reset, it disables the taskqueue and
waits for pending interrupts, tx, rx and tx completion before
it begins the reset or channel change.
TX and RX both abort if called during an active reset or channel
change.
Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS
is set. Instead, completed TX and RX frames are passed back up to
net80211 before the reset occurs.
This is not without problems:
* Raw frame xmit are just dropped, rather than placed on a queue.
The net80211 stack should be the one which queues these frames
rather than the driver.
* It's all very messy. It'd be better if these hardware operations
were serialised on some kind of work queue, rather than hoping
they can be run in parallel.
* The taskqueue block/unblock may occur in parallel with the
newstate() function - which shuts down the taskqueue and restarts
it once the new state is known. It's likely these operations should
be refcounted so the taskqueue is restored once no other areas
in the code wish to suspend operations.
* .. interrupt disable/enable should likely be refcounted as well.
With this work, the driver does not drop frames during stuck beacon
or fatal errors and thus 11n traffic continues to run correctly.
Default and full resets however do still drop frames and it's possible
this may occur, causing traffic loss and session stalls.
Sponsored by: Hobnob, Inc.
completely skipping them, create ahcich devices for them to allocate unit
numbers, but mark them as disabled to prevent driver probe and attach.
Last time some BIOSes tend to report unused channels as "not implemented".
This change makes ahcichX devices numbering consistent, independently of
connected disks. It makes per-channel driver hints usable and CAM devices
wiring possible on such systems.
I/O from userspace, capable of line rate at 10G, see
http://info.iet.unipi.it/~luigi/netmap/
At this time I am bringing in only the generic code (sys/dev/netmap/
plus two headers under sys/net/), and some sample applications in
tools/tools/netmap. There is also a manpage in share/man/man4 [1]
In order to make use of the framework you need to build a kernel
with "device netmap", and patch individual drivers with the code
that you can find in
sys/dev/netmap/head.diff
The file will go away as the relevant pieces are committed to
the various device drivers, which should happen in a few days
after talking to the driver maintainers.
Netmap support is available at the moment for Intel 10G and 1G
cards (ixgbe, em/lem/igb), and for the Realtek 1G card ("re").
I have partial patches for "bge" and am starting to work on "cxgbe".
Hopefully changes are trivial enough so interested third parties
can submit their patches. Interested people can contact me
for advice on how to add netmap support to specific devices.
CREDITS:
Netmap has been developed by Luigi Rizzo and other collaborators
at the Universita` di Pisa, and supported by EU project CHANGE
(http://www.change-project.eu/)
The code is distributed under a BSD Copyright.
[1] In my opinion is a bad idea to have all manpage in one directory.
We should place kernel documentation in the same dir that contains
the code, which would make it much simpler to keep doc and code
in sync, reduce the clutter in share/man/ and incidentally is
the policy used for all of userspace code.
Makefiles and doc tools can be trivially adjusted to find the
manpages in the relevant subdirs.
controllers.
More and more RealTek controllers started to implement EEE feature.
Vendor driver seems to load a kind of firmware for EEE with
additional PHY fixups. It is known that the EEE feature may need
ASPM support. Unfortunately there is no documentation for EEE of
the controller so enabling ASPM may cause more problems.
Unnecessarily complex LE format used on Marvell controller was
main reason not to enable 64bit DMA addressing in driver. If high
32bit address of DMA address of TX/RX buffer is changed, driver has
to generate a new LE. In TX path, driver will keep track of lastly
used high 32bit address of DMA address and generate a new LE
whenever it sees high address change in the DMA address. In RX path,
driver will always use two LEs to specify 64bit DMA address of RX
buffer. If the high 32bit address of DMA address of RX buffer is
the same as previous DMA address of RX buffer, driver does not have
to use two LEs but driver will use two LEs for simplicity in RX
ring management.
One of draw back for switching to 64bit DMA addressing is that the
large amount of LEs are used to specify 64bit DMA address such that
number of available LEs for TX/RX buffers are considerably reduced.
To mitigate the issue, increase number of available LEs from 256 to
384 for TX and from 256 to 512 for RX. For 32bit architectures,
msk(4) does not use 64bit DMA addressing to save resources.
Tested by: das
