FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F7.1.0_cvs 2008-12-31T22:57:14Z 2008-12-31T22:57:14Z Ken Smith kensmith@FreeBSD.org 2008-12-31T22:57:14Z urn:sha1:8d4eb975d2e49f56d057a19aac09bcb92b3e71f7 Approved by: re (implicit) This commit was manufactured to restore the state of the 7.1-RELEASE image. 2008-12-15T21:37:40Z Marius Strobl marius@FreeBSD.org 2008-12-15T21:37:40Z urn:sha1:e91dd3cb0d2c663ee58c99f6a082c5f705dbb269 - According to the corresponding Linux, NetBSD and OpenSolaris drivers, there should be a 1us delay after every write when bit-banging the MII. Also insert barriers in order to ensure the intended ordering. These changes hopefully will solve the bus wedging occasionally experienced with DM9102A since r182461. - Deobfuscate dc_mii_readreg() a bit. Approved by: re (kib) 2008-09-01T00:42:00Z Marius Strobl marius@FreeBSD.org 2008-09-01T00:42:00Z urn:sha1:12302036a990b617aed55a6913e1f3dbcaa03592 For chips with a broken DC_ISR_RX_STATE which f.e. never signals stopped nor the waiting state and also no other means to check whether the receiver is idle (see also r163774), we have no choice than to call mii_tick(9) unconditionally even in the case of the DC_REDUCED_MII_POLL handling as far as the RX side is concerned. This isn't necessarily worse than checking whether RX is idle though because unlike as with TX we're racing with the hardware, which might receive packets any time while we poll the MII, anyway. Reported and tested by: Jacob Owens Reviewed by: yongari 2008-08-26T19:14:55Z Marius Strobl marius@FreeBSD.org 2008-08-26T19:14:55Z urn:sha1:fcd2d2ab26375d18114f4317f5bf45028735486c - Use m_collapse(9) instead of m_defrag(9) if possible. This results in a noticeable reduction in system time spent. - If bus_dmamap_load_mbuf_sg(9) fails with EFBIG and we already have defragmented the mbuf chain, don't bother to defragment and load it a second time just yet as it's likely to fail again anyway. 2008-06-19T01:36:31Z Pyun YongHyeon yongari@FreeBSD.org 2008-06-19T01:36:31Z urn:sha1:a68dc781ae8b172b2d9a411f6e2120a179cd4009 Ethernet hardware address stored in DC_AL_PAR0/DC_AL_PAR1 register is in little endian form. Likewise setting DC_AL_PAR0/DC_AL_PAR1 register expect the address to be in little endian form. For big endian architectures the address should be swapped to get correct one. Change setting/getting ethernet hardware address to big endian architecture frendly. Reported by: Robert Murillo ( billypilgrim782001 at yahoo dot com ) Tested by: Robert Murillo ( billypilgrim782001 at yahoo dot com ) 2008-04-11T23:38:07Z Marius Strobl marius@FreeBSD.org 2008-04-11T23:38:07Z urn:sha1:c669d09cca7d5cf0bf6d08e674ceaf047ff780f9 - Const'ify the dc_devs array. - Correct the maxsize parameter when creating the mbufs busdma tag to reflect the actual requirement of dc(4). - Move the KASSERT in dc_newbuf() to the right spot. - Also convert the TX side to take advantage of bus_dmamap_load_mbuf_sg(9). - Move the comment regarding dc_start_locked() to the right spot. 2008-03-13T07:50:48Z Pyun YongHyeon yongari@FreeBSD.org 2008-03-13T07:50:48Z urn:sha1:b9251501098ece76306aa0fd7417efc01883a316 2008-02-03T04:12:06Z Pyun YongHyeon yongari@FreeBSD.org 2008-02-03T04:12:06Z urn:sha1:97096c313d42d07b4ca1d5b14f99afa1cfcf303b IEEE 802.3 Annex 28B.3 explicitly specifies the following relative priorities of the technologies supported by 802.3 Selector Field value. 1000BASE-T full duplex 1000BASE-T 100BASE-T2 full duplex 100BASE-TX full duplex 100BASE-T2 100BASE-T4 100BASE-TX 10BASE-T full duplex 10BAST-T However PHY drivers didn't honor the order such that 100BASE-T4 had higher priority than 100BASE-TX full duplex. Fix that long standing bugs such that have PHY drivers choose the highest common denominator ability. Fix a bug in dcphy which inadvertently aceepts 100BASE-T4. PR: 92599 2007-08-05T11:28:19Z Marius Strobl marius@FreeBSD.org 2007-08-05T11:28:19Z urn:sha1:82a67a70a2e64e1bba16a291b6aff5332de33b81 requiring DC_TX_ALIGN or DC_TX_COALESCE, which was previously done in dc_start_locked(), into dc_encap(). o In dc_encap(): - If m_defrag() fails just drop the packet like other NIC drivers do. This should only happen when there's a mbuf shortage, in which case it was possible to end up with an IFQ full of packets which couldn't be processed as they couldn't be defragmented as they were taking up all the mbufs themselves. This includes adjusting dc_start_locked() to not trying to prepend the mbuf (chain) if dc_encap() has freed it. - Likewise, if bus_dmamap_load_mbuf() fails as dc_dma_map_txbuf() failed, free the mbuf possibly allocated by the above call to m_defrag() and drop the packet. o In dc_txeof(): - Don't clear IFF_DRV_OACTIVE unless there are at least 6 free TX descriptors. Further down the road dc_encap() will bail if there are only 5 or fewer free TX descriptors, causing dc_start_locked() to abort and prepend the dequeued mbuf again so it makes no sense to pretend we could process mbufs again when in fact we won't. While at it replace this magic 5 with a macro DC_TX_LIST_RSVD. - Just always assign idx to sc->dc_cdata.dc_tx_cons; it doesn't make much sense to exclude the idx == sc->dc_cdata.dc_tx_cons case. o In dc_dma_map_txbuf() there's no need to set sc->dc_cdata.dc_tx_err to error if the latter is != 0, bus_dmamap_load_mbuf() already returns the same error value in that case anyway. o For less overhead, convert to use bus_dmamap_load_mbuf_sg() for loading RX buffers. o Remove some banal and/or outdated comments. Approved by: re (kensmith) MFC after: 1 week 2007-02-23T12:19:07Z Paolo Pisati piso@FreeBSD.org 2007-02-23T12:19:07Z urn:sha1:ef544f631226436ef590825881e7a28369df82f6 bus_setup_intr() o add an int return code to all fast handlers o retire INTR_FAST/IH_FAST For more info: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=465712+0+current/freebsd-current Reviewed by: many Approved by: re@