src/sys/dev/dc, branch release/8.1.0FreeBSD source treehttps://cgit-dev.freebsd.org/src/atom?h=release%2F8.1.02009-06-26T11:45:06ZUse if_maddr_rlock()/if_maddr_runlock() rather than IF_ADDR_LOCK()/2009-06-26T11:45:06ZRobert Watsonrwatson@FreeBSD.org2009-06-26T11:45:06Zurn:sha1:eb956cd041f956275522092d6ba66671356ff84f
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
When user_frac in the polling subsystem is low it is going to busy the2009-05-30T15:14:44ZAttilio Raoattilio@FreeBSD.org2009-05-30T15:14:44Zurn:sha1:1abcdbd127e95ffe08399ec75a7001edd1ca2f5f
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
- Set MIIF_NOLOOP and don't add IFM_LOOP as loopback apparently isn't2009-03-19T22:34:55ZMarius Stroblmarius@FreeBSD.org2009-03-19T22:34:55Zurn:sha1:b54282f61ea4481ca374db4e3405f6ce84acb9ac
supported with these pseudo-PHYs. The MIIF_NOLOOP flag currently triggers
nothing but hopefully will be respected by mii_phy_setmedia() later on.
- Don't add IFM_NONE as isolation isn't supported by these pseudo-PHYs.
- Use mii_phy_add_media() instead of mii_add_media() so the latter can
be eventually retired.
remove now-redunant cardbus attachment.2009-03-09T13:23:54ZWarner Loshimp@FreeBSD.org2009-03-09T13:23:54Zurn:sha1:155a83e87ada23dc65476957d310cdf309a16c7b- According to the corresponding Linux, NetBSD and OpenSolaris2008-12-07T23:02:37ZMarius Stroblmarius@FreeBSD.org2008-12-07T23:02:37Zurn:sha1:155781198a1e5f675dbb3bb8b4df4ecc182c67f9
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.
cosmetic changes and style fixes2008-09-30T20:53:15ZMarius Stroblmarius@FreeBSD.org2008-09-30T20:53:15Zurn:sha1:36bef328f5021a5dfd4f9094498669c053d44593For chips with a broken DC_ISR_RX_STATE which f.e. never signals2008-08-29T20:31:41ZMarius Stroblmarius@FreeBSD.org2008-08-29T20:31:41Zurn:sha1:d0d67284f8dd998545e70830b375a9fa90e55255
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
MFC after: 3 days
- Use m_collapse(9) instead of m_defrag(9) if possible. This results2008-08-23T20:57:48ZMarius Stroblmarius@FreeBSD.org2008-08-23T20:57:48Zurn:sha1:993a741ac633bfd4b1304c17fca145f87da5c968
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.
MFC after: 3 days
Ethernet hardware address stored in DC_AL_PAR0/DC_AL_PAR1 register2008-06-08T02:52:26ZPyun YongHyeonyongari@FreeBSD.org2008-06-08T02:52:26Zurn:sha1:2e3d4b798b464a72903f3da6ffa68626e1ec06d7
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 )
- Const'ify the dc_devs array.2008-03-24T17:38:24ZMarius Stroblmarius@FreeBSD.org2008-03-24T17:38:24Zurn:sha1:ebc284cc8358b85713d12ec1ce2e36833b785248
- 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.
MFC after: 2 weeks