Searched hist:5 (Results 126 - 150 of 11096) sorted by relevance

1234567891011>>

/freebsd-11.0-release/sys/dev/bxe/
H A Decore_init.hdiff 295830 Fri Feb 19 22:53:52 MST 2016 davidcs Remove dead code. Code Cleanup. Improve clarity in debug messages

MFC after:5 days
diff 292639 Wed Dec 23 03:29:52 MST 2015 davidcs Add support for firmware dump (a.k.a grcdump)

MFC after:5 days
diff 265411 Tue May 06 02:40:04 MDT 2014 davidcs Modify Copyright information to reflect Qlogic Corporation's purchase
of Broadcom's NetXtreme business

Submitted by:David C Somayajulu (davidcs@freebsd.org) QLogic Corporation
MFC after:5 days
H A Decore_reg.hdiff 284335 Sat Jun 13 01:33:45 MDT 2015 davidcs PHY LOCK acquires the hardware lock via bxe_acquire_phy_lock() and releases it via bxe_release_phy_lock(). It was simply acquiring a mutex earlier which can cause the PHY to use bogus values. Fixes intermittent link failures.

bxe_ioctl() completes all functions within its context as opposed to a taskqueue earlier.

bxe_handle_rx_mode_tq() no longer required. bxe_set_rx_mode() handles the functionality within its context

Submitted by:gary.zambrano@qlogic.com
MFC after:5 days
diff 268854 Fri Jul 18 20:14:46 MDT 2014 davidcs Initiate error recovery stats fail to update after 3 retries.
Change bxe_panic() ECORE_DBG_BREAK_IF() ECORE_BUG() ECORE_BUG_ON() to
panic only if ECORE_STOP_ON_ERROR is defined.

MFC after:5 days
diff 265411 Tue May 06 02:40:04 MDT 2014 davidcs Modify Copyright information to reflect Qlogic Corporation's purchase
of Broadcom's NetXtreme business

Submitted by:David C Somayajulu (davidcs@freebsd.org) QLogic Corporation
MFC after:5 days
H A Dbxe_stats.hdiff 297873 Tue Apr 12 21:11:22 MDT 2016 davidcs 1. Process tx completions in bxe_periodic_callout_func() and restart
transmissions if possible.
2. For SIOCSIFFLAGS call bxe_init_locked() only if !BXE_STATE_DISABLED
3. remove code not needed in bxe_init_internal_common()

Submitted by:vaishali.kulkarni@qlogic.com;venkata.bhavaraju@qlogic.com
Approved by:davidcs@freebsd.org
MFC after:5 days
diff 292638 Wed Dec 23 01:41:00 MST 2015 davidcs Check for packet_length is greater than 60 bytes as well as packet_length is
greater than len_on_bd, before invoking the routine to handle jumbo over SGL
(bxe_service_rxsgl()).
Add counters for number of jumbo_over_SGL packets (rx_bxe_service_rxsgl) and
erroneous jumbo_over_SGL packets (rx_erroneous_jumbo_sge_pkts)

Fix formatting in bxe_sysctl_state()

MFC after:5 days
diff 283274 Fri May 22 01:49:37 MDT 2015 davidcs Add stat counters for Jumbo Frames using SGE ring.
Also remove the checks for IFCAP_LRO in bxe_alloc_fp_buffers() and bxe_pf_rx_q_prep() since both TPA and Jumbo can use SGE ring.

Submitted by:gary.zambrano@qlogic.com
Approved by:davidcs@freebsd.org
MFC after:5 days
diff 265411 Tue May 06 02:40:04 MDT 2014 davidcs Modify Copyright information to reflect Qlogic Corporation's purchase
of Broadcom's NetXtreme business

Submitted by:David C Somayajulu (davidcs@freebsd.org) QLogic Corporation
MFC after:5 days
/freebsd-11.0-release/sys/geom/raid/
H A Dtr_raid5.cdiff 254275 Tue Aug 13 08:07:48 MDT 2013 mav Return error when opening read-only volumes (like RAID4/5/...) for writing.
Previously opens succeeded, but actual write operations returned errors.

Requested by: peter
MFC after: 2 weeks
diff 234993 Fri May 04 07:42:32 MDT 2012 mav Implement read-only support for volumes in optimal state (without using
redundancy) for the following RAID levels: RAID4/5E/5EE/6/MDF.
diff 234993 Fri May 04 07:42:32 MDT 2012 mav Implement read-only support for volumes in optimal state (without using
redundancy) for the following RAID levels: RAID4/5E/5EE/6/MDF.
/freebsd-11.0-release/sys/modules/bxe/
H A DMakefilediff 298591 Mon Apr 25 19:07:16 MDT 2016 davidcs 1. Removed -Wno-shift-negative-value from Makefile
2. Fixed warning its absence caused in bxe_elink.c

MFC after:5 days
diff 271726 Wed Sep 17 22:29:14 MDT 2014 davidcs Remove clean option

MFC after:5 days
diff 265411 Tue May 06 02:40:04 MDT 2014 davidcs Modify Copyright information to reflect Qlogic Corporation's purchase
of Broadcom's NetXtreme business

Submitted by:David C Somayajulu (davidcs@freebsd.org) QLogic Corporation
MFC after:5 days
/freebsd-11.0-release/lib/libc/posix1e/
H A Dmac.conf.5diff 113741 Sun Apr 20 04:43:56 MDT 2003 rwatson Add FILES section to mac.3 and mac.conf.5. Properly Xref mac.conf.5
from mac.3; likewise, mac.conf.5 from mac_prepare.3.

Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
diff 113741 Sun Apr 20 04:43:56 MDT 2003 rwatson Add FILES section to mac.3 and mac.conf.5. Properly Xref mac.conf.5
from mac.3; likewise, mac.conf.5 from mac_prepare.3.

Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
diff 113741 Sun Apr 20 04:43:56 MDT 2003 rwatson Add FILES section to mac.3 and mac.conf.5. Properly Xref mac.conf.5
from mac.3; likewise, mac.conf.5 from mac_prepare.3.

Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
/freebsd-11.0-release/etc/defaults/
H A DMakefilediff 152286 Thu Nov 10 19:09:22 MST 2005 emax Start integrating Bluetooth into rc.d system.

