and the X1034A (quad HME; QFE) cards the X1033A (single HME) don't have a
PCI-PCI-bridge so we can't rely on the PCI slot number being useable as
index for the network address to read from the VPD on the latter. Use
the end tag to determine whether it is a QFE VPD with 4 NAs and only use
the slot number as index in this case.
- Remove a useless check.
Prodded by: joerg
Additional testing by: joerg
MFC after: 1 day
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
without Open Firmware:
- The PCI data structure of some HME PROMs contains a non-zero interface
revision in the class code. Thus remove the checks for matching class
code and PCI data structure length and revsion. These were pretty much
useless anyway as we only really need the pointer to the VPD which is
located before the structure length and revision fields.
- On Sun QFE (Quad FastEthernet) cards read the Nth MAC-address for the
Nth HME controller instead of always the first one for all four HMEs. [1]
- Improve the comment describing the used VPD format to better reflect
reality.
- Minor clean-up.
Prodded by: joerg [1]
- 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
without Open Firmware directly instead of using OF_getetheraddr(). This is
a bit painful though, as the MAC address is contained in the NA field of
the VPD of the EBus bridge, which is is another function of the same chip.
To make it worse, the VPD of the EBus bridge can't be accessed via the PCI
capability pointer but has to be digged out from the Boot PROM and has a
non-standard format.
The PCI VPD struct and macros used here should be part of the FreeBSD PCI
code nevertheless.
Approved by: tmm
Based on: NetBSD
Tested with: Sun X1032A (hme(4)-isp(4)-combo card) on alpha and i386
subset ("compatible", "device_type", "model" and "name") of the standard
properties in drivers for devices on Open Firmware supported busses. The
standard properties "reg", "interrupts" und "address" are not covered by
this interface because they are only of interest in the respective bridge
code. There's a remaining standard property "status" which is unclear how
to support properly but which also isn't used in FreeBSD at present.
This ofw_bus kobj-interface allows to replace the various (ebus_get_node(),
ofw_pci_get_node(), etc.) and partially inconsistent (central_get_type()
vs. sbus_get_device_type(), etc.) existing IVAR ones with a common one.
This in turn allows to simplify and remove code-duplication in drivers for
devices that can hang off of more than one OFW supported bus.
- Convert the sparc64 Central, EBus, FHC, PCI and SBus bus drivers and the
drivers for their children to use the ofw_bus kobj-interface. The IVAR-
interfaces of the Central, EBus and FHC are entirely replaced by this. The
PCI bus driver used its own kobj-interface and now also uses the ofw_bus
one. The IVARs special to the SBus, e.g. for retrieving the burst size,
remain.
Beware: this causes an ABI-breakage for modules of drivers which used the
IVAR-interfaces, i.e. esp(4), hme(4), isp(4) and uart(4), which need to be
recompiled.
The style-inconsistencies introduced in some of the bus drivers will be
fixed by tmm@ in a generic clean-up of the respective drivers later (he
requested to add the changes in the "new" style).
- Convert the powerpc MacIO bus driver and the drivers for its children to
use the ofw_bus kobj-interface. This invloves removing the IVARs related
to the "reg" property which were unused and a leftover from the NetBSD
origini of the code. There's no ABI-breakage caused by this because none
of these driver are currently built as modules.
There are other powerpc bus drivers which can be converted to the ofw_bus
kobj-interface, e.g. the PCI bus driver, which should be done together
with converting powerpc to use the OFW PCI code from sparc64.
- Make the SBus and FHC front-end of zs(4) and the sparc64 eeprom(4) take
advantage of the ofw_bus kobj-interface and simplify them a bit.
Reviewed by: grehan, tmm
Approved by: re (scottl)
Discussed with: tmm
Tested with: Sun AX1105, AXe, Ultra 2, Ultra 60; PPC cross-build on i386
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
network layer (ether).
- Don't abuse module names to facilitate ifconfig module loading;
such abuse isn't really needed. (And if we do need type information
associated with a module then we should make it explicit and not
use hacks.)
- 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
- remove some useless code from the status change handler that was intended
to enable the the MII drivers for external phys; this is already done
during interface initialization, and the deleted code made some
assumptions about phy addresses that do not seem to hold true on newer
cards. This should get at least one of the two hmes of newer Netra t1
machines working.
- correct the interrupt resource allocation
- bump the number of RX descriptors, lower values cause promblems on some
machines
