Searched hist:4 (Results 1 - 25 of 9856) sorted by relevance

1234567891011>>

/freebsd-11-stable/share/man/man4/
H A Djedec_ts.4diff 336976 Tue Jul 31 16:25:11 MDT 2018 rpokala MFC r336662,r336682

r336662: Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead

jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
fact that it is a superset of jedec_ts(4).

r336682: Update .Dd in light of r336662.
diff 336976 Tue Jul 31 16:25:11 MDT 2018 rpokala MFC r336662,r336682

r336662: Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead

jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
fact that it is a superset of jedec_ts(4).

r336682: Update .Dd in light of r336662.
diff 336976 Tue Jul 31 16:25:11 MDT 2018 rpokala MFC r336662,r336682

r336662: Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead

jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
fact that it is a superset of jedec_ts(4).

r336682: Update .Dd in light of r336662.
diff 336976 Tue Jul 31 16:25:11 MDT 2018 rpokala MFC r336662,r336682

r336662: Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead

jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
fact that it is a superset of jedec_ts(4).

r336682: Update .Dd in light of r336662.
diff 336976 Tue Jul 31 16:25:11 MDT 2018 rpokala MFC r336662,r336682

r336662: Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead

jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
fact that it is a superset of jedec_ts(4).

r336682: Update .Dd in light of r336662.
diff 336976 Tue Jul 31 16:25:11 MDT 2018 rpokala MFC r336662,r336682

r336662: Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead

jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
fact that it is a superset of jedec_ts(4).

r336682: Update .Dd in light of r336662.
diff 336976 Tue Jul 31 16:25:11 MDT 2018 rpokala MFC r336662,r336682

r336662: Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead

jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
fact that it is a superset of jedec_ts(4).

r336682: Update .Dd in light of r336662.
diff 336976 Tue Jul 31 16:25:11 MDT 2018 rpokala MFC r336662,r336682

r336662: Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead

jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
fact that it is a superset of jedec_ts(4).

r336682: Update .Dd in light of r336662.
diff 336976 Tue Jul 31 16:25:11 MDT 2018 rpokala MFC r336662,r336682

r336662: Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead

jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
fact that it is a superset of jedec_ts(4).

r336682: Update .Dd in light of r336662.
diff 336976 Tue Jul 31 16:25:11 MDT 2018 rpokala MFC r336662,r336682

r336662: Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead

jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
fact that it is a superset of jedec_ts(4).

r336682: Update .Dd in light of r336662.
H A Diwm.4diff 330228 Thu Mar 01 07:28:42 MST 2018 eadler MFC r325123:

Reference iwm8265fw support in iwm(4) as well

This documentation update is similar to what was done in iwmfw(4) in r325121.
diff 330228 Thu Mar 01 07:28:42 MST 2018 eadler MFC r325123:

Reference iwm8265fw support in iwm(4) as well

This documentation update is similar to what was done in iwmfw(4) in r325121.
303628 Mon Aug 01 16:06:43 MDT 2016 sbruno MFC r303322,303326,303327,303345,303413,303416,303418,303557

Update iwm(4) and iwmfw(4) to current in order to stabilize and improve
functionality.

Approved by: re (gjb)
303628 Mon Aug 01 16:06:43 MDT 2016 sbruno MFC r303322,303326,303327,303345,303413,303416,303418,303557

Update iwm(4) and iwmfw(4) to current in order to stabilize and improve
functionality.

Approved by: re (gjb)
H A Djedec_dimm.4diff 355366 Tue Dec 03 23:02:30 MST 2019 rpokala MFC r343583:

Remove unecessary "All rights reserved" from files under my or Panasas's
copyright.

When all member nations of the Buenos Aires Convention adopted the Berne
Convention, the phrase "All rights reserved" became unnecessary to assert
copyright. Remove it from files under my or Panasas's copyright. The files
related to jedec_dimm(4) also bear avg@'s copyright; he has approved this
change.
diff 336976 Tue Jul 31 16:25:11 MDT 2018 rpokala MFC r336662,r336682

r336662: Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead

jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
fact that it is a superset of jedec_ts(4).

r336682: Update .Dd in light of r336662.
diff 336976 Tue Jul 31 16:25:11 MDT 2018 rpokala MFC r336662,r336682

r336662: Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead

jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
fact that it is a superset of jedec_ts(4).

r336682: Update .Dd in light of r336662.
diff 336976 Tue Jul 31 16:25:11 MDT 2018 rpokala MFC r336662,r336682

r336662: Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead

jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
fact that it is a superset of jedec_ts(4).

r336682: Update .Dd in light of r336662.
diff 336976 Tue Jul 31 16:25:11 MDT 2018 rpokala MFC r336662,r336682

r336662: Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead

jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
fact that it is a superset of jedec_ts(4).

r336682: Update .Dd in light of r336662.
diff 336976 Tue Jul 31 16:25:11 MDT 2018 rpokala MFC r336662,r336682

r336662: Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead

jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
fact that it is a superset of jedec_ts(4).

r336682: Update .Dd in light of r336662.
diff 336976 Tue Jul 31 16:25:11 MDT 2018 rpokala MFC r336662,r336682

r336662: Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead

jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
fact that it is a superset of jedec_ts(4).

r336682: Update .Dd in light of r336662.
diff 336976 Tue Jul 31 16:25:11 MDT 2018 rpokala MFC r336662,r336682

r336662: Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead

jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
fact that it is a superset of jedec_ts(4).

r336682: Update .Dd in light of r336662.
diff 336976 Tue Jul 31 16:25:11 MDT 2018 rpokala MFC r336662,r336682

r336662: Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead

jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
fact that it is a superset of jedec_ts(4).

r336682: Update .Dd in light of r336662.
diff 336976 Tue Jul 31 16:25:11 MDT 2018 rpokala MFC r336662,r336682

r336662: Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead

jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
fact that it is a superset of jedec_ts(4).

r336682: Update .Dd in light of r336662.
diff 336976 Tue Jul 31 16:25:11 MDT 2018 rpokala MFC r336662,r336682

r336662: Deprecate jedec_ts(4) and point users to jedec_dimm(4) instead

jedec_dimm(4) is a superset of the functionality of jedec_ts(4). Mark
jedec_ts(4) as removed in FreeBSD 12, and include a pointer to the migration
instructions in the jedec_dimm(4) manpage, in both the jedec_ts(4) code and
the jedec_ts(4) manpage. Add a note to the jedec_dimm(4) manpage about the
fact that it is a superset of jedec_ts(4).

r336682: Update .Dd in light of r336662.
H A Dvmm.4327974 Sun Jan 14 20:37:22 MST 2018 eadler MFC r326281:

Add vmm(4) man page

PR: 205705
H A Dsnd_uaudio.4diff 219004 Thu Feb 24 16:09:51 MST 2011 hselasky - Add missing xhci(4) manual page.
- Minor update in some USB manual pages.

MFC after: 3 days
Approved by: thompsa (mentor)
diff 204605 Tue Mar 02 20:14:14 MST 2010 joel The NetBSD Foundation has granted permission to remove clause 3 and 4 from
their software.

Obtained from: NetBSD
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
H A Dmlx4en.4diff 316229 Thu Mar 30 05:55:14 MDT 2017 ngie Backport mlx4{en,ib}(4) from ^/head

MFCing other pieces would be very structurally disruptive. This just
brings back the manpages so they can be used by end-users and to ease
future backports.

svn:mergeinfo omitted, in part because this is a direct commit to
^/stable/11.

Sponsored by: Dell EMC Isilon
316226 Thu Mar 30 05:45:48 MDT 2017 ngie MFC r315759,r315761:

r315759 (by gjb):

Add mlx5en(4) to the hardware page. [1]
Belatedly bump copyright years after several changes.

r315761:

Add cxgbe(4), ixl(4), and mlx4en(4) to the hardware release notes
316226 Thu Mar 30 05:45:48 MDT 2017 ngie MFC r315759,r315761:

r315759 (by gjb):