Introduce /etc/rc.d/bluetooth script to start/stop Bluetooth devices. It
will be called from devd(8) in response to device arrival/departure events.
It is also possible to call it by hand to start/stop particular device
without unplugging it.

Introduce generic way to set configuration parameters for Bluetooth devices.
By default /etc/rc.d/bluetooth script has hardwired defaults compatible
with old rc.bluetooth from /usr/share/netgraph/bluetooth/examples. These
can be overridden using /etc/defaults/bluetooth.device.conf file (system
wide defaults). Finally, there could be another device specific override
file located in /etc/bluetooth/$device.conf (where $device is ubt0, btccc0
etc.)

The list of configuration parameters and their meaning described in the
/etc/defaults/bluetooth.device.conf file. Even though Bluetooth device
configuration files are not shell scripts, they must follow basic sh(1) syntax.

The bluetooth.device.conf(5) and handbook update will follow shortly.

Inspired by: Panagiotis Astithas ( past at ebs dot gr )
Reviewed by: brooks, yar
MFC after: 1 week
diff 119166 Wed Aug 20 06:15:18 MDT 2003 mtm Add a general mechanism for creating and applying
devfs(8) rules in rc(8). It is most useful for applying
rules to devfs(5) mount points in /dev or inside jails.
The following line of script is sufficient to
mount a relatively useful+secure devfs(5) in a jail:

devfs_mount_jail /some/jail/dev

Some new shell routines available to scripts that source
rc.subr(5):
o devfs_link - Makes it a little easier to create symlinks
o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules
o devfs_set_ruleset - Set a ruleset to a devfs(5) mount
o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount
o devfs_domount - Mount devfs(5) and apply some ruleset
o devfs_mount_jail - Mount devfs(5) and apply a ruleset
appropriate to jails.

Additional rulesets can be specified in /etc/devfs.rules.
If the devfs_system_ruleset variable is defined in rc.conf
and it contains the name of a ruleset defined in /etc/defaults/devfs.rules
or user supplied rulesets in /etc/devfs.rules then that ruleset will
be applied to /dev at startup by the /etc/rc.d/devfs script. It can
also be applied post-startup:

/etc/rc.d/devfs start

This is a more flexible mechanism than the previous method of using
/etc/devfs.conf. However, that method is still available.

Note: since devfs(8) doesn't provide any way for creating symlinks
as part of a ruleset, anyone wishing to create symlinks in a devfs(5)
as part of the bootup sequence will still have to rely on /etc/devfs.conf.
diff 119166 Wed Aug 20 06:15:18 MDT 2003 mtm Add a general mechanism for creating and applying
devfs(8) rules in rc(8). It is most useful for applying
rules to devfs(5) mount points in /dev or inside jails.
The following line of script is sufficient to
mount a relatively useful+secure devfs(5) in a jail:

devfs_mount_jail /some/jail/dev

Some new shell routines available to scripts that source
rc.subr(5):
o devfs_link - Makes it a little easier to create symlinks
o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules
o devfs_set_ruleset - Set a ruleset to a devfs(5) mount
o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount
o devfs_domount - Mount devfs(5) and apply some ruleset
o devfs_mount_jail - Mount devfs(5) and apply a ruleset
appropriate to jails.

Additional rulesets can be specified in /etc/devfs.rules.
If the devfs_system_ruleset variable is defined in rc.conf
and it contains the name of a ruleset defined in /etc/defaults/devfs.rules
or user supplied rulesets in /etc/devfs.rules then that ruleset will
be applied to /dev at startup by the /etc/rc.d/devfs script. It can
also be applied post-startup:

/etc/rc.d/devfs start

This is a more flexible mechanism than the previous method of using
/etc/devfs.conf. However, that method is still available.

Note: since devfs(8) doesn't provide any way for creating symlinks
as part of a ruleset, anyone wishing to create symlinks in a devfs(5)
as part of the bootup sequence will still have to rely on /etc/devfs.conf.
diff 119166 Wed Aug 20 06:15:18 MDT 2003 mtm Add a general mechanism for creating and applying
devfs(8) rules in rc(8). It is most useful for applying
rules to devfs(5) mount points in /dev or inside jails.
The following line of script is sufficient to
mount a relatively useful+secure devfs(5) in a jail:

devfs_mount_jail /some/jail/dev

Some new shell routines available to scripts that source
rc.subr(5):
o devfs_link - Makes it a little easier to create symlinks
o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules
o devfs_set_ruleset - Set a ruleset to a devfs(5) mount
o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount
o devfs_domount - Mount devfs(5) and apply some ruleset
o devfs_mount_jail - Mount devfs(5) and apply a ruleset
appropriate to jails.

Additional rulesets can be specified in /etc/devfs.rules.
If the devfs_system_ruleset variable is defined in rc.conf
and it contains the name of a ruleset defined in /etc/defaults/devfs.rules
or user supplied rulesets in /etc/devfs.rules then that ruleset will
be applied to /dev at startup by the /etc/rc.d/devfs script. It can
also be applied post-startup:

/etc/rc.d/devfs start

This is a more flexible mechanism than the previous method of using
/etc/devfs.conf. However, that method is still available.

Note: since devfs(8) doesn't provide any way for creating symlinks
as part of a ruleset, anyone wishing to create symlinks in a devfs(5)
as part of the bootup sequence will still have to rely on /etc/devfs.conf.
diff 119166 Wed Aug 20 06:15:18 MDT 2003 mtm Add a general mechanism for creating and applying
devfs(8) rules in rc(8). It is most useful for applying
rules to devfs(5) mount points in /dev or inside jails.
The following line of script is sufficient to
mount a relatively useful+secure devfs(5) in a jail:

devfs_mount_jail /some/jail/dev

Some new shell routines available to scripts that source
rc.subr(5):
o devfs_link - Makes it a little easier to create symlinks
o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules
o devfs_set_ruleset - Set a ruleset to a devfs(5) mount
o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount
o devfs_domount - Mount devfs(5) and apply some ruleset
o devfs_mount_jail - Mount devfs(5) and apply a ruleset
appropriate to jails.

