should obviously have been CSR_READ(sc, BGE_MARB_MODE) incurred during
my backport of 5714/5715 support from my netbsd-3 development branch,
back into -current.
bcm5715 PCI-Express dual-port NICs. Taken from the Broadcom-supplied
Linux driver, bcm-8.3.13a.
Add nascent support for the bcm5780, but (since I have no bcm5780 to
test), don't yet add an entry which allows us to match or attach to a
5780.
Change 5752 support: Follow the lead of the Broadcom-supplied Linux
driver (bcm) and the Linux tg3 driver, and treat the 5752 like a 5750.
ethernet devices: bcm5714, bcm5752 (previously the 5789, but fvdl
committed that whilst I was musing).
Add definitions to sys/dev/pci/if_bgereg.h for the Broadcom 57xx-family
ASIC revisions on these newer chips.
Add entries to the PCI-device-version and bge-internal-asic-revision
tables in sys/dev/pci/if_bge.c to use these new devices. Pending
further information, follow the lead of FreeBSD's if_bge.c driver and,
pending further info, treat these new chips as we do the 5750.
shipped from the factory with TSO-capable firmware. The TSO support
here may also work on 5705 chips, but that is (so far) untested.
TSO support written after careful reading of the Linux tg3 driver,
and (after attempting to deconstruct the cut-and-paste mess therein)
very close reading of the Broadcom-supplied Linux driver, particularly
the building of Tx-DMA buffer descriptors (bds). The TSO code herein was
then rewritten from scratch, circa 4am local time, October 27 2005.
(In other words: this is 4am software; caveat emptor.)
Other magic register settings in this patch are required; without
them, attepmting to use TSO locks up the chip. The required register
settings were extracted from the cited Linux drivers.
Note that TSO-capable firmware for the 5703/5704 is distributed in
non-GPL form with the aforementioned Linux drivers. Once the 5705 case
is debugged, (particularly the pseudo-header checksum precalculation
flagged with an XXX) downloading that TSO-capable firmware to the
5703/5704 should, in principle, enable TSO support on all but the
original bcm5700 (I forget if the 5701 can support TSO, or not).
Note also that the ``hard case '' of IP/TCP headers spanning more than
one mbuf is not handled; I haven't been able to trigger it. In any
case, since TSO applies only to packets generated by the local TCP,
and our TCP always leaves space for TCP headers and a normal IP
header, TSO on an IP/TCP header spanning multiple headers can only
arise due to insertion of IP options. I beleive that we are clearly
better off outlawing that case, and requiring ip_insertoptions()
to pull-up TCP headers on any packets with M_CSUM_TSOv4 set.
As far as I know, bge hardwar does not support TSO for IPv6.
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.
perry