Add mlx5en(4) to the hardware page. [1]
Belatedly bump copyright years after several changes.

r315761:

Add cxgbe(4), ixl(4), and mlx4en(4) to the hardware release notes
316226 Thu Mar 30 05:45:48 MDT 2017 ngie MFC r315759,r315761:

r315759 (by gjb):

Add mlx5en(4) to the hardware page. [1]
Belatedly bump copyright years after several changes.

r315761:

Add cxgbe(4), ixl(4), and mlx4en(4) to the hardware release notes
316226 Thu Mar 30 05:45:48 MDT 2017 ngie MFC r315759,r315761:

r315759 (by gjb):

Add mlx5en(4) to the hardware page. [1]
Belatedly bump copyright years after several changes.

r315761:

Add cxgbe(4), ixl(4), and mlx4en(4) to the hardware release notes
H A Dmlx4ib.4diff 316229 Thu Mar 30 05:55:14 MDT 2017 ngie Backport mlx4{en,ib}(4) from ^/head

MFCing other pieces would be very structurally disruptive. This just
brings back the manpages so they can be used by end-users and to ease
future backports.

svn:mergeinfo omitted, in part because this is a direct commit to
^/stable/11.

Sponsored by: Dell EMC Isilon
316226 Thu Mar 30 05:45:48 MDT 2017 ngie MFC r315759,r315761:

r315759 (by gjb):

Add mlx5en(4) to the hardware page. [1]
Belatedly bump copyright years after several changes.

r315761:

Add cxgbe(4), ixl(4), and mlx4en(4) to the hardware release notes
316226 Thu Mar 30 05:45:48 MDT 2017 ngie MFC r315759,r315761:

r315759 (by gjb):

Add mlx5en(4) to the hardware page. [1]
Belatedly bump copyright years after several changes.

r315761:

Add cxgbe(4), ixl(4), and mlx4en(4) to the hardware release notes
316226 Thu Mar 30 05:45:48 MDT 2017 ngie MFC r315759,r315761:

r315759 (by gjb):

Add mlx5en(4) to the hardware page. [1]
Belatedly bump copyright years after several changes.

r315761:

Add cxgbe(4), ixl(4), and mlx4en(4) to the hardware release notes
316226 Thu Mar 30 05:45:48 MDT 2017 ngie MFC r315759,r315761:

r315759 (by gjb):

Add mlx5en(4) to the hardware page. [1]
Belatedly bump copyright years after several changes.

r315761:

Add cxgbe(4), ixl(4), and mlx4en(4) to the hardware release notes
H A Dsnd_ds1.4diff 351111 Fri Aug 16 05:02:26 MDT 2019 pfg MFC r350969:
Add deprecation notice to snd_ds1(4).

As suggested in:
https://wiki.freebsd.org/WhatsGoing/FreeBSD13

We will be dropping the snd_ds1 driver. The driver is known to be buggy
and no one has been working on it for years now.
Users of old Yamaha cards may have luck with the OSS drivers instead.
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
diff 134938 Wed Sep 08 06:28:02 MDT 2004 ru Update sound-related manpages to account for the recent change in
device and module naming. The following files were repo-copied:

csa.4 -> snd_csa.4
gusc.4 -> snd_gusc.4
maestro3.4 -> snd_maestro3.4
sbc.4 -> snd_sbc.4
uaudio.4 -> snd_uaudio.4

The pcm(4) manpage wasn't renamed to sound(4) as there are nearby
plans to rename "device sound" to "device snd", to address the
ambiguity in naming, so pcm.4 is linked to sound.4 for the moment.
(We also mumble something about the future plans in the manpage.)

Removed links from pcm.4 to als4000.4 and emu10k1.4 -- they now
have their own snd_*.4 manpages.

Fixes for recent snd_*.4 manpages: added missing "device sound"
to the SYNOPSIS, fixed hints (they are still "hint.pcm.<unit>"
in most cases).

MT5 after: 3 days
H A Daltq.4diff 331511 Sun Mar 25 01:20:02 MDT 2018 sevan MFC r331274

Extend the description of ALTQ to call it a system which is a framework in
altq(4) to match altq(9). This makes preserving the history section as the
author of ALTQ easier in the history section, rather than calling it a framework
in the description & a system in the history.
Add a history section to altq(4) and extend the history section in altq(9)
diff 331511 Sun Mar 25 01:20:02 MDT 2018 sevan MFC r331274

Extend the description of ALTQ to call it a system which is a framework in
altq(4) to match altq(9). This makes preserving the history section as the
author of ALTQ easier in the history section, rather than calling it a framework
in the description & a system in the history.
Add a history section to altq(4) and extend the history section in altq(9)
diff 261975 Sun Feb 16 10:33:28 MST 2014 brueffer Retire the nve(4) driver; nfe(4) has been the default driver for NVIDIA
nForce MCP adapters for a long time.

Yays: jhb, remko, yongari
Nays: none on the current and stable lists
diff 261975 Sun Feb 16 10:33:28 MST 2014 brueffer Retire the nve(4) driver; nfe(4) has been the default driver for NVIDIA
nForce MCP adapters for a long time.

Yays: jhb, remko, yongari
Nays: none on the current and stable lists
diff 255736 Fri Sep 20 18:26:33 MDT 2013 davidch Substantial rewrite of bxe(4) to add support for the BCM57712 and
BCM578XX controllers.

Approved by: re
MFC after: 4 weeks
diff 255736 Fri Sep 20 18:26:33 MDT 2013 davidch Substantial rewrite of bxe(4) to add support for the BCM57712 and
BCM578XX controllers.

Approved by: re
MFC after: 4 weeks
diff 228370 Fri Dec 09 17:32:58 MST 2011 yongari After r228293, et(4) supports altq(4).
diff 228370 Fri Dec 09 17:32:58 MST 2011 yongari After r228293, et(4) supports altq(4).
diff 227348 Tue Nov 08 16:47:54 MST 2011 yongari ti(4) supports altq(4).
diff 227348 Tue Nov 08 16:47:54 MST 2011 yongari ti(4) supports altq(4).
/freebsd-11-stable/sys/sparc64/conf/
H A DGENERICdiff 318156 Wed May 10 20:57:59 MDT 2017 marius MFC: r305507

Disable vt(4) by default on sparc64 as creator_vt(4) and vt_ofwfb(4)
have the serious problem of not actually attaching the hardware they
are driving at the bus level. This causes creator(4) and machfb(4)
to attach and drive the very same hardware in parallel when both
syscons(4) and vt(4) as well as their associated hardware drivers
are built into a kernel, i. e. GENERIC, at the same time.
Also, syscons(4) and its drivers still are way superior to vt(4) and
its equivalents; unlike the syscons(4) counterparts the vt(4) drivers
don't provide hardware acceleration resulting in considerably slower
screen drawing, creator_vt(4) doesn't provide a /dev/fb node as
required by the Xorg sunffb(4) etc. In theory, vt_ofwfb(4) should be
able to handle more devices than machfb(4). However, testing shows
that it hardly works with any hardware machfb(4) isn't also able to
drive, making vt(4) and vt_ofwfb(4) not favorable for the time being
from that perspective either.
diff 318156 Wed May 10 20:57:59 MDT 2017 marius MFC: r305507

Disable vt(4) by default on sparc64 as creator_vt(4) and vt_ofwfb(4)
have the serious problem of not actually attaching the hardware they
are driving at the bus level. This causes creator(4) and machfb(4)
to attach and drive the very same hardware in parallel when both
syscons(4) and vt(4) as well as their associated hardware drivers
are built into a kernel, i. e. GENERIC, at the same time.
Also, syscons(4) and its drivers still are way superior to vt(4) and
its equivalents; unlike the syscons(4) counterparts the vt(4) drivers
don't provide hardware acceleration resulting in considerably slower
screen drawing, creator_vt(4) doesn't provide a /dev/fb node as
required by the Xorg sunffb(4) etc. In theory, vt_ofwfb(4) should be
able to handle more devices than machfb(4). However, testing shows
that it hardly works with any hardware machfb(4) isn't also able to
drive, making vt(4) and vt_ofwfb(4) not favorable for the time being
from that perspective either.
diff 318156 Wed May 10 20:57:59 MDT 2017 marius MFC: r305507

