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)
- Eliminate the use of a recursive mutex.
- Mark the driver INTR_MPSAFE.
This work is incomplete and will be refined in a future commit.
- Most notably, _locked() variants of entry points need to be introduced.
- The mii upcall/downcall may still be racy.
- Add a stubbed-out guard against racing rl_detach() for the time being.
Tested on: UP, debug.mpsafenet && !debug.mpsafenet
Reviewed by: silence on -net
Use C99 types. Use ANSI function definitions. Sort prototypes.
Split long lines correctly. Punctuate/wordsmith comments.
Use device_printf()/if_printf() where possible.
Reviewed by: -net (silence)
- 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.
- Remove recursive locking situations. Remove the MTX_RECURSE bit.
- Take the lock for any routine which is not called from within if_vr.c
itself; this includes entry points called by newbus, ifnet, callout,
ifmedia, and polling subsystems.
- Remove spl references from the code added to miibus callbacks in rev 1.60.
- Add the INTR_MPSAFE bit.
- Tidy up some assignments; locks are not needed for taking the address
of something at a known offset, for example.
- Tested on the machine this was committed from.
Tested on: UP only, !debug.mpsafenet && debug.mpsafenet
Reviewed by: rwatson
Put some braces around the busy-wait loop in vr_rxeoc() to make the
no-op semicolon more obvious.
No functional changes.
Running on the machine I am committing from without problems.
Reviewed by: jmallett
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
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.
registers, so add a register offset array to the softc. We key off the
device ID to determine which set of register offsets. Currently the 8385
host bridge used on amd64 is the only bridge to use the AGP3_VIA_*
register offsets and all other bridges use the AGP_VIA_* offsets. It is
currently unclear if the AGP3_VIA_* offsets are for VIA bridges that
implement AGP 3.0 bridges or just for amd64 bridges.
Submitted by: Kenneth Culver culverk at sweetdreamsracing dot biz
caller to vm_page_grab(). Although this gives VM_ALLOC_ZERO a
different meaning for vm_page_grab() than for vm_page_alloc(), I feel
such change is necessary to accomplish other goals. Specifically, I
want to make the PG_ZERO flag immutable between the time it is
allocated by vm_page_alloc() and freed by vm_page_free() or
vm_page_free_zero() to avoid locking overheads. Once we gave up on
the ability to automatically recognize a zeroed page upon entry to
vm_page_free(), the ability to mutate the PG_ZERO flag became useless.
Instead, I would like to say that "Once a page becomes valid, its
PG_ZERO flag must be ignored."
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...
status registers for error conditions and updating statistics
when there are cycles left (inspired by the nge(4) driver).
- Removed the TX list counter and the producer/consumer gap; it's
enough to just ensure we don't reuse the last (free) descriptor,
as the chip may not have read its next pointer yet. If we reuse
it, the TX may stall under a heavy TX load with polling enabled.
- Dropped code to recharge the watchdog timer, it's pointless; the
watchdog routine will re-init the chip and both RX and TX lists.
without the (defunct) isa compatibility shims. The new-bus-specific
parts are very similar to the ones for the pci probe and attach.
This was held up too long waiting for a repo copy to src/sys/dev/cy,
so I decided to fix the files in their old place. This gives easier
to read and merge diffs anyway.
The "count" line in src/sys/conf/files won't be changed until after
the repo copy, so old kernel configs that specify a count need not be
(and must not be) changed until then. The count is just ignored in
the driver. One unfinished detail is dynamic allocation of arrays
with <count> and (<count> * 32) entries, and iteration over the arrays.
This is now kludged with a fixed count of 10 (up to 10 cards with up
to 32 ports each).
Prodded by: imp
Submitted by: mostly by imp
Approved by: imp
Add in missing case for i845G in the attach routine. I'll MFC this
with the rest of the change after the 4.10 codefreeze lifts.
Reviewed By: Doug Rabson
Under polling(4), we counted non-existent output packets and wasted
CPU cycles, corrected. (PR kern/64975.)
The fix in revision 1.71 to correct resetting of the watchdog timer
was wrong.
In rl(4), the TX list does not have a gap between the consumer and
producer, so the "empty TX list" test was wrong, corrected.
Also, resetting the timer to five each time we know there is still
some TX work to do was a bad idea -- under polling(4), if the chip
goes out to lunch, this results in the watchdog routine to _never_
be called. Instead, let the timer downgrade to zero and fire the
watchdog, then reset it to five when it is zero AND there is some
TX work left. (Most other network drivers need this fix too.)
MFC after: 3 days
Moved the RX ring resyncing code to ste_rxeoc(), and only run it
if we were asked to POLL_AND_CHECK_STATUS, under DEVICE_POLLING.
(This significantly reduces the CPU load.)
Improved the RX ring resyncing code by re-checking if the head
is still empty before doing resyncing. This mostly affects the
DEVICE_POLLING mode, where we run this code periodically. We
could start checking with an empty head (well, an empty ring
even), and after doing a few iterations, the chip might write
a few entries, including the head, and we would bogusly consider
this case as requiring resyncing. On a test box, this reduced
the number of resyncs done by a factor of 10.
In ste_txeof(sc), only reset the watchdog timer to zero when
the TX list is completely empty.
Converted ste_tx_prev_idx to a pointer -- faster.
Removed some bitrot.
the driver's RX ring head may fall behind the chip, causing the
stuck traffic, disordered packets, etc. Work around this by
adopting the technique of resyncing RX head used in dc(4) and
xl(4) drivers, but do it in a slightly different place to reduce
the number of resyncs needed.
Also, set the NIC's RX polling period to a more meaningful value,
to stop overloading the PCI bus (this also reduces the number of
resyncs by a factor of 3 or more in a long run; the actual number
is very dependent on a nature of the traffic).
Maintain the statistics counter as the hw.ste_rxsyncs sysctl.
In cooperation with: Vsevolod Lobko
OK'ed by: ambrisko
MFC after: 5 days
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
No functional change, the previous ste_encap() was correct WRT
long mbuf chains; this just reduces code duplication.
MFC after: 3 days
Prodded by: ambrisko
attach/detach time.
Assigning the default behaviour to this particular device is
incorrect, corrupting the video BIOS aperture, and breaking
VESA support in the kernel and XFree86.
Reviewed By: dfr
MFC after: 1 week
PR: kern/62906
Introduce d_version field in struct cdevsw, this must always be
initialized to D_VERSION.
Flip sense of D_NOGIANT flag to D_NEEDGIANT, this involves removing
four D_NOGIANT flags and adding 145 D_NEEDGIANT flags.
Free approx 86 major numbers with a mostly automatically generated patch.
A number of strategic drivers have been left behind by caution, and a few
because they still (ab)use their major number.
MAC address in the EEPROM, and we need to get it from OpenFirmware.
This isn't very pretty but time is lacking to do this in a better
way this near 5.2-RELEASE. This is a RELENG_5_2 candidate.
Original version by: Marius Strobl <marius@alchemy.franken.de>
Tested by: Pete Bentley <pete@sorted.org>
Reviewed by: jake
frame, not the first. It is probably also not safe to free the mbuf chain
as soon as the OWN bit is cleared on the first descriptor since the chip
may not be done copying the frame into the transmit FIFO. Revert the part of
of busdma conversion (if_dc.c rev 1.115) which changed dc_txeof() to look for
the status in the first descriptor and free the mbuf chain when processing
the first descriptor for the frame, and revert the matching changes elsewhere
in the driver. This part of the busdma change caused the driver to report
spurious collisions and output errors, even when running in full-duplex mode.
Reverting the mbuf chain handling slightly complicates dc_dma_map_txbuf(),
since it is responsible for setting the OWN bits on the descriptors, but does
not normally have direct access to the mbuf chain.
Tested by:
Dejan Lesjak <dejan.lesjak at ijs.si> alpha/<Intel 21143 10/100BaseTX>
"Xin LI" <delphij at frontfree.net> i386/<Macronix 98713 10/100BaseTX>
Wiktor Niesiobedzki <bsd at w.evip.pl> i386/<3Com OfficeConnect 10/100B>
Reviewed by: mux
report a hardware rev of 0x00000000. Sadly, the 8169 gigE MAC
also reports 0x00000000, so testing against this for exclusion
results in both cards being skipped by rl_probe(). Make the 8169
test more specific by matching against both the hwrev and the PCI
ID for this chip.
PR: kern/60824
this driver by introducing a flag saying we already stopped the device.
On my Soekris net4801, this took a ping -i 0.001 from spending 80% of
time in interrupt handling to 10% (approx numbers).
This was a particular problem for the net4801 because the tree
interfaces share the same interrupt, but it would be a problem for
any configuration where an unused if_sis interface shares an interrupt
with a busy device.
Other drivers may have similar problems.
Thanks to: Luigi
Only do short-cable on revisions that need it.
Move generic initialization before short-cable fix, in order to not
clobber short cable fix register setting.
code. Both the driver and the new code were wrong. Driver interrupt
handlers are supposed to take "void *vsc" arg, but some including all
COMPAT_ISA drivers and the pci part of the cy driver want an "int unit"
arg. They got this using bogus casts of function pointers which should
have kept working despite their bogusness. However, the new interrupt
code doesn't honor requests to pass an arg of ((void *)0), so things
are very broken if the arg is actually a representation of unit 0.
The fix is to use a normal "void *vsc" arg for the pci case and a
wrapper for the COMPAT_ISA case (of the cy driver). This cleans up
new-busification of the pci case but takes the COMPAT_ISA case a little
further from new-bus. The corresponding bug for the COMPAT_ISA case
has already been fixed similarly using a wrapper in compat_isa.c and
we need another wrapper just to undo that.
Fixed some directly related style bugs (mainly by removing compatibility
cruft).
cy.c:
Fixed an indirectly related old bug in cyattach_common(). A wrong status
was returned in the unlikely event that malloc() failed.
Approved by: re (scottl)
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).
