for buffer allocation. If driver know we are out of Rx buffers let
controller stop. This should fix panic when interface is run even
if it had no configured Rx buffers.
and Rx DMA tag separately. Previously it used a common mbuf DMA tag
for both Tx and Rx path but Rx buffer(standard ring case) should
have a single DMA segment and maximum buffer size of the segment
should be less than or equal to MCLBYTES. This change also make it
possible to add TSO with minor changes.
bge_newbuf_std still has a bug for handling dma map load failure
under high network load. Just reusing mbuf is not enough as driver
already unloaded the dma map of the mbuf. Graceful recovery needs
more work.
Ideally we can just update dma address part of a Rx descriptor
because the controller never overwrite the Rx descriptor. This
requires some Rx initialization code changes and it would be done
later after fixing other incorrect bus_dma(9) usages.
instead of POSTREAD: the hardware do not touch this memory (CPU
updates it). It is already synchronized as PREWRITE after the
processing is done.
- Synchronize RX return ring memory in rx_eof. This is needed
as the deviced updates this memory when receives packets.
- Decouple the synchronization of BGE status block in the interrupt
service routine: perfrom PREREAD synchronization only all accesses
to this block are finished. This seems to be more natural.
Reviewed by: yongari, marius
MFC after: 2 weeks
to the lock we hold, disable interrupts, and announce to the firmware
that we are shutting down. Especially do this before disabling blocks.
This makes some types of machines with asf enabled no longer hang upon
boot, when we start configuring the interface.
PR: i386/96382, kern/100410, kern/122252, kern/116328
Reported by: erwin
Hardware provided by: TDC A/S
Reviewed by: stas
Tested by: stas
BGE_PCI_PRODID_ASICREV register to store the chip identifier and its revision.
- Add new grouping macro for 7575+ chips (BGE_IS_5755_PLUS).
- Add IDs for Fujitsu-branded Broadcom adapters.
PR: kern/127587
Tested by: Thomas Quinot <thomas@quinot.org> (BCM7561 A0)
MFC after: 2 weeks
Obtained from: OpenBSD
loop iteration as it can be updated by the card while we
process the RX ring forcing us to process RX descriptors
for which DMA synchronisation operation has not been
performed. This fixes the bug when bge(4) drops packets
under high load.
Discussed with: yongari, marius
Approved by: re (kib)
MFC after: 1 week
IF_ADDR_UNLOCK() across network device drivers when accessing the
per-interface multicast address list, if_multiaddrs. This will
allow us to change the locking strategy without affecting our driver
programming interface or binary interface.
For two wireless drivers, remove unnecessary locking, since they
don't actually access the multicast address list.
Approved by: re (kib)
MFC after: 6 weeks
CPU for too long period than necessary. Additively, interfaces are kept
polled (in the tick) even if no more packets are available.
In order to avoid such situations a new generic mechanism can be
implemented in proactive way, keeping track of the time spent on any
packet and fragmenting the time for any tick, stopping the processing
as soon as possible.
In order to implement such mechanism, the polling handler needs to
change, returning the number of packets processed.
While the intended logic is not part of this patch, the polling KPI is
broken by this commit, adding an int return value and the new flag
IFCAP_POLLING_NOCOUNT (which will signal that the return value is
meaningless for the installed handler and checking should be skipped).
Bump __FreeBSD_version in order to signal such situation.
Reviewed by: emaste
Sponsored by: Sandvine Incorporated
drops and re-grabs the softc mutex in the middle, resulting in kernel
trap 12. This may happen when a lot of traffic is being hammered on
one bge(4) interface while the system is shutting down.
Reported by: Alexander Sack <pisymbol gmail com>
PR: kern/134548
MFC After: 2 weeks
quirk requiring it to be enabled even when using MSI. This makes
the latter work again after r189285.
- Remove a comment which no longer applies since r190194.
- If boot verbose, print asicrev, chiprev and bus type on attach.
- For PCI Express devices:
1) Adjust max read request size to 4Kbytes
2) Turn on FIFO_LONG_BURST in RDMA during bge_blockinit()
Though 1) does not seem to have much to do with the poor TX performance
observed on PCI Express bge(4), 2) does fix the problem. [1]
- Nuke the RX CPU self-diag, which prevents working cards from working
(Linux tg3 does not have this diag neither does OpenBSD's bge(4)).
The increasing of the firmware handshaking timeout to 20000 retries
done as part of the original commit isn't merged as way already have a
way higher BGE_TIMEOUT of 100000.
PR: 119361 [1]
Obtained from: tg3 via DragonflyBSD [1], DragonflyBSD
causes data corruption in combination with certain bridges.
Information about this problem was kindly provided by davidch. [1]
- As BGE_FLAG_PCIX is meant to indicate that the controller is in
PCI-X mode, revert to the pre __FreeBSD_version 602101 method of
reading the bus mode register rather than checking the mere
existence of a PCI-X capability, which is also there when the
NIC f.e. is put into a 32-bit slot causing it not to be in PCI-X
mode. Setting BGE_FLAG_PCIX inappropriately could cause the NIC
to be tuned incorrectly.
PR: 128833 [1]
Reviewed by: jhb
MFC after: 3 days
for the BCM5714 revision A0 when in a multi-port configuration
and unconditionally for the remainder of the class of BCM575X
and beyond chips.
This was prodded by mav and is based on a suggestion and a
patch submitted by jhb.
Reviewed by: jhb
MFC after: 2 months
containing an Ethernet address fitted as this is yet another thing
that fails in that case in order to avoid the one second delay
until pci_read_vpd_reg() times out.
- Const'ify the bge_devs array.
- Rename BGE_FLAG_EEPROM to BGE_FLAG_EADDR to underline it's absence means
"there's no chip containing an Ethernet address fitted to the BGE chip
so we have to get it from the firmware instead" rather than "there's no
EEPROM, but maybe NVRAM or something else".
- Don't treat BCM5906[M] generally like chips w/o BGE_FLAG_EADDR set, just
in the two cases really necessary. This gets us line with the original
patch for DragonFlyBSD.
- For sparc64 restore the intended behavior of obtaining the Ethernet
address from the firmware in case BGE_FLAG_EADDR is not set, even for
BCM5906[M].
- Fix some style(9) bugs introduced with rev. 1.208 of if_bge.c
Approved by: jhb
Additional testing by: Thomas Nystroem (BCM5906)
all cards/modes.
In addition to the intr forcing added with rev. 1.205 adopt the other
places to use the same logic.
We need to exclude a few chips/revisions (5700, 5788) from using the
enhanced version and fall back to the old way as that is the only
method they support.
Tested by: phk
Suggested by: davidch, Broadcom (thanks a lot for the help!)
MFC after: 16 days
10/100 operation and place the mailbox registers at a different offset.
They also do not have an EEPROM, so the MAC address must be read from
NVRAM instead.
MFC after: 1 month
PR: kern/118975
Submitted by: benjsc, Thomas Nyström thn at saeab dot se
Submitted by: sephe (original patch for DragonflyBSD)
when creating the parent bus DMA tag. While at it correct the style
and a nearby comment.
- Take advantage of m_collapse(9) for performance reasons.
MFC after: 2 weeks
Because of this we were not getting further interrupts for link state
changes, thus never went into iface UP state and thus could not transmit.
The only way out of this was an incoming packet generating an rx interrupt
and making us call into bge_link_upd.
Up to rev. 1.101, in bge_start_locked, we only returned instantly
if there was 'no link AND nothing queued for tx'. So with a packet queued
for tx, we hit the register scrubbing at the end of bge_start_locked
and were out fine. We simply lost a packet or two but got the interrupts
need to get into UP state.
With rev. 1.102 this was turned into 'if there is no link OR there is
nothing to send' (correct behaviour) and as long as there is no link
we never hit the register scrubbing and consequently never got the link UP.
What we do now is force an interrupt at the end of bge_ifmedia_upd_locked
so we will call bge_link_upd, clear the link state attention and get
further interrupts.
This helps to get the iface UP on an idle network or at least to get
it UP faster not depending on an rx intr anymore.
In case you could not get a DHCP lease or it took very long,
it was because of this.
It is unknown which chips are affected by this. ASIC rev. 0x2003 was the
most popular trouble candidate.
At least the fiber cards should have been working fine.
Which register to scrub is currently under discussion. The comitted
solution was tested and found to work for a lot of setups. It might
not help with MSI.
The reason why we end up in such a situation is entirely unknown.
PR: kern/111804
Tested by: phk, scottl at Y!
MFC after: 14 days
The register layout is little different from memory-mapped stats
in the previous generation chips. In fact, it is bad because
registers in this range are cleared after reading them.
Reviewed by: scottl
MFC after: 3 days
support machines having multiple independently numbered PCI domains
and don't support reenumeration without ambiguity amongst the
devices as seen by the OS and represented by PCI location strings.
This includes introducing a function pci_find_dbsf(9) which works
like pci_find_bsf(9) but additionally takes a domain number argument
and limiting pci_find_bsf(9) to only search devices in domain 0 (the
only domain in single-domain systems). Bge(4) and ofw_pcibus(4) are
changed to use pci_find_dbsf(9) instead of pci_find_bsf(9) in order
to no longer report false positives when searching for siblings and
dupe devices in the same domain respectively.
Along with this change the sole host-PCI bridge driver converted to
actually make use of PCI domain support is uninorth(4), the others
continue to use domain 0 only for now and need to be converted as
appropriate later on.
Note that this means that the format of the location strings as used
by pciconf(8) has been changed and that consumers of <sys/pciio.h>
potentially need to be recompiled.
Suggested by: jhb
Reviewed by: grehan, jhb, marcel
Approved by: re (kensmith), jhb (PCI maintainer hat)
sysctl_handle_int is not sizeof the int type you want to export.
The type must always be an int or an unsigned int.
Remove the instances where a sizeof(variable) is passed to stop
people accidently cut and pasting these examples.
In a few places this was sysctl_handle_int was being used on 64 bit
types, which would truncate the value to be exported. In these
cases use sysctl_handle_quad to export them and change the format
to Q so that sysctl(1) can still print them.
Blade 2500, Fire V210 and probably some other sparc64 machines.
These chips are typically not fitted with an EEPROM which means
that we have to obtain the MAC address via OFW and that some chip
tests will just always fail.
These changes are based on the respective code found in OpenBSD
with some additional info obtained from OpenSolaris and some style
suggestions by jkim@. They also have the desired side-effect of
respecting the 'local-mac-address?' system configuration variable
for the affected BGEs.
- In bge_attach() factor out calling bge_release_resources() before
going to the fail label into the fail label as well as replace a
magic 6 with ETHER_ADDR_LEN.
Reviewed by: yongari (before style changes), jkim
- Remove some excessive parentheses around shift operators.
- Use macro instead of magic number where it is applicable.
- Change lower-case hexdecimals to upper cases to match wpaul's style.
- Revert some unnecessary line wraps and changes from the previous commit.
Pointed out by: bde
- Move some PHY bug detections from brgphy.c to if_bge.c.
- Do not penalize working PHYs.
- Re-arrange bge_flags roughly by their categories.
- Fix minor style(9) nits.
PR: kern/107257
Obtained from: OpenBSD
Tested by: Mike Hibler <mike at flux dot utah dot edu>
bge_intr(). Some of them are used in bge_poll(). Simplify by only
initializing these for polling mode and not toggling them when switching
modes. This also fixes missing synchronization with the coalescing
engine in the toggling.
been handled instead of when at least one descriptor was just handled.
For bge, it is normal to get a txeof when only a small fraction of the
queued tx descriptors have been handled, so the bug broke the watchdog
in a usual case.
- moved the synchronizing bus read to after the bus write for the first
interrupt ack so that it actually synchronizes everything necessary.
We were acking not only the status update that triggered the interrupt
together with any status updates that occurred before we got around
to the bus write for the ack, but also any status updates that occur
after we do the bus write but before the write reaches the device.
The corresponding race for the second interrupt ack resulted in
sometimes returning from the interrupt handler with acked but
unserviced interrupt events. Such events then remain unserviced
until further events cause another interrupt or the watchdog times
out.
The race was often lost on my 5705, apparently since my 5705 has broken
event coalescing which causes a status update for almost every packet,
so another status update is quite likely to occur while the interrupt
handler is running. Watchdog timeouts weren't very noticeable,
apparently because bge_txeof() has one of the usual bugs resetting the
watchdog.
- don't disable device interrupts while bge_intr() is running. Doing this
just had the side effects of:
- entering a device mode in which different coalescing parameters apply.
Different coalescing parameters can be used to either inhibit or
enhance the chance of getting another status update while in the
interrupt handler. This feature is useless with the current
organization of the interrupt handler but might be useful with a
taskqueue handler.
- giving a race for ack+reenable/return. This cannot be handled
by simply rearranging the order of bus accesses like the race for
ack+keepenable/entry. It is necessary to sync the ack and then
check for new events.
- taking longer, especially with the extra code to avoid the race on
ack+reenable/return.
Reviewed by: ru, gleb, scottl
- Do not repeatedly read vendor/device IDs while probing.
- Remove redundant bzero(3) for softc. device_get_softc(9) does it for free[1].
Reviewed by: glebius
Suggested by: glebius[1]
have been added erroneously, and it causes problems on some chips. A larger
change is needed to do this write at a more appropriate place, but that
change requires reworking the ASF logic. That will be worked on in the
future.
Submitted by: Bruce Evans
- Use the appropriate register writing method when reseting the chip
- Program the descriptor DMA engine correctly.
- More reliably detect certain chips and their features.
Also add some low-level debugging tools to help future work on this driver.
Submitted by: David Christenson (proof of concept changes)
Sponsored by: www.UIA.net
- Correct RX packet drop counter for BCM5705+. This register is read/clear
and it wraps very quickly under heavy packet drops because only the lower
ten bits are valid according to the documentation. However, it seems few
more bits are actually valid and the rest bits are always zeros[1].
Therefore, we don't mask them off here. To get accurate packet drop count,
we need to check the register from bge_rxeof(). It is commented out for now,
not to penalize normal operation. Actual performance impact should be
measured later.
- Correct integer casting from u_long to uint32_t. Casting is not really
needed for all supported platforms but we better do this correctly[2].
Tested by: bde[1]
Suggested by: bde[2]
discarded RX packets to input error for BCM5705 or newer chipset as the others.
Unfortunately we cannot do the same for output errors because ifOutDiscards
equivalent register does not exist. While I am here, replace misleading and
wrong BGE_RX_STATS/BGE_TX_STATS with BGE_MAC_STATS. They were reversed but
worked accidently.
m_pkthdr.ether_vlan. The presence of the M_VLANTAG flag on the mbuf
signifies the presence and validity of its content.
Drivers that support hardware VLAN tag stripping fill in the received
VLAN tag (containing both vlan and priority information) into the
ether_vtag mbuf packet header field:
m->m_pkthdr.ether_vtag = vlan_id; /* ntohs()? */
m->m_flags |= M_VLANTAG;
to mark the packet m with the specified VLAN tag.
On output the driver should check the mbuf for the M_VLANTAG flag to
see if a VLAN tag is present and valid:
if (m->m_flags & M_VLANTAG) {
... = m->m_pkthdr.ether_vtag; /* htons()? */
... pass tag to hardware ...
}
VLAN tags are stored in host byte order. Byte swapping may be necessary.
(Note: This driver conversion was mechanic and did not add or remove any
byte swapping in the drivers.)
Remove zone_mtag_vlan UMA zone and MTAG_VLAN definition. No more tag
memory allocation have to be done.
Reviewed by: thompsa, yar
Sponsored by: TCP/IP Optimization Fundraise 2005
if_watchdog, etc., or in functions used only in these methods.
In all other functions in the driver use device_printf().
- Use __func__ instead of typing function name.
Submitted by: Alex Lyashkov <umka sevcity.net>
to it. Try to co-operate with the IPMI/ASF firmware accessing the PHY.
One we get link we don't mess with the PHY. If we do then over time
the NIC will go off line. It would be nice if we could tell if IPMI
was enabled on the chip but I can't figure out a reliable way to do
that. The scheme I tried worked on a Dell PE850 but not on an HP machine.
So we assume any NIC that has ASF capability needs to deal with it.
The code was inspired by the support in Linux from kernel.org and Broadcom.
Broadcom did give me some info. but it is rather limited and is mostly
just what is in the Linux driver. Thanks to the numerous people that
helped debug the many prior versions and that I didn't break other
bge(4) HW.
Reviewed by: several people
Tested by: even more
required by arches like sparc64 (not yet implemented) and sun4v where there
are seperate IOMMU's for each PCI bus... For all other arches, it will
end up returning NULL, which makes it a no-op...
Convert a few drivers (the ones we've been working w/ on sun4v) to the
new convection... Eventually all drivers will need to replace the parent
tag of NULL, w/ bus_get_dma_tag(dev), though dev is usually different for
each driver, and will require hand inspection...
Reviewed by: scottl (earlier version)
Following issues should be resolved:
- random watchdog timeouts (caused by concurrent phy access)
- some link state issues
- non working TX if media type was set explicitly
PR: kern/98738
Approved by: glebius (mentor)
MFC after: 2 weeks