Disable vt(4) by default on sparc64 as creator_vt(4) and vt_ofwfb(4)
have the serious problem of not actually attaching the hardware they
are driving at the bus level. This causes creator(4) and machfb(4)
to attach and drive the very same hardware in parallel when both
syscons(4) and vt(4) as well as their associated hardware drivers
are built into a kernel, i. e. GENERIC, at the same time.
Also, syscons(4) and its drivers still are way superior to vt(4) and
its equivalents; unlike the syscons(4) counterparts the vt(4) drivers
don't provide hardware acceleration resulting in considerably slower
screen drawing, creator_vt(4) doesn't provide a /dev/fb node as
required by the Xorg sunffb(4) etc. In theory, vt_ofwfb(4) should be
able to handle more devices than machfb(4). However, testing shows
that it hardly works with any hardware machfb(4) isn't also able to
drive, making vt(4) and vt_ofwfb(4) not favorable for the time being
from that perspective either.
diff 318156 Wed May 10 20:57:59 MDT 2017 marius MFC: r305507

Disable vt(4) by default on sparc64 as creator_vt(4) and vt_ofwfb(4)
have the serious problem of not actually attaching the hardware they
are driving at the bus level. This causes creator(4) and machfb(4)
to attach and drive the very same hardware in parallel when both
syscons(4) and vt(4) as well as their associated hardware drivers
are built into a kernel, i. e. GENERIC, at the same time.
Also, syscons(4) and its drivers still are way superior to vt(4) and
its equivalents; unlike the syscons(4) counterparts the vt(4) drivers
don't provide hardware acceleration resulting in considerably slower
screen drawing, creator_vt(4) doesn't provide a /dev/fb node as
required by the Xorg sunffb(4) etc. In theory, vt_ofwfb(4) should be
able to handle more devices than machfb(4). However, testing shows
that it hardly works with any hardware machfb(4) isn't also able to
drive, making vt(4) and vt_ofwfb(4) not favorable for the time being
from that perspective either.
diff 318156 Wed May 10 20:57:59 MDT 2017 marius MFC: r305507

Disable vt(4) by default on sparc64 as creator_vt(4) and vt_ofwfb(4)
have the serious problem of not actually attaching the hardware they
are driving at the bus level. This causes creator(4) and machfb(4)
to attach and drive the very same hardware in parallel when both
syscons(4) and vt(4) as well as their associated hardware drivers
are built into a kernel, i. e. GENERIC, at the same time.
Also, syscons(4) and its drivers still are way superior to vt(4) and
its equivalents; unlike the syscons(4) counterparts the vt(4) drivers
don't provide hardware acceleration resulting in considerably slower
screen drawing, creator_vt(4) doesn't provide a /dev/fb node as
required by the Xorg sunffb(4) etc. In theory, vt_ofwfb(4) should be
able to handle more devices than machfb(4). However, testing shows
that it hardly works with any hardware machfb(4) isn't also able to
drive, making vt(4) and vt_ofwfb(4) not favorable for the time being
from that perspective either.
diff 318156 Wed May 10 20:57:59 MDT 2017 marius MFC: r305507

Disable vt(4) by default on sparc64 as creator_vt(4) and vt_ofwfb(4)
have the serious problem of not actually attaching the hardware they
are driving at the bus level. This causes creator(4) and machfb(4)
to attach and drive the very same hardware in parallel when both
syscons(4) and vt(4) as well as their associated hardware drivers
are built into a kernel, i. e. GENERIC, at the same time.
Also, syscons(4) and its drivers still are way superior to vt(4) and
its equivalents; unlike the syscons(4) counterparts the vt(4) drivers
don't provide hardware acceleration resulting in considerably slower
screen drawing, creator_vt(4) doesn't provide a /dev/fb node as
required by the Xorg sunffb(4) etc. In theory, vt_ofwfb(4) should be
able to handle more devices than machfb(4). However, testing shows
that it hardly works with any hardware machfb(4) isn't also able to
drive, making vt(4) and vt_ofwfb(4) not favorable for the time being
from that perspective either.
diff 318156 Wed May 10 20:57:59 MDT 2017 marius MFC: r305507

Disable vt(4) by default on sparc64 as creator_vt(4) and vt_ofwfb(4)
have the serious problem of not actually attaching the hardware they
are driving at the bus level. This causes creator(4) and machfb(4)
to attach and drive the very same hardware in parallel when both
syscons(4) and vt(4) as well as their associated hardware drivers
are built into a kernel, i. e. GENERIC, at the same time.
Also, syscons(4) and its drivers still are way superior to vt(4) and
its equivalents; unlike the syscons(4) counterparts the vt(4) drivers
don't provide hardware acceleration resulting in considerably slower
screen drawing, creator_vt(4) doesn't provide a /dev/fb node as
required by the Xorg sunffb(4) etc. In theory, vt_ofwfb(4) should be
able to handle more devices than machfb(4). However, testing shows
that it hardly works with any hardware machfb(4) isn't also able to
drive, making vt(4) and vt_ofwfb(4) not favorable for the time being
from that perspective either.
diff 318156 Wed May 10 20:57:59 MDT 2017 marius MFC: r305507

Disable vt(4) by default on sparc64 as creator_vt(4) and vt_ofwfb(4)
have the serious problem of not actually attaching the hardware they
are driving at the bus level. This causes creator(4) and machfb(4)
to attach and drive the very same hardware in parallel when both
syscons(4) and vt(4) as well as their associated hardware drivers
are built into a kernel, i. e. GENERIC, at the same time.
Also, syscons(4) and its drivers still are way superior to vt(4) and
its equivalents; unlike the syscons(4) counterparts the vt(4) drivers
don't provide hardware acceleration resulting in considerably slower
screen drawing, creator_vt(4) doesn't provide a /dev/fb node as
required by the Xorg sunffb(4) etc. In theory, vt_ofwfb(4) should be
able to handle more devices than machfb(4). However, testing shows
that it hardly works with any hardware machfb(4) isn't also able to
drive, making vt(4) and vt_ofwfb(4) not favorable for the time being
from that perspective either.
diff 318156 Wed May 10 20:57:59 MDT 2017 marius MFC: r305507

Disable vt(4) by default on sparc64 as creator_vt(4) and vt_ofwfb(4)
have the serious problem of not actually attaching the hardware they
are driving at the bus level. This causes creator(4) and machfb(4)
to attach and drive the very same hardware in parallel when both
syscons(4) and vt(4) as well as their associated hardware drivers
are built into a kernel, i. e. GENERIC, at the same time.
Also, syscons(4) and its drivers still are way superior to vt(4) and
its equivalents; unlike the syscons(4) counterparts the vt(4) drivers
don't provide hardware acceleration resulting in considerably slower
screen drawing, creator_vt(4) doesn't provide a /dev/fb node as
required by the Xorg sunffb(4) etc. In theory, vt_ofwfb(4) should be
able to handle more devices than machfb(4). However, testing shows
that it hardly works with any hardware machfb(4) isn't also able to
drive, making vt(4) and vt_ofwfb(4) not favorable for the time being
from that perspective either.
diff 318156 Wed May 10 20:57:59 MDT 2017 marius MFC: r305507

Disable vt(4) by default on sparc64 as creator_vt(4) and vt_ofwfb(4)
have the serious problem of not actually attaching the hardware they
are driving at the bus level. This causes creator(4) and machfb(4)
to attach and drive the very same hardware in parallel when both
syscons(4) and vt(4) as well as their associated hardware drivers
are built into a kernel, i. e. GENERIC, at the same time.
Also, syscons(4) and its drivers still are way superior to vt(4) and
its equivalents; unlike the syscons(4) counterparts the vt(4) drivers
don't provide hardware acceleration resulting in considerably slower
screen drawing, creator_vt(4) doesn't provide a /dev/fb node as
required by the Xorg sunffb(4) etc. In theory, vt_ofwfb(4) should be
able to handle more devices than machfb(4). However, testing shows
that it hardly works with any hardware machfb(4) isn't also able to
drive, making vt(4) and vt_ofwfb(4) not favorable for the time being
from that perspective either.
diff 318156 Wed May 10 20:57:59 MDT 2017 marius MFC: r305507