Additional rulesets can be specified in /etc/devfs.rules.
If the devfs_system_ruleset variable is defined in rc.conf
and it contains the name of a ruleset defined in /etc/defaults/devfs.rules
or user supplied rulesets in /etc/devfs.rules then that ruleset will
be applied to /dev at startup by the /etc/rc.d/devfs script. It can
also be applied post-startup:

/etc/rc.d/devfs start

This is a more flexible mechanism than the previous method of using
/etc/devfs.conf. However, that method is still available.

Note: since devfs(8) doesn't provide any way for creating symlinks
as part of a ruleset, anyone wishing to create symlinks in a devfs(5)
as part of the bootup sequence will still have to rely on /etc/devfs.conf.
diff 119166 Wed Aug 20 06:15:18 MDT 2003 mtm Add a general mechanism for creating and applying
devfs(8) rules in rc(8). It is most useful for applying
rules to devfs(5) mount points in /dev or inside jails.
The following line of script is sufficient to
mount a relatively useful+secure devfs(5) in a jail:

devfs_mount_jail /some/jail/dev

Some new shell routines available to scripts that source
rc.subr(5):
o devfs_link - Makes it a little easier to create symlinks
o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules
o devfs_set_ruleset - Set a ruleset to a devfs(5) mount
o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount
o devfs_domount - Mount devfs(5) and apply some ruleset
o devfs_mount_jail - Mount devfs(5) and apply a ruleset
appropriate to jails.

Additional rulesets can be specified in /etc/devfs.rules.
If the devfs_system_ruleset variable is defined in rc.conf
and it contains the name of a ruleset defined in /etc/defaults/devfs.rules
or user supplied rulesets in /etc/devfs.rules then that ruleset will
be applied to /dev at startup by the /etc/rc.d/devfs script. It can
also be applied post-startup:

/etc/rc.d/devfs start

This is a more flexible mechanism than the previous method of using
/etc/devfs.conf. However, that method is still available.

Note: since devfs(8) doesn't provide any way for creating symlinks
as part of a ruleset, anyone wishing to create symlinks in a devfs(5)
as part of the bootup sequence will still have to rely on /etc/devfs.conf.
diff 119166 Wed Aug 20 06:15:18 MDT 2003 mtm Add a general mechanism for creating and applying
devfs(8) rules in rc(8). It is most useful for applying
rules to devfs(5) mount points in /dev or inside jails.
The following line of script is sufficient to
mount a relatively useful+secure devfs(5) in a jail:

devfs_mount_jail /some/jail/dev

Some new shell routines available to scripts that source
rc.subr(5):
o devfs_link - Makes it a little easier to create symlinks
o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules
o devfs_set_ruleset - Set a ruleset to a devfs(5) mount
o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount
o devfs_domount - Mount devfs(5) and apply some ruleset
o devfs_mount_jail - Mount devfs(5) and apply a ruleset
appropriate to jails.

Additional rulesets can be specified in /etc/devfs.rules.
If the devfs_system_ruleset variable is defined in rc.conf
and it contains the name of a ruleset defined in /etc/defaults/devfs.rules
or user supplied rulesets in /etc/devfs.rules then that ruleset will
be applied to /dev at startup by the /etc/rc.d/devfs script. It can
also be applied post-startup:

/etc/rc.d/devfs start

This is a more flexible mechanism than the previous method of using
/etc/devfs.conf. However, that method is still available.

Note: since devfs(8) doesn't provide any way for creating symlinks
as part of a ruleset, anyone wishing to create symlinks in a devfs(5)
as part of the bootup sequence will still have to rely on /etc/devfs.conf.
diff 119166 Wed Aug 20 06:15:18 MDT 2003 mtm Add a general mechanism for creating and applying
devfs(8) rules in rc(8). It is most useful for applying
rules to devfs(5) mount points in /dev or inside jails.
The following line of script is sufficient to
mount a relatively useful+secure devfs(5) in a jail:

devfs_mount_jail /some/jail/dev

Some new shell routines available to scripts that source
rc.subr(5):
o devfs_link - Makes it a little easier to create symlinks
o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules
o devfs_set_ruleset - Set a ruleset to a devfs(5) mount
o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount
o devfs_domount - Mount devfs(5) and apply some ruleset
o devfs_mount_jail - Mount devfs(5) and apply a ruleset
appropriate to jails.

Additional rulesets can be specified in /etc/devfs.rules.
If the devfs_system_ruleset variable is defined in rc.conf
and it contains the name of a ruleset defined in /etc/defaults/devfs.rules
or user supplied rulesets in /etc/devfs.rules then that ruleset will
be applied to /dev at startup by the /etc/rc.d/devfs script. It can
also be applied post-startup:

/etc/rc.d/devfs start

This is a more flexible mechanism than the previous method of using
/etc/devfs.conf. However, that method is still available.

Note: since devfs(8) doesn't provide any way for creating symlinks
as part of a ruleset, anyone wishing to create symlinks in a devfs(5)
as part of the bootup sequence will still have to rely on /etc/devfs.conf.
diff 119166 Wed Aug 20 06:15:18 MDT 2003 mtm Add a general mechanism for creating and applying
devfs(8) rules in rc(8). It is most useful for applying
rules to devfs(5) mount points in /dev or inside jails.
The following line of script is sufficient to
mount a relatively useful+secure devfs(5) in a jail:

devfs_mount_jail /some/jail/dev

Some new shell routines available to scripts that source
rc.subr(5):
o devfs_link - Makes it a little easier to create symlinks
o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules
o devfs_set_ruleset - Set a ruleset to a devfs(5) mount
o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount
o devfs_domount - Mount devfs(5) and apply some ruleset
o devfs_mount_jail - Mount devfs(5) and apply a ruleset
appropriate to jails.

Additional rulesets can be specified in /etc/devfs.rules.
If the devfs_system_ruleset variable is defined in rc.conf
and it contains the name of a ruleset defined in /etc/defaults/devfs.rules
or user supplied rulesets in /etc/devfs.rules then that ruleset will
be applied to /dev at startup by the /etc/rc.d/devfs script. It can
also be applied post-startup:

