things a bit:
- use dpcpu data to track the ifps with packets queued up,
- per-cpu locking and driver flags
- along with .nh_drainedcpu and NETISR_POLICY_CPU.
- Put the mbufs in flight reference count, preventing interfaces
from going away, under INVARIANTS as this is a general problem
of the stack and should be solved in if.c/netisr but still good
to verify the internal queuing logic.
- Permit changing the MTU to virtually everythinkg like we do for loopback.
Hook epair(4) up to the build.
Approved by: re (kib)
DP83065 Saturn Gigabit Ethernet controllers. These are the successors
of the Sun GEM controllers and still have a similar but extended transmit
logic. As such this driver is based on gem(4).
Thanks to marcel@ for providing a Sun Quad GigaSwift Ethernet UTP (QGE)
card which was vital for getting this driver to work on architectures
not using Open Firmware.
Approved by: re (kib)
MFC after: 2 weeks
controller. These controllers are also known as L1C(AR8131) and
L2C(AR8132) respectively. These controllers resembles the first
generation controller L1 but usage of different descriptor format
and new register mappings over L1 register space requires a new
driver. There are a couple of registers I still don't understand
but the driver seems to have no critical issues for performance and
stability. Currently alc(4) supports the following hardware
features.
o MSI
o TCP Segmentation offload
o Hardware VLAN tag insertion/stripping
o Tx/Rx interrupt moderation
o Hardware statistics counters(dev.alc.%d.stats)
o Jumbo frame
o WOL
AR8131/AR8132 also supports Tx checksum offloading but I disabled
it due to stability issues. I'm not sure this comes from broken
sample boards or hardware bugs. If you know your controller works
without problems you can still enable it. The controller has a
silicon bug for Rx checksum offloading, so the feature was not
implemented.
I'd like to say big thanks to Atheros. Atheros kindly sent sample
boards to me and answered several questions I had.
HW donated by: Atheros Communications, Inc.
driver in Linux 2.6. uscanner was just a simple wrapper around a fifo and
contained no logic, the default interface is now libusb (supported by sane).
Reviewed by: HPS
functions used in the bootloader. The goal is to make the code more
readable and smaller (especially because we have size issues
in the loader's environment).
High level description of the changes:
+ define some string manipulation functions to improve readability;
+ create functions to manipulate module descriptors, removing some
duplicated code;
+ rename the error codes to ESOMETHING;
+ consistently use set_environment_variable (which evaluates
$variables) when interpreting variable=value assignments;
I have tested the code, but there might be code paths that I have
not traversed so please let me know of any issues.
Details of this change:
--- loader.4th ---
+ add some module operators, to remove duplicated code while parsing
module-related commands:
set-module-flag
enable-module
disable-module
toggle-module
show-module
--- pnp.4th ---
+ move here the definition related to the pnp devices list, e.g.
STAILQ_* , pnpident, pnpinfo
--- support.4th ---
+ rename error codes to capital e.g. ENOMEM EFREE ... and do obvious
changes related to the renaming;
+ remove unused structures (those relevant to pnp are moved to pnp.4th)
+ various string functions
- strlen removed (it is an internal function)
- strchr, defined as the C function
- strtype -- type a string to output
- strref -- assign a reference to the string on the stack
- unquote -- remove quotes from a string
+ remove reset_line_buffer
+ move up the 'set_environment_variable' function (which now
uses the interpreter, so $variables are evaluated).
Use the function in various places
+ add a 'test_file function' for debugging purposes
MFC after: 4 weeks
loader_conf_files="foo bar baz"
should cause loading the files listed, and then resume with the
remaining config files (from previous values of the variable).
Unfortunately, sometimes the line was ignored -- actually even
modifying the line in /boot/default/loader.conf sometimes doesn't work.
ANALYSIS: After much investigation, turned out to be a bug in the logic.
The existing code detected a new assignment by looking at the address
of the the variable containing the string. This only worked by pure
chance, i.e. if the new string is longer than the previous value
then the memory allocator may return a different address
to store the string hence triggering the detection.
SOLUTION: This commit contains a minimal change to fix the problem,
without altering too much the existing structure of the code.
However, as a step towards improving the quality and reliability of
this code, I have introduced a handful of one-line functions
(strget, strset, strfree, string= ) that could be used in dozens
of places in the existing code.
HOWEVER:
There is a much bigger problem here. Even though I am no Forth
expert (as most fellow src committers) I can tell that much of the
forth code (in support.4th at least) is in severe need of a
review/refactoring:
+ pieces of code are replicated multiple times instead of writing
functions (see e.g. set_module_*);
+ a lot of stale code (e.g. "structure" definitions for
preloaded_files, kernel_module, pnp stuff) which is not used
or at least belongs elsewhere.
The code bload is extremely bad as the loader runs with very small
memory constraints, and we already hit the limit once (see
http://svn.freebsd.org/viewvc/base?view=revision&revision=185132
Reducing the footprint of the forth files is critical.
+ two different styles of coding, one using pure stack functions
(maybe beautiful but surely highly unreadable), one using
high level mechanisms to give names to arguments and local
variables (which leads to readable code).
Note that this code is used by default by all FreeBSD installations,
so the fragility and the code bloat are extremely damaging.
I will try to work fixing the three items above, but if others have
time, please have a look at these issues.
MFC after: 4 weeks
controller. The controller is also known as L1E(AR8121) and
L2E(AR8113/AR8114). Unlike its predecessor Attansic L1,
AR8121/AR8113/AR8114 uses completely different Rx logic such that
it requires separate driver. Datasheet for AR81xx is not available
to open source driver writers but it shares large part of Tx and
PHY logic of L1. I still don't understand some part of register
meaning and some MAC statistics counters but the driver seems to
have no critical issues for performance and stability.
The AR81xx requires copy operation to pass received frames to upper
stack such that ale(4) consumes a lot of CPU cycles than that of
other controller. A couple of silicon bugs also adds more CPU
cycles to address the known hardware bug. However, if you have fast
CPU you can still saturate the link.
Currently ale(4) supports the following hardware features.
- MSI.
- TCP Segmentation offload.
- Hardware VLAN tag insertion/stripping with checksum offload.
- Tx TCP/UDP checksum offload and Rx IP/TCP/UDP checksum offload.
- Tx/Rx interrupt moderation.
- Hardware statistics counters.
- Jumbo frame.
- WOL.
AR81xx PCIe ethernet controllers are mainly found on ASUS EeePC or
P5Q series of ASUS motherboards. Special thanks to Jeremy Chadwick
who sent the hardware to me. Without his donation writing a driver
for AR81xx would never have been possible. Big thanks to all people
who reported feedback or tested patches.
HW donated by: koitsu
Tested by: bsam, Joao Barros <joao.barros <> gmail DOT com >
Jan Henrik Sylvester <me <> janh DOT de >
Ivan Brawley < ivan <> brawley DOT id DOT au >,
CURRENT ML
current@ and stable@ for the locking patches. The driver can always be
revived if someone tests it.
This driver also sleeps in its if_init routine, so it likely doesn't really
work at all anyway in modern releases.
encounters a syntax error, and add a tip about adding first
the `vital' options and then experimental ones.
PR: docs/119658
Submitted by: Julian Stacey, jhs at berklix.org