Disable vt(4) by default on sparc64 as creator_vt(4) and vt_ofwfb(4)
have the serious problem of not actually attaching the hardware they
are driving at the bus level. This causes creator(4) and machfb(4)
to attach and drive the very same hardware in parallel when both
syscons(4) and vt(4) as well as their associated hardware drivers
are built into a kernel, i. e. GENERIC, at the same time.
Also, syscons(4) and its drivers still are way superior to vt(4) and
its equivalents; unlike the syscons(4) counterparts the vt(4) drivers
don't provide hardware acceleration resulting in considerably slower
screen drawing, creator_vt(4) doesn't provide a /dev/fb node as
required by the Xorg sunffb(4) etc. In theory, vt_ofwfb(4) should be
able to handle more devices than machfb(4). However, testing shows
that it hardly works with any hardware machfb(4) isn't also able to
drive, making vt(4) and vt_ofwfb(4) not favorable for the time being
from that perspective either.
diff 318156 Wed May 10 20:57:59 MDT 2017 marius MFC: r305507

Disable vt(4) by default on sparc64 as creator_vt(4) and vt_ofwfb(4)
have the serious problem of not actually attaching the hardware they
are driving at the bus level. This causes creator(4) and machfb(4)
to attach and drive the very same hardware in parallel when both
syscons(4) and vt(4) as well as their associated hardware drivers
are built into a kernel, i. e. GENERIC, at the same time.
Also, syscons(4) and its drivers still are way superior to vt(4) and
its equivalents; unlike the syscons(4) counterparts the vt(4) drivers
don't provide hardware acceleration resulting in considerably slower
screen drawing, creator_vt(4) doesn't provide a /dev/fb node as
required by the Xorg sunffb(4) etc. In theory, vt_ofwfb(4) should be
able to handle more devices than machfb(4). However, testing shows
that it hardly works with any hardware machfb(4) isn't also able to
drive, making vt(4) and vt_ofwfb(4) not favorable for the time being
from that perspective either.
diff 318156 Wed May 10 20:57:59 MDT 2017 marius MFC: r305507

Disable vt(4) by default on sparc64 as creator_vt(4) and vt_ofwfb(4)
have the serious problem of not actually attaching the hardware they
are driving at the bus level. This causes creator(4) and machfb(4)
to attach and drive the very same hardware in parallel when both
syscons(4) and vt(4) as well as their associated hardware drivers
are built into a kernel, i. e. GENERIC, at the same time.
Also, syscons(4) and its drivers still are way superior to vt(4) and
its equivalents; unlike the syscons(4) counterparts the vt(4) drivers
don't provide hardware acceleration resulting in considerably slower
screen drawing, creator_vt(4) doesn't provide a /dev/fb node as
required by the Xorg sunffb(4) etc. In theory, vt_ofwfb(4) should be
able to handle more devices than machfb(4). However, testing shows
that it hardly works with any hardware machfb(4) isn't also able to
drive, making vt(4) and vt_ofwfb(4) not favorable for the time being
from that perspective either.
diff 318156 Wed May 10 20:57:59 MDT 2017 marius MFC: r305507

Disable vt(4) by default on sparc64 as creator_vt(4) and vt_ofwfb(4)
have the serious problem of not actually attaching the hardware they
are driving at the bus level. This causes creator(4) and machfb(4)
to attach and drive the very same hardware in parallel when both
syscons(4) and vt(4) as well as their associated hardware drivers
are built into a kernel, i. e. GENERIC, at the same time.
Also, syscons(4) and its drivers still are way superior to vt(4) and
its equivalents; unlike the syscons(4) counterparts the vt(4) drivers
don't provide hardware acceleration resulting in considerably slower
screen drawing, creator_vt(4) doesn't provide a /dev/fb node as
required by the Xorg sunffb(4) etc. In theory, vt_ofwfb(4) should be
able to handle more devices than machfb(4). However, testing shows
that it hardly works with any hardware machfb(4) isn't also able to
drive, making vt(4) and vt_ofwfb(4) not favorable for the time being
from that perspective either.
diff 318156 Wed May 10 20:57:59 MDT 2017 marius MFC: r305507

Disable vt(4) by default on sparc64 as creator_vt(4) and vt_ofwfb(4)
have the serious problem of not actually attaching the hardware they
are driving at the bus level. This causes creator(4) and machfb(4)
to attach and drive the very same hardware in parallel when both
syscons(4) and vt(4) as well as their associated hardware drivers
are built into a kernel, i. e. GENERIC, at the same time.
Also, syscons(4) and its drivers still are way superior to vt(4) and
its equivalents; unlike the syscons(4) counterparts the vt(4) drivers
don't provide hardware acceleration resulting in considerably slower
screen drawing, creator_vt(4) doesn't provide a /dev/fb node as
required by the Xorg sunffb(4) etc. In theory, vt_ofwfb(4) should be
able to handle more devices than machfb(4). However, testing shows
that it hardly works with any hardware machfb(4) isn't also able to
drive, making vt(4) and vt_ofwfb(4) not favorable for the time being
from that perspective either.
diff 318156 Wed May 10 20:57:59 MDT 2017 marius MFC: r305507

Disable vt(4) by default on sparc64 as creator_vt(4) and vt_ofwfb(4)
have the serious problem of not actually attaching the hardware they
are driving at the bus level. This causes creator(4) and machfb(4)
to attach and drive the very same hardware in parallel when both
syscons(4) and vt(4) as well as their associated hardware drivers
are built into a kernel, i. e. GENERIC, at the same time.
Also, syscons(4) and its drivers still are way superior to vt(4) and
its equivalents; unlike the syscons(4) counterparts the vt(4) drivers
don't provide hardware acceleration resulting in considerably slower
screen drawing, creator_vt(4) doesn't provide a /dev/fb node as
required by the Xorg sunffb(4) etc. In theory, vt_ofwfb(4) should be
able to handle more devices than machfb(4). However, testing shows
that it hardly works with any hardware machfb(4) isn't also able to
drive, making vt(4) and vt_ofwfb(4) not favorable for the time being
from that perspective either.
diff 318156 Wed May 10 20:57:59 MDT 2017 marius MFC: r305507

Disable vt(4) by default on sparc64 as creator_vt(4) and vt_ofwfb(4)
have the serious problem of not actually attaching the hardware they
are driving at the bus level. This causes creator(4) and machfb(4)
to attach and drive the very same hardware in parallel when both
syscons(4) and vt(4) as well as their associated hardware drivers
are built into a kernel, i. e. GENERIC, at the same time.
Also, syscons(4) and its drivers still are way superior to vt(4) and
its equivalents; unlike the syscons(4) counterparts the vt(4) drivers
don't provide hardware acceleration resulting in considerably slower
screen drawing, creator_vt(4) doesn't provide a /dev/fb node as
required by the Xorg sunffb(4) etc. In theory, vt_ofwfb(4) should be
able to handle more devices than machfb(4). However, testing shows
that it hardly works with any hardware machfb(4) isn't also able to
drive, making vt(4) and vt_ofwfb(4) not favorable for the time being
from that perspective either.
diff 318156 Wed May 10 20:57:59 MDT 2017 marius MFC: r305507

