Only clear the IFF_OACTIVE flag when we have a chance of being able
to queue a packet to the hardware, instead of when the hardware queue
is empty, and fix up handling and prodding of the tx.
These fixes clear up an occasional "sk0: watchdog timeout" from the
on-board ethernet on my Asus A8V motherboard.
OK christos@
o Intel 82801FBM ICH6M LPC Interface Bridge
o Intel 82801FB/FR PCI Express Port #2
o TI PCIxx21/x515 Cardbus Controller
o TI PCI7x21/7x11 IEEE 1394 Host Controller
o TI PCIxx11/21 Integrated FlashMedia Controller
Each call to the FreeBSD bge_start() routine the transmit producer
pointer index from the chip mailbox register BGE_MBX_TX_HOST_PROD0_LO.
The local copy of that value is then updated by bge_encap() as
bge_encap() encapsulates packets in the Tx ring. If bge_encap()
succeds in encpuslating one or more packets, bge_start() tells the
chip to start sending the newly-encinitiates writes the new value back
to the chip mailbox register.
However, comparison of the Linux drivers (Broadcom-supplied and
open-source tg3.c) and to the OpenSolaris driver confirms that
register BGE_MBX_TX_HOST_PROD0_LO is write-only to software.
Thus, we can just keep a copy in the softc, and eliminate the
(expensive) PCI register write on each call to bge_start().
``Make it so''.
blindly assuming MCLBYTES will DTRT.
- Use bus_dmamap_load_mbuf() instead of bus_dmamap_load() where
appropriate.
- If we have to coalesce a Tx mbuf chain comprised of more than IWI_MAX_NSEG
segments, allocate a cluster iff the payload won't fit in the header.
The change adopts the idea of fxp to drop the incoming packet and panic
if the old mbuf cannot be reloaded. Since the bus_dmamap is allocated
during attach, this is not supposed to happen. Since a lot of code moves
anyway, factor out the allocation of RX ring elements, which is shared
between the init path and the RX interrupt path.
XXX A better fix might be to borrow the mbuf from the logic end of the
XXX ring buffer, but that needs more involved driver changes.
Reviewed by dyoung@ and nick@
expensive, and pointless. As elsewhere in the kernel (and as approved
under FIPS-140-2 by multiple test labs, incidentally) we use arc4 to
generate IVs here; there is no benefit to their being cryptographically
strong so long as there is a sufficient Hamming distance between them.
and 795x. This was present in the driver before, but disabled due to
problems with the actual randomness of generated numbers on the
ubiquitious 7900-series parts. The code here is far, far more
conservative than anyone else's driver for this RNG is -- but I
believe that conservatism is called for, because the 79xx RNG
design is missing a number of pieces from Hifn's "reference" 6500
RNG, and thus the numbers it generates must be treated with some
care.
Support for the 7811 RNG (which is a full-fledged 6500 type
generator) is pretty much the same here as in other variants of
this driver, except that it uses Hifn's "worst case" estimate of
actual entropy per output bit, so it will accumulate bits much
more slowly. The 7811 support is untested.
alignment architectures
fix ETHER_ALIGN to 2 (same value as on FreeBSD) - appears VGE_FIXUP_RX
code cuts part of packet otherwise; also add comment about it's purpose
PR: 31323 by Murata Shuuichirou
- don't disable/enable as we're already at splnet()
- ack the interrupts early
Fixes my "lost interrupt" problem.
Thanks to dyoung and scw for the suggestions.
ignore errors of codec initializations if at least one
codec is initialized successfully
* azalia_alloc_dmamem()
fail if the HDA controller does not support 64 bit addressing
and buf_dmamap_* allocate a 64 bit address.
Pointed out by Brett Lymn
skrll