/etc/rc.d/devfs start

This is a more flexible mechanism than the previous method of using
/etc/devfs.conf. However, that method is still available.

Note: since devfs(8) doesn't provide any way for creating symlinks
as part of a ruleset, anyone wishing to create symlinks in a devfs(5)
as part of the bootup sequence will still have to rely on /etc/devfs.conf.
/freebsd-11.0-release/sys/dev/ath/ath_hal/ar9002/
H A Dar9002phy.h219393 Tue Mar 08 07:10:35 MST 2011 adrian Implement open-loop TX power control (OLC) for Merlin (AR9280) and
generally tidy up the TX power programming code.

Enforce that the TX power offset for Merlin is -5 dBm, rather than
any other value programmable in the EEPROM. This requires some
further code to be ported over from ath9k, so until that is done
and tested, fail to attach NICs whose TX power offset isn't -5
dBm.

This improves both legacy and HT transmission on my merlin board.
It allows for stable MCS TX up to MCS15.

Specifics:

* Refactor out a bunch of the TX power calibration code -
setting/obtaining the power detector / gain boundaries,
programming the PDADC
* Take the -5 dBm TX power offset into account on Merlin -
"0" in the per-rate TX power register means -5 dBm, not
0 dBm
* When doing OLC
* Enforce min (0) and max (AR5416_MAX_RATE_POWER) when fiddling
with the TX power, to avoid the TX power values from wrapping
when low.
* Implement the 1 dBm cck power offset when doing OLC
* Implement temperature compensation for 2.4ghz mode when doing OLC
* Implement an AR9280 specific TX power calibration routine which
includes the OLC twiddles, leaving the earlier chipset path
(AR5416, AR9160) alone

Whilst here, use these refactored routines for the AR9285 TX power
calibration/programming code and enforce correct overflow/underflow
handling when fiddling with TX power values.

Obtained from: linux ath9k
219393 Tue Mar 08 07:10:35 MST 2011 adrian Implement open-loop TX power control (OLC) for Merlin (AR9280) and
generally tidy up the TX power programming code.

Enforce that the TX power offset for Merlin is -5 dBm, rather than
any other value programmable in the EEPROM. This requires some
further code to be ported over from ath9k, so until that is done
and tested, fail to attach NICs whose TX power offset isn't -5
dBm.

This improves both legacy and HT transmission on my merlin board.
It allows for stable MCS TX up to MCS15.

Specifics:

* Refactor out a bunch of the TX power calibration code -
setting/obtaining the power detector / gain boundaries,
programming the PDADC
* Take the -5 dBm TX power offset into account on Merlin -
"0" in the per-rate TX power register means -5 dBm, not
0 dBm
* When doing OLC
* Enforce min (0) and max (AR5416_MAX_RATE_POWER) when fiddling
with the TX power, to avoid the TX power values from wrapping
when low.
* Implement the 1 dBm cck power offset when doing OLC
* Implement temperature compensation for 2.4ghz mode when doing OLC
* Implement an AR9280 specific TX power calibration routine which
includes the OLC twiddles, leaving the earlier chipset path
(AR5416, AR9160) alone

Whilst here, use these refactored routines for the AR9285 TX power
calibration/programming code and enforce correct overflow/underflow
handling when fiddling with TX power values.

Obtained from: linux ath9k
219393 Tue Mar 08 07:10:35 MST 2011 adrian Implement open-loop TX power control (OLC) for Merlin (AR9280) and
generally tidy up the TX power programming code.

Enforce that the TX power offset for Merlin is -5 dBm, rather than
any other value programmable in the EEPROM. This requires some
further code to be ported over from ath9k, so until that is done
and tested, fail to attach NICs whose TX power offset isn't -5
dBm.

This improves both legacy and HT transmission on my merlin board.
It allows for stable MCS TX up to MCS15.

Specifics:

* Refactor out a bunch of the TX power calibration code -
setting/obtaining the power detector / gain boundaries,
programming the PDADC
* Take the -5 dBm TX power offset into account on Merlin -
"0" in the per-rate TX power register means -5 dBm, not
0 dBm
* When doing OLC
* Enforce min (0) and max (AR5416_MAX_RATE_POWER) when fiddling
with the TX power, to avoid the TX power values from wrapping
when low.
* Implement the 1 dBm cck power offset when doing OLC
* Implement temperature compensation for 2.4ghz mode when doing OLC
* Implement an AR9280 specific TX power calibration routine which
includes the OLC twiddles, leaving the earlier chipset path
(AR5416, AR9160) alone

Whilst here, use these refactored routines for the AR9285 TX power
calibration/programming code and enforce correct overflow/underflow
handling when fiddling with TX power values.

Obtained from: linux ath9k
219393 Tue Mar 08 07:10:35 MST 2011 adrian Implement open-loop TX power control (OLC) for Merlin (AR9280) and
generally tidy up the TX power programming code.

Enforce that the TX power offset for Merlin is -5 dBm, rather than
any other value programmable in the EEPROM. This requires some
further code to be ported over from ath9k, so until that is done
and tested, fail to attach NICs whose TX power offset isn't -5
dBm.

This improves both legacy and HT transmission on my merlin board.
It allows for stable MCS TX up to MCS15.

Specifics:

* Refactor out a bunch of the TX power calibration code -
setting/obtaining the power detector / gain boundaries,
programming the PDADC
* Take the -5 dBm TX power offset into account on Merlin -
"0" in the per-rate TX power register means -5 dBm, not
0 dBm
* When doing OLC
* Enforce min (0) and max (AR5416_MAX_RATE_POWER) when fiddling
with the TX power, to avoid the TX power values from wrapping
when low.
* Implement the 1 dBm cck power offset when doing OLC
* Implement temperature compensation for 2.4ghz mode when doing OLC
* Implement an AR9280 specific TX power calibration routine which
includes the OLC twiddles, leaving the earlier chipset path
(AR5416, AR9160) alone

Whilst here, use these refactored routines for the AR9285 TX power
calibration/programming code and enforce correct overflow/underflow
handling when fiddling with TX power values.