Disable vt(4) by default on sparc64 as creator_vt(4) and vt_ofwfb(4)
have the serious problem of not actually attaching the hardware they
are driving at the bus level. This causes creator(4) and machfb(4)
to attach and drive the very same hardware in parallel when both
syscons(4) and vt(4) as well as their associated hardware drivers
are built into a kernel, i. e. GENERIC, at the same time.
Also, syscons(4) and its drivers still are way superior to vt(4) and
its equivalents; unlike the syscons(4) counterparts the vt(4) drivers
don't provide hardware acceleration resulting in considerably slower
screen drawing, creator_vt(4) doesn't provide a /dev/fb node as
required by the Xorg sunffb(4) etc. In theory, vt_ofwfb(4) should be
able to handle more devices than machfb(4). However, testing shows
that it hardly works with any hardware machfb(4) isn't also able to
drive, making vt(4) and vt_ofwfb(4) not favorable for the time being
from that perspective either.
/freebsd-11-stable/contrib/hyperv/tools/scripts/
H A Dhyperv_vfup322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
H A Dhyperv_vfattach322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
322134 Mon Aug 07 02:54:11 MDT 2017 sephe MFC 321762
hyperv: Add VF bringup scripts and devd rules.

How network VF works with hn(4) on Hyper-V in non-transparent mode:

- Each network VF has a cooresponding hn(4).
- The network VF and the it's cooresponding hn(4) have the same hardware
address.
- Once the network VF is up, e.g. ifconfig VF up:
o All of the transmission should go through the network VF.
o Most of the reception goes through the network VF.
o Small amount of reception may go through the cooresponding hn(4).
This reception will happen, even if the the cooresponding hn(4) is
down. The cooresponding hn(4) will change the reception interface
to the network VF, so that network layer and application layer will
be tricked into thinking that these packets were received by the
network VF.
o The cooresponding hn(4) pretends the physical link is down.
- Once the network VF is down or detached:
o All of the transmission should go through the cooresponding hn(4).
o All of the reception goes through the cooresponding hn(4).
o The cooresponding hn(4) fallbacks to the original physical link
detection logic.

All these features are mainly used to help live migration, during which
the network VF will be detached, while the network communication to the
VM must not be cut off. In order to reach this level of live migration
transparency, we use failover mode lagg(4) with the network VF and the
cooresponding hn(4) attached to it.

To ease user configuration for both network VF and non-network VF, the
lagg(4) will be created by the following rules, and the configuration
of the cooresponding hn(4) will be applied to the lagg(4) automatically.

Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D11635
/freebsd-11-stable/sys/contrib/dev/iwm/
H A Diwm-3160-16.fw.uu303628 Mon Aug 01 16:06:43 MDT 2016 sbruno MFC r303322,303326,303327,303345,303413,303416,303418,303557

Update iwm(4) and iwmfw(4) to current in order to stabilize and improve
functionality.

Approved by: re (gjb)
303628 Mon Aug 01 16:06:43 MDT 2016 sbruno MFC r303322,303326,303327,303345,303413,303416,303418,303557

Update iwm(4) and iwmfw(4) to current in order to stabilize and improve
functionality.

Approved by: re (gjb)
H A Diwm-3160-9.fw.uu303628 Mon Aug 01 16:06:43 MDT 2016 sbruno MFC r303322,303326,303327,303345,303413,303416,303418,303557

Update iwm(4) and iwmfw(4) to current in order to stabilize and improve
functionality.

Approved by: re (gjb)
303628 Mon Aug 01 16:06:43 MDT 2016 sbruno MFC r303322,303326,303327,303345,303413,303416,303418,303557

Update iwm(4) and iwmfw(4) to current in order to stabilize and improve
functionality.

Approved by: re (gjb)
H A Diwm-7260-16.fw.uu303628 Mon Aug 01 16:06:43 MDT 2016 sbruno MFC r303322,303326,303327,303345,303413,303416,303418,303557

Update iwm(4) and iwmfw(4) to current in order to stabilize and improve
functionality.

Approved by: re (gjb)
303628 Mon Aug 01 16:06:43 MDT 2016 sbruno MFC r303322,303326,303327,303345,303413,303416,303418,303557

Update iwm(4) and iwmfw(4) to current in order to stabilize and improve
functionality.

Approved by: re (gjb)
H A Diwm-7260-9.fw.uu303628 Mon Aug 01 16:06:43 MDT 2016 sbruno MFC r303322,303326,303327,303345,303413,303416,303418,303557

Update iwm(4) and iwmfw(4) to current in order to stabilize and improve
functionality.

Approved by: re (gjb)
303628 Mon Aug 01 16:06:43 MDT 2016 sbruno MFC r303322,303326,303327,303345,303413,303416,303418,303557

Update iwm(4) and iwmfw(4) to current in order to stabilize and improve
functionality.

Approved by: re (gjb)
H A Diwm-7265-16.fw.uu303628 Mon Aug 01 16:06:43 MDT 2016 sbruno MFC r303322,303326,303327,303345,303413,303416,303418,303557

Update iwm(4) and iwmfw(4) to current in order to stabilize and improve
functionality.

Approved by: re (gjb)
303628 Mon Aug 01 16:06:43 MDT 2016 sbruno MFC r303322,303326,303327,303345,303413,303416,303418,303557

Update iwm(4) and iwmfw(4) to current in order to stabilize and improve
functionality.

Approved by: re (gjb)
H A Diwm-7265-9.fw.uu303628 Mon Aug 01 16:06:43 MDT 2016 sbruno MFC r303322,303326,303327,303345,303413,303416,303418,303557

Update iwm(4) and iwmfw(4) to current in order to stabilize and improve
functionality.

Approved by: re (gjb)
303628 Mon Aug 01 16:06:43 MDT 2016 sbruno MFC r303322,303326,303327,303345,303413,303416,303418,303557

Update iwm(4) and iwmfw(4) to current in order to stabilize and improve
functionality.

Approved by: re (gjb)
H A Diwm-8000C-16.fw.uu303628 Mon Aug 01 16:06:43 MDT 2016 sbruno MFC r303322,303326,303327,303345,303413,303416,303418,303557

Update iwm(4) and iwmfw(4) to current in order to stabilize and improve
functionality.

Approved by: re (gjb)
303628 Mon Aug 01 16:06:43 MDT 2016 sbruno MFC r303322,303326,303327,303345,303413,303416,303418,303557

Update iwm(4) and iwmfw(4) to current in order to stabilize and improve
functionality.

Approved by: re (gjb)
/freebsd-11-stable/sys/dev/iwm/
H A Dif_iwm_led.h303628 Mon Aug 01 16:06:43 MDT 2016 sbruno MFC r303322,303326,303327,303345,303413,303416,303418,303557

Update iwm(4) and iwmfw(4) to current in order to stabilize and improve
functionality.

Approved by: re (gjb)
303628 Mon Aug 01 16:06:43 MDT 2016 sbruno MFC r303322,303326,303327,303345,303413,303416,303418,303557

Update iwm(4) and iwmfw(4) to current in order to stabilize and improve
functionality.

Approved by: re (gjb)
/freebsd-11-stable/sys/dev/cxgbe/firmware/
H A Dt4fw-1.23.0.0.bin.uu346940 Tue Apr 30 01:38:55 MDT 2019 np MFC r338954, r340651, r344524, r345083.

r338954:
cxgbe(4): Enable support for per-connection rate limiting in the default
firmware configuration files.

Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications

r340651:
cxgbe(4): Update T4/5/6 firmwares to 1.22.0.3.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications

r344524:
cxgbe(4): Updates to the default and hashfilter configurations.

- Do not use nvf = 4 as it is not really supported by the firmware.
Firmwares 1.23.3.0 and above will ignore it silently.
- Increase PF4's share of the VIs and let it use all of the RSS table.

Sponsored by: Chelsio Communications

r345083:
cxgbe(4): Update T4/5/6 firmwares to 1.23.0.0.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications
346940 Tue Apr 30 01:38:55 MDT 2019 np MFC r338954, r340651, r344524, r345083.

r338954:
cxgbe(4): Enable support for per-connection rate limiting in the default
firmware configuration files.

Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications

r340651:
cxgbe(4): Update T4/5/6 firmwares to 1.22.0.3.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications

r344524:
cxgbe(4): Updates to the default and hashfilter configurations.

