entered the interface start function, no packets were actually dequeued.
Therefore, keep a count of how many packets we really added onto the tx
chain, and initiate a transmit only if the count is non-zero.
frames. BGE hardware with the rx alignment bug will still be handled by the
calls to m_adj() that already exist. m_adj() is probably better suited for
this task anyways. Just as with if_em, this saves a malloc + several locks
per packet and prevents unneeded data copying within busdma.
I have from Broadcom does not give much information on these devices,
so the Broadcom Linux driver was used for clues to what these chips
support. It turns out they are similar to the 5705 with the 5751
being the PCI-Express version and needing special work-arounds and
settings.
copper NICs, a link change event is posted whenever MII autopolling is
toggled off and on, which happens whenever someone calls
bge_miibus_readreg() or bge_miibus_writereg() to access the PHY
registers. This means anytime someone called the SIOCGIFMEDIA ioctl
on a bge interface, the link would reset. Even a simple "ifconfig bge0"
would do it, though other apps like dhclient or the PPPoE daemon could
trigger it as well. An obvious symptom of this problem is lots of
"bgeX: gigabit link up" messages appearing on the console for no
apparent reason.
Through experimentation, I determined that when a real link change
event occurs, the BGE_MIMODE_AUTOPOLL in the BGE_MI_MODE register
is always set, so now if we have a copper NIC and an link change
event occurs and the BGE_MIMODE_AUTOPOLL bit is clear, we ignore
the event.
Note that this does not apply to the original BCM5700 chip since we
use a different method for sensing link changes with that chip (the
status block method was broken), nor to fiber optic NICs since they
don't use the GMII PHY access registers.
(in particular, bge(4) hasn't supported rxcsum since if_bge.c#1.5)
Clean up some aspects of capabilities usage, i.e. stop using
if_hwassist to see whether we are doing offload now because if_hwassist
is for TCP/IP layer and it is subordinate to if_capenable.
Thanks to: Aled Morris for donating a nice bge(4) NIC to me
Reviewed by: -net, -hackers (silence)
mode. The 5704 apparently has some s00p3r s33kr1t registers for setting
the advertisement of pause frame ability (i.e flow control) when in
autoneg mode. If we don't set these registers correctly, we may not
be able to negotiate a proper link with some switches. (Symptom is that
the NIC reports the link as up (PCS synched) but no traffic can be
exchanged.)
PR: kern/67598
multicast hash are written. There are still two distinct algorithms used,
and there actually isn't any reason each driver should have its own copy
of this function as they could all share one copy of it (if it grew an
additional argument).
if_xname, if_dname, and if_dunit. if_xname is the name of the interface
and if_dname/unit are the driver name and instance.
This change paves the way for interface renaming and enhanced pseudo
device creation and configuration symantics.
Approved By: re (in principle)
Reviewed By: njl, imp
Tested On: i386, amd64, sparc64
Obtained From: NetBSD (if_xname)
These are 10/100 only NICs found on the IBM Thinkpad R40E and
G40. These seem to be based on the BCM5705 MAC but with a PHY
that doesn't support 1000Mbps modes.
Submitted by: Igor Sviridov <sia@nest.org>
to configure this correctly yields many watchdog timeouts even on lightly
loaded machines. This is a common complaint from users with Dell 1750
servers with built-in dual 5704 NICs.
BGE_MACSTAT_MI_COMPLETE bit in the MAC status register as a link
change indicator. We turn this bit on now because some of the newer
chips need it, but it usually just means that reading/writing
an MII/GMII register has completed, not that a link change has
occured.
larger than normal frames, to account for the case where a bge(4) NIC
is used with VLANs. Since we set the IFCAP_VLAN_MTU flag, we must allow
reception of frames up to 1522 bytes in size rather than 1518.
Note that it is possible to work around this bug by doing:
# ifconfig bge0 mtu 1504
prior to configuring any VLAN interfaces.
- 5705 doesn't support jumbo frames
- Statistics must be read from registers
- RX return ring must be capped at 512 entries
- Omit initialization of certain device blocks
- Acknowledge link change interrupts by setting the 'link changed'
bit in the status register (used to have no effect)
- Remember to toggle the MI completion bit too
- Set the mbuf low watermark differently (on-chip memory buffers,
not BSD mbufs)
- Don't enable Ethernet@WireSpeed feature for certain 5705 chip revs
- Add additional PCI IDs for 5705 and 5782 parts
- Add a forgotten 5704 PCI ID
Most changes ripped kicking and screaming from the Broadcom linux driver.
Thanks to Paul Saab for sanity testing. (My lack of sanity has been
confirmed.)
(mainly the 3Com 3c996B/BCM5701).
For some reason that I don't fully understand, the 5701 signals PCS
encoding errors as though they were link change events, i.e. the 'link
state changed' bit in the status word of the status block is updated
and an interrupt is generated. This would cause the bge_tick() function
to be invoked and a "gigabit link up" message to be printed on the console.
To avoid this, the interrupt handler now checks the MAC status register
when a link change interrupt is triggered, and it will only call the
bge_tick() function if the 'PCS encoding error detected' bit is clear.
(This change should have no effect on copper NICs since this bit can
only ever be set in TBI mode. I do not know how it affects 5704 NICs
with a BCM8002 SERDES PHY.)
Special thanks to: Sherry Rogers at UCB for allowing me access to one
of their traffic monitor boxes so I could diagnose this problem.
ASIC revision is really the major number of the CHIPID. Also store
the chipid, asic rev and chip revision in the softc for later use.
- The write twice to send producer index workaround only applies to
the 5700_BX chips, so only do it there.
Requested by: jdp
- Do not initalize the LED's to 0x00. The default configuration
the chip comes up in should yeild proper operation of the LED's.
Confirmed by: John Cagle <john.cagle@hp.com>
Approved by: re (blanket)
