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.
cards and teach the re(4) driver to attach to revision 3 cards.
Submitted by: Fredrik Lindberg fli+freebsd-current at shapeshifter dot se
MFC after: 2 weeks
Reviewed by: imp, mdodd
based on XMAC II chip should be ready for this in their initial
mode of operation, and Yukon-based NICs are configured so by
the driver.
PR: kern/79998
MFC after: 1 month
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
While there also check for failed device_add_child calls.
Found by: Coventry Analysis tool[1].
Submitted by: sam[1]
Approved by: pjd (mentor)
MFC after: 1 week
Do our best to plug some memory leaks (VPD data, jumbo memory buffer,...).
Log if we cannot free because memory still in use[1].
Change locking to avoid ''acquiring duplicate lock of same
type: "network driver"'' and potential deadlock. Also seems to fix LOR #063.
[1] This change does not solve problems if buffers are still in use when
unloading if_sk.ko. There is ongoing work which will address jumbogram
allocations in a more general way.
PR: kern/75677 (with changes, no mii fixes in here)
Tested by: net, Antoine Brodin (slightly different version)
Approved by: rwatson (mentor)
MFC after: 5 days
Obtained from: NetBSD if_sk.c rev. 1.11
* Take PHY out of reset for Yukon Lite Rev. A3.
Submitted by: postings on net@ in thread "skc0: no PHY found", 2005-02-22
Tested by: net
Approved by: rwatson (mentor)
MFC after: 5 days
if the interface is marked RUNNING.
Obtained from: NetBSD if_sk.c rev. 1.12
* Don't initialize the card (and start an autonegotiation) every time the IP
address changes. Makes 'dhclient sk0' invocations way faster and more
consistant. i.e. one DHCPREQUEST elicits the DHCPACK.
Obtained from: OpenBSD if_sk.c rev. 1.56
* Additional locking changes in sk_ioctl.
PR: kern/61296 should see improvements by the last two.
Approved by: rwatson (mentor)
MFC after: 5 days
In contrast to OpenBSD we enable jumbo frame support
depending on MTU setting (like done for xmac).
Approved by: pjd (mentor)
Obtained from: OpenBSD if_sk.c r1.52 (YU_SMR_MFL_JUMBO flag)
Tested by: Heinz Knocke <knockefreebsd at o2 dot pl>
MFC after: 5 days
queue a packet to the hardware... instead of when the hardware queue is
empty..
don't initalize cur_tx now that it doesn't need to be...
Pointed out by: bde
also fix up handling and proding of the tx, _OACTIVE is now handled
better...
Submitted by: Peter Edwards (sk_jfree)
Obtained from: OpenBSD and/or NetBSD (tx prod)
but sk(4) is so prevalent on AMD64 motherboards we need to reduce the number
of round trips in the mailing lists trying to get sufficient information to
make sure we've got a handle on all the problems and are working towards
making sk(4) solid.
Submitted by: bz
* Announce some more fields from ro area for better debugging of broken
sk(4)s on various boards.
Submitted by: Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net>
algorithm, supplied by wpaul himself. The lame one has an origin
that's been called into question, so rather than argue about that (one
could make an excellent fair use argument), replace it with better
code since that's what FreeBSD is about.
Submitted by: wpaul[1], Klaus Klein
[1] Bill called this a silly bikeshed. Maybe his is not incorrect.
they all do and handle that without alarming the user. Also pull in a bit
of defensive code from OpenBSD that triggers when a card is recognised but
not properly classified as either Genesis or Yukon. Not that I could ever
have needed this. :-)
Obtained from: OpenBSD/NetBSD (partially)
MFC after: 2 weeks
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