- Do not use nvf = 4 as it is not really supported by the firmware.
Firmwares 1.23.3.0 and above will ignore it silently.
- Increase PF4's share of the VIs and let it use all of the RSS table.

Sponsored by: Chelsio Communications

r345083:
cxgbe(4): Update T4/5/6 firmwares to 1.23.0.0.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications
346940 Tue Apr 30 01:38:55 MDT 2019 np MFC r338954, r340651, r344524, r345083.

r338954:
cxgbe(4): Enable support for per-connection rate limiting in the default
firmware configuration files.

Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications

r340651:
cxgbe(4): Update T4/5/6 firmwares to 1.22.0.3.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications

r344524:
cxgbe(4): Updates to the default and hashfilter configurations.

- Do not use nvf = 4 as it is not really supported by the firmware.
Firmwares 1.23.3.0 and above will ignore it silently.
- Increase PF4's share of the VIs and let it use all of the RSS table.

Sponsored by: Chelsio Communications

r345083:
cxgbe(4): Update T4/5/6 firmwares to 1.23.0.0.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications
346940 Tue Apr 30 01:38:55 MDT 2019 np MFC r338954, r340651, r344524, r345083.

r338954:
cxgbe(4): Enable support for per-connection rate limiting in the default
firmware configuration files.

Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications

r340651:
cxgbe(4): Update T4/5/6 firmwares to 1.22.0.3.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications

r344524:
cxgbe(4): Updates to the default and hashfilter configurations.

- Do not use nvf = 4 as it is not really supported by the firmware.
Firmwares 1.23.3.0 and above will ignore it silently.
- Increase PF4's share of the VIs and let it use all of the RSS table.

Sponsored by: Chelsio Communications

r345083:
cxgbe(4): Update T4/5/6 firmwares to 1.23.0.0.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications
346940 Tue Apr 30 01:38:55 MDT 2019 np MFC r338954, r340651, r344524, r345083.

r338954:
cxgbe(4): Enable support for per-connection rate limiting in the default
firmware configuration files.

Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications

r340651:
cxgbe(4): Update T4/5/6 firmwares to 1.22.0.3.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications

r344524:
cxgbe(4): Updates to the default and hashfilter configurations.

- Do not use nvf = 4 as it is not really supported by the firmware.
Firmwares 1.23.3.0 and above will ignore it silently.
- Increase PF4's share of the VIs and let it use all of the RSS table.

Sponsored by: Chelsio Communications

r345083:
cxgbe(4): Update T4/5/6 firmwares to 1.23.0.0.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications
H A Dt5fw-1.23.0.0.bin.uu346940 Tue Apr 30 01:38:55 MDT 2019 np MFC r338954, r340651, r344524, r345083.

r338954:
cxgbe(4): Enable support for per-connection rate limiting in the default
firmware configuration files.

Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications

r340651:
cxgbe(4): Update T4/5/6 firmwares to 1.22.0.3.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications

r344524:
cxgbe(4): Updates to the default and hashfilter configurations.

- Do not use nvf = 4 as it is not really supported by the firmware.
Firmwares 1.23.3.0 and above will ignore it silently.
- Increase PF4's share of the VIs and let it use all of the RSS table.

Sponsored by: Chelsio Communications

r345083:
cxgbe(4): Update T4/5/6 firmwares to 1.23.0.0.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications
346940 Tue Apr 30 01:38:55 MDT 2019 np MFC r338954, r340651, r344524, r345083.

r338954:
cxgbe(4): Enable support for per-connection rate limiting in the default
firmware configuration files.

Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications

r340651:
cxgbe(4): Update T4/5/6 firmwares to 1.22.0.3.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications

r344524:
cxgbe(4): Updates to the default and hashfilter configurations.

- Do not use nvf = 4 as it is not really supported by the firmware.
Firmwares 1.23.3.0 and above will ignore it silently.
- Increase PF4's share of the VIs and let it use all of the RSS table.

Sponsored by: Chelsio Communications

r345083:
cxgbe(4): Update T4/5/6 firmwares to 1.23.0.0.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications
346940 Tue Apr 30 01:38:55 MDT 2019 np MFC r338954, r340651, r344524, r345083.

r338954:
cxgbe(4): Enable support for per-connection rate limiting in the default
firmware configuration files.

Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications

r340651:
cxgbe(4): Update T4/5/6 firmwares to 1.22.0.3.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications

r344524:
cxgbe(4): Updates to the default and hashfilter configurations.

- Do not use nvf = 4 as it is not really supported by the firmware.
Firmwares 1.23.3.0 and above will ignore it silently.
- Increase PF4's share of the VIs and let it use all of the RSS table.

Sponsored by: Chelsio Communications

r345083:
cxgbe(4): Update T4/5/6 firmwares to 1.23.0.0.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications
346940 Tue Apr 30 01:38:55 MDT 2019 np MFC r338954, r340651, r344524, r345083.

r338954:
cxgbe(4): Enable support for per-connection rate limiting in the default
firmware configuration files.

Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications

r340651:
cxgbe(4): Update T4/5/6 firmwares to 1.22.0.3.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications

r344524:
cxgbe(4): Updates to the default and hashfilter configurations.

- Do not use nvf = 4 as it is not really supported by the firmware.
Firmwares 1.23.3.0 and above will ignore it silently.
- Increase PF4's share of the VIs and let it use all of the RSS table.

Sponsored by: Chelsio Communications

r345083:
cxgbe(4): Update T4/5/6 firmwares to 1.23.0.0.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications
346940 Tue Apr 30 01:38:55 MDT 2019 np MFC r338954, r340651, r344524, r345083.

r338954:
cxgbe(4): Enable support for per-connection rate limiting in the default
firmware configuration files.

Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications

r340651:
cxgbe(4): Update T4/5/6 firmwares to 1.22.0.3.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications

r344524:
cxgbe(4): Updates to the default and hashfilter configurations.

- Do not use nvf = 4 as it is not really supported by the firmware.
Firmwares 1.23.3.0 and above will ignore it silently.
- Increase PF4's share of the VIs and let it use all of the RSS table.

Sponsored by: Chelsio Communications

r345083:
cxgbe(4): Update T4/5/6 firmwares to 1.23.0.0.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications
H A Dt6fw-1.23.0.0.bin.uu346940 Tue Apr 30 01:38:55 MDT 2019 np MFC r338954, r340651, r344524, r345083.

r338954:
cxgbe(4): Enable support for per-connection rate limiting in the default
firmware configuration files.

Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications

r340651:
cxgbe(4): Update T4/5/6 firmwares to 1.22.0.3.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications

r344524:
cxgbe(4): Updates to the default and hashfilter configurations.

- Do not use nvf = 4 as it is not really supported by the firmware.
Firmwares 1.23.3.0 and above will ignore it silently.
- Increase PF4's share of the VIs and let it use all of the RSS table.

Sponsored by: Chelsio Communications

r345083:
cxgbe(4): Update T4/5/6 firmwares to 1.23.0.0.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications
346940 Tue Apr 30 01:38:55 MDT 2019 np MFC r338954, r340651, r344524, r345083.

r338954:
cxgbe(4): Enable support for per-connection rate limiting in the default
firmware configuration files.

Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications

r340651:
cxgbe(4): Update T4/5/6 firmwares to 1.22.0.3.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications

r344524:
cxgbe(4): Updates to the default and hashfilter configurations.

- Do not use nvf = 4 as it is not really supported by the firmware.
Firmwares 1.23.3.0 and above will ignore it silently.
- Increase PF4's share of the VIs and let it use all of the RSS table.

Sponsored by: Chelsio Communications

r345083:
cxgbe(4): Update T4/5/6 firmwares to 1.23.0.0.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications
346940 Tue Apr 30 01:38:55 MDT 2019 np MFC r338954, r340651, r344524, r345083.

r338954:
cxgbe(4): Enable support for per-connection rate limiting in the default
firmware configuration files.

Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications

r340651:
cxgbe(4): Update T4/5/6 firmwares to 1.22.0.3.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications

