before adding/removing packets from the queue. Also, the if_obytes and
if_omcasts fields should only be manipulated under protection of the mutex.
IF_ENQUEUE, IF_PREPEND, and IF_DEQUEUE perform all necessary locking on
the queue. An IF_LOCK macro is provided, as well as the old (mutex-less)
versions of the macros in the form _IF_ENQUEUE, _IF_QFULL, for code which
needs them, but their use is discouraged.
Two new macros are introduced: IF_DRAIN() to drain a queue, and IF_HANDOFF,
which takes care of locking/enqueue, and also statistics updating/start
if necessary.
ether_ifdetach().
The former consolidates the operations of if_attach(), ng_ether_attach(),
and bpfattach(). The latter consolidates the corresponding detach operations.
Reviewed by: julian, freebsd-net
of the individual drivers and into the common routine ether_input().
Also, remove the (incomplete) hack for matching ethernet headers
in the ip_fw code.
The good news: net result of 1016 lines removed, and this should make
bridging now work with *all* Ethernet drivers.
The bad news: it's nearly impossible to test every driver, especially
for bridging, and I was unable to get much testing help on the mailing
lists.
Reviewed by: freebsd-net
for transmit to the adapter, not when we receive a transmit interrupt
indicating that they were sent. This fix now allows tcpdump to produce
sane results by recording the timestamp at the point where the mbuf was
actually transmitted.
This means that we will not have to have a bpf and a non-bpf version
of our driver modules.
This does not open any security hole, because the bpf core isn't loadable
The drivers left unchanged are the "cross platform" drivers where the respective
maintainers are urged to DTRT, whatever that may be.
Add a couple of missing FreeBSD tags.
events, in order to pave the way for removing a number of the ad-hoc
implementations currently in use.
Retire the at_shutdown family of functions and replace them with
new event handler lists.
Rework kern_shutdown.c to take greater advantage of the use of event
handlers.
Reviewed by: green
to achieve a delay is pretty mean.
Andrew reports:
"The tulip_delay_300ns() is, well, bloody stupid on machines with a
heavily loaded PCI bus. It tries to do a delay by assuming PCI reads
will take a certain amount of time & issues a large amount of
(expensive, 5% CPU when your PCI bus is heavily loaded) pci reads.
Locally, we've replaced the calls to tulip_delay_300ns(sc) in the EMIT
macros with a simple DELAY(1) and not seen any problems. Plus we've
gained about 50Mb/sec throughput on our gigabit network cards because
of the added PCI bus bandwidth available."
Also, I do not understand why, but this change appears to stop the
Transmit Fifo underrun on one of my systems (but not the Alpha PC164SX).
This shouldn't make that much of a difference since the mii bus isn't
touched all that often, but perhaps when it does get accessed and hence
hammers the register, it was causing the chip to get upset.
Submitted by: Andrew Gallatin <gallatin@cs.duke.edu>
Allow chipset drivers to specify the direct-mapped DMA window's mask in
preparation for tsunami support. Previous chipsets' direct-mapped DMA
mask was always 1024*1024*1024. The Tsunami chipset needs it to be
2*1024*1024*1024
Reviewed by: Doug Rabson <dfr@nlsystems.com>
#define COMPAT_PCI_DRIVER(name,data) DATA_SET(pcidevice_set,data)
.. to 2.2.x and 3.x if people think it's worth it. Driver writers can do
this if it's not defined. (The reason for this is that I'm trying to
progressively eliminate use of linker_sets where it hurts modularity and
runtime load capability, and these DATA_SET's keep getting in the way.)
* Make the network code in the bootstrap more chatty (helps debugging)
* Add nfs root stuff to cpu_rootconf(). I also added a check to make sure
it really was netbooting which allows the use of the same kernel for local
and network boots.
* Tweak the de driver so that it takes the speed setting from the console
for the alpha (some PWSs have broken de chipsets). This is the same
behaviour as NetBSD/alpha.
Submitted by: Andrew Gallatin <gallatin@cs.duke.edu>
a wierd double-queue arrangement.. It always empties the if_snd queue
then puts the transmit packets into a different queue that is limited
by the number of TX descriptors and does it's own discards...
This should stop the boot-time XXX warning anyway.
tulip_addr_filter() on SIOCSIFFLAGS, and was nuking the IFF_ALLMULTI
on entering tulip_addr_filter(). As a result it was impossible to run
a multicast router on a machine with a "de" interface.
v_caddr_t with extreme prejudice. Here the bogons were originally
the same as for c_caddr_t (half-baked K&R support), but rev.1.95
changed one wrong cast and one harmless cast to 2 wrong casts,
and rev.1.96 only fixed the originally wrong cast.
c_caddr_t with extreme prejudice. Here the original casts to
caddr_t were to support K&R compilers (or missing prototypes),
but the relevant source files require an ANSI compiler.
const char *. Originally I was going to add casts from const char * to
char * in some of the pci device drivers, but the reality is that the
pci device probes return constant quoted strings.
this myself for ages, but wasn't able to get any feedback from the people
that I sent it to for testing.
Guy Helmer <ghelmer@scl.ameslab.gov> has given it a shot (before getting on
a plane, thanks!) and it appears to stop his reproducable page fault panic
in the testing he was able to do.
respectively. Most of the longs should probably have been
u_longs, but this changes is just to prevent warnings about
casts between pointers and integers of different sizes, not
to fix poorly chosen types.
- connector selection values (should fix aui/bnc),
- non-shifting version of crc calculation using a table,
- interrupt mask adjustments,
- add some brackets where a #ifdef could break an if(),
- don't reset the card unless it's up.
or unsigned int (this doesn't change the struct layout, size or
alignment in any of the files changed in this commit, at least for
gcc on i386's. Using bitfields of type u_char may affect size and
alignment but not packing)).
FreeBSD/alpha. The most significant item is to change the command
argument to ioctl functions from int to u_long. This change brings us
inline with various other BSD versions. Driver writers may like to
use (__FreeBSD_version == 300003) to detect this change.
The prototype FreeBSD/alpha machdep will follow in a couple of days
time.
This will not make any of object files that LINT create change; there
might be differences with INET disabled, but hardly anything compiled
before without INET anyway. Now the 'obvious' things will give a
proper error if compiled without inet - ipx_ip, ipfw, tcp_debug. The
only thing that _should_ work (but can't be made to compile reasonably
easily) is sppp :-(
This commit move struct arpcom from <netinet/if_ether.h> to
<net/if_arp.h>.
The #ifdef IPXIP in netipx/ipx_if.h is OK (used from ipx_usrreq.c and
ifconfig.c only).
I also fixed a typo IPXTUNNEL -> IPTUNNEL (and #ifdef'ed out the code
inside, as it never could have compiled - doh.)
a change that might have an effect on the problems some have seen
with older chips, it looks like the driver may have mistakenly thought
there was an SIA when there isn't.
rather than extracting the diff from Mark's patch, but it turns out that
I was freeing one allocation twice due to a previous cut/paste braino.
My botch, not Mark's.
Pointed out by: Mark Valentine <mv@pobox.com>
large (over 4KB) softc struct. The descriptor array is accessed by
busmaster dma and must be physically contiguous in memory. malloc() of
a block greater than a page is only virtually contiguous, and not
necessarily physically contigious.
contigmalloc() could do this, but that is a bit on the overkill side.
I'm not sure of the origins of the problem report and diagnosis, I learned
of the problem via mail forwarded from Jim Shankland <jas@flyingfox.com>.
Jim said that Matt Thomas's workaround was to reduce the number of
transmit descriptors from 128 to 32, but I was concerned that it might
cost performance. Anyway, this change is my fault, not Jim's. :-)
Reviewed by: davidg
changes relative to the 2.2 compatable version are include file
related, the new multicast interface (!) and the new PCI interface.
This should work "as-is" but has not been tested (I have not been able
to get a dc21x4x based card for testing).
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
previous hackery involving struct in_ifaddr and arpcom. Get rid of the
abominable multi_kludge. Update all network interfaces to use the
new machanism. Distressingly few Ethernet drivers program the multicast
filter properly (assuming the hardware has one, which it usually does).
a) Removal of private typedefs tulip_uint*_t, use standard u_int_*_t.
b) Change [Dd][Cc]21.4. to just 21.4., seems Dec has done this to all
of the drivers for all OS's. (Did they get in trouble with someone?)
[The few that remain can either not be eliminated, or are waiting for
additional driver functional changes that will remove them.]
c) Move some code from dc21040.h into the driver, later a whole block of that
code and more will move to devar.h, but for now this makes it easier
to study diffs.
d) Add a big bold comment to the README.de file about it not reflecting
reality anymore.
Note that these are all cosmetic changes and should be no functional
change in the driver whatsoever. If _anyone_ spots a problem introduced
by this please let me know ASAP!
changes. This version should fix a number of bugs such as with auto-
speed sensing and at least one known panic.
Submitted by: Matt Thomas (matt@3am-software.com)
