Searched hist:4 (Results 1 - 25 of 9856) sorted by relevance
/freebsd-11-stable/share/man/man4/ | ||
H A D | jedec_ts.4 | 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 D | iwm.4 | 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. 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 D | jedec_dimm.4 | diff 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 D | vmm.4 | 327974 Sun Jan 14 20:37:22 MST 2018 eadler MFC r326281: Add vmm(4) man page PR: 205705 |
H A D | snd_uaudio.4 | diff 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 D | mlx4en.4 | diff 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 D | mlx4ib.4 | diff 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 D | snd_ds1.4 | diff 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 D | altq.4 | 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 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 D | GENERIC | 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. 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 D | hyperv_vfup | 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 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 D | hyperv_vfattach | 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 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 D | iwm-3160-16.fw.uu | 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 D | iwm-3160-9.fw.uu | 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 D | iwm-7260-16.fw.uu | 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 D | iwm-7260-9.fw.uu | 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 D | iwm-7265-16.fw.uu | 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 D | iwm-7265-9.fw.uu | 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 D | iwm-8000C-16.fw.uu | 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) |
/freebsd-11-stable/sys/dev/iwm/ | ||
H A D | if_iwm_led.h | 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) |
/freebsd-11-stable/sys/dev/cxgbe/firmware/ | ||
H A D | t4fw-1.23.0.0.bin.uu | 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 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 D | t5fw-1.23.0.0.bin.uu | 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 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 D | t6fw-1.23.0.0.bin.uu | 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 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 D | t6fw_cfg_uwire.txt | 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 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 D | article.xml | diff 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