r344524:
cxgbe(4): Updates to the default and hashfilter configurations.

- Do not use nvf = 4 as it is not really supported by the firmware.
Firmwares 1.23.3.0 and above will ignore it silently.
- Increase PF4's share of the VIs and let it use all of the RSS table.

Sponsored by: Chelsio Communications

r345083:
cxgbe(4): Update T4/5/6 firmwares to 1.23.0.0.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications
346940 Tue Apr 30 01:38:55 MDT 2019 np MFC r338954, r340651, r344524, r345083.

r338954:
cxgbe(4): Enable support for per-connection rate limiting in the default
firmware configuration files.

Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications

r340651:
cxgbe(4): Update T4/5/6 firmwares to 1.22.0.3.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications

r344524:
cxgbe(4): Updates to the default and hashfilter configurations.

- Do not use nvf = 4 as it is not really supported by the firmware.
Firmwares 1.23.3.0 and above will ignore it silently.
- Increase PF4's share of the VIs and let it use all of the RSS table.

Sponsored by: Chelsio Communications

r345083:
cxgbe(4): Update T4/5/6 firmwares to 1.23.0.0.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications
346940 Tue Apr 30 01:38:55 MDT 2019 np MFC r338954, r340651, r344524, r345083.

r338954:
cxgbe(4): Enable support for per-connection rate limiting in the default
firmware configuration files.

Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications

r340651:
cxgbe(4): Update T4/5/6 firmwares to 1.22.0.3.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications

r344524:
cxgbe(4): Updates to the default and hashfilter configurations.

- Do not use nvf = 4 as it is not really supported by the firmware.
Firmwares 1.23.3.0 and above will ignore it silently.
- Increase PF4's share of the VIs and let it use all of the RSS table.

Sponsored by: Chelsio Communications

r345083:
cxgbe(4): Update T4/5/6 firmwares to 1.23.0.0.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications
H A Dt6fw_cfg_uwire.txtdiff 346940 Tue Apr 30 01:38:55 MDT 2019 np MFC r338954, r340651, r344524, r345083.

r338954:
cxgbe(4): Enable support for per-connection rate limiting in the default
firmware configuration files.

Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications

r340651:
cxgbe(4): Update T4/5/6 firmwares to 1.22.0.3.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications

r344524:
cxgbe(4): Updates to the default and hashfilter configurations.

- Do not use nvf = 4 as it is not really supported by the firmware.
Firmwares 1.23.3.0 and above will ignore it silently.
- Increase PF4's share of the VIs and let it use all of the RSS table.

Sponsored by: Chelsio Communications

r345083:
cxgbe(4): Update T4/5/6 firmwares to 1.23.0.0.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications
diff 346940 Tue Apr 30 01:38:55 MDT 2019 np MFC r338954, r340651, r344524, r345083.

r338954:
cxgbe(4): Enable support for per-connection rate limiting in the default
firmware configuration files.

Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications

r340651:
cxgbe(4): Update T4/5/6 firmwares to 1.22.0.3.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications

r344524:
cxgbe(4): Updates to the default and hashfilter configurations.

- Do not use nvf = 4 as it is not really supported by the firmware.
Firmwares 1.23.3.0 and above will ignore it silently.
- Increase PF4's share of the VIs and let it use all of the RSS table.

Sponsored by: Chelsio Communications

r345083:
cxgbe(4): Update T4/5/6 firmwares to 1.23.0.0.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications
diff 346940 Tue Apr 30 01:38:55 MDT 2019 np MFC r338954, r340651, r344524, r345083.

r338954:
cxgbe(4): Enable support for per-connection rate limiting in the default
firmware configuration files.

Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications

r340651:
cxgbe(4): Update T4/5/6 firmwares to 1.22.0.3.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications

r344524:
cxgbe(4): Updates to the default and hashfilter configurations.

- Do not use nvf = 4 as it is not really supported by the firmware.
Firmwares 1.23.3.0 and above will ignore it silently.
- Increase PF4's share of the VIs and let it use all of the RSS table.

Sponsored by: Chelsio Communications

r345083:
cxgbe(4): Update T4/5/6 firmwares to 1.23.0.0.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications
diff 346940 Tue Apr 30 01:38:55 MDT 2019 np MFC r338954, r340651, r344524, r345083.

r338954:
cxgbe(4): Enable support for per-connection rate limiting in the default
firmware configuration files.

Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications

r340651:
cxgbe(4): Update T4/5/6 firmwares to 1.22.0.3.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications

r344524:
cxgbe(4): Updates to the default and hashfilter configurations.

- Do not use nvf = 4 as it is not really supported by the firmware.
Firmwares 1.23.3.0 and above will ignore it silently.
- Increase PF4's share of the VIs and let it use all of the RSS table.

Sponsored by: Chelsio Communications

r345083:
cxgbe(4): Update T4/5/6 firmwares to 1.23.0.0.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications
diff 346940 Tue Apr 30 01:38:55 MDT 2019 np MFC r338954, r340651, r344524, r345083.

r338954:
cxgbe(4): Enable support for per-connection rate limiting in the default
firmware configuration files.

Approved by: re@ (gjb@)
Sponsored by: Chelsio Communications

r340651:
cxgbe(4): Update T4/5/6 firmwares to 1.22.0.3.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications

r344524:
cxgbe(4): Updates to the default and hashfilter configurations.

- Do not use nvf = 4 as it is not really supported by the firmware.
Firmwares 1.23.3.0 and above will ignore it silently.
- Increase PF4's share of the VIs and let it use all of the RSS table.

Sponsored by: Chelsio Communications

r345083:
cxgbe(4): Update T4/5/6 firmwares to 1.23.0.0.

Obtained from: Chelsio Communications
Sponsored by: Chelsio Communications
diff 333642 Tue May 15 18:51:34 MDT 2018 np MFC r331340, r331342, r331472, r332050, r333276, r333448:

r331340:
cxgbe(4): Tunnel congestion drops on a port should be cleared when the
stats for that port are cleared.

r331342:
cxgbe(4): Do not read MFG diags information from custom boards.

r331472:
cxgbe(4): Always initialize requested_speed to a valid value.

This fixes an avoidable EINVAL when the user tries to disable AN after
the port is initialized but l1cfg doesn't have a valid speed to use.

r332050:
cxgbe(4): Always display an error message if SIOCSIFFLAGS will leave
IFF_UP and IFF_DRV_RUNNING out of sync. ifhwioctl in the kernel pays no
attention to the return code from the driver ioctl during SIOCSIFFLAGS
so these messages are the only indication that the ioctl was called but
failed.

r333276:
cxgbe(4): Update all firmwares to 1.19.1.0.

r333448:
cxgbe(4): Disable write-combined doorbells by default.

This had been the default behavior but was changed accidentally as part
of the recent iw_cxgbe+OFED overhaul. Fix another bug in that change
while here: the global knob affects all the adapters in the system and
should be left alone by per-adapter code.

Approved by: re@ (marius@)
Sponsored by: Chelsio Communications
diff 333642 Tue May 15 18:51:34 MDT 2018 np MFC r331340, r331342, r331472, r332050, r333276, r333448:

r331340:
cxgbe(4): Tunnel congestion drops on a port should be cleared when the
stats for that port are cleared.

r331342:
cxgbe(4): Do not read MFG diags information from custom boards.

r331472:
cxgbe(4): Always initialize requested_speed to a valid value.

This fixes an avoidable EINVAL when the user tries to disable AN after
the port is initialized but l1cfg doesn't have a valid speed to use.

r332050:
cxgbe(4): Always display an error message if SIOCSIFFLAGS will leave
IFF_UP and IFF_DRV_RUNNING out of sync. ifhwioctl in the kernel pays no
attention to the return code from the driver ioctl during SIOCSIFFLAGS
so these messages are the only indication that the ioctl was called but
failed.

r333276:
cxgbe(4): Update all firmwares to 1.19.1.0.

r333448:
cxgbe(4): Disable write-combined doorbells by default.

