Discussed on hackers and recommended for inclusion into 9.0 at the devsummit.
All support email to devin dteske at vicor dot ignoreme dot com .
Submitted by: dteske at vicor dot ignoreme dot com
Reviewed by: me and many others
The controller is commonly found on DM&P Vortex86 x86 SoC. The
driver supports all hardware features except flow control. The
flow control was intentionally disabled due to silicon bug.
DM&P Electronics, Inc. provided all necessary information including
sample board to write driver and answered many questions I had.
Many thanks for their support of FreeBSD.
H/W donated by: DM&P Electronics, Inc.
BIOS does not support ACPI. The other options in the menu retain their
existing numbers, option 2 is simply blanked out (and '2' is ignored).
MFC after: 1 month
bottom of the manpages and order them consistently.
GNU groff doesn't care about the ordering, and doesn't even mention
CAVEATS and SECURITY CONSIDERATIONS as common sections and where to put
them.
Found by: mdocml lint run
Reviewed by: ru
This driver was written by Alexander Pohoyda and greatly enhanced
by Nikolay Denev. I don't have these hardwares but this driver was
tested by Nikolay Denev and xclin.
Because SiS didn't release data sheet for this controller, programming
information came from Linux driver and OpenSolaris. Unlike other open
source driver for SiS190/191, sge(4) takes full advantage of TX/RX
checksum offloading and does not require additional copy operation in
RX handler.
The controller seems to have advanced offloading features like VLAN
hardware tag insertion/stripping, TCP segmentation offload(TSO) as
well as jumbo frame support but these features are not available
yet. Special thanks to xclin <xclin<> cs dot nctu dot edu dot tw>
who sent fix for receiving VLAN oversized frames.
Note that due to e.g. write throttling ('wdrain'), it can stall all the disk
I/O instead of just the device it's configured for. Using it for removable
media is therefore not a good idea.
Reviewed by: pjd (earlier version)
kern.ngroups+1. kern.ngroups can range from NGROUPS_MAX=1023 to
INT_MAX-1. Given that the Windows group limit is 1024, this range
should be sufficient for most applications.
MFC after: 1 month
video console which doesn't take any input from keyboard and hides
all output replacing it with ``spinning'' character (useful for
embedded products and custom installations).
Sponsored by: Sippy Software, Inc.
devices that we also support, just not by default (thus only LINT or
module builds by default).
While currently there is only "/dev/full" [2], we are planning to see more
in the future. We may decide to change the module/dependency logic in the
future should the list grow too long.
This is not part of linux.ko as also non-linux binaries like kFreeBSD
userland or ports can make use of this as well.
Suggested by: rwatson [1] (name)
Submitted by: ed [2]
Discussed with: markm, ed, rwatson, kib (weeks ago)
Reviewed by: rwatson, brueffer (prev. version)
PR: kern/68961
MFC after: 6 weeks
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
the serial console speed (i386 and amd64 only). If the previous
stage boot loader requested a serial console (RB_SERIAL or RB_MULTIPLE)
then the default speed is determined from the current serial port
speed. Otherwise it is set to 9600 or the value of BOOT_COMCONSOLE_SPEED
at compile time.
This makes it possible to set the serial port speed once in
/boot.config and the setting will propagate to boot2, loader and
the kernel serial console.
user to interrupt autoboot process at all. Currently, even when
`autoboot_delay' is set to 0, loader(8) still allows autoboot process to be
interrupted by pressing any key on the console when the loader reads kernel
and modules from the disk. In some cases (i.e. untrusted environment) such
behaviour is highly indesirable and user should not be allowed to interfere
with the autoboot process at all.
Sponsored by: PBXpress Inc.
MFC after: 3 days
they would leave enough elements on the stack that if you escaped to the
loader prompt and then typed 'setenv', it would pull in all of the leaked
junk and cause an exception in the environment. There still seems to be
3 leaked elements, but they don't appear to be coming from this file.
keyboards to work if no PS/2 keyboard is attached. The position in the
menu was chosen to avoid moving option 6 (loader prompt). This should
be a no-op on non-i386/amd64 machines.
after loading such a kernel, "module_path" will be set to
an insane value. Fixed example by providing an equivalent
setting. For the record, when automatically loading a
kernel (commands "boot" and "boot-conf"), the following is
tried, in this order:
path=/boot/${kernel} file=${bootfile}
path=/boot/${kernel} file=${kernel}
path=${kernel} file=${bootfile}
path=${kernel} file=${kernel}
path=${module_path} file=${kernel}
will prepend the current kernel booting... This prevents a problem of
loading /boot/kernel's modules when a different kernel has no modules,
but you left your module_load="YES" in loader.conf...
Reviewed by: dcs (minus the help part)
bootp -> BOOTP
bootp.nfsroot -> BOOTP_NFSROOT
bootp.nfsv3 -> BOOTP_NFSV3
bootp.compat -> BOOTP_COMPAT
bootp.wired_to -> BOOTP_WIRED_TO
- i.e. back out the previous commit. It's already possible to
pxeboot(8) with a GENERIC kernel.
Pointed out by: dwmalone
BOOTP -> bootp
BOOTP_NFSROOT -> bootp.nfsroot
BOOTP_NFSV3 -> bootp.nfsv3
BOOTP_COMPAT -> bootp.compat
BOOTP_WIRED_TO -> bootp.wired_to
This lets you PXE boot with a GENERIC kernel by putting this sort of thing
in loader.conf:
bootp="YES"
bootp.nfsroot="YES"
bootp.nfsv3="YES"
bootp.wired_to="bge1"
or even setting the variables manually from the OK prompt.
pf/pflog/pfsync as modules. Do not list them in NOTES or modules/Makefile
(i.e. do not connect it to any (automatic) builds - yet).
Approved by: bms(mentor)
is reserved by the loader, and thus any tunable name with that suffix will
be silently discarded.
Document this in the header and man page so that other developers do not
develop so many bumps on the head after banging it against the wall.
Detective work by: Mark Santcroos, grehan
assure backward compatibility (conditional on !BURN_BRIDGES), look it up
by its old name first, and log a warning (but accept the setting) if it
was found. If both the old and new name are defined, the new name takes
precedence.
Also export vm.kmem_size as a read-only sysctl variable; I find it hard to
tune a parameter when I don't know its default value, especially when that
default value is computed at boot time.
queue items that can be allocated by netgraph and the number of free queue
items that are cached on a private list.
Netgraph places an upper limit on the number of queue items it may allocate.
When there is a large number of netgraph messages travelling through the
system (100k/sec and more) there is a high probability, that messages get
queued at the nodes and netgraph runs out of queue items. In this case the data
flow through netgraph gets blocked. The tuneable for the number of free
items lets one trade memory for performance.
The tunables are also available as read-only sysctls.
PR: kern/47393
Reviewed by: julian
Approved by: jake (mentor)
this is called /boot/nextboot.conf. This file is required to have it's first
line be nextboot_enable="YES" for it to be read. Also, this file is
rewritten by the loader to nextboot_enable="NO"<space> after it is read.
This makes it so the file is read exactly once. Finally, the nextboot.conf
is removed shortly after the filesystems are mounted r/w.
Caution should be taken as you can shoot yourself in the foot. This is only
the loader piece. There will be a tool called nextboot(8) that will manage
the nextboot.conf file for you. It is coming shortly.
Reviewed by: dcs
Approved by: jake (mentor)
loader variable, which let users specify the root mount point
the exact way one does after booting the kernel.
Let's take this opportunity to document it...
around. If the kernel boots successfully, the record of this kernel
is erased, it is intended to be a one-shot option for testing
kernels.
This could be improved by having the loader remove the record of
the next kernel to boot, it is currently removed in /etc/rc immediately
after disks are mounted r/w.
I'd like to MFC this before the 4.6 freeze unless there is violent
objection.
Reviewed by: Several on IRC
MFC after: 4 days
This allows obtaining crash dumps from the panics occured during late stages
of kernel initialisation before system enters into single-user mode.
MFC after: 2 weeks
