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''.
The __UNCONST macro is now used only where necessary and the RW macros
are gone. Most of the changes here are consumers of the
sysctl_createv(9) interface that now takes a pair of const pointers
which used not to be.
also restructure and simplify input VLAN ID code handling somewhat, to not use
local have_vlan/vlan_tag variables, and use the appropriate cur_rx condition
on the one place where it's needed
some special cases for the PCI-Express versions. As there is no
documentation available, all of this is inspired from Linux or taken from
FreeBSD (itself inspired from Linux). There are a lot of magic numbers.
Tested on two BCM5751 devices as found in newer Dell computers.
pass the bge_softc * to a function expecting the struct ifnet*,
triggering a panic every time the Rx-mitigation value is changed via sysctl.
(Testing via kernel debugger before Andrew's recent sysctl(9) changes
was done with the exact same mistaken argument.)
(tightly scoped) reason for recording the node address by recording
the assigned number. Dink pci/if_bge.c to match, since ic/ath.c was
used as the archetype.
yesterday's sys/dev/ic/ath.c) to match today's ath.c driver.
Commit now in the hope that Andrew Brown will pick up this file for
any more pending changes.
Rx interrupts, functions to post a request for new table entries, and
code to apply pending Rx-interrupt control values at the next hardware
interrupt.
As used in a third-party proprietary tree since at least March 2003.
As discussed on tech-kern/tech-net in January 2004 (in the context of
NetBSD for packet capture, bpf, and FreeBSD-sylte IFF_POLL), and as
posted to tech-net for comments in mid-March 2004.
Still missing sysctl or other knobs to acutally change the config-time
values, due to my ignorance of any accepted per-device sysctl namespace.
(e.g., polling for a half-second or more at splnet(), blocking most
interrupts, durin an ifconfig down/ifconfig up).
Appears to help for a 5704C rev A3, which is the only chip I've
ever seen that had even a mild version of the reported problem.
found empiricaly that (at least on bcm5700s) the Rx coalesce and bd
counts cannot be updated on-the-fly; attempting to do so (even at
splhigh()) causes weird behaviour.
Instead, add a softc flag to record that the desired softc values for
Rx-interrupt thresholds have changed; check that boolean in the interrupt
routine. If set, apply the new values there and clear the flag.
including chips that matched only the asic-revision fallback table.
When dong DMA setup for 5703 and 5704, use the new BGE_ASICREV() macro
to extract the ASIC revision.
* erratum: disable the nocrc RX bit, as it may cause problems on the 570{1-4}.
adjust the length of the incoming packet accordingly to trim it.
* the 5704 has a smaller MBUF_POOL, so set a smaller value
Local change:
* Pass the autoneg force flag to mii_attach. Some PHYs need to be kicked
out of their falsely autoneged 10baseT state with this.
* don't set the NOCRC bit in the mode control register, it can cause
problems on some chips (from the broadcom errata via FreeBSD)
* implement a fallback quirktable that is searched only using the
major asic revision, so that the driver has a shot at supporting
newer versions properly without modification
* rename asicrev -> chipid, like the FreeBSD driver
observation is that some 570x devices can get themselves into a state
where they miscompute off-loaded TCP or UDP checksums on packets so
small that Ethernet padding is required. Further obsevation suggests
that the bge checksum-offload hardware is adding those padding bytes
into its TCP checksum computation. (Once a 5700 gets in this state,
even a warm boot won't fix it: it needs a hard powerdown.)
Work around the problem by padding such runts with zeros: even if the
checksum-offload adds in extra zeros, the resulting sum will be correct.
Also, dont trust the checksum-offload on received packets smaller than
the minimum ethernet frame, in case the Rx-side has a similar bug.
Finally, on packets where we do trust the outboard Rx-side TCP or UDP
checksum, the bge did not include the pseudo-header. Set the
M_CSUM_NO_PSEUDOHDR bit as well as M_CSUM_DATA, and rely on
udp_input() or tcp_input() adding in the sum via in_cksum_phdr().
if we m_dup() a packet to compactify it, and later run out of DMA
descriptors, bge_encap() will return ENOBUFS, hoping the driver will
try again later. But we have just m_freem()'d the original chain
which was m_dup()'d, leaving a pointer to the just-freed packet header
in the tx queue.
Fix by always walking the chain, shuffling data towards the head;
except if we find a runt in the very last mbuf, we must borrow data
from its predecessor.
(Patch is verbatim from a third-party tree, apologies for any style woes.)
jonathan