This had been the default behavior but was changed accidentally as part
of the recent iw_cxgbe+OFED overhaul. Fix another bug in that change
while here: the global knob affects all the adapters in the system and
should be left alone by per-adapter code.

Approved by: re@ (marius@)
Sponsored by: Chelsio Communications
diff 333642 Tue May 15 18:51:34 MDT 2018 np MFC r331340, r331342, r331472, r332050, r333276, r333448:

r331340:
cxgbe(4): Tunnel congestion drops on a port should be cleared when the
stats for that port are cleared.

r331342:
cxgbe(4): Do not read MFG diags information from custom boards.

r331472:
cxgbe(4): Always initialize requested_speed to a valid value.

This fixes an avoidable EINVAL when the user tries to disable AN after
the port is initialized but l1cfg doesn't have a valid speed to use.

r332050:
cxgbe(4): Always display an error message if SIOCSIFFLAGS will leave
IFF_UP and IFF_DRV_RUNNING out of sync. ifhwioctl in the kernel pays no
attention to the return code from the driver ioctl during SIOCSIFFLAGS
so these messages are the only indication that the ioctl was called but
failed.

r333276:
cxgbe(4): Update all firmwares to 1.19.1.0.

r333448:
cxgbe(4): Disable write-combined doorbells by default.

This had been the default behavior but was changed accidentally as part
of the recent iw_cxgbe+OFED overhaul. Fix another bug in that change
while here: the global knob affects all the adapters in the system and
should be left alone by per-adapter code.

Approved by: re@ (marius@)
Sponsored by: Chelsio Communications
diff 333642 Tue May 15 18:51:34 MDT 2018 np MFC r331340, r331342, r331472, r332050, r333276, r333448:

r331340:
cxgbe(4): Tunnel congestion drops on a port should be cleared when the
stats for that port are cleared.

r331342:
cxgbe(4): Do not read MFG diags information from custom boards.

r331472:
cxgbe(4): Always initialize requested_speed to a valid value.

This fixes an avoidable EINVAL when the user tries to disable AN after
the port is initialized but l1cfg doesn't have a valid speed to use.

r332050:
cxgbe(4): Always display an error message if SIOCSIFFLAGS will leave
IFF_UP and IFF_DRV_RUNNING out of sync. ifhwioctl in the kernel pays no
attention to the return code from the driver ioctl during SIOCSIFFLAGS
so these messages are the only indication that the ioctl was called but
failed.

r333276:
cxgbe(4): Update all firmwares to 1.19.1.0.

r333448:
cxgbe(4): Disable write-combined doorbells by default.

This had been the default behavior but was changed accidentally as part
of the recent iw_cxgbe+OFED overhaul. Fix another bug in that change
while here: the global knob affects all the adapters in the system and
should be left alone by per-adapter code.

Approved by: re@ (marius@)
Sponsored by: Chelsio Communications
diff 333642 Tue May 15 18:51:34 MDT 2018 np MFC r331340, r331342, r331472, r332050, r333276, r333448:

r331340:
cxgbe(4): Tunnel congestion drops on a port should be cleared when the
stats for that port are cleared.

r331342:
cxgbe(4): Do not read MFG diags information from custom boards.

r331472:
cxgbe(4): Always initialize requested_speed to a valid value.

This fixes an avoidable EINVAL when the user tries to disable AN after
the port is initialized but l1cfg doesn't have a valid speed to use.

r332050:
cxgbe(4): Always display an error message if SIOCSIFFLAGS will leave
IFF_UP and IFF_DRV_RUNNING out of sync. ifhwioctl in the kernel pays no
attention to the return code from the driver ioctl during SIOCSIFFLAGS
so these messages are the only indication that the ioctl was called but
failed.

r333276:
cxgbe(4): Update all firmwares to 1.19.1.0.

r333448:
cxgbe(4): Disable write-combined doorbells by default.

This had been the default behavior but was changed accidentally as part
of the recent iw_cxgbe+OFED overhaul. Fix another bug in that change
while here: the global knob affects all the adapters in the system and
should be left alone by per-adapter code.

Approved by: re@ (marius@)
Sponsored by: Chelsio Communications
diff 333642 Tue May 15 18:51:34 MDT 2018 np MFC r331340, r331342, r331472, r332050, r333276, r333448:

r331340:
cxgbe(4): Tunnel congestion drops on a port should be cleared when the
stats for that port are cleared.

r331342:
cxgbe(4): Do not read MFG diags information from custom boards.

r331472:
cxgbe(4): Always initialize requested_speed to a valid value.

This fixes an avoidable EINVAL when the user tries to disable AN after
the port is initialized but l1cfg doesn't have a valid speed to use.

r332050:
cxgbe(4): Always display an error message if SIOCSIFFLAGS will leave
IFF_UP and IFF_DRV_RUNNING out of sync. ifhwioctl in the kernel pays no
attention to the return code from the driver ioctl during SIOCSIFFLAGS
so these messages are the only indication that the ioctl was called but
failed.

r333276:
cxgbe(4): Update all firmwares to 1.19.1.0.

r333448:
cxgbe(4): Disable write-combined doorbells by default.

This had been the default behavior but was changed accidentally as part
of the recent iw_cxgbe+OFED overhaul. Fix another bug in that change
while here: the global knob affects all the adapters in the system and
should be left alone by per-adapter code.

Approved by: re@ (marius@)
Sponsored by: Chelsio Communications
/freebsd-11-stable/release/doc/en_US.ISO8859-1/hardware/
H A Darticle.xmldiff 362512 Mon Jun 22 21:46:10 MDT 2020 hrs Fix a build error due to removal of hardware section in umass(4).
diff 318455 Thu May 18 15:57:12 MDT 2017 gjb Add qlnxe(4)

Sponsored by: The FreeBSD Foundation
diff 316224 Thu Mar 30 05:33:05 MDT 2017 ngie MFC r315759,r315761:

r315759 (by gjb):

Add mlx5en(4) to the hardware page. [1]
Belatedly bump copyright years after several changes.

r315761:

Add cxgbe(4), ixl(4), and mlx4en(4) to the hardware release notes
diff 316224 Thu Mar 30 05:33:05 MDT 2017 ngie MFC r315759,r315761:

r315759 (by gjb):

Add mlx5en(4) to the hardware page. [1]
Belatedly bump copyright years after several changes.

r315761:

Add cxgbe(4), ixl(4), and mlx4en(4) to the hardware release notes
diff 316224 Thu Mar 30 05:33:05 MDT 2017 ngie MFC r315759,r315761:

r315759 (by gjb):

Add mlx5en(4) to the hardware page. [1]
Belatedly bump copyright years after several changes.

r315761:

Add cxgbe(4), ixl(4), and mlx4en(4) to the hardware release notes
diff 316224 Thu Mar 30 05:33:05 MDT 2017 ngie MFC r315759,r315761:

r315759 (by gjb):

Add mlx5en(4) to the hardware page. [1]
Belatedly bump copyright years after several changes.

r315761:

Add cxgbe(4), ixl(4), and mlx4en(4) to the hardware release notes
diff 309377 Thu Dec 01 16:52:59 MST 2016 shurd MFC r308696, r308729, r308787, r308813, r309028, r309073, r309078:

r308696:
New driver for Broadcom NetXtreme-C and NetXtreme-E devices.

r308729:
Add bnxt(4) to the hardware notes.

r308787:
Add missing newline in error mesage

r308813:
Check link status after init

r309028:
Add missing break to switch statement

r309073:
Fix version string

r309078:
Add new device IDs

Approved by: sbruno
Relnotes: yes
Sponsored by: Broadcom Limited
diff 293170 Mon Jan 04 16:39:38 MST 2016 brueffer Add rtwn(4) to the hardware list.
diff 288378 Tue Sep 29 15:07:23 MDT 2015 brueffer Add otus(4) to the hardware notes.
diff 286572 Mon Aug 10 08:50:44 MDT 2015 brueffer Add iwm(4) to the hardware notes.

Completed in 384 milliseconds

1234567891011>>