Obtained from: linux ath9k
/freebsd-11.0-release/sys/dev/bwn/
H A Dif_bwnvar.hdiff 300114 Wed May 18 06:05:16 MDT 2016 adrian [bwn] add initial 5xx firmware API support

* Add the new TX/RX frame formats;
* Use the right TX/RX format based on the frame info;
* Disable the 5xx firmware check, since now it should
somewhat work (but note, we don't yet use it unless
you manually add ucode11/initvals11 from the 5.x driver
to bwn-kmod-firmware;

* Misc: update some comments/debugging now I know what's
actually going on.

Tested:

* BCM4321MC, STA mode, both 4xx and 666 firmware, DMA mode

TODO:

* The newer firmware ends up logging "warn: firmware state (0)";
not sure yet what's going on there. But, yes, it still works.
I'm committing this via a BCM4321MC, 11a station, firmware
rev 666.

Obtained from: Linux b43 (TX/RX descriptor format for 5xx)
diff 300114 Wed May 18 06:05:16 MDT 2016 adrian [bwn] add initial 5xx firmware API support

* Add the new TX/RX frame formats;
* Use the right TX/RX format based on the frame info;
* Disable the 5xx firmware check, since now it should
somewhat work (but note, we don't yet use it unless
you manually add ucode11/initvals11 from the 5.x driver
to bwn-kmod-firmware;

* Misc: update some comments/debugging now I know what's
actually going on.

Tested:

* BCM4321MC, STA mode, both 4xx and 666 firmware, DMA mode

TODO:

* The newer firmware ends up logging "warn: firmware state (0)";
not sure yet what's going on there. But, yes, it still works.
I'm committing this via a BCM4321MC, 11a station, firmware
rev 666.

Obtained from: Linux b43 (TX/RX descriptor format for 5xx)
diff 300114 Wed May 18 06:05:16 MDT 2016 adrian [bwn] add initial 5xx firmware API support

* Add the new TX/RX frame formats;
* Use the right TX/RX format based on the frame info;
* Disable the 5xx firmware check, since now it should
somewhat work (but note, we don't yet use it unless
you manually add ucode11/initvals11 from the 5.x driver
to bwn-kmod-firmware;

* Misc: update some comments/debugging now I know what's
actually going on.

Tested:

* BCM4321MC, STA mode, both 4xx and 666 firmware, DMA mode

TODO:

* The newer firmware ends up logging "warn: firmware state (0)";
not sure yet what's going on there. But, yes, it still works.
I'm committing this via a BCM4321MC, 11a station, firmware
rev 666.

Obtained from: Linux b43 (TX/RX descriptor format for 5xx)
diff 300114 Wed May 18 06:05:16 MDT 2016 adrian [bwn] add initial 5xx firmware API support

* Add the new TX/RX frame formats;
* Use the right TX/RX format based on the frame info;
* Disable the 5xx firmware check, since now it should
somewhat work (but note, we don't yet use it unless
you manually add ucode11/initvals11 from the 5.x driver
to bwn-kmod-firmware;

* Misc: update some comments/debugging now I know what's
actually going on.

Tested:

* BCM4321MC, STA mode, both 4xx and 666 firmware, DMA mode

TODO:

* The newer firmware ends up logging "warn: firmware state (0)";
not sure yet what's going on there. But, yes, it still works.
I'm committing this via a BCM4321MC, 11a station, firmware
rev 666.

Obtained from: Linux b43 (TX/RX descriptor format for 5xx)
diff 299790 Sat May 14 23:52:44 MDT 2016 adrian [bwn] add new types, prepare for PHY-N; prepare for rev 5xx firmware.

This is a big commit with a whole lot of little changes, all in
preparation for PHY-N and rev 5xx firmware.

* add in a write method that does an explicit flush
* change the txpwr recalc type to return an enum, versus just an int.
* add in PHY-N RX frame format bits, for decoding RX RSSI and such
* add in the header space calculation for rev 5xx firmware.
* add in a whole bunch of new types that the newer and 5g phy code
needs. Notably, broadcom has a split 5GHz band concept -
5G-Low, 5G(-Mid) and 5G-High. I kept encountering this at my
day job and wondered whether it was just some marketing thing.
Nope, turns out it isn't; it's an actual PHY thing.

* Add a "am I a siba bus device" method, that returns true.
The aim is to convert all the siba/bhnd specific bits in if_bwn
over to be wrapped in this check, so when landon does a BHND
drive through he knows which bits need updating.

Now, this the /complete/ set of changes for rev 5xx firmware.
Notably, the TX descriptor handling isn't at all done yet and the
format has changed. So don' try blindly flipping this on just yet!
diff 299790 Sat May 14 23:52:44 MDT 2016 adrian [bwn] add new types, prepare for PHY-N; prepare for rev 5xx firmware.

This is a big commit with a whole lot of little changes, all in
preparation for PHY-N and rev 5xx firmware.

* add in a write method that does an explicit flush
* change the txpwr recalc type to return an enum, versus just an int.
* add in PHY-N RX frame format bits, for decoding RX RSSI and such
* add in the header space calculation for rev 5xx firmware.
* add in a whole bunch of new types that the newer and 5g phy code
needs. Notably, broadcom has a split 5GHz band concept -
5G-Low, 5G(-Mid) and 5G-High. I kept encountering this at my
day job and wondered whether it was just some marketing thing.
Nope, turns out it isn't; it's an actual PHY thing.

* Add a "am I a siba bus device" method, that returns true.
The aim is to convert all the siba/bhnd specific bits in if_bwn
over to be wrapped in this check, so when landon does a BHND
drive through he knows which bits need updating.

Now, this the /complete/ set of changes for rev 5xx firmware.
Notably, the TX descriptor handling isn't at all done yet and the
format has changed. So don' try blindly flipping this on just yet!
diff 299790 Sat May 14 23:52:44 MDT 2016 adrian [bwn] add new types, prepare for PHY-N; prepare for rev 5xx firmware.

This is a big commit with a whole lot of little changes, all in
preparation for PHY-N and rev 5xx firmware.

* add in a write method that does an explicit flush
* change the txpwr recalc type to return an enum, versus just an int.
* add in PHY-N RX frame format bits, for decoding RX RSSI and such
* add in the header space calculation for rev 5xx firmware.
* add in a whole bunch of new types that the newer and 5g phy code
needs. Notably, broadcom has a split 5GHz band concept -
5G-Low, 5G(-Mid) and 5G-High. I kept encountering this at my
day job and wondered whether it was just some marketing thing.
Nope, turns out it isn't; it's an actual PHY thing.

* Add a "am I a siba bus device" method, that returns true.
The aim is to convert all the siba/bhnd specific bits in if_bwn
over to be wrapped in this check, so when landon does a BHND
drive through he knows which bits need updating.

Now, this the /complete/ set of changes for rev 5xx firmware.
Notably, the TX descriptor handling isn't at all done yet and the
format has changed. So don' try blindly flipping this on just yet!
diff 299790 Sat May 14 23:52:44 MDT 2016 adrian [bwn] add new types, prepare for PHY-N; prepare for rev 5xx firmware.

This is a big commit with a whole lot of little changes, all in
preparation for PHY-N and rev 5xx firmware.

* add in a write method that does an explicit flush
* change the txpwr recalc type to return an enum, versus just an int.
* add in PHY-N RX frame format bits, for decoding RX RSSI and such
* add in the header space calculation for rev 5xx firmware.
* add in a whole bunch of new types that the newer and 5g phy code
needs. Notably, broadcom has a split 5GHz band concept -
5G-Low, 5G(-Mid) and 5G-High. I kept encountering this at my
day job and wondered whether it was just some marketing thing.
Nope, turns out it isn't; it's an actual PHY thing.

* Add a "am I a siba bus device" method, that returns true.
The aim is to convert all the siba/bhnd specific bits in if_bwn
over to be wrapped in this check, so when landon does a BHND
drive through he knows which bits need updating.

Now, this the /complete/ set of changes for rev 5xx firmware.
Notably, the TX descriptor handling isn't at all done yet and the
format has changed. So don' try blindly flipping this on just yet!
diff 299790 Sat May 14 23:52:44 MDT 2016 adrian [bwn] add new types, prepare for PHY-N; prepare for rev 5xx firmware.

This is a big commit with a whole lot of little changes, all in
preparation for PHY-N and rev 5xx firmware.

* add in a write method that does an explicit flush
* change the txpwr recalc type to return an enum, versus just an int.
* add in PHY-N RX frame format bits, for decoding RX RSSI and such
* add in the header space calculation for rev 5xx firmware.
* add in a whole bunch of new types that the newer and 5g phy code
needs. Notably, broadcom has a split 5GHz band concept -
5G-Low, 5G(-Mid) and 5G-High. I kept encountering this at my
day job and wondered whether it was just some marketing thing.
Nope, turns out it isn't; it's an actual PHY thing.

* Add a "am I a siba bus device" method, that returns true.
The aim is to convert all the siba/bhnd specific bits in if_bwn
over to be wrapped in this check, so when landon does a BHND
drive through he knows which bits need updating.

Now, this the /complete/ set of changes for rev 5xx firmware.
Notably, the TX descriptor handling isn't at all done yet and the
format has changed. So don' try blindly flipping this on just yet!
diff 299790 Sat May 14 23:52:44 MDT 2016 adrian [bwn] add new types, prepare for PHY-N; prepare for rev 5xx firmware.

This is a big commit with a whole lot of little changes, all in
preparation for PHY-N and rev 5xx firmware.

* add in a write method that does an explicit flush
* change the txpwr recalc type to return an enum, versus just an int.
* add in PHY-N RX frame format bits, for decoding RX RSSI and such
* add in the header space calculation for rev 5xx firmware.
* add in a whole bunch of new types that the newer and 5g phy code
needs. Notably, broadcom has a split 5GHz band concept -
5G-Low, 5G(-Mid) and 5G-High. I kept encountering this at my
day job and wondered whether it was just some marketing thing.
Nope, turns out it isn't; it's an actual PHY thing.

* Add a "am I a siba bus device" method, that returns true.
The aim is to convert all the siba/bhnd specific bits in if_bwn
over to be wrapped in this check, so when landon does a BHND
drive through he knows which bits need updating.

Now, this the /complete/ set of changes for rev 5xx firmware.
Notably, the TX descriptor handling isn't at all done yet and the
format has changed. So don' try blindly flipping this on just yet!
diff 299790 Sat May 14 23:52:44 MDT 2016 adrian [bwn] add new types, prepare for PHY-N; prepare for rev 5xx firmware.

This is a big commit with a whole lot of little changes, all in
preparation for PHY-N and rev 5xx firmware.

* add in a write method that does an explicit flush
* change the txpwr recalc type to return an enum, versus just an int.
* add in PHY-N RX frame format bits, for decoding RX RSSI and such
* add in the header space calculation for rev 5xx firmware.
* add in a whole bunch of new types that the newer and 5g phy code
needs. Notably, broadcom has a split 5GHz band concept -
5G-Low, 5G(-Mid) and 5G-High. I kept encountering this at my
day job and wondered whether it was just some marketing thing.
Nope, turns out it isn't; it's an actual PHY thing.

* Add a "am I a siba bus device" method, that returns true.
The aim is to convert all the siba/bhnd specific bits in if_bwn
over to be wrapped in this check, so when landon does a BHND
drive through he knows which bits need updating.

Now, this the /complete/ set of changes for rev 5xx firmware.
Notably, the TX descriptor handling isn't at all done yet and the
format has changed. So don' try blindly flipping this on just yet!
diff 299790 Sat May 14 23:52:44 MDT 2016 adrian [bwn] add new types, prepare for PHY-N; prepare for rev 5xx firmware.

This is a big commit with a whole lot of little changes, all in
preparation for PHY-N and rev 5xx firmware.

* add in a write method that does an explicit flush
* change the txpwr recalc type to return an enum, versus just an int.
* add in PHY-N RX frame format bits, for decoding RX RSSI and such
* add in the header space calculation for rev 5xx firmware.
* add in a whole bunch of new types that the newer and 5g phy code
needs. Notably, broadcom has a split 5GHz band concept -
5G-Low, 5G(-Mid) and 5G-High. I kept encountering this at my
day job and wondered whether it was just some marketing thing.
Nope, turns out it isn't; it's an actual PHY thing.

* Add a "am I a siba bus device" method, that returns true.
The aim is to convert all the siba/bhnd specific bits in if_bwn
over to be wrapped in this check, so when landon does a BHND
drive through he knows which bits need updating.

Now, this the /complete/ set of changes for rev 5xx firmware.
Notably, the TX descriptor handling isn't at all done yet and the
format has changed. So don' try blindly flipping this on just yet!
diff 299790 Sat May 14 23:52:44 MDT 2016 adrian [bwn] add new types, prepare for PHY-N; prepare for rev 5xx firmware.

This is a big commit with a whole lot of little changes, all in
preparation for PHY-N and rev 5xx firmware.

* add in a write method that does an explicit flush
* change the txpwr recalc type to return an enum, versus just an int.
* add in PHY-N RX frame format bits, for decoding RX RSSI and such
* add in the header space calculation for rev 5xx firmware.
* add in a whole bunch of new types that the newer and 5g phy code
needs. Notably, broadcom has a split 5GHz band concept -
5G-Low, 5G(-Mid) and 5G-High. I kept encountering this at my
day job and wondered whether it was just some marketing thing.
Nope, turns out it isn't; it's an actual PHY thing.

* Add a "am I a siba bus device" method, that returns true.
The aim is to convert all the siba/bhnd specific bits in if_bwn
over to be wrapped in this check, so when landon does a BHND
drive through he knows which bits need updating.

Now, this the /complete/ set of changes for rev 5xx firmware.
Notably, the TX descriptor handling isn't at all done yet and the
format has changed. So don' try blindly flipping this on just yet!
/freebsd-11.0-release/sys/boot/forth/
H A Dcheck-password.4th.8diff 281616 Thu Apr 16 20:54:11 MDT 2015 dteske Add "GELI Passphrase:" prompt to boot loader.

A new loader.conf(5) option of geom_eli_passphrase_prompt="YES" will now
allow you to enter your geli(8) root-mount credentials prior to invoking
the kernel.

See check-password.4th(8) for details.

Differential Revision: https://reviews.freebsd.org/D2105
Reviewed by: imp, kmoore
Discussed on: -current
MFC after: 3 days
X-MFC-to: stable/10
Relnotes: yes
diff 280938 Wed Apr 01 02:03:27 MDT 2015 dteske Add "GELI Passphrase:" prompt to boot loader.

Summary:
Add "GELI Passphrase:" prompt to boot loader.

A new loader.conf(5) option of geom_eli_passphrase_prompt="YES" will now
allow you to enter your geli(8) root-mount credentials prior to invoking
the kernel.

See check-password.4th(8) for details.

Differential Revision: https://reviews.freebsd.org/D2105
Reviewed by: (your name[s] here)
MFC after: 3 days
X-MFC-to: stable/10
Relnotes: yes

Test Plan:
Drop a head copy of check-password.4th into /boot and then apply the patch
(only the patch to /boot/check-password.4th is required; no other changes are
required but you do have to have a HEAD copy of check-password.4th to
apply the patch).

NB: The rest of your /boot files can be up to 2 years old but no older.
NB: The test won't work unless your kernel has the following change

https://svnweb.freebsd.org/base?view=revision&revision=273489

Now, put into /boot/loader.conf:

geom_eli_passphrase_prompt="YES"

and reboot.

You should be prompted for a GELI passphrase before the menu (if enabled),
just after loading loader.conf(5).

NB: It doesn't matter if you're using GELI or not. However if you are using
GELI and a sufficiently new enough release (has SVN r273489) and you entered
the proper passphrase to mount your GELI encrypted root device(s), you should
notice that the boot process did not stop (you went from loader all the way to login).

Reviewers: cperciva, allanjude, scottl, kmoore

Subscribers: jkh, imp

Differential Revision: https://reviews.freebsd.org/D2105
diff 280938 Wed Apr 01 02:03:27 MDT 2015 dteske Add "GELI Passphrase:" prompt to boot loader.

Summary:
Add "GELI Passphrase:" prompt to boot loader.

A new loader.conf(5) option of geom_eli_passphrase_prompt="YES" will now
allow you to enter your geli(8) root-mount credentials prior to invoking
the kernel.

See check-password.4th(8) for details.

Differential Revision: https://reviews.freebsd.org/D2105
Reviewed by: (your name[s] here)
MFC after: 3 days
X-MFC-to: stable/10
Relnotes: yes

Test Plan:
Drop a head copy of check-password.4th into /boot and then apply the patch
(only the patch to /boot/check-password.4th is required; no other changes are
required but you do have to have a HEAD copy of check-password.4th to
apply the patch).

NB: The rest of your /boot files can be up to 2 years old but no older.
NB: The test won't work unless your kernel has the following change

https://svnweb.freebsd.org/base?view=revision&revision=273489

Now, put into /boot/loader.conf:

geom_eli_passphrase_prompt="YES"

and reboot.

You should be prompted for a GELI passphrase before the menu (if enabled),
just after loading loader.conf(5).

NB: It doesn't matter if you're using GELI or not. However if you are using
GELI and a sufficiently new enough release (has SVN r273489) and you entered
the proper passphrase to mount your GELI encrypted root device(s), you should
notice that the boot process did not stop (you went from loader all the way to login).

Reviewers: cperciva, allanjude, scottl, kmoore

Subscribers: jkh, imp

Differential Revision: https://reviews.freebsd.org/D2105
diff 244158 Wed Dec 12 17:57:56 MST 2012 dteske Fix a regression caused by SVN r222417.

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>
diff 244158 Wed Dec 12 17:57:56 MST 2012 dteske Fix a regression caused by SVN r222417.

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>
diff 244158 Wed Dec 12 17:57:56 MST 2012 dteske Fix a regression caused by SVN r222417.

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>
diff 244158 Wed Dec 12 17:57:56 MST 2012 dteske Fix a regression caused by SVN r222417.

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>
diff 244158 Wed Dec 12 17:57:56 MST 2012 dteske Fix a regression caused by SVN r222417.

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>
diff 244158 Wed Dec 12 17:57:56 MST 2012 dteske Fix a regression caused by SVN r222417.

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>
/freebsd-11.0-release/sys/boot/pc98/boot0/
H A DMakefile64123 Wed Aug 02 08:46:08 MDT 2000 kato Added PC-98 HDD boot manager. The boot0 is the `IPL' which occupies
sector 0 of a disk and boot0.5 is the `boot selector' which starts
from address 0x400. The IPL loads boot0.5 and boot0.5 loads bootblock
of a slice.

The boot manager stuff was developed by me (kato) with Borland C++,
and then, translated into bcc in the ports collection by Nokubi-san.
After that, boot0 has been translated into gas with the .code16
directive by Takahashi-san (nyan) and boot0.5 has been rewritten in
gas by me.
64123 Wed Aug 02 08:46:08 MDT 2000 kato Added PC-98 HDD boot manager. The boot0 is the `IPL' which occupies
sector 0 of a disk and boot0.5 is the `boot selector' which starts
from address 0x400. The IPL loads boot0.5 and boot0.5 loads bootblock
of a slice.

The boot manager stuff was developed by me (kato) with Borland C++,
and then, translated into bcc in the ports collection by Nokubi-san.
After that, boot0 has been translated into gas with the .code16
directive by Takahashi-san (nyan) and boot0.5 has been rewritten in
gas by me.
64123 Wed Aug 02 08:46:08 MDT 2000 kato Added PC-98 HDD boot manager. The boot0 is the `IPL' which occupies
sector 0 of a disk and boot0.5 is the `boot selector' which starts
from address 0x400. The IPL loads boot0.5 and boot0.5 loads bootblock
of a slice.

The boot manager stuff was developed by me (kato) with Borland C++,
and then, translated into bcc in the ports collection by Nokubi-san.
After that, boot0 has been translated into gas with the .code16
directive by Takahashi-san (nyan) and boot0.5 has been rewritten in
gas by me.
64123 Wed Aug 02 08:46:08 MDT 2000 kato Added PC-98 HDD boot manager. The boot0 is the `IPL' which occupies
sector 0 of a disk and boot0.5 is the `boot selector' which starts
from address 0x400. The IPL loads boot0.5 and boot0.5 loads bootblock
of a slice.

The boot manager stuff was developed by me (kato) with Borland C++,
and then, translated into bcc in the ports collection by Nokubi-san.
After that, boot0 has been translated into gas with the .code16
directive by Takahashi-san (nyan) and boot0.5 has been rewritten in
gas by me.
/freebsd-11.0-release/sys/boot/pc98/boot0.5/
H A DMakefile64123 Wed Aug 02 08:46:08 MDT 2000 kato Added PC-98 HDD boot manager. The boot0 is the `IPL' which occupies
sector 0 of a disk and boot0.5 is the `boot selector' which starts
from address 0x400. The IPL loads boot0.5 and boot0.5 loads bootblock
of a slice.

The boot manager stuff was developed by me (kato) with Borland C++,
and then, translated into bcc in the ports collection by Nokubi-san.
After that, boot0 has been translated into gas with the .code16
directive by Takahashi-san (nyan) and boot0.5 has been rewritten in
gas by me.
64123 Wed Aug 02 08:46:08 MDT 2000 kato Added PC-98 HDD boot manager. The boot0 is the `IPL' which occupies
sector 0 of a disk and boot0.5 is the `boot selector' which starts
from address 0x400. The IPL loads boot0.5 and boot0.5 loads bootblock
of a slice.

The boot manager stuff was developed by me (kato) with Borland C++,
and then, translated into bcc in the ports collection by Nokubi-san.
After that, boot0 has been translated into gas with the .code16
directive by Takahashi-san (nyan) and boot0.5 has been rewritten in
gas by me.
64123 Wed Aug 02 08:46:08 MDT 2000 kato Added PC-98 HDD boot manager. The boot0 is the `IPL' which occupies
sector 0 of a disk and boot0.5 is the `boot selector' which starts
from address 0x400. The IPL loads boot0.5 and boot0.5 loads bootblock
of a slice.

The boot manager stuff was developed by me (kato) with Borland C++,
and then, translated into bcc in the ports collection by Nokubi-san.
After that, boot0 has been translated into gas with the .code16
directive by Takahashi-san (nyan) and boot0.5 has been rewritten in
gas by me.
64123 Wed Aug 02 08:46:08 MDT 2000 kato Added PC-98 HDD boot manager. The boot0 is the `IPL' which occupies
sector 0 of a disk and boot0.5 is the `boot selector' which starts
from address 0x400. The IPL loads boot0.5 and boot0.5 loads bootblock
of a slice.

The boot manager stuff was developed by me (kato) with Borland C++,
and then, translated into bcc in the ports collection by Nokubi-san.
After that, boot0 has been translated into gas with the .code16
directive by Takahashi-san (nyan) and boot0.5 has been rewritten in
gas by me.
/freebsd-11.0-release/share/man/man5/
H A Drctl.conf.5220640 Thu Apr 14 18:40:13 MDT 2011 trasz Add manual page for rctl.conf(5).
/freebsd-11.0-release/tools/build/options/
H A DWITHOUT_ACPI156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage.
H A DWITHOUT_ATM156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage.
H A DWITHOUT_AUDIT156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage.
H A DWITHOUT_AUTHPF156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage.
H A DWITHOUT_BLUETOOTH156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage.
H A DWITHOUT_BOOT156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage.
H A DWITHOUT_CALENDAR156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage.
H A DWITHOUT_CPP156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage.
H A DWITHOUT_CRYPT156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage.
H A DWITHOUT_CVS156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage.
H A DWITHOUT_DICT156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage.
H A DWITHOUT_DYNAMICROOT156932 Tue Mar 21 07:50:50 MST 2006 ru Prepare to autogenerate the src.conf(5) manpage.

Completed in 406 milliseconds

1234567891011>>