NB: Using NULL for default values in-case someone
or something uncomments it and reboots. See
check-password.4th(8) for additional details.
MFC after: 3 days
X-MFC-to: stable/10 stable/9
When taking user input, don't show asterisks as the user types
but instead spin a twiddle. Implement Ctrl-U to clear user input.
If the buffer is empty, either because the user has yet to type
anything, presses Ctrl-U at any time, or presses backspace enough
to end in an empty buffer, the twiddle is erased to provide feed-
back to the user.
MFC after: 3 days
X-MFC-to: stable/10 stable/9
locking out everyone in the case of setting a password longer than
the maximum (currently 16 characters). Now the required password is
truncated to the maximum input that can be read from the user.
PR: kern/198760
MFC after: 3 days
MFH: stable/10 stable/9
Implement a subset of the multiboot specification in order to boot Xen
and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot
implementation is tailored to boot Xen and FreeBSD Dom0, and it will
most surely fail to boot any other multiboot compilant kernel.
In order to detect and boot the Xen microkernel, two new file formats
are added to the bootloader, multiboot and multiboot_obj. Multiboot
support must be tested before regular ELF support, since Xen is a
multiboot kernel that also uses ELF. After a multiboot kernel is
detected, all the other loaded kernels/modules are parsed by the
multiboot_obj format.
The layout of the loaded objects in memory is the following; first the
Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to
long mode by itself), after that the FreeBSD kernel is loaded as a RAW
file (Xen will parse and load it using it's internal ELF loader), and
finally the metadata and the modules are loaded using the native
FreeBSD way. After everything is loaded we jump into Xen's entry point
using a small trampoline. The order of the multiboot modules passed to
Xen is the following, the first module is the RAW FreeBSD kernel, and
the second module is the metadata and the FreeBSD modules.
Since Xen will relocate the memory position of the second
multiboot module (the one that contains the metadata and native
FreeBSD modules), we need to stash the original modulep address inside
of the metadata itself in order to recalculate its position once
booted. This also means the metadata must come before the loaded
modules, so after loading the FreeBSD kernel a portion of memory is
reserved in order to place the metadata before booting.
In order to tell the loader to boot Xen and then the FreeBSD kernel the
following has to be added to the /boot/loader.conf file:
xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga"
xen_kernel="/boot/xen"
The first argument contains the command line that will be passed to the Xen
kernel, while the second argument is the path to the Xen kernel itself. This
can also be done manually from the loader command line, by for example
typing the following set of commands:
OK unload
OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga
OK load kernel
OK load zfs
OK load if_tap
OK load ...
OK boot
Sponsored by: Citrix Systems R&D
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D517
For the Forth bits:
Submitted by: Julien Grall <julien.grall AT citrix.com>
output frequency of the "twiddle" IO progress indicator. The default
value is 1. For larger values N, the next stage of the animation is only
output on every Nth call to the output routine. A sufficiently large N
effectively disables the animation completely.
have chosen different (and more traditional) stateless/statuful
NAT64 as translation mechanism. Last non-trivial commits to both
faith(4) and faithd(8) happened more than 12 years ago, so I assume
it is time to drop RFC3142 in FreeBSD.
No objections from: net@
bootloader. Implement the following routines:
pcibios-device-count count the number of instances of a devid
pcibios-read-config read pci config space
pcibios-write-config write pci config space
pcibios-find-devclass find the nth device with a given devclass
pcibios-find-device find the nth device with a given devid
pcibios-locator convert bus device function ti pcibios locator
These commands are thin wrappers over their PCI BIOS 2.1 counterparts. More
informaiton, such as it is, can be found in the standard.
Export a nunmber of pcibios.X variables into the environment to report
what the PCI IDENTIFY command returned.
Also implmenet a new command line primitive (pci-device-count), but don't
include it by default just yet, since it depends on the recently added
words and any errors here can render a system unbootable.
This is intended to allow the boot loader to do special things based
on the hardware it finds. This could be have special settings that are
optimized for the specific cards, or even loading special drivers. It
goes without saying that writing to pci config space should not be
done without a just cause and a sound mind.
Sponsored by: Netflix
If the user specifies in /boot/loader.conf:
loader_brand="mycustom-brand"
Then "mycustom-brand" will be executed instead of "fbsd-logo".
Submitted by: alfred
Obtained from: FreeNAS
lindev(4) was only used to provide /dev/full which is now a standard feature of
FreeBSD. /dev/full was never linux-specific and provides a generally useful
feature.
Document this in UPDATING and bump __FreeBSD_version. This will be documented
in the PH shortly.
Reported by: jkim
conditionally include (but ignore failures) /boot/loader.rc.local and
/boot/menu.rc.local -- to make customizing the menu easier.
Reviewed by: alfred
Discussed on: -hackers
menu. This is reported to save headaches on some PPC systems where unload
followed by load does not produce the desired results wherein if-given
the opportunicy to abort the initial loading sequence, you can customize
the first load.
Reviewed by: nwhitehorn, kan
Discussed on: -current
kernel selection menu to the beastie menu. List of kernels is taken from
`kernels' in loader.conf(5) as a space (or comma) separated list of names
to display (up to 9). If not set, default value is "kernel kernel.old".
Does not validate that kernels exist because the next enhancement will be
to allow selection of the root device.
Discussed on: -current
MFC after: 3 days
The ng_create_one() and ng_mkpeer() functions in network.subr are
now not used anywhere, but I left them, since they can be useful
in future in netgraph scripting.
Submitted by: pluknet
Looking pretty good; this mostly works now. New code includes:
* Read cached entropy at startup, both from files and from loader(8) preloaded entropy. Failures are soft, but announced. Untested.
* Use EVENTHANDLER to do above just before we go multiuser. Untested.
and add support for default underride to $loader_version, acting as a way to
name a release. Release text is not displayed for the aforementioned feature
of alternate display layout (introduced in r254237); however, for all other
layouts (incl. default), the release name is displayed at lower-right.
See version.4th(8) for additional information and/or historical details.
NOTE: Also a minor edit to version.4th(8) while we're here.
Prior to r222417, setting `password' in loader.conf(5) did not prevent boot
but instead only prevented changes to boot options by prompting for password
if autoboot failed or the user interrupted the countdown sequence.
After r222417 the same machine with `password' set in loader.conf(5) would no
longer boot without _always_ entering the password.
This patch restores the old (8.x and older) functionality for password in
loader.conf(5) while adding a new bootlock_password feature to replace the
edge-case should anybody desire the regressed functionality (HINT: great for
PXE servers and/or private distributions).
loader.conf(5) was updated to be more clear with-respect to password setting
(previous text was misleading).
Documentation (loader.conf(5) and check-password.4th(8)) has been updated to
include notes on the new bootlock_password setting.
Special thanks to Alex Verbod for bringing this to my attention and helping to
refine the loader.conf(5) text.
PR: conf/170110
Submitted by: Vitaly Zakharov <ded3axap@gmail.com>
Reviewed by: Alexander Verbod <alexander.verbod@gmail.com>
Committed with changes to support the following from loader.conf(5):
+ console="vidconsole comconsole" (not just console="comconsole")
+ boot_serial="anything" (not just boot_serial="YES")
+ boot_multicons="anything" (unsupported in originally-submitted patch)
PR: conf/121064
Submitted by: koitsu
Reviewed by: gcooper, adrian (co-mentor)
Approved by: adrian (co-mentor)
Make the following interface changes to my beastie boot menu:
+ Move boot options to a submenu
+ Add a new "Boot Single" menu item
+ Make "Boot" item and new "Boot Single" item reverse when boot_single is set
+ Add new "Load Defaults" item (in new "Boot Options" submenu) for overridding
loader.conf(5) provided values with system defaults.
Reviewed by: adrian (co-mentor)
Approved by: adrian (co-mentor)
+ Cleanup syntax, slim-down code, and make things more readable
+ Introduce new +c! operator and ilk to reduce heap usage/allocations
+ Add safemode_enabled? safemode_enable and safemode_disable functions
+ Add singleuser_enabled? singleuser_enable singleuser_disable functions
+ Add verbose_enabled? verbose_enable and verbose_disable functions
+ Centralize strings (also to reduce heap usage)
Reviewed by: peterj, adrian (co-mentor)
Approved by: adrian (co-mentor)
submenus. See menusets.4th(8) for additional details including examples.
Discussed on arch and recommended for inclusion at the devsummit.
This change does not alter the appearance or user experience, only enhances
possibilities.
Reviewed by: adrian (co-mentor)
Approved by: adrian (co-mentor)
GIANT from VFS. This code is particulary broken and fragile and other
in-kernel implementations around, found in other operating systems,
don't really seem clean and solid enough to be imported at all.
If someone wants to reconsider in-kernel NTFS implementation for
inclusion again, a fair effort for completely fixing and cleaning it
up is expected.
In the while NTFS regular users can use FUSE interface and ntfs-3g
port to work with their NTFS partitions.
This is not targeted for MFC.
"boot verbose", "single user mode", "ACPI" and more are now stateful boolean
menuitems rather than direct action-items.
A short-coming in this new menu system is that when a user sets a non-default
value in loader.conf(5), this non-default state is not reflected in the menu
-- leading to confusion as to whether the option was taking effect or not.
This patch adds dynamic menuitem constructors _and_ the necessary Forth
callbacks to initialize these stateful menuitems -- causing the aforementioned
menuitems to adhere to loader.conf(5) settings.
PR: bin/172529
Approved by: adrian (co-mentor)
MFC after: 21 days
executed to better differentiate between loader-specific errors and kernel-
specific errors (if ever any of either).
This type of functionality hasn't been required before the introduction of the
advanced menu system (r222417). Adding this functionality will help different-
iate errors at the loader-level such as a BTX halt caused by heap exhaustion
and errors that may be involved with executing the kernel (wrong architecture
for example). A user can learn that messages before "Booting..." are related to
the loader(8) environment and it's Forth-ilk, while those after are not
related to loader(8) -- the point that loader(8) has ``left the building''.
This patch also includes a man-page update to color.4th(8) as the color logic
moves to a lower-level (from being included by beastie.4th to being included
by loader.4th).
After noticing a delay between execution of the overloaded "boot" FICL word and
the display of text on-screen, gcooper confirmed that the introduction of a
builtin memory test (disabled by adding hw.memtest.tests="0" to loader.conf(5))
was the cause of the delay.
This patch adds an echo to produce "Booting..." when the overloaded "boot" word
is executed (this includes from the interactive command-prompt on all arches,
from the menu system on arches that run the beastie menu, and even those arches
that run the menu but disable it by setting beastie_disable="YES" in
loader.conf(5)). When loader_color="YES" in loader.conf(5), the same message is
produced but in white text on a blue background (only the letters produced have
this background -- opposed to perhaps the entire line).
The menu item is now made completely independent with the ACPI item - most
modern systems seem to require ACPI and become even more "unsafe"
without it.
Safe Mode no longer disables APIC for the same reason.
kbdmux is not disabled as this feature has proven itself stable.
New actions:
- SMP is disabled in the Safe Mode now
- eventtimers are forced to periodic mode (some real and virtual systems
seem to have problems otherwise)
- geom extra vigorous integrity checking is disabled, this is to
facilitate migration from previous versions
Possible short term to do:
- make SMP switch a separate menu item
- restore APIC switch as a separate menu item
Longer term to do:
- turn various tweaks into separate menu items in a Safe Mode sub-menu
Please consider adding a safety tweak to Safe Mode when introducing
new major features or changes that may cause instabilities.
Discussed with: jhb, scottl, Devin Teske
MFC after: 3 weeks (stable/9 only)
Winbond Super I/O chips.
With minor efforts it should be possible the extend the driver to support
further chips/revisions available from Winbond. In the simplest case
only new IDs need to be added, while different chipsets might require
their own function to enter extended function mode, etc.
Sponsored by: Sandvine Incorporated ULC (in 2011)
Reviewed by: emaste, brueffer
MFC after: 2 weeks
- Enter instead of ENTER
- Remove colons
- Line up option values
- Use dots to provide a line to visually connect the menu
selections with their values
- Replace Enabled/Disabled with off/On
(bigger inital cap for "On" is a visual indicator)
- Remove confusing "Boot" from selections that don't boot.
- With loader_color=1 in /boot/loader.conf, use reverse video to
highlight enabled options
PR: misc/160818
Submitted by: Warren Block <wblock wonkity com>
Reviewed by: Devin Teske <devin dot teske fisglobal com>, current@
MFC after: 1 week
from the interactive loader(8) prompt and beastie_disable="YES" is set
in loader.conf(5). In this case menu.rc is not evaluated and consequently
menu-unset does not have a body yet. This results in the ficl warning
"menu-unset not found" when try-menu-unset invokes menu-unset.
Check for beastie_disable="YES" explicitly, so that the try-menu-unset
word will not attempt to invoke menu-unset because the menu will have
never been configured. [1]
Use the sfind primitive as a last resort as an additional safer approach
conjuring a foreign word safely. [2]
PR: kern/163938
Submitted by: Devin Teske [1]
Reviewed by: Devin Teske [2]
Reported and tested by: dim
MFC after: 1 week
X-MFC with: r228985
before invoking the kernel.
Quoting submitter:
The issue is with the new boot loader menu. It adds many loader variables
including ones that contain ANSI color escapes.
Obviously, these ANSI codes don't play well with serial consoles when
kenv(1) is executed without arguments (reports vary as to what happens,
but it's never pretty).
The net-effect is that kenv(1) no longer reports menu-related variables.
In essence, kenv(1) output should now appear the same as on RELENG_8
(which lacks the new boot loader and didn't use any such variables).
Thus, restoring serial console glory.
Submitted by: Devin Teske <devin dott teske fisglobal.com>
MFC after: 2 weeks
pre-r222417 state. The behavior was essentially reversed in r222417
which can cause confusion.
PR: 159775
Submitted by: Devin Teske
Approved by: re (kib)
default/loader.conf
This should help people installing ${OS} to USB devices, where there are
frequently cases where kernel tries to mount root before actual umass sensing
is finished.
Reviewed by: mav
Approved by: re (kib)
MFC after: 1 week
containing a kernel under /boot and that it's default value is "kernel"
not "/boot/kernel/kernel".
PR: docs/158992
Reported by: Wayne Mitchell wayne.mitchell.iz at gmail
Approved by: re (kib)
MFC after: 1 week
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
