- Add locked variants of start, init, and ifmedia_upd.
- Use callout_* instead of timeout/untimeout.
- Don't recurse on the driver lock.
- Fixup locking in ioctl.
- Lock the driver lock in the ifmedia handlers rather than across
ifmedia_ioctl().
Tested by: brueffer
MFC after: 3 days
- Don't set IFF_ALLMULTI in our ifnet's if_flags if we end up allowing
all multicast due to limits in the MAC receive filters in hardware.
Requested by: rwatson (2)
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
- Add locked versions of the init() and start() methods.
- Use callout_*() rather than timeout().
- Make the driver lock non-recursive.
- Push down locking in detach() and ioctl().
- Fix the tick routine to bail if the interface has been stopped and use
callout_drain() in detach() after the call to stop().
- Lock the driver lock in the ifmedia handlers.
Tested by: Ketrien I. Saihr-Kesenchedra ketrien at error404.nls.net
MFC after: 1 week
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
- Add locking to protect the softc and mark this driver as MP safe. There
are still some edge cases with multiport cards that need more locking
work.
MFC after: 1 week
Tested on: alpha
set in tulip_attach() and its value is never changed, so all the extra sets
are redundant. I'm guessing that at some point in time de(4) had an
alternate start routine, but that hasn't been true in recent history.
default:
- TULIP_NEED_FASTTIMEOUT - tulip_fasttimeout() wasn't called anywhere
- BIG_PACKET - only worked on i386 anyway
- TULIP_USE_SOFTINTR - doesn't compile and was never updated to handle
new netisr registration
- non-FreeBSD code
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
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
dc0: MII without any PHY!
We have to enable the connection to the MII first. Doing so fixes the
problem cards without breaking the older, working cards.
Bad card provided by: deischen
This adds support for the SiS intergrated NIC on some Athlon64 motherboards.
The MAC address is stored in the APC CMOS RAM and this fixes the
sis driver ending up with a 00:00:00:00:00:00 MAC address.
Submitted by: Stasys Smailys <ssmailys@komvista.lt>
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
asks that each buffer be (2048 * 256) bytes long. I suspect that alignment
isn't a real requirement since busdma only recently started honoring it. The
size is also bogus. Fix both of these and stop busdma from trying to
exhaust the system memory pool with bounce pages.
Submitted by: Kevin Oberman
MFC After: 7 days
can retransmit on TX underrun and set TOK in addition to TUND. Also add a
check to prevent overflow of the addressable threshold.
This fixes some reports of rl(4) slowness, believed to be related to ALTQ
before.
PR: kern/61448
Submitted by: Tim Draegen-Gilman <timNOeudaemonSPAMnet> (with changes)
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
generic bridge support was biting us more than it helped, whenever a new chipset
came out from a vendor and misprogramming it caused strange hangs or corruption.
[2] Add a large number of PCI IDs based on what the linux drivers support.
Note that the new PCI IDs haven't been tested, they're just *likely* to work.
In particular the VIA AGP 8x chipsets are concerning, due to lack of testing,
possible issues (kern/69953), and not having a nice "does this bridge say it
would do 8x" function. However, this shouldn't make the situation worse, since
these chips would have probed in the past anyway.
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
zero-copy receive of jumbo frames. This eliminates the need for the
jumbo frame allocator implemented in kern/uipc_jumbo.c and sys/jumbo.h.
Remove it.
Note: Zero-copy receive of jumbo frames did not work without these changes;
I believe there was insufficient locking on the jumbo vm object.
Tested by: ken@
Discussed with: gallatin@
- Initialize sc->pcn_type during ATTACH as softc contents may not surivive
from PROBE.
- Print out chip-id to assist with ongoing pcn(4) debugging efforts.
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
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
* 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>
the device is suspended or shutting down. This will need to be rethought
slightly if we implement suspend/resume support within vr(4).
This appears to fix the vr_shutdown() panic on SMP machines.
My theory here is there's a race somewhere during vr_detach() with
vr_intr() in the SMP case which was sometimes being triggered,
although quite why this was happening is unclear (vr_stop() also
explicitly disables interrupts by writing to the IMR register).
MFC-to-RELENG_5* candidate.
PR: kern/62889
Tested by: seb at struchtrup dot com
MFC after: 10 days
two loops in agp_generic_bind_memory(). As an intended side-effect, all
of the calls to vm_page_wakeup() are now performed with the containing
vm object lock held.
as the original logic did. This fixes a race with vr_intr() which was
masked on UP systems and manifested on SMP systems.
PR: kern/62889
MFC after: 1 day
(usually taking 20 seconds to transmit a packet).. no longer fall back
to only transmitting one packet (instead of the entire queue) after we
have processed the entire send queue... I have no idea why we didn't
start seeing this problem ~6 years ago when this code was introduced...
is a no-op on little endian architectures, but fixes getting the MAC
address for some dc(4) cards on big endian architectures.
This is a RELENG_5 candidate.
Tested by: gallatin (powerpc), marius (sparc64)
First version of the patch written by: gallatin
to 7422 since it appears that the 8169S can't transmit anything larger..
The 8169S can receive full jumbo frames, but we don't have an mru to let
the upper layers know this...
add fixup so that this driver should work on alignment constrained platforms
(!i386 && !amd64)
MFC after: 5 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
by default. As such, mark if_dc as IFF_NEEDSGIANT until such
time as appropriate locking review and testing can take place,
and the locking can be enabled by default.
RELENG_5 candidate.
to check aperture size, avoiding hangs. Maintain the rest of the bits when
setting/unsetting ATTBASE. This essentially matches Linux's AGP driver as well.
PR: kern/70037
Submitted by: Mark Tinguely <tinguely at casselton dot net>
Obtained from: NetBSD
variable. If set to "true" OF_getetheraddr() will now return the unique
MAC address stored in the "local-mac-address" property of the device's
OFW node if present and the host address/system default MAC address if
the node doesn't doesn't have such a property. If set to "false" the
host address will be returned for all devices like before this change.
This brings the behaviour of device drivers for NICs with OFW support/
FCode, i.e. dc(4) for on-board DM9102A on Sun machines, gem(4) and hme(4),
regarding "local-mac-address?" in line with NetBSD and Solaris.
The man pages of the respective drivers will be updated separately to
reflect this change.
- Remove OF_getetheraddr2() which was used as a stopgap in dc(4). Its
functionality is now part of OF_getetheraddr().
chipsets, based on Linux's via-agp.c. On boot, the system selects which AGP
version to use based on the inserted card. If v2 was chosen, the chipset
needs to be programmed with the v2 registers still. Also included in kern/69953
are changes to make the programming of the v3 registers match linux, but that
will be left out until the need to do so is confirmed (want specs or a tester).
PR: kern/69953
Submitted by: Oleg Sharoiko <os@rsu.ru>
Tested by: Oleg Sharoiko <os@rsu.ru>, Geoff Speicher <geoff@speicher.org>
(full version from PR)
- 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
- Add *_locked() entry points as needed to avoid unnecessary lock thrashing.
- Use these entry points wisely.
- Only acquire the lock once when servicing an interrupt.
- Check 'suspended' on interrupt to avoid racing detach.
- Correct a mis-spelled comment.
- Don't take the lock in vr_reset() to avoid lock thrashing in attach.
- Comment this.
Reviewed by: -net (silence)
- Avoid unnecessary re-acquisition elsewhere by adding *_locked()
entry points as needed.
- Correct locking for the DEVICE_POLLING case.
- Hold the driver lock for the entire duration of interrupt servicing,
to avoid unneeded, expensive re-acquisition; use *_locked() entry
points as needed.
Reviewed by: -net (silence)
