to dequeue a packet.
The tx path was trying to ensure that enough Xenbus TX ring slots existed but
it didn't check to see whether the mbuf TX ring slots were also available.
They get freed in xn_txeof() which occurs after transmission, rather than earlier
on in the process. (The same happens under Linux too.)
Due to whatever reason (CPU use, scheduling, memory constraints, whatever) the
mbuf TX ring may not have enough slots free and would allocate slot 0. This is
used as the freelist head pointer to represent "free" mbuf TX ring slots; setting
this to an actual mbuf value rather than an id crashes the code.
This commit introduces some basic code to track the TX mbuf ring use and then
(hopefully!) ensures that enough slots are free in said TX mbuf ring before it
enters the actual work loop.
A few notes:
* Similar logic needs to be introduced to check there are enough actual slots
available in the xenbuf TX ring. There's some logic which is invoked earlier
but it doesn't hard-check against the number of available ring slots.
Its trivial to do; I'll do it in a subsequent commit.
* As I've now commented in the source, it is likely possible to deadlock the
driver under certain conditions where the rings aren't receiving any changes
(which I should enumerate) and thus Xen doesn't send any further software
interrupts. I need to make sure that the timer(s) are running right and
the queues are periodically kicked.
PR: 134926
Slot 0 must always remain "free" and be a pointer to the first free entry in the
mbuf descriptor list. It is thus an error to have code allocate or push slot 0
back into the list.
get a quick snapshot of the kernel's symbol table including the symbols
from any loaded modules (the symbols are all merged into one symbol
table). Unlike like other implementations, this ksyms driver maps
memory in the process memory space to store the snapshot at the time
/dev/ksyms is opened. It also checks to see if the process has already
a snapshot open and won't allow it to open /dev/ksyms it again until it
closes first. This prevents kernel and process memory from being
exhausted. Note that /dev/ksyms is used by the lockstat(1) command.
Reviewed by: gallatin kib (freebsd-arch)
Approved by: gnn (mentor)
severe silicon bugs that can't handle VLAN hardware tagging as well
as status LE writeback bug. The status LE writeback bug is so
critical we can't trust status word of received frame. To accept
frames on Yukon FE+ A0 msk(4) just do minimal check for received
frames and pass them to upper stack. This means msk(4) can pass
corrupted frames to upper layer. You have been warned!
Also I supposed RX_GMF_FL_THR to be 32bits register but Linux
driver treated it as 16bit register so follow their leads. At least
this does not seem to break msk(4) on Yukon FE+.
Tested by: bz, Tanguy Bouzeloc ( the.zauron <> gmail dot com )
Bruce Cran ( bruce <> cran dot org dot uk )
Michael Reifenberger ( mike <> reifenberger dot com )
Stephen Montgomery-Smith ( stephen <> missouri dot edu )
Yukon FE+ is fast ethernet controller and uses new descriptor
format. Since I don't have this controller, the support code was
written from guess and various feedback from enthusiastic users.
Thanks to all users who patiently tested my initial patches.
Special thanks to Tanguy Bouzeloc who fixed critical bug of initial
patch.
Tested by: bz, Tanguy Bouzeloc ( the.zauron <> gmail dot com )
Bruce Cran ( bruce <> cran dot org dot uk )
Michael Reifenberger ( mike <> reifenberger dot com )
Stephen Montgomery-Smith ( stephen <> missouri dot edu )
The GM_GP_CTRL register may have stale content from previous link
information so clearing it will make hardware update the register
correctly when it established a valid link.
While I'm here remove stale comment.
does not guarantee established link. Also 1000baseT link report for
fast ethernet controller is not valid one so make sure gigabit link
is allowed for this controller.
Whenever we lost link, check whether Rx/Tx MACs were enabled. If both
MAC are not active, do not try to disable it again.
mark controller's capability. Controllers that have jumbo frame
support sets MSK_FLAG_JUMBO, and controllers that does not support
checksum offloading for jumbo frames will set MSK_FLAG_JUMBO_NOCSUM.
For Fast Ethernet controllers it will set MSK_FLAG_FASTETHER and it
would be used in link state handling.
While here, disable Tx checksum offloading if jumbo frame is used
on controllers that does not have Tx checksum offloading capability
for jumbo frame(e.g. Yukon EC Ultra).
FE+ controller. Due to the severe silicon bugs for Yukon FE+,
88E3016 seems to require more workarounds. However I'm not sure
whether the workaround is PHY specific or only applicable to Yukon
FE+. The datasheet for the PHY is publicly available but it lacks
several details for the workaround used in this change. The
workaround information was obtained from Linux. Many thanks to
Yukon FE+ users who helped me add 88E3016 support.
Tested by: bz, Tanguy Bouzeloc ( the.zauron <> gmail dot com )
Bruce Cran ( bruce <> cran dot org dot uk )
Michael Reifenberger ( mike <> reifenberger dot com )
Stephen Montgomery-Smith ( stephen <> missouri dot edu )
advertisement register. Some PHYs such as 88E3016 requires NEXT
Page capability to establish valid link. Also set protocol selector
field which is read only but it makes the intention clearer.
is valid only for auto-negotiation case so check the bit if we know
auto-negotiation is active. While I'm here explicitly checks
current speed with speed mask and set IFM_NONE if resolved speed
is unknown.
checks extended status register to see whether the PHY is fast
ethernet or not. This removes a lot of checks for specific PHY
models and it makes easy to add more PHYs to e1000phy(4).
While I'm here remove setting mii_anegticks as it is set with
mii_phy_add_media().
Remove PAGE_SIZE alignment used in Rx buffer DMA tag creation. The
alignment restriction was used in old local jumbo allocator and
nfe(4) switched to UMA backed page allocator for jumbo frame.
This change should fix jumbo buffer allocation failure.
Reported by: Pascal Braun ( pascal.braun <> continum dot net )
only if prepping the adapter failed.
Slight adjustment to comments.
Fix a bug whereby downing the interface didn't preven it from
processing packets.
Submitted by: Navdeep Parhar
MFC after: 1 week