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
in case of IP fast forwarding. Enqueue a taskqueue(9) task instead of
calling xl_rxeof() directly.
Reported & tested by: Slava Alpatov
Reviewed by: wpaul
MFC after: 1 week
3C920B-EMB-WNM Integrated Fast Ethernet Controller
Submitter reports that the card appears to autonegotiate properly, and
operate well with high levels of NFS traffic.
PR: 75253
Submitted by: "Oleg V. Nauman" <oleg at reis dot zp dot ua>
MFC after: 2 weeks
sensitive, but less excercised location (the watchdog). While here use the
*_start_locked function directly to avoid drop, grab, drop lock.
I have to be very careful with future ALTQ patches!
Found & reviewed by: rwatson
MFC after: 3 days
it only if we weren't UP before. In some cases xl_init causes long media
re-negotiation, and ppp(8) fails to open PPPoE connection because it sets
IFF_UP every time before opening PPPoE connection.
PR: kern/69133
Patch by: mdodd
Approved by: wpaul, julian (mentor)
MFC after: 1 week
- Avoid an additional lock acquire/release when leaving xl_intr(), by
changing xl_start*() to xl_start*_locked(), and calling the appropriate
routine by chip revision (as the DMA descriptors are different).
- Simplify the appropriate routines now that they are called with the
lock held.
This should save a significant amount of CPU cycles spent on servicing
each interrupt for both UP and SMP whilst remaining MPSAFE.
Tested by: rwatson
- Eliminate the use of a recursive mutex.
- Mark the driver as INTR_MPSAFE.
- Split the default media choice code out into xl_choose_media() to
avoid making poor assumptions about the state of the lock during attach.
- The miibus upcall/downcall paths may still be racy.
Change to commented-out locking assertions there for now.
- Tested with nfsclient, routed, ssh, ntp, dhclient and quagga bgpd.
- This needs SMP test coverage. I do not have such resources.
Tested on: UP, !debug.mpsafenet && debug.mpsafenet
Hardware: 3C905B-TX (0x905510b7)
- Use device_printf() during device probe/attach.
- Move if_xname initialization to before xl_reset() is called.
- Use if_printf() at all other times after struct ifnet has been
initialized.
following drivers: bfe(4), em(4), fxp(4), lnc(4), tun(4), de(4) rl(4),
sis(4) and xl(4)
More patches are pending on: http://peoples.freebsd.org/~mlaier/ Please take
a look and tell me if "your" driver is missing, so I can fix this.
Tested-by: many
No-objection: -current, -net
same problems as their Hurricane 575* bretheren in that one could set
the memory mapped port, but that has no effect. Add a quirk for this.
# I'll have to see if I can dig up documentation on these parts to see
# if there's someway software can know this other than a table...
this problem put these lines back in. While they should be
unnecessary, they appear to be sometimes necessary.
Reviewed in concept: dfr
Approved by: re (scottl@)
the packets are immediately returned for sending (e.g. when bridging
or packet forwarding). There are more efficient ways to do this
but for now use the least intrusive approach.
Reviewed by: imp, rwatson
multicast hash are written. There are still two distinct algorithms used,
and there actually isn't any reason each driver should have its own copy
of this function as they could all share one copy of it (if it grew an
additional argument).
to the pci attachment. Cardbus is a derived class of pci so all pci
drivers are automatically available for matching against cardbus devices.
Reviewed by: imp
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)
register, present only on 3c90xB and later NICs. This meant that you could
not use a 1500 byte MTU with VLANs on original 3c905/3c900 cards (boomerang
chipset). The boomerang chip does support large frames though, just not
in the same way: you can set the 'allow large frames' bit in the MAC
control register to receive frames up to 4K in size.
Changes:
- Set the 'allow large frames' bit for boomerang chips and increase
the packet size register for cyclone and later chips. This allows
us to use IFCAP_VLAN_MTU on all supported xl(4) NICs.
- Actually set the IFCAP_VLAN_MTU flag in the capabilities word
in xl_attach().
- Change the method used to detect older boomerang chips. My 3c575C
cardbus NIC was being incorrectly identified as 3c90x chip instead
of 3c90xB because the capabilities word in its EEPROM reports
a bizzare value. In addition to checking for the supportsNoTxLength
bit, also check for the absence of the supportsLargePackets bit.
Both of these cases denote a 3c90xB chip.
- Make RX and TX checksums configurable via the SIOCSIFCAP ioctl.
- Avoid an unecessary le32toh() in xl_rxeof(): we already have the
received frame size in the lower 16 bits of rxstat, no need to
read it again.
Tested with 3c905-TX, 3c900-TPO, 3c980C and 3c575C NICs.
BUS_DMA_NOWAIT flag, since the code can't handle this.
- Use NULL, NULL for the lockfunc and lockfuncarg parameters of
bus_dma_tag_create() since deferred loads can't happen now.
forced to do slightly bogus power state manipulation. However, this
is one of those features that is preventing further progress, so mark
them as BURN_BIRDGES like I did for the drivers in sys/dev/...
This, like the other change, are a no-op unless you have BURN_BRIDGES
in your kernel.
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
mapped I/O mode, we pause for .1 seconds after issuing the reset command
before trying to poll the 'command busy' bit in the status register.
With my 3c575C cardbus NIC, my Sony Picturebook locks up when it tries
to read the status register immediately after the reset. This appears
to be a problem only with certain NICs on certain hardware, but the
added delay should not hurt cards that already work.
This bug seems to have been brought to light by the fact that the xl
driver now defaults to memory mapped I/O mode instead of programmed
I/O mode like it used to. With PIO mode, the delay isn't needed and
everything works (which is why this NIC worked with 5.0-RELEASE but
not 5.1). I suspect that what's happening is that when the chip is
reset, it takes a little while for the memory-mapped decoding logic
to recover. Trying to access the chip's registers during this period
causes an error condition of some kind that wedges the system.
if attach succeeded. device_is_alive just tells us that probe
succeeded. Since we were using it to do things like detach net
interfaces, this caused problems when there were errors in the attach
routine.
Symptoms of problem reported by: martin blapp
