summaryrefslogtreecommitdiffstats
path: root/sys/dev/bge
Commit message (Collapse)AuthorAgeFilesLines
* Do a sweep of the tree replacing calls to pci_find_extcap() with calls tojhb2011-03-231-3/+3
| | | | pci_find_cap() instead.
* sysctl(9) cleanup checkpoint: amd64 GENERIC builds cleanly.mdf2011-01-121-1/+1
| | | | Commit the rest of the devices.
* Apply DMA address space restriction to controllers that have 4GByongari2011-01-101-1/+11
| | | | | | | | | | | | DMA boundary bug and runs with PCI-X mode. watchdog timeout was observed on BCM5704 which lives behind certain PCI-X bridge(e.g. AMD 8131 PCI-X bridge). It's still not clear whether the root cause came from that PCI-X bridge or not. The watchdog timeout indicates the issue is in TX path. If the bridge reorders TX mailbox write accesses it would generate all kinds of problems but I'm not sure. This should be revisited. Tested by: Michael L. Squires (mikes <> siralan dot org)
* Backout r216973 and r216970. r216973 didn't solve watchdog timeoutyongari2011-01-101-11/+1
| | | | | | | issue seen on PCIX BCM5704 controller. r216970 fixed the issue but the DMA address space restriction was applied to all bge(4) controllers such that it caused unnecessary performance degradation for controllers that have no such issues.
* Limit hardware bug workaround to controllers that have 4GB boundaryyongari2011-01-041-1/+4
| | | | | | | bug instead of blindly applying it to all controllers. Pointed out by: marius MFC after: 3 days
* Partially revert change made in r212061. r212061 relied onyongari2011-01-041-1/+8
| | | | | | | | | | | | | | | bus_dma(9)'s capability which honors boundary restrictions of DMA tag for dynamic buffers. However it seems this does not work well and it triggered watchodg timeouts on controller that has the hardware bug. It's not clear whether there is still another hardware bug not mentioned in errata. This should be revisited since this change shall make use of bounce buffers which in turn reduces performance a lot on systems that have more than 4GB memory. Reported by: Michael L. Squires (mikes <> siralan dot org) Tested by: Michael L. Squires (mikes <> siralan dot org) MFC after: 3 days
* - Remove the remaining support for older (in this case pre-7.0-RELEASE)marius2010-11-301-47/+19
| | | | | | | | | | | | versions of FreeBSD. In fact we are already missing a lot of conditional code necessary to support older versions of FreeBSD, including alternatives for vital functionality not yet provided by the respective subsystem back then (see for example r199663). So this change shouldn't actually break this driver on versions of FreeBSD that were supported before. Besides, this driver also isn't maintained as an multi-release version outside of the main repository, so removing the conditional code shouldn't be a problem in that regard either. - Sprinkle some more const on tables.
* Move the limiting of the PHY to 10/100 modes of operation due to limitationsmarius2010-11-141-5/+23
| | | | | | of certain MAC models from brgphy(4) to bge(4) where it belongs. While at it, update the list of models having that restriction to what OpenBSD uses, which in turn seems to have obtained that information from the Linux tg3 driver.
* o Flesh out the generic IEEE 802.3 annex 31B full duplex flow controlmarius2010-11-141-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | support in mii(4): - Merge generic flow control advertisement (which can be enabled by passing by MIIF_DOPAUSE to mii_attach(9)) and parsing support from NetBSD into mii_physubr.c and ukphy_subr.c. Unlike as in NetBSD, IFM_FLOW isn't implemented as a global option via the "don't care mask" but instead as a media specific option this. This has the following advantages: o allows flow control advertisement with autonegotiation to be turned on and off via ifconfig(8) with the default typically being off (though MIIF_FORCEPAUSE has been added causing flow control to be always advertised, allowing to easily MFC this changes for drivers that previously used home-grown support for flow control that behaved that way without breaking POLA) o allows to deal with PHY drivers where flow control advertisement with manual selection doesn't work or at least isn't implemented, like it's the case with brgphy(4), e1000phy(4) and ip1000phy(4), by setting MIIF_NOMANPAUSE o the available combinations of media options are readily available from the `ifconfig -m` output - Add IFM_FLOW to IFM_SHARED_OPTION_DESCRIPTIONS and IFM_ETH_RXPAUSE and IFM_ETH_TXPAUSE to IFM_SUBTYPE_ETHERNET_OPTION_DESCRIPTIONS so these are understood by ifconfig(8). o Make the master/slave support in mii(4) actually usable: - Change IFM_ETH_MASTER from being implemented as a global option via the "don't care mask" to a media specific one as it actually is only applicable to IFM_1000_T to date. - Let mii_phy_setmedia() set GTCR_MAN_MS in IFM_1000_T slave mode to actually configure manually selected slave mode (like we also do in the PHY specific implementations). - Add IFM_ETH_MASTER to IFM_SUBTYPE_ETHERNET_OPTION_DESCRIPTIONS so it is understood by ifconfig(8). o Switch bge(4), bce(4), msk(4), nfe(4) and stge(4) along with brgphy(4), e1000phy(4) and ip1000phy(4) to use the generic flow control support instead of home-grown solutions via IFM_FLAGs. This includes changing these PHY drivers and smcphy(4) to no longer unconditionally advertise support for flow control but only if the selected media has IFM_FLOW set (or MIIF_FORCEPAUSE is set) and implemented for these media variants, i.e. typically only for copper. o Switch brgphy(4), ciphy(4), e1000phy(4) and ip1000phy(4) to report and set IFM_1000_T master mode via IFM_ETH_MASTER instead of via IFF_LINK0 and some IFM_FLAGn. o Switch brgphy(4) to add at least the the supported copper media based on the contents of the BMSR via mii_phy_add_media() instead of hardcoding them. The latter approach seems to have developed historically, besides causing unnecessary code duplication it was also undesirable because brgphy_mii_phy_auto() already based the capability advertisement on the contents of the BMSR though. o Let brgphy(4) set IFM_1000_T master mode on all supported PHY and not just BCM5701. Apparently this was a misinterpretation of a workaround in the Linux tg3 driver; BCM5701 seem to require RGPHY_1000CTL_MSE and BRGPHY_1000CTL_MSC to be set when configuring autonegotiation but this doesn't mean we can't set these as well on other PHYs for manual media selection. o Let ukphy_status() report IFM_1000_T master mode via IFM_ETH_MASTER so IFM_1000_T master mode support now is generally available with all PHY drivers. o Don't let e1000phy(4) set master/slave bits for IFM_1000_SX as it's not applicable there. Reviewed by: yongari (plus additional testing) Obtained from: NetBSD (partially), OpenBSD (partially) MFC after: 2 weeks
* Add initial BCM5718 family support. The BCM5718 family includesyongari2010-10-272-69/+290
| | | | | | | | | | | | | | | | | | | | | | | the dual port BCM5717 and BCM5718 devices which are intended for mainstream workstation and entry-level server designs and represents the twelfth generation of NetXtreme Ethernet controllers. This family is the successor to the BCM5714/BCM5715 family and supports IPv4/IPv6 checksum offloading, TSO, VLAN hardware tagging, jumbo frames, MSI/MSIX, IOV, RSS and TSS. This change set supports all hardware features except IOV and RSS/TSS. Unlike its predecessors, only extended RX buffer descriptors can be posted to the jumbo producer ring. Single RX buffer descriptors for jumbo frame are not supported. RSS requires a more substantial set of changes and will apply to a larger set of NetXtreme devices so RSS/TSS multi-queue support will be implemented in a future releases. Special thanks to Broadcom who kindly sent a sample board to me and to davidch who gave provided the initial support code. Submitted by: davidch (initial version) HW donated by: Broadcom
* Use bge_chipid to compare controller ids. r214251 incorrectly usedyongari2010-10-241-3/+3
| | | | | | bge_chiprev. Reported by: Buganini <buganini <> gmail dot com >
* Apply the same workaround for SDI flow control used on BCM5906 A1yongari2010-10-232-5/+9
| | | | | | | | | | to BCM6906 A0/A2. This should fix a long standing BCM5906 A2 lockup issues. Data sheet explicitly mentions BCM5906 A0, A1 and A2 use de-pipelined mode on these revisions. Special thanks to Buganini who tried all combinations of experimental patches for more than 10 days. Tested by: Buganini <buganini <> gmail dot com >
* Add workaround for BCM5906 A1 controller silicon bug. Whenyongari2010-10-222-0/+6
| | | | | | | | | | | auto-negotiation results in half-duplex operation, excess collision on the ethernet link may cause internal chip delays that may result in subsequent valid frames being dropped due to insufficient receive buffer resources. The workaround is to choose de-pipeline method as a flow control decision for SDI. De-pipeline method allows only 1 data in TxMbuf at a time such that a request to RDMA from SDI is made only when TxMbuf is empty. Thanks for david for providing detailed errata information.
* Enable TX MAC state machine lockup fix for both BCM5755 or higheryongari2010-10-222-1/+7
| | | | | and BCM5906. Publicly available data sheet just says it may happen due to corrupted TxMbuf.
* Add workaround for BCM5906 controller silicon bug. If deviceyongari2010-10-192-0/+44
| | | | | | | | | receive two back-to-back send BDs with less than or equal to 8 total bytes then the device may hang. The two back-to-back send BDs must be in the same frame for this failure to occur. Thanks to davidch for detailed errata information. Reviewed by: davidch
* Convert the PHY drivers to honor the mii_flags passed down and convertmarius2010-10-152-12/+7
| | | | | | | | | | | | | | | | | | | | | | | the NIC drivers as well as the PHY drivers to take advantage of the mii_attach() introduced in r213878 to get rid of certain hacks. For the most part these were: - Artificially limiting miibus_{read,write}reg methods to certain PHY addresses; we now let mii_attach() only probe the PHY at the desired address(es) instead. - PHY drivers setting MIIF_* flags based on the NIC driver they hang off from, partly even based on grabbing and using the softc of the parent; we now pass these flags down from the NIC to the PHY drivers via mii_attach(). This got us rid of all such hacks except those of brgphy() in combination with bce(4) and bge(4), which is way beyond what can be expressed with simple flags. While at it, I took the opportunity to change the NIC drivers to pass up the error returned by mii_attach() (previously by mii_phy_probe()) and unify the error message used in this case where and as appropriate as mii_attach() actually can fail for a number of reasons, not just because of no PHY(s) being present at the expected address(es). Reviewed by: jhb, yongari
* Make sure to not use stale ip/tcp header pointers. The ip/tcpyongari2010-10-141-0/+2
| | | | | | | | | | | header parser uses m_pullup(9) to get access to mbuf chain. m_pullup(9) can allocate new mbuf chain and free old one if the space left in the mbuf chain is not enough to hold requested contiguous bytes. Previously drivers can use stale ip/tcp header pointer if m_pullup(9) returned new mbuf chain. Reported by: Andrew Boyer (aboyer <> averesystems dot com) MFC after: 10 days
* Fix a regression introduced in r213710. r213710 removed the use ofyongari2010-10-131-0/+7
| | | | | | | | | | | | | | | | | | auto polling such that it made all controllers obtain link status information from the state of the LNKRDY input signal. Broadcom recommends disabling auto polling such that driver should rely on PHY interrupts for link status change indications. Unfortunately it seems some controllers(BCM5703, BCM5704 and BCM5705) have PHY related issues so Linux took other approach to workaround it. bge(4) didn't follow that and it used to enable auto polling to workaround it. Restore this old behavior for BCM5700 family controllers and BCM5705 to use auto polling. For BCM5700 and BCM5701, it seems it does not need to enable auto polling but I restored it for safety. Special thanks to marius who tried lots of patches with patience. Reported by: marius Tested by: marius
* Add more checks for resolved link speed in bge_miibus_statchg().yongari2010-10-131-6/+24
| | | | | | | Link UP state could be reported first before actual completion of auto-negotiation. This change makes bge(4) reprogram BGE_MAC_MODE, BGE_TX_MODE and BGE_RX_MODE register only after controller got a valid link.
* Protect bge(4) from accessing invalid NIC internal memory regionsyongari2010-10-121-0/+8
| | | | | | on BCM5906. Tested by: Buganini < buganini <> gmail dot com >
* Fix a regression introduced in r213495. r213495 disabled miniyongari2010-10-121-1/+1
| | | | | | | | | | | receive producer ring only for BCM5700. It was believed that BCM5700 with external SSRAM is the only controller that supports mini ring but it seems all BCM570[0-4] requires to disable mini receive producer ring. Otherwise, it caused unexpected RX DMA error or watchdog timeouts. Reported by: marius, Steve Kargl <sgk <> troutmask dot apl dot washington dot edu> Tested by: marius, Steve Kargl <sgk <> troutmask dot apl dot washington dot edu>
* The IFF_DRV_RUNNING flag is set at the end of bge_init_locked. Butyongari2010-10-111-9/+13
| | | | | | | | | | | | before setting the flag, interrupt was already enabled such that interrupt handler could be run before setting IFF_DRV_RUNNING flag. This can lose initial link state change interrupt which in turn make bge(4) think that it still does not have valid link. Fix this race by protecting the taskqueue with a driver lock. While I'm here move reenabling interrupt code after handling of link state chage. Reviewed by: davidch
* Remove one last reference of BGE_MI_MODE register for auto polling.yongari2010-10-111-5/+15
| | | | | | | | Previously bge(4) always enabled auto polling for non-BGE_FLAG_TBI controllers. With this change, auto polling is not used anymore so polling through mii(4) was introduced. Reviewed by: davidch
* Do not blindly UP the interface when interface's MTU is changed. Ifyongari2010-10-081-2/+6
| | | | | | driver is not running there is no need to up the interface. While I'm here hold driver lock before modifying MTU as it is referenced in RX handler.
* Fix a long standing bug which regarded some revisions of controlleryongari2010-10-071-8/+6
| | | | | | | | | | as 5788. This caused BGE_MISC_LOCAL_CTL register is used to generate link state change interrupt for non-5788 controllers. The interrupt handler may or may not detect link state attention as status block wouldn't be updated when an interrupt was generated with BGE_MISC_LOCAL_CTL register. All controllers except 5700 and 5788 should use host coalescing mode register to trigger an interrupt.
* Add more comments to rings supported by the controller. Differentyongari2010-10-061-37/+103
| | | | | | | | | | | | | | | | | | | | | versions of controller support different number of ring control blocks such that adjust code a bit to access known number of send/receive ring control blocks. Previously bge(4) blindly accessed 16 send/receive RCBs. Also move initializing standard receive producer ring producer index, jumbo receive producer ring producer index and mini receive producer ring producer index to the end of each receive producer ring initialization. Do not assume mini receive producer ring is available only when controller has jumbo frame capability, instead explicitly check ASIC version BCM5700 to disable mini receive producer ring. Additionally always enable send ring 0 regardless of controller versions. Previously bge(4) didn't enable send ring 0 if controller is BGE_IS_5705_PLUS. Becase bge(4) need 1 send ring to send frames at least, I have no idea how it would have worked so far. Submitted by: davidch
* Remove bge_tx_buf_ratio, unused member of softc.yongari2010-10-061-1/+0
|
* Overhaul MII register access routine and remove unnecessaryyongari2010-10-062-39/+94
| | | | | | | | | | | | | | | | | | | | | | | | | BGE_MI_MODE register accesses. Previously bge(4) used to read BGE_MI_MODE register to detect whether it needs to disable autopolling feature or not. Because we don't touch autopolling in other part of driver there is no reason to read BGE_MI_MODE register given that we know default value in advance. In order to achieve the goal, check whether the controller has CPMU(Central Power Mangement Unit) capability. If controller has CPMU feature, use 500KHz MII management interface(mdio/mdc) frequency regardless core clock frequency. Otherwise use default MII clock. While I'm here, add CPMU register definition. In bge_miibus_readreg(), rearrange code a bit and remove goto statement. In bge_miibus_writereg(), make sure to restore autopolling even if MII write failed. The delay time inserted after accessing BGE_MI_MODE register increased from 40us to 80us. The default PHY address is now stored in softc. All PHYs supported by bge(4) currently uses PHY address 1 but it will be changed when we add newer controllers. This change will make it easier to change default PHY address depending on PHY models. Submitted by: davidch
* Fix bge(4) build breakage when BGE_REGISTER_DEBUG is defined.yongari2010-10-061-1/+1
|
* Rearrange code a bit to correctly set PHY flags. This change makeyongari2010-10-051-5/+7
| | | | | | it easy to add more newer ASICs. Obtained from: OpenBSD
* Separate common flags into controller specific and PHY relatedyongari2010-10-052-28/+29
| | | | | | | flags. There should be no functional changes. This change will make it easy to add more quirk/flags in future. Reviewed by: davidch
* Enable fix for read DMA FIFO overruns on controllers that have thisyongari2010-10-042-0/+17
| | | | | | | fix. Note, we still need workaround for controllers that lacks this fix and it needs more work in RX BD updating. Submitted by: davidch
* Consistently use ifHCOutOctets/ifHCInOctets instead of Octets asyongari2010-10-041-9/+9
| | | | | | | | these names are used in data sheet. Also use UnicastPkts, MulticastPkts and BroadcastPkts instead of UcastPkts, McastPkts and BcastPkts to clarify its meaning. Suggested by: bde
* Remove extra semicolon.yongari2010-10-011-2/+2
|
* Allow write DMA to request larger DMA burst size to get betteryongari2010-10-012-0/+5
| | | | | | performance on BCM5785. Obtained from: OpenBSD
* Fix IFCAP_TXCSUM/IFCAP_RXCSUM handling. Previously bge(4) usedyongari2010-09-301-4/+8
| | | | | | IFCAP_HWCSUM to know which capability should be changed such that disabling RX checksun offloading resulted in disabling TX checksum offloading.
* Implement hardware MAC statistics for BCM5705 or newer Broadcomyongari2010-09-292-49/+339
| | | | | | | controllers. bge(4) exported MAC statistics on controllers that maintain the statistics in the NIC's internal memory. Newer controllers require register access to fetch these values. These counters provide useful information to diagnose driver issues.
* After r207391, brgphy(4) passes resolved flow-control settings toyongari2010-09-291-2/+13
| | | | | | | | parent driver. Use that information to configure flow-control. One drawback is there is no way to disable flow-control as we still don't have proper way to not advertise RX/TX pause capability to link partner. But I don't think it would cause severe problems and users can selectively disable flow-control in switch port.
* Set the number of RX frames to receive after RX MBUF low watermarkyongari2010-09-292-0/+9
| | | | | | | | | | has reached. This reduced number of dropped frames when flow-control is enabled. Previously it dropped incoming frames once RX MBUF low watermark has reached. The value used in MAC RX MBUF low watermark is greater than or equal to 4 so receiving two more RX frames should not be a problem. Obtained from: OpenBSD
* Always show asic/chip revision in device attach phase. There areyongari2010-09-231-6/+5
| | | | | | | | too many bge(4) controllers there and model name does not necessarily match asic/chip revision. Relying on VPD string made it hard to identify exact asic/chip revision so the first step to debug bge(4) was getting exact asic/chip information with verbose boot which may not be available on production server.
* Fix incorrect RX BD producer updates. The producer index wasyongari2010-09-161-2/+4
| | | | | | | | | | already updated after allocating mbuf so driver had to use the last index instead of using next producer index. This should fix driver hang which may happen under high network load. Reported by: Igor Sysoev <is <> rambler-co dot ru>, Vlad Galu <dudu <> dudu dot ro> Tested by: Igor Sysoev <is <> rambler-co dot ru>, Vlad Galu <dudu <> dudu dot ro> MFC after: 10 days
* Make sure to create DMA'able memory for statistics block. This wasyongari2010-09-071-0/+9
| | | | | | | missed in r212061 and it caused crashes for 570x controllers as controller DMAed statistics to physical address 0. Reported by: kan
* Remove unnecessary atomic operation in bge_poll. bge(4) alwaysyongari2010-08-311-2/+2
| | | | | holds a driver lock in the function entry and memory synchronization is handled by bus_dmamap_sync(9).
* bge_txeof() already checks whether it has to free transmitted mbufsyongari2010-08-311-4/+3
| | | | | | or not by comparing reported TX consumer index with saved index. So remove unnecessary check done after freeing transmitted mbufs. While I'm here nuke unnecessary variable initializations.
* Handle PAE case correctly. You cannot effectively specify a 4GByongari2010-08-312-3/+7
| | | | | | | | boundary in PAE case so use a 2GB boundary for PAE as suggested by jhb. Pointed out by: jhb Reviewed by: jhb
* Split common parent DMA tag into ring DMA tag and TX/RX mbuf DMAyongari2010-08-312-243/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | tag. All controllers that are not BCM5755 or higher have 4GB boundary DMA bug. Previously bge(4) used 32bit DMA address to workaround the bug(r199670). However this caused the use of bounce buffers such that it resulted in poor performance for systems which have more than 4GB memory. Because bus_dma(9) honors boundary restriction requirement of DMA tag for dynamic buffers, having a separate TX/RX mbuf DMA tag will greatly reduce the possibility of using bounce buffers. For DMA buffers allocated with bus_dmamem_alloc(9), now bge(4) explicitly checks whether the requested memory region crossed the boundary or not. With this change, only the DMA buffer that crossed the boundary will use 32bit DMA address. Other DMA buffers are not affected as separate DMA tag is created for each DMA buffer. Even if 32bit DMA address space is used for a buffer, the chance to use bounce buffer is still very low as the size of buffer is small. This change should eliminate most usage of bounce buffers on systems that have more than 4GB memory. More correct fix would be teaching bus_dma(9) to honor boundary restriction for buffers created with bus_dmamem_alloc(9) but it seems that is not easy. While I'm here cleanup bge_dma_map_addr() and remove unnecessary member variables in bge_dmamap_arg structure. Tested by: marcel
* It seems all Broadcom controllers have a bug that can generate UDPyongari2010-08-222-7/+43
| | | | | | | | | | | | | | | | datagrams with checksum value 0 when TX UDP checksum offloading is enabled. Generating UDP checksum value 0 is RFC 768 violation. Even though the probability of generating such UDP datagrams is low, I don't want to see FreeBSD boxes to inject such datagrams into network so disable UDP checksum offloading by default. Users still override this behavior by setting a sysctl variable or loader tunable, dev.bge.%d.forced_udpcsum. I have no idea why this issue was not reported so far given that bge(4) is one of the most commonly used controller on high-end server class systems. Thanks to andre@ who passed the PR to me. PR: kern/104826
* Load tunable from loader.conf(5) instead of device.hints(5).yongari2010-08-211-3/+6
|
* Use Miscellaneous Configuration Register bit definition instead ofyongari2010-07-152-1/+2
| | | | magic number.
* Remove enabling Data FIFO protection with indirect memory access.yongari2010-07-141-6/+3
| | | | | | | | r165114 added that code and that change ignored the same logic committed in r135772. In addition, data FIFO protection should be selectively enabled instead of applying to all PCIe devices. While I'm here add BCM5785 to devices that do not require this fix.
OpenPOWER on IntegriCloud