hme_watchdog() in order to avoid races accessing if_timer.
- Use bus_get_dma_tag() so hme(4) works on platforms requiring it.
- Don't bother to set if_mtu to ETHERMTU, ether_ifattach() does that.
- In hme_eint() print MIF register contents on MIF interrupts.
- In hme_mifinit() don't bother to preserve the previous MIF config.
This was mainly done in order to preserve the PHY select bit (external
or internal PHY) but which only needs to be set as appropriate when
reading from or writing to the desired PHY in hme_mii_{read,write}reg().
Similarly don't bother to set the PHY select bit in hme_mii_statchg().
- In hme_mii_{read,write}reg() ignore requests to PHYs other than the
external and internal PHY one.
- Move enabling/disabling the MII drivers of the external transceiver
from hme_init_locked() and based on the sheer presence of an external
to hme_mifinit() and based on the currently selected media, defaulting
to the internal transceiver when the media hasn't been set, yet.
Invoke hme_mifinit() from the newly added hme_mediachange_locked() so
the setting of the MII drivers is updated when changing media.
These changes keep the MII bus from wedging (which manifests in the HME
and the PHYs no longer being able to communicate with each other) when
the PHY device drivers isolate the unused PHY in two-PHY configurations
as present in f.e. Netra t1 100 while changing media, either from
hme_init_locked() (see also below) or via ifconfig(8). They also allow
for using both transceivers/PHYs.
- In the newly added hme_mediachange_locked() also reset the PHYs in two-
PHY configurations before invoking mii_mediachg(). This is required
for successfully unisolating the previously unused PHY when switching
between PHYs.
- Now that changing media should no longer cause problems back out rev.
1.27 and re-enable setting the current media in hme_init_locked() (see
the commit message of rev. 1.23 for more info).
These changes are roughly a merge of NetBSD gem.c rev. 1.32 - 1.35 (1.30
was already fixed differently in our 1.36; 1.31 and 1.32 were wrong) with
some parts reworked and things that don't make sense like setting the MII
drivers and restoring the previous MIF and XIF settings in hme_mii_{read,
write}reg() omitted.
MFC after: 2 weeks
Use proper pointer dereference to inform modified mbuf chains to
caller.
While I'm here perform checksum offload setup after loading DMA
maps as m_defrag(9) can return new mbuf chains.
In collaboration with: glebius
rather than in ifindex_table[]; all (except one) accesses are
through ifp anyway. IF_LLADDR() works faster, and all (except
one) ifaddr_byindex() users were converted to use ifp->if_addr.
- Stop storing a (pointer to) Ethernet address in "struct arpcom",
and drop the IFP2ENADDR() macro; all users have been converted
to use IF_LLADDR() instead.
- Move hardware counter reading/zeroing to hme_tick(). This saves
8 register access per interrupt. [1]
- Use imax macro for getting max. argument between two integers.
- Invoke bus_dmamap_sync(9) first before freeing mbuf.
- Check driver queue first to reduce locking operation in hme_start_locked()
and interrupt handler.
- Simplyfy watchdog timer setup in interrupt handler.
- Don't log normal errors such as RX overrun. If we have DMA stuck
condition, reinitialize the driver and log it.
Reviewed by: marius
Obtained from: OpenBSD [1]
and detach() since mtx_lock() will assert that already since the driver
lock is not recursive.
- Move the call to callout_init_mtx() before hme_stop() so that the
callout_stop() in hme_stop() doesn't operate on an uninitialized callout
structure during attach.
Reported by: yongari (2)
MFC after: 3 days
that if softclock is running on another CPU and is blocked on our driver
lock, we will wait until it has acquired the lock, seen that it was
cancelled, dropped the lock, and awakened us so that we can safely destroy
the mutex.
MFC after: 3 days
- Use the driver lock instead of Giant in a bus dma callback.
- Clear IFF_DRV_(RUNNING|OACTIVE) in hme_stop() instead of just clearing
RUNNING in hme_ioctl() to be more like other ethernet drivers.
- Lock the driver lock around mii operations.
- Remove spls.
- Cleanup locking in hme_ioctl().
MFC after: 1 week
IFF_DRV_RUNNING, as well as the move from ifnet.if_flags to
ifnet.if_drv_flags. Device drivers are now responsible for
synchronizing access to these flags, as they are in if_drv_flags. This
helps prevent races between the network stack and device driver in
maintaining the interface flags field.
Many __FreeBSD__ and __FreeBSD_version checks maintained and continued;
some less so.
Reviewed by: pjd, bz
MFC after: 7 days
over iteration of their multicast address lists when synchronizing the
hardware address filter with the network stack-maintained list.
Problem reported by: Ed Maste (emaste at phaedrus dot sandvine dot ca>
MFC after: 1 week
struct ifnet or the layer 2 common structure it was embedded in have
been replaced with a struct ifnet pointer to be filled by a call to the
new function, if_alloc(). The layer 2 common structure is also allocated
via if_alloc() based on the interface type. It is hung off the new
struct ifnet member, if_l2com.
This change removes the size of these structures from the kernel ABI and
will allow us to better manage them as interfaces come and go.
Other changes of note:
- Struct arpcom is no longer referenced in normal interface code.
Instead the Ethernet address is accessed via the IFP2ENADDR() macro.
To enforce this ac_enaddr has been renamed to _ac_enaddr.
- The second argument to ether_ifattach is now always the mac address
from driver private storage rather than sometimes being ac_enaddr.
Reviewed by: sobomax, sam
program RXMAC to discard frames with SA field matching the stations's
MAC address. Experimentation shows that HME receives its own frames
when it operates at 10Mbps half-duplex. With this change HME runs at
10Mbps half-duplx should work with IPv6.
(No more "DAD detected duplicate IPv6 address".)
Reported by: jacques brierre <jbrierre AT bellsouth DOT net>
Reviewed by: marius
The cause of "Duplicate mbuf free panic" is in the programming
error of hme_load_txmbuf(). The code path of the panic is the
following.
1. Due to unknown reason DMA engine was freezed. So TX descritors
of HME become full and the last failed attempt to transmit a
packet had set its associated mbuf address to hme_txdesc
structure. Also the failed packet is requeued into interface
queue structure in order to retrasmit it when there are more
available TX descritors.
2. Since DMA engine was freezed, if_timer starts to decrement its
counter. When if_timer expires it tries to reset HME. During
the reset phase, hme_meminit() is called and it frees all
associated mbuf with descriptors. The last failed mbuf is also
freed here.
3. After HME reset completed, HME starts to retransmit packets
by dequeing the first packet in interface queue.(Note! the
packet was already freed in hme_meminit()!)
4. When a TX completion interrupt is posted by the HME, driver
tries to free the successfylly transmitted mbuf. Since the
mbuf was freed in step2, now we get "Duplicate mbuf free panic".
However, the real cause is in DMA engine freeze. Since no fatal
errors reported via interrupts, there might be other cause of
the freeze. I tried hard to understand the cause of DMA engine
freeze but couldn't find any clues. It seems that the freeze
happens under very high network loads(e.g. 7.5-8.0 MB/s TX speed).
Though this fix is not enough to eliminate DMA engine freeze it's
better than panic.
Reported by: jhb via sparc64 ML
- Let hme_start()/hme_init() acquire lock and then call
hme_start_locked()/hme_init_locked() respectivly.
- Teardown interrupt handler before hme_detach().
- Remove IFF_NEEDSGIANT flag and mark interrupt handler INTR_MPSAFE.
- Set callout handler to CALLOUT_MPSAFE.
- Add locks in hme MII interface.
Reviewed by: jake
Tested by: Julian C. Dunn <jdunn at opentrend dot net>
MFC after: 2 weeks
Since HME doesn't compensate the checksum for UDP datagram which
can yield to 0x0, UDP transmit checksum offload is disabled by
default. The UDP Transmit checksum offload can be reactivated
by setting special link option link0 with ifconfig(8).
Approved by: jake (mentor)
Reviewed by: tmm
Tested by: Herve Boulouis <amon@sockar.homeip.net>
pass any traffic. Unfortunately this means no full-duplex link with auto-
negotiation on hme(4) using DP83840A PHYs again.
I really thought I had tested this also on a Netra t1 100...
This is part 2/2 of fixing autonegotiation on hme(4) using DP83840A PHYs.
It appears to also fix the occasional problems to establish a link on
hme(4) using LU6612 PHYs and shouldn't hurt on those using QS6612 PHYs.
Obtained from: NetBSD
and Rx frames up to 8191 octets, so it is perfectly capable of supporting
vlan(4)-style VLAN natively.
Thus, make it support VLAN `oversize' frames.
Reviewed by: tmm
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)
Add two new arguments to bus_dma_tag_create(): lockfunc and lockfuncarg.
Lockfunc allows a driver to provide a function for managing its locking
semantics while using busdma. At the moment, this is used for the
asynchronous busdma_swi and callback mechanism. Two lockfunc implementations
are provided: busdma_lock_mutex() performs standard mutex operations on the
mutex that is specified from lockfuncarg. dftl_lock() is a panic
implementation and is defaulted to when NULL, NULL are passed to
bus_dma_tag_create(). The only time that NULL, NULL should ever be used is
when the driver ensures that bus_dmamap_load() will not be deferred.
Drivers that do not provide their own locking can pass
busdma_lock_mutex,&Giant args in order to preserve the former behaviour.
sparc64 and powerpc do not provide real busdma_swi functions, so this is
largely a noop on those platforms. The busdma_swi on is64 is not properly
locked yet, so warnings will be emitted on this platform when busdma
callback deferrals happen.
If anyone gets panics or warnings from dflt_lock() being called, please
let me know right away.
Reviewed by: tmm, gibbs
- Remove NetBSD-style or-ed together BUS_DMASYNC operations, in some
cases relaxing the (intended) syncing operation a bit.
- Add syncs before reading the descriptor rings.
- Try to combine syncs where possible to avoid overhead.
- Sync all maps before unloading them.
from the hardware descriptors to avoid the overhead of having a DMA
map for each of them. Bump the number of hardware descriptors to 128,
and use half as many software descriptors for now.
Some minor cleanups.
o don't strip the Ethernet header from inbound packets; pass packets
up the stack intact (required significant changes to some drivers)
o reference common definitions in net/ethernet.h (e.g. ETHER_ALIGN)
o track ether_ifattach/ether_ifdetach API changes
o track bpf changes (use BPF_TAP and BPF_MTAP)
o track vlan changes (ifnet capabilities, revised processing scheme, etc.)
o use if_input to pass packets "up"
o call ether_ioctl for default handling of ioctls
Reviewed by: many
Approved by: re
- always reinitialize the rx descriptors, even if the mbuf is kept.
This should fix the hangs on ifconfig that were observed
- on an rx overflow, reinitialize the descriptor so that the interface
will not hang
- correct some bus_dmamap_sync() calls
- correct some debug messages
- some minor nits
