Searched hist:4 (Results 451 - 475 of 17372) sorted by relevance
/freebsd-10.2-release/share/man/man4/ | ||
H A D | targ.4 | diff 228481 Tue Dec 13 21:29:24 MST 2011 ed Change targ(4) to use cdevpriv, instead of multiple character devices. Also update the manpage and the scsi_target example program accordingly. Discussed on: scsi@ Tested by: Chuck Tuffli <chuck tuffli net> diff 198125 Thu Oct 15 11:47:35 MDT 2009 brueffer Use our standard section 4 SYNOPSIS. MFC after: 3 days diff 109345 Thu Jan 16 00:24:29 MST 2003 njl kernel: * Fix a bug where devices weren't cleaned up on close(): CAM_REQ_CMP != 0 user: * Increase timeout in usermode to CAM_TIME_INFINITY. The initiator is in charge of timeouts and the value was in ms, not seconds. * Bring two debugging printfs under the debug flag * Clean up man page to show increased testing on isp(4) Submitted by: gibbs (bugfixes) 107178 Fri Nov 22 22:55:51 MST 2002 njl New SCSI target emulator code This code allows a user program to enable target mode on a SIM and then emulate any number of devices (disks, tape drives, etc.) All decisions about device behavior (UA, CA, inquiry response) are left to the usermode program and the kernel driver is merely a conduit for CCBs. This enables multiple concurrent target emulators, each using its own backing store and IO model. Also included is a user program that emulates a disk (RBC) using a file as a backing store. This provides functionality similar to md(4) at the CAM layer. Code has been tested on ahc(4) and should also work on isp(4) (and other SIMs that gain target mode support). It is a complete rewrite of /sys/cam/scsi_target* and /usr/share/examples/scsi_target. Design, comments from: gibbs Supported by: Cryptography Research Approved by: re 107178 Fri Nov 22 22:55:51 MST 2002 njl New SCSI target emulator code This code allows a user program to enable target mode on a SIM and then emulate any number of devices (disks, tape drives, etc.) All decisions about device behavior (UA, CA, inquiry response) are left to the usermode program and the kernel driver is merely a conduit for CCBs. This enables multiple concurrent target emulators, each using its own backing store and IO model. Also included is a user program that emulates a disk (RBC) using a file as a backing store. This provides functionality similar to md(4) at the CAM layer. Code has been tested on ahc(4) and should also work on isp(4) (and other SIMs that gain target mode support). It is a complete rewrite of /sys/cam/scsi_target* and /usr/share/examples/scsi_target. Design, comments from: gibbs Supported by: Cryptography Research Approved by: re 107178 Fri Nov 22 22:55:51 MST 2002 njl New SCSI target emulator code This code allows a user program to enable target mode on a SIM and then emulate any number of devices (disks, tape drives, etc.) All decisions about device behavior (UA, CA, inquiry response) are left to the usermode program and the kernel driver is merely a conduit for CCBs. This enables multiple concurrent target emulators, each using its own backing store and IO model. Also included is a user program that emulates a disk (RBC) using a file as a backing store. This provides functionality similar to md(4) at the CAM layer. Code has been tested on ahc(4) and should also work on isp(4) (and other SIMs that gain target mode support). It is a complete rewrite of /sys/cam/scsi_target* and /usr/share/examples/scsi_target. Design, comments from: gibbs Supported by: Cryptography Research Approved by: re |
H A D | nve.4 | diff 261972 Sun Feb 16 11:16:10 MST 2014 brueffer MFC: r261838 Add a deprecation notice to nve.4 and Xref nfe.4. diff 261972 Sun Feb 16 11:16:10 MST 2014 brueffer MFC: r261838 Add a deprecation notice to nve.4 and Xref nfe.4. diff 217468 Sun Jan 16 04:17:13 MST 2011 marius Reference rgephy.4 in man pages of additional MAC drivers also known to come in combination with these PHYs. Submitted by: yongari MFC after: 3 days diff 166346 Tue Jan 30 08:40:04 MST 2007 brueffer Xref altq(4) for drivers that support it according to altq(4). diff 166346 Tue Jan 30 08:40:04 MST 2007 brueffer Xref altq(4) for drivers that support it according to altq(4). diff 148145 Tue Jul 19 00:26:30 MDT 2005 trhodes Add a "Load module on start up" comment, similar to mac_*.4 pages[1]. Quote .Cd and .Nd text. Bump doc date. Requested by: some user through ru Supported by: ru, dwmalone, brueffer |
H A D | sched_ule.4 | diff 239185 Fri Aug 10 19:16:45 MDT 2012 mav Some minor tunings/cleanups inspired by bde@ after previous commits: - remove extra dynamic variable initializations; - restore (4BSD) and implement (ULE) hogticks variable setting; - make sched_rr_interval() more tolerant to options; - restore (4BSD) and implement (ULE) kern.sched.quantum sysctl, a more user-friendly wrapper for sched_slice; - tune some sysctl descriptions; - make some style fixes. diff 239185 Fri Aug 10 19:16:45 MDT 2012 mav Some minor tunings/cleanups inspired by bde@ after previous commits: - remove extra dynamic variable initializations; - restore (4BSD) and implement (ULE) hogticks variable setting; - make sched_rr_interval() more tolerant to options; - restore (4BSD) and implement (ULE) kern.sched.quantum sysctl, a more user-friendly wrapper for sched_slice; - tune some sysctl descriptions; - make some style fixes. diff 175638 Thu Jan 24 13:48:20 MST 2008 ru - sched_4bsd is no longer a default system scheduler on some architectures, so call it "traditional" instead. - sched_ule is no longer buggy or experimental (according to rev. 1.7 of sched_ule(4)), so don't call it experimental (reported by a user on stable@). Reviewed by: rwatson diff 170312 Tue Jun 05 01:10:47 MDT 2007 delphij sched_core(4) removed. diff 163041 Thu Oct 05 20:31:58 MDT 2006 simon - Remove SCHED_ULE from GENERIC to better avoid foot-shooting by unsuspecting users. - Add a comment in NOTES about experimental status of SCHED_ULE. - Make warning about experimental status in sched_ule(4) a bit stronger. Suggested and reviewed by: dougb Discussed on: developers MFC after: 3 days 144759 Thu Apr 07 21:57:19 MDT 2005 rwatson Add rudimentary man pages for kernel options sched_4bsd and sched_ule, which document some of the sysctls available for configuring 4bsd, some of the bullet features of ule, and that ule is considered experimental still. MFC after: 3 days |
H A D | usb.4 | diff 262137 Mon Feb 17 22:40:43 MST 2014 markj MFC r258036: Add IDs for the ASIX 88179 and 88178A USB to GigE adapters. MFC r258331: Import the axge(4) driver for the ASIX AX88178A and AX88179 USB Ethernet adapters. Both devices support Gigabit Ethernet and USB 2.0, and the AX88179 supports USB 3.0. MFC r258617 (by lwhsu): Also note to add xhci(4) to kernel configuration to utilize USB 3.0 MFC r258618 (by lwhsu): Mention axge(4) diff 262137 Mon Feb 17 22:40:43 MST 2014 markj MFC r258036: Add IDs for the ASIX 88179 and 88178A USB to GigE adapters. MFC r258331: Import the axge(4) driver for the ASIX AX88178A and AX88179 USB Ethernet adapters. Both devices support Gigabit Ethernet and USB 2.0, and the AX88179 supports USB 3.0. MFC r258617 (by lwhsu): Also note to add xhci(4) to kernel configuration to utilize USB 3.0 MFC r258618 (by lwhsu): Mention axge(4) diff 262137 Mon Feb 17 22:40:43 MST 2014 markj MFC r258036: Add IDs for the ASIX 88179 and 88178A USB to GigE adapters. MFC r258331: Import the axge(4) driver for the ASIX AX88178A and AX88179 USB Ethernet adapters. Both devices support Gigabit Ethernet and USB 2.0, and the AX88179 supports USB 3.0. MFC r258617 (by lwhsu): Also note to add xhci(4) to kernel configuration to utilize USB 3.0 MFC r258618 (by lwhsu): Mention axge(4) diff 232258 Tue Feb 28 15:51:56 MST 2012 kevlo Mention mos(4) diff 219004 Thu Feb 24 18: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 194860 Wed Jun 24 17:16:17 MDT 2009 thompsa Move programming info from usb(4) to usbdi(9) and update for the usb stack changeover. Needs much more content still. diff 192551 Thu May 21 17:33:45 MDT 2009 thompsa Update usb(4) to match reality, remove section on permissions. Delete usb2_core.4. Submitted by: Hans Petter Selasky diff 192551 Thu May 21 17:33:45 MDT 2009 thompsa Update usb(4) to match reality, remove section on permissions. Delete usb2_core.4. Submitted by: Hans Petter Selasky diff 190100 Thu Mar 19 20:33:43 MDT 2009 thompsa Remove the uscanner(4) driver, this follows the removal of the kernel scanner driver in Linux 2.6. uscanner was just a simple wrapper around a fifo and contained no logic, the default interface is now libusb (supported by sane). Reviewed by: HPS diff 164524 Wed Nov 22 21:30:02 MST 2006 brueffer Use our standard section 4 SYNOPSIS. MFC after: 3 days |
H A D | amr.4 | diff 157271 Wed Mar 29 21:02:35 MST 2006 brueffer Mention that MegaRAID SAS controllers are supported by mfi(4). diff 146803 Mon May 30 12:26:12 MDT 2005 brueffer Add the Dell PERC 4/IM as supported. Submitted by: Muthu_T@Dell.com diff 145126 Fri Apr 15 21:18:31 MDT 2005 simon - Add Dell PERC 4ei to the list of supported devices. It's an alias used by Dell sometimes for PERC 4e/Si. [1] - Delete some trailing whitespace. MFC after: 1 day Rapported by: Jon Kuster <kwsn@earthlink.net> [1] diff 145126 Fri Apr 15 21:18:31 MDT 2005 simon - Add Dell PERC 4ei to the list of supported devices. It's an alias used by Dell sometimes for PERC 4e/Si. [1] - Delete some trailing whitespace. MFC after: 1 day Rapported by: Jon Kuster <kwsn@earthlink.net> [1] diff 139657 Tue Jan 04 04:18:21 MST 2005 brueffer - list the LSI MegaRAID SATA 150-(2|4|6) controllers as supported (1) - mention SATA support in a few places - AMI -> AMI/LSI for controllers now sold my LSI - bump .Dd PR: 61878 (1) Submitted by: Sten Spans <sten@blinkenlights.nl> Discussed with: simon (sorting) MFC after: 3 days diff 138012 Tue Nov 23 10:47:08 MST 2004 simon Add Dell PERC 4e/Di and Dell PERC 4e/Si to the list of supported devices. Submitted by: Muthu_T@Dell.com MFC after: 3 days diff 138012 Tue Nov 23 10:47:08 MST 2004 simon Add Dell PERC 4e/Di and Dell PERC 4e/Si to the list of supported devices. Submitted by: Muthu_T@Dell.com MFC after: 3 days diff 123771 Tue Dec 23 16:22:34 MST 2003 trhodes Add the MegaRAID 320-4X cards to the supported device list. Submitted by: Andre Guibert de Bruet <andy@siliconlandmark.com> (via -doc) diff 120523 Sat Sep 27 18:03:03 MDT 2003 simon - Add the Dell PERC 4/Di to the list of supported devices; it has been supported for the last 10 months. [1] - Make the device list compact, since it is getting rather large. Reported by: David Magda <dmagda@magda.ca> [1] MFC after: 2 weeks diff 112653 Wed Mar 26 01:34:23 MST 2003 keramida Update amr(4) to note that LSILogic MegaRAID 320-[1/2] cards work. PR: 50139 Submitted by: asmodai |
/freebsd-10.2-release/share/man/man8/ | ||
H A D | nanobsd.8 | diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes |
/freebsd-10.2-release/sys/dev/ppbus/ | ||
H A D | vpoio.c | diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( diff 187576 Wed Jan 21 23:14:29 MST 2009 jhb Add locking to ppc and ppbus and mark the whole lot MPSAFE: - To avoid having a bunch of locks that end up always getting acquired as a group, give each ppc(4) device a mutex which it shares with all the child devices including ppbus(4), lpt(4), plip(4), etc. This mutex is then used for all the locking. - Rework the interrupt handling stuff yet again. Now ppbus drivers setup their interrupt handler during attach and tear it down during detach like most other drivers. ppbus(4) only invokes the interrupt handler of the device that currently owns the bus (if any) when an interrupt occurs, however. Also, interrupt handlers in general now accept their softc pointers as their argument rather than the device_t. Another feature of the ppbus interrupt handlers is that they are called with the parent ppc device's lock already held. This minimizes the number of lock operations during an interrupt. - Mark plip(4), lpt(4), pcfclock(4), ppi(4), vpo(4) MPSAFE. - lpbb(4) uses the ppc lock instead of Giant. - Other plip(4) changes: - Add a mutex to protect the global tables in plip(4) and free them on module unload. - Add a detach routine. - Split out the init/stop code from the ioctl routine into separate functions. - Other lpt(4) changes: - Use device_printf(). - Use a dedicated callout for the lptout timer. - Allocate the I/O buffers at attach and detach rather than during open and close as this simplifies the locking at the cost of 1024+32 bytes when the driver is attached. - Other ppi(4) changes: - Use an sx lock to serialize open and close. - Remove unused HADBUS flag. - Add a detach routine. - Use a malloc'd buffer for each read and write to avoid races with concurrent read/write. - Other pps(4) changes: - Use a callout rather than a callout handle with timeout(). - Conform to the new ppbus requirements (regular mutex, non-filter interrupt handler). pps(4) is probably going to have to become a standalone driver that doesn't use ppbus(4) to satisfy it's requirements for low latency as a result. - Use an sx lock to serialize open and close. - Other vpo(4) changes: - Use the parent ppc device's lock to create the CAM sim instead of Giant. - Other ppc(4) changes: - Fix ppc_isa's detach method to detach instead of calling attach. Tested by: no one :-( |
/freebsd-10.2-release/sys/dev/age/ | ||
H A D | if_agereg.h | diff 190499 Sat Mar 28 07:54:31 MDT 2009 yongari o Don't access VPD even if hardware advertised the capability. It seems that some revision of controller hang while accessing the VPD. Because VPD access routine are unused, nuke it. o Let TWSI reload EEPROM if VPD capability is detected. Reloading EEPROM will also set ethernet address so age(4) now reads AGE_PAR0 and AGE_PAR1 register to get ethernet address. This removes a lot of hack and enhance readability a lot. o Double PHY reset timeout as it takes more time to take PHY out of power-saving state. o Explicitly check power-saving state by checking undocumented PHY registers. If link is not up, poke undocumented registers to take PHY out of power-saving state. This is the same way what Linux does. On resume, make sure to wake up PHY. o Don't rely on auto-clearing feature of master reset bit, just wait 1ms and check idle status of MAC. o Add PCI device revision information in bootverbose mode. This should fix occasional controller hang in device attach phase. Reported by: barbara < barbara.xxx1975 at libero DOT it > Tested by: barbara < barbara.xxx1975 at libero DOT it > 179100 Mon May 19 01:39:59 MDT 2008 yongari Add age(4), a driver for Attansic/Atheros L1 gigabit ethernet controller. L1 has several threshold/timer registers and they seem to require careful tuned parameters to get best performance. Datasheet for L1 is not available to open source driver writers so age(4) focus on stability and correctness of basic Tx/Rx operation. ATM the performance of age(4) is far from optimal which in turn means there are mis-programmed registers or incorrectly configured registers. Currently age(4) supports all known hardware assistance including - MSI support. - TCP Segmentation Offload. - Hardware VLAN tag insertion/stripping. - TCP/UDP checksum offload. - Interrupt moderation. - Hardware statistics counter support. - Jumbo frame support. - WOL support. L1 gigabit ethernet controller is mainly found on ASUS motherboards. Note, it seems that there are other variants of hardware as known as L2(Fast ethernet) and newer gigabit ethernet (AR81xx) from Atheros. These are not supported by age(4) and requires a seperate driver. Big thanks to all people who reported feedback or tested patches. Tested by: kevlo, bsam, Francois Ranchin < fyr AT fyrou DOT net > Thomas Nystroem < thn AT saeab DOT se > Roman Pogosyan < asternetadmin AT gmail DOT com > Derek Tattersal < dlt AT mebtel DOT net > Oliver Seitz < karlkiste AT yahoo DOT com > 179100 Mon May 19 01:39:59 MDT 2008 yongari Add age(4), a driver for Attansic/Atheros L1 gigabit ethernet controller. L1 has several threshold/timer registers and they seem to require careful tuned parameters to get best performance. Datasheet for L1 is not available to open source driver writers so age(4) focus on stability and correctness of basic Tx/Rx operation. ATM the performance of age(4) is far from optimal which in turn means there are mis-programmed registers or incorrectly configured registers. Currently age(4) supports all known hardware assistance including - MSI support. - TCP Segmentation Offload. - Hardware VLAN tag insertion/stripping. - TCP/UDP checksum offload. - Interrupt moderation. - Hardware statistics counter support. - Jumbo frame support. - WOL support. L1 gigabit ethernet controller is mainly found on ASUS motherboards. Note, it seems that there are other variants of hardware as known as L2(Fast ethernet) and newer gigabit ethernet (AR81xx) from Atheros. These are not supported by age(4) and requires a seperate driver. Big thanks to all people who reported feedback or tested patches. Tested by: kevlo, bsam, Francois Ranchin < fyr AT fyrou DOT net > Thomas Nystroem < thn AT saeab DOT se > Roman Pogosyan < asternetadmin AT gmail DOT com > Derek Tattersal < dlt AT mebtel DOT net > Oliver Seitz < karlkiste AT yahoo DOT com > 179100 Mon May 19 01:39:59 MDT 2008 yongari Add age(4), a driver for Attansic/Atheros L1 gigabit ethernet controller. L1 has several threshold/timer registers and they seem to require careful tuned parameters to get best performance. Datasheet for L1 is not available to open source driver writers so age(4) focus on stability and correctness of basic Tx/Rx operation. ATM the performance of age(4) is far from optimal which in turn means there are mis-programmed registers or incorrectly configured registers. Currently age(4) supports all known hardware assistance including - MSI support. - TCP Segmentation Offload. - Hardware VLAN tag insertion/stripping. - TCP/UDP checksum offload. - Interrupt moderation. - Hardware statistics counter support. - Jumbo frame support. - WOL support. L1 gigabit ethernet controller is mainly found on ASUS motherboards. Note, it seems that there are other variants of hardware as known as L2(Fast ethernet) and newer gigabit ethernet (AR81xx) from Atheros. These are not supported by age(4) and requires a seperate driver. Big thanks to all people who reported feedback or tested patches. Tested by: kevlo, bsam, Francois Ranchin < fyr AT fyrou DOT net > Thomas Nystroem < thn AT saeab DOT se > Roman Pogosyan < asternetadmin AT gmail DOT com > Derek Tattersal < dlt AT mebtel DOT net > Oliver Seitz < karlkiste AT yahoo DOT com > 179100 Mon May 19 01:39:59 MDT 2008 yongari Add age(4), a driver for Attansic/Atheros L1 gigabit ethernet controller. L1 has several threshold/timer registers and they seem to require careful tuned parameters to get best performance. Datasheet for L1 is not available to open source driver writers so age(4) focus on stability and correctness of basic Tx/Rx operation. ATM the performance of age(4) is far from optimal which in turn means there are mis-programmed registers or incorrectly configured registers. Currently age(4) supports all known hardware assistance including - MSI support. - TCP Segmentation Offload. - Hardware VLAN tag insertion/stripping. - TCP/UDP checksum offload. - Interrupt moderation. - Hardware statistics counter support. - Jumbo frame support. - WOL support. L1 gigabit ethernet controller is mainly found on ASUS motherboards. Note, it seems that there are other variants of hardware as known as L2(Fast ethernet) and newer gigabit ethernet (AR81xx) from Atheros. These are not supported by age(4) and requires a seperate driver. Big thanks to all people who reported feedback or tested patches. Tested by: kevlo, bsam, Francois Ranchin < fyr AT fyrou DOT net > Thomas Nystroem < thn AT saeab DOT se > Roman Pogosyan < asternetadmin AT gmail DOT com > Derek Tattersal < dlt AT mebtel DOT net > Oliver Seitz < karlkiste AT yahoo DOT com > 179100 Mon May 19 01:39:59 MDT 2008 yongari Add age(4), a driver for Attansic/Atheros L1 gigabit ethernet controller. L1 has several threshold/timer registers and they seem to require careful tuned parameters to get best performance. Datasheet for L1 is not available to open source driver writers so age(4) focus on stability and correctness of basic Tx/Rx operation. ATM the performance of age(4) is far from optimal which in turn means there are mis-programmed registers or incorrectly configured registers. Currently age(4) supports all known hardware assistance including - MSI support. - TCP Segmentation Offload. - Hardware VLAN tag insertion/stripping. - TCP/UDP checksum offload. - Interrupt moderation. - Hardware statistics counter support. - Jumbo frame support. - WOL support. L1 gigabit ethernet controller is mainly found on ASUS motherboards. Note, it seems that there are other variants of hardware as known as L2(Fast ethernet) and newer gigabit ethernet (AR81xx) from Atheros. These are not supported by age(4) and requires a seperate driver. Big thanks to all people who reported feedback or tested patches. Tested by: kevlo, bsam, Francois Ranchin < fyr AT fyrou DOT net > Thomas Nystroem < thn AT saeab DOT se > Roman Pogosyan < asternetadmin AT gmail DOT com > Derek Tattersal < dlt AT mebtel DOT net > Oliver Seitz < karlkiste AT yahoo DOT com > |
/freebsd-10.2-release/sys/dev/ahci/ | ||
H A D | ahciem.c | diff 281140 Mon Apr 06 08:26:36 MDT 2015 mav MFC r280393: Reduce priority of ATA/SATA drivers. Legacy ata(4) -> BUS_PROBE_LOW_PRIORITY; more functional ahci(4), siis(4), mvs(4) -> BUS_PROBE_DEFAULT; BUS_PROBE_VENDOR leave for vendor drivers. diff 281140 Mon Apr 06 08:26:36 MDT 2015 mav MFC r280393: Reduce priority of ATA/SATA drivers. Legacy ata(4) -> BUS_PROBE_LOW_PRIORITY; more functional ahci(4), siis(4), mvs(4) -> BUS_PROBE_DEFAULT; BUS_PROBE_VENDOR leave for vendor drivers. diff 281140 Mon Apr 06 08:26:36 MDT 2015 mav MFC r280393: Reduce priority of ATA/SATA drivers. Legacy ata(4) -> BUS_PROBE_LOW_PRIORITY; more functional ahci(4), siis(4), mvs(4) -> BUS_PROBE_DEFAULT; BUS_PROBE_VENDOR leave for vendor drivers. diff 281140 Mon Apr 06 08:26:36 MDT 2015 mav MFC r280393: Reduce priority of ATA/SATA drivers. Legacy ata(4) -> BUS_PROBE_LOW_PRIORITY; more functional ahci(4), siis(4), mvs(4) -> BUS_PROBE_DEFAULT; BUS_PROBE_VENDOR leave for vendor drivers. 238805 Thu Jul 26 14:01:25 MDT 2012 mav Refactor enclosure manegement support in ahci(4). Move it out into separate subdevice ahciem. Emulate SEMB SES device from AHCI LED interface to expose it to users in form of ses(4) CAM device. If we ever see AHCI controllers supporting SES of SAF-TE over I2C as described by specification, they should fit well into this new picture. Sponsored by: iXsystems, Inc. 238805 Thu Jul 26 14:01:25 MDT 2012 mav Refactor enclosure manegement support in ahci(4). Move it out into separate subdevice ahciem. Emulate SEMB SES device from AHCI LED interface to expose it to users in form of ses(4) CAM device. If we ever see AHCI controllers supporting SES of SAF-TE over I2C as described by specification, they should fit well into this new picture. Sponsored by: iXsystems, Inc. |
/freebsd-10.2-release/usr.sbin/cpucontrol/ | ||
H A D | Makefile | diff 228436 Mon Dec 12 12:38:45 MST 2011 fabient Add VIA microde update support to cpuctl(4) and cpucontrol(8). Support have been tested with X2 CPU and QuadCore CPU. MFC after: 1 month 181430 Fri Aug 08 16:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month 181430 Fri Aug 08 16:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month 181430 Fri Aug 08 16:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month 181430 Fri Aug 08 16:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month 181430 Fri Aug 08 16:35:20 MDT 2008 stas - Add cpuctl(4) pseudo-device driver to provide access to some low-level features of CPUs like reading/writing machine-specific registers, retrieving cpuid data, and updating microcode. - Add cpucontrol(8) utility, that provides userland access to the features of cpuctl(4). - Add subsequent manpages. The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX is created for each cpu present in the systems. The pseudo-device minor number corresponds to the cpu number in the system. The cpuctl(4) pseudo- device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID and UPDATE. The first pair alows the caller to read/write machine-specific registers from the correspondent CPU. cpuid data could be retrieved using the CPUID call, and microcode updates are applied via UPDATE. The permissions are inforced based on the pseudo-device file permissions. RDMSR/CPUID will be allowed when the caller has read access to the device node, while WRMSR/UPDATE will be granted only when the node is opened for writing. There're also a number of priv(9) checks. The cpucontrol(8) utility is intened to provide userland access to the cpuctl(4) device features. The utility also allows one to apply cpu microcode updates. Currently only Intel and AMD cpus are supported and were tested. Approved by: kib Reviewed by: rpaulo, cokane, Peter Jeremy MFC after: 1 month |
/freebsd-10.2-release/usr.sbin/kbdcontrol/ | ||
H A D | kbdmap.5 | diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes |
/freebsd-10.2-release/tools/tools/vt/keymaps/ | ||
H A D | KBDFILES.map | diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes |
H A D | convert-keymap.pl | diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes diff 271095 Thu Sep 04 13:51:25 MDT 2014 se MFC r270647: Add references to vt(4) and the configuration files in /usr/sha MFC r270653: Update man-pages to correctly refer to changed pathes and namin MFC r270657: More man pages that need to know about vt in addition to syscon MFC r270659: (by pluknet@) Missed comma. MFC r270660: Back-out the references to vt(4) from this man-page. It appears MFC r270933: Add references to vt(4) to further man-pages. MFC r270934: Final patches to the tools used to convert syscons keymaps for MFC r270935: Add vt(4) support to the console initialisation script, specifi Second batch of MFCs to add support for Unicode keymaps for use with vt(4). It contains the following changes: - Add references to vt(4) to relevant man-pages. - Update comment in defaults/rc.conf to mention vt - Update rc.d/syscons to warn about syscons keymaps used under vt. An attempt is made to identify the vt keymap to load instead. - Minor changes to the conversion tool based on mail comments on keymaps. Relnotes: yes |
/freebsd-10.2-release/sys/dev/cxgbe/ | ||
H A D | adapter.h | diff 284089 Sat Jun 06 18:03:46 MDT 2015 np MFC r278239 and r278374. r278239: cxgbe(4): reserve id for iSCSI upper layer driver. r278374: cxgbe(4): tidy up some of the interaction between the Upper Layer Drivers (ULDs) and the base if_cxgbe driver. Track the per-adapter activation of ULDs in a new "active_ulds" field. This was done pretty arbitrarily before this change -- via TOM_INIT_DONE in adapter->flags for TOM, and the (1 << MAX_NPORTS) bit in adapter->offload_map for iWARP. iWARP and hw-accelerated iSCSI rely on the TOE (supported by the TOM ULD). The rules are: a) If the iWARP and/or iSCSI ULDs are available when TOE is enabled then iWARP and/or iSCSI are enabled too. b) When the iWARP and iSCSI modules are loaded they go looking for adapters with TOE enabled and enable themselves on that adapter. c) You cannot deactivate or unload the TOM module from underneath iWARP or iSCSI. Any such attempt will fail with EBUSY. diff 284089 Sat Jun 06 18:03:46 MDT 2015 np MFC r278239 and r278374. r278239: cxgbe(4): reserve id for iSCSI upper layer driver. r278374: cxgbe(4): tidy up some of the interaction between the Upper Layer Drivers (ULDs) and the base if_cxgbe driver. Track the per-adapter activation of ULDs in a new "active_ulds" field. This was done pretty arbitrarily before this change -- via TOM_INIT_DONE in adapter->flags for TOM, and the (1 << MAX_NPORTS) bit in adapter->offload_map for iWARP. iWARP and hw-accelerated iSCSI rely on the TOE (supported by the TOM ULD). The rules are: a) If the iWARP and/or iSCSI ULDs are available when TOE is enabled then iWARP and/or iSCSI are enabled too. b) When the iWARP and iSCSI modules are loaded they go looking for adapters with TOE enabled and enable themselves on that adapter. c) You cannot deactivate or unload the TOM module from underneath iWARP or iSCSI. Any such attempt will fail with EBUSY. diff 284052 Sat Jun 06 09:35:14 MDT 2015 np MFC r276480, r276485, r276498, r277225, r277226, r277227, r277230, r277637, and r283149 (by emaste@). r276485 is the real change here, the rest deal with the fallout of mp_ring's reliance on 64b atomics. Use the incorrectly spelled 'eigth' from struct pkthdr in this branch instead of MFC'ing r261733, which would have renamed the field of a public structure in a -STABLE branch. --- r276480: Temporarily unplug cxgbe(4) from !amd64 builds. r276485: cxgbe(4): major tx rework. a) Front load as much work as possible in if_transmit, before any driver lock or software queue has to get involved. b) Replace buf_ring with a brand new mp_ring (multiproducer ring). This is specifically for the tx multiqueue model where one of the if_transmit producer threads becomes the consumer and other producers carry on as usual. mp_ring is implemented as standalone code and it should be possible to use it in any driver with tx multiqueue. It also has: - the ability to enqueue/dequeue multiple items. This might become significant if packet batching is ever implemented. - an abdication mechanism to allow a thread to give up writing tx descriptors and have another if_transmit thread take over. A thread that's writing tx descriptors can end up doing so for an unbounded time period if a) there are other if_transmit threads continuously feeding the sofware queue, and b) the chip keeps up with whatever the thread is throwing at it. - accurate statistics about interesting events even when the stats come at the expense of additional branches/conditional code. The NIC txq lock is uncontested on the fast path at this point. I've left it there for synchronization with the control events (interface up/down, modload/unload). c) Add support for "type 1" coalescing work request in the normal NIC tx path. This work request is optimized for frames with a single item in the DMA gather list. These are very common when forwarding packets. Note that netmap tx in cxgbe already uses these "type 1" work requests. d) Do not request automatic cidx updates every 32 descriptors. Instead, request updates via bits in individual work requests (still every 32 descriptors approximately). Also, request an automatic final update when the queue idles after activity. This means NIC tx reclaim is still performed lazily but it will catch up quickly as soon as the queue idles. This seems to be the best middle ground and I'll probably do something similar for netmap tx as well. e) Implement a faster tx path for WRQs (used by TOE tx and control queues, _not_ by the normal NIC tx). Allow work requests to be written directly to the hardware descriptor ring if room is available. I will convert t4_tom and iw_cxgbe modules to this faster style gradually. r276498: cxgbe(4): remove buf_ring specific restriction on the txq size. r277225: Make cxgbe(4) buildable with the gcc in base. r277226: Allow cxgbe(4) to be built on i386. Driver attach will succeed only on a subset of i386 systems. r277227: Plug cxgbe(4) back into !powerpc && !arm builds, instead of building it on amd64 only. r277230: Build cxgbe(4) on powerpc64 too. r277637: Make sure the compiler flag to get cxgbe(4) to compile with gcc is used only when gcc is being used. This is what r277225 should have been. diff 284052 Sat Jun 06 09:35:14 MDT 2015 np MFC r276480, r276485, r276498, r277225, r277226, r277227, r277230, r277637, and r283149 (by emaste@). r276485 is the real change here, the rest deal with the fallout of mp_ring's reliance on 64b atomics. Use the incorrectly spelled 'eigth' from struct pkthdr in this branch instead of MFC'ing r261733, which would have renamed the field of a public structure in a -STABLE branch. --- r276480: Temporarily unplug cxgbe(4) from !amd64 builds. r276485: cxgbe(4): major tx rework. a) Front load as much work as possible in if_transmit, before any driver lock or software queue has to get involved. b) Replace buf_ring with a brand new mp_ring (multiproducer ring). This is specifically for the tx multiqueue model where one of the if_transmit producer threads becomes the consumer and other producers carry on as usual. mp_ring is implemented as standalone code and it should be possible to use it in any driver with tx multiqueue. It also has: - the ability to enqueue/dequeue multiple items. This might become significant if packet batching is ever implemented. - an abdication mechanism to allow a thread to give up writing tx descriptors and have another if_transmit thread take over. A thread that's writing tx descriptors can end up doing so for an unbounded time period if a) there are other if_transmit threads continuously feeding the sofware queue, and b) the chip keeps up with whatever the thread is throwing at it. - accurate statistics about interesting events even when the stats come at the expense of additional branches/conditional code. The NIC txq lock is uncontested on the fast path at this point. I've left it there for synchronization with the control events (interface up/down, modload/unload). c) Add support for "type 1" coalescing work request in the normal NIC tx path. This work request is optimized for frames with a single item in the DMA gather list. These are very common when forwarding packets. Note that netmap tx in cxgbe already uses these "type 1" work requests. d) Do not request automatic cidx updates every 32 descriptors. Instead, request updates via bits in individual work requests (still every 32 descriptors approximately). Also, request an automatic final update when the queue idles after activity. This means NIC tx reclaim is still performed lazily but it will catch up quickly as soon as the queue idles. This seems to be the best middle ground and I'll probably do something similar for netmap tx as well. e) Implement a faster tx path for WRQs (used by TOE tx and control queues, _not_ by the normal NIC tx). Allow work requests to be written directly to the hardware descriptor ring if room is available. I will convert t4_tom and iw_cxgbe modules to this faster style gradually. r276498: cxgbe(4): remove buf_ring specific restriction on the txq size. r277225: Make cxgbe(4) buildable with the gcc in base. r277226: Allow cxgbe(4) to be built on i386. Driver attach will succeed only on a subset of i386 systems. r277227: Plug cxgbe(4) back into !powerpc && !arm builds, instead of building it on amd64 only. r277230: Build cxgbe(4) on powerpc64 too. r277637: Make sure the compiler flag to get cxgbe(4) to compile with gcc is used only when gcc is being used. This is what r277225 should have been. diff 284052 Sat Jun 06 09:35:14 MDT 2015 np MFC r276480, r276485, r276498, r277225, r277226, r277227, r277230, r277637, and r283149 (by emaste@). r276485 is the real change here, the rest deal with the fallout of mp_ring's reliance on 64b atomics. Use the incorrectly spelled 'eigth' from struct pkthdr in this branch instead of MFC'ing r261733, which would have renamed the field of a public structure in a -STABLE branch. --- r276480: Temporarily unplug cxgbe(4) from !amd64 builds. r276485: cxgbe(4): major tx rework. a) Front load as much work as possible in if_transmit, before any driver lock or software queue has to get involved. b) Replace buf_ring with a brand new mp_ring (multiproducer ring). This is specifically for the tx multiqueue model where one of the if_transmit producer threads becomes the consumer and other producers carry on as usual. mp_ring is implemented as standalone code and it should be possible to use it in any driver with tx multiqueue. It also has: - the ability to enqueue/dequeue multiple items. This might become significant if packet batching is ever implemented. - an abdication mechanism to allow a thread to give up writing tx descriptors and have another if_transmit thread take over. A thread that's writing tx descriptors can end up doing so for an unbounded time period if a) there are other if_transmit threads continuously feeding the sofware queue, and b) the chip keeps up with whatever the thread is throwing at it. - accurate statistics about interesting events even when the stats come at the expense of additional branches/conditional code. The NIC txq lock is uncontested on the fast path at this point. I've left it there for synchronization with the control events (interface up/down, modload/unload). c) Add support for "type 1" coalescing work request in the normal NIC tx path. This work request is optimized for frames with a single item in the DMA gather list. These are very common when forwarding packets. Note that netmap tx in cxgbe already uses these "type 1" work requests. d) Do not request automatic cidx updates every 32 descriptors. Instead, request updates via bits in individual work requests (still every 32 descriptors approximately). Also, request an automatic final update when the queue idles after activity. This means NIC tx reclaim is still performed lazily but it will catch up quickly as soon as the queue idles. This seems to be the best middle ground and I'll probably do something similar for netmap tx as well. e) Implement a faster tx path for WRQs (used by TOE tx and control queues, _not_ by the normal NIC tx). Allow work requests to be written directly to the hardware descriptor ring if room is available. I will convert t4_tom and iw_cxgbe modules to this faster style gradually. r276498: cxgbe(4): remove buf_ring specific restriction on the txq size. r277225: Make cxgbe(4) buildable with the gcc in base. r277226: Allow cxgbe(4) to be built on i386. Driver attach will succeed only on a subset of i386 systems. r277227: Plug cxgbe(4) back into !powerpc && !arm builds, instead of building it on amd64 only. r277230: Build cxgbe(4) on powerpc64 too. r277637: Make sure the compiler flag to get cxgbe(4) to compile with gcc is used only when gcc is being used. This is what r277225 should have been. diff 284052 Sat Jun 06 09:35:14 MDT 2015 np MFC r276480, r276485, r276498, r277225, r277226, r277227, r277230, r277637, and r283149 (by emaste@). r276485 is the real change here, the rest deal with the fallout of mp_ring's reliance on 64b atomics. Use the incorrectly spelled 'eigth' from struct pkthdr in this branch instead of MFC'ing r261733, which would have renamed the field of a public structure in a -STABLE branch. --- r276480: Temporarily unplug cxgbe(4) from !amd64 builds. r276485: cxgbe(4): major tx rework. a) Front load as much work as possible in if_transmit, before any driver lock or software queue has to get involved. b) Replace buf_ring with a brand new mp_ring (multiproducer ring). This is specifically for the tx multiqueue model where one of the if_transmit producer threads becomes the consumer and other producers carry on as usual. mp_ring is implemented as standalone code and it should be possible to use it in any driver with tx multiqueue. It also has: - the ability to enqueue/dequeue multiple items. This might become significant if packet batching is ever implemented. - an abdication mechanism to allow a thread to give up writing tx descriptors and have another if_transmit thread take over. A thread that's writing tx descriptors can end up doing so for an unbounded time period if a) there are other if_transmit threads continuously feeding the sofware queue, and b) the chip keeps up with whatever the thread is throwing at it. - accurate statistics about interesting events even when the stats come at the expense of additional branches/conditional code. The NIC txq lock is uncontested on the fast path at this point. I've left it there for synchronization with the control events (interface up/down, modload/unload). c) Add support for "type 1" coalescing work request in the normal NIC tx path. This work request is optimized for frames with a single item in the DMA gather list. These are very common when forwarding packets. Note that netmap tx in cxgbe already uses these "type 1" work requests. d) Do not request automatic cidx updates every 32 descriptors. Instead, request updates via bits in individual work requests (still every 32 descriptors approximately). Also, request an automatic final update when the queue idles after activity. This means NIC tx reclaim is still performed lazily but it will catch up quickly as soon as the queue idles. This seems to be the best middle ground and I'll probably do something similar for netmap tx as well. e) Implement a faster tx path for WRQs (used by TOE tx and control queues, _not_ by the normal NIC tx). Allow work requests to be written directly to the hardware descriptor ring if room is available. I will convert t4_tom and iw_cxgbe modules to this faster style gradually. r276498: cxgbe(4): remove buf_ring specific restriction on the txq size. r277225: Make cxgbe(4) buildable with the gcc in base. r277226: Allow cxgbe(4) to be built on i386. Driver attach will succeed only on a subset of i386 systems. r277227: Plug cxgbe(4) back into !powerpc && !arm builds, instead of building it on amd64 only. r277230: Build cxgbe(4) on powerpc64 too. r277637: Make sure the compiler flag to get cxgbe(4) to compile with gcc is used only when gcc is being used. This is what r277225 should have been. diff 284052 Sat Jun 06 09:35:14 MDT 2015 np MFC r276480, r276485, r276498, r277225, r277226, r277227, r277230, r277637, and r283149 (by emaste@). r276485 is the real change here, the rest deal with the fallout of mp_ring's reliance on 64b atomics. Use the incorrectly spelled 'eigth' from struct pkthdr in this branch instead of MFC'ing r261733, which would have renamed the field of a public structure in a -STABLE branch. --- r276480: Temporarily unplug cxgbe(4) from !amd64 builds. r276485: cxgbe(4): major tx rework. a) Front load as much work as possible in if_transmit, before any driver lock or software queue has to get involved. b) Replace buf_ring with a brand new mp_ring (multiproducer ring). This is specifically for the tx multiqueue model where one of the if_transmit producer threads becomes the consumer and other producers carry on as usual. mp_ring is implemented as standalone code and it should be possible to use it in any driver with tx multiqueue. It also has: - the ability to enqueue/dequeue multiple items. This might become significant if packet batching is ever implemented. - an abdication mechanism to allow a thread to give up writing tx descriptors and have another if_transmit thread take over. A thread that's writing tx descriptors can end up doing so for an unbounded time period if a) there are other if_transmit threads continuously feeding the sofware queue, and b) the chip keeps up with whatever the thread is throwing at it. - accurate statistics about interesting events even when the stats come at the expense of additional branches/conditional code. The NIC txq lock is uncontested on the fast path at this point. I've left it there for synchronization with the control events (interface up/down, modload/unload). c) Add support for "type 1" coalescing work request in the normal NIC tx path. This work request is optimized for frames with a single item in the DMA gather list. These are very common when forwarding packets. Note that netmap tx in cxgbe already uses these "type 1" work requests. d) Do not request automatic cidx updates every 32 descriptors. Instead, request updates via bits in individual work requests (still every 32 descriptors approximately). Also, request an automatic final update when the queue idles after activity. This means NIC tx reclaim is still performed lazily but it will catch up quickly as soon as the queue idles. This seems to be the best middle ground and I'll probably do something similar for netmap tx as well. e) Implement a faster tx path for WRQs (used by TOE tx and control queues, _not_ by the normal NIC tx). Allow work requests to be written directly to the hardware descriptor ring if room is available. I will convert t4_tom and iw_cxgbe modules to this faster style gradually. r276498: cxgbe(4): remove buf_ring specific restriction on the txq size. r277225: Make cxgbe(4) buildable with the gcc in base. r277226: Allow cxgbe(4) to be built on i386. Driver attach will succeed only on a subset of i386 systems. r277227: Plug cxgbe(4) back into !powerpc && !arm builds, instead of building it on amd64 only. r277230: Build cxgbe(4) on powerpc64 too. r277637: Make sure the compiler flag to get cxgbe(4) to compile with gcc is used only when gcc is being used. This is what r277225 should have been. diff 284052 Sat Jun 06 09:35:14 MDT 2015 np MFC r276480, r276485, r276498, r277225, r277226, r277227, r277230, r277637, and r283149 (by emaste@). r276485 is the real change here, the rest deal with the fallout of mp_ring's reliance on 64b atomics. Use the incorrectly spelled 'eigth' from struct pkthdr in this branch instead of MFC'ing r261733, which would have renamed the field of a public structure in a -STABLE branch. --- r276480: Temporarily unplug cxgbe(4) from !amd64 builds. r276485: cxgbe(4): major tx rework. a) Front load as much work as possible in if_transmit, before any driver lock or software queue has to get involved. b) Replace buf_ring with a brand new mp_ring (multiproducer ring). This is specifically for the tx multiqueue model where one of the if_transmit producer threads becomes the consumer and other producers carry on as usual. mp_ring is implemented as standalone code and it should be possible to use it in any driver with tx multiqueue. It also has: - the ability to enqueue/dequeue multiple items. This might become significant if packet batching is ever implemented. - an abdication mechanism to allow a thread to give up writing tx descriptors and have another if_transmit thread take over. A thread that's writing tx descriptors can end up doing so for an unbounded time period if a) there are other if_transmit threads continuously feeding the sofware queue, and b) the chip keeps up with whatever the thread is throwing at it. - accurate statistics about interesting events even when the stats come at the expense of additional branches/conditional code. The NIC txq lock is uncontested on the fast path at this point. I've left it there for synchronization with the control events (interface up/down, modload/unload). c) Add support for "type 1" coalescing work request in the normal NIC tx path. This work request is optimized for frames with a single item in the DMA gather list. These are very common when forwarding packets. Note that netmap tx in cxgbe already uses these "type 1" work requests. d) Do not request automatic cidx updates every 32 descriptors. Instead, request updates via bits in individual work requests (still every 32 descriptors approximately). Also, request an automatic final update when the queue idles after activity. This means NIC tx reclaim is still performed lazily but it will catch up quickly as soon as the queue idles. This seems to be the best middle ground and I'll probably do something similar for netmap tx as well. e) Implement a faster tx path for WRQs (used by TOE tx and control queues, _not_ by the normal NIC tx). Allow work requests to be written directly to the hardware descriptor ring if room is available. I will convert t4_tom and iw_cxgbe modules to this faster style gradually. r276498: cxgbe(4): remove buf_ring specific restriction on the txq size. r277225: Make cxgbe(4) buildable with the gcc in base. r277226: Allow cxgbe(4) to be built on i386. Driver attach will succeed only on a subset of i386 systems. r277227: Plug cxgbe(4) back into !powerpc && !arm builds, instead of building it on amd64 only. r277230: Build cxgbe(4) on powerpc64 too. r277637: Make sure the compiler flag to get cxgbe(4) to compile with gcc is used only when gcc is being used. This is what r277225 should have been. diff 284052 Sat Jun 06 09:35:14 MDT 2015 np MFC r276480, r276485, r276498, r277225, r277226, r277227, r277230, r277637, and r283149 (by emaste@). r276485 is the real change here, the rest deal with the fallout of mp_ring's reliance on 64b atomics. Use the incorrectly spelled 'eigth' from struct pkthdr in this branch instead of MFC'ing r261733, which would have renamed the field of a public structure in a -STABLE branch. --- r276480: Temporarily unplug cxgbe(4) from !amd64 builds. r276485: cxgbe(4): major tx rework. a) Front load as much work as possible in if_transmit, before any driver lock or software queue has to get involved. b) Replace buf_ring with a brand new mp_ring (multiproducer ring). This is specifically for the tx multiqueue model where one of the if_transmit producer threads becomes the consumer and other producers carry on as usual. mp_ring is implemented as standalone code and it should be possible to use it in any driver with tx multiqueue. It also has: - the ability to enqueue/dequeue multiple items. This might become significant if packet batching is ever implemented. - an abdication mechanism to allow a thread to give up writing tx descriptors and have another if_transmit thread take over. A thread that's writing tx descriptors can end up doing so for an unbounded time period if a) there are other if_transmit threads continuously feeding the sofware queue, and b) the chip keeps up with whatever the thread is throwing at it. - accurate statistics about interesting events even when the stats come at the expense of additional branches/conditional code. The NIC txq lock is uncontested on the fast path at this point. I've left it there for synchronization with the control events (interface up/down, modload/unload). c) Add support for "type 1" coalescing work request in the normal NIC tx path. This work request is optimized for frames with a single item in the DMA gather list. These are very common when forwarding packets. Note that netmap tx in cxgbe already uses these "type 1" work requests. d) Do not request automatic cidx updates every 32 descriptors. Instead, request updates via bits in individual work requests (still every 32 descriptors approximately). Also, request an automatic final update when the queue idles after activity. This means NIC tx reclaim is still performed lazily but it will catch up quickly as soon as the queue idles. This seems to be the best middle ground and I'll probably do something similar for netmap tx as well. e) Implement a faster tx path for WRQs (used by TOE tx and control queues, _not_ by the normal NIC tx). Allow work requests to be written directly to the hardware descriptor ring if room is available. I will convert t4_tom and iw_cxgbe modules to this faster style gradually. r276498: cxgbe(4): remove buf_ring specific restriction on the txq size. r277225: Make cxgbe(4) buildable with the gcc in base. r277226: Allow cxgbe(4) to be built on i386. Driver attach will succeed only on a subset of i386 systems. r277227: Plug cxgbe(4) back into !powerpc && !arm builds, instead of building it on amd64 only. r277230: Build cxgbe(4) on powerpc64 too. r277637: Make sure the compiler flag to get cxgbe(4) to compile with gcc is used only when gcc is being used. This is what r277225 should have been. diff 284052 Sat Jun 06 09:35:14 MDT 2015 np MFC r276480, r276485, r276498, r277225, r277226, r277227, r277230, r277637, and r283149 (by emaste@). r276485 is the real change here, the rest deal with the fallout of mp_ring's reliance on 64b atomics. Use the incorrectly spelled 'eigth' from struct pkthdr in this branch instead of MFC'ing r261733, which would have renamed the field of a public structure in a -STABLE branch. --- r276480: Temporarily unplug cxgbe(4) from !amd64 builds. r276485: cxgbe(4): major tx rework. a) Front load as much work as possible in if_transmit, before any driver lock or software queue has to get involved. b) Replace buf_ring with a brand new mp_ring (multiproducer ring). This is specifically for the tx multiqueue model where one of the if_transmit producer threads becomes the consumer and other producers carry on as usual. mp_ring is implemented as standalone code and it should be possible to use it in any driver with tx multiqueue. It also has: - the ability to enqueue/dequeue multiple items. This might become significant if packet batching is ever implemented. - an abdication mechanism to allow a thread to give up writing tx descriptors and have another if_transmit thread take over. A thread that's writing tx descriptors can end up doing so for an unbounded time period if a) there are other if_transmit threads continuously feeding the sofware queue, and b) the chip keeps up with whatever the thread is throwing at it. - accurate statistics about interesting events even when the stats come at the expense of additional branches/conditional code. The NIC txq lock is uncontested on the fast path at this point. I've left it there for synchronization with the control events (interface up/down, modload/unload). c) Add support for "type 1" coalescing work request in the normal NIC tx path. This work request is optimized for frames with a single item in the DMA gather list. These are very common when forwarding packets. Note that netmap tx in cxgbe already uses these "type 1" work requests. d) Do not request automatic cidx updates every 32 descriptors. Instead, request updates via bits in individual work requests (still every 32 descriptors approximately). Also, request an automatic final update when the queue idles after activity. This means NIC tx reclaim is still performed lazily but it will catch up quickly as soon as the queue idles. This seems to be the best middle ground and I'll probably do something similar for netmap tx as well. e) Implement a faster tx path for WRQs (used by TOE tx and control queues, _not_ by the normal NIC tx). Allow work requests to be written directly to the hardware descriptor ring if room is available. I will convert t4_tom and iw_cxgbe modules to this faster style gradually. r276498: cxgbe(4): remove buf_ring specific restriction on the txq size. r277225: Make cxgbe(4) buildable with the gcc in base. r277226: Allow cxgbe(4) to be built on i386. Driver attach will succeed only on a subset of i386 systems. r277227: Plug cxgbe(4) back into !powerpc && !arm builds, instead of building it on amd64 only. r277230: Build cxgbe(4) on powerpc64 too. r277637: Make sure the compiler flag to get cxgbe(4) to compile with gcc is used only when gcc is being used. This is what r277225 should have been. |
H A D | t4_l2t.c | diff 284052 Sat Jun 06 09:35:14 MDT 2015 np MFC r276480, r276485, r276498, r277225, r277226, r277227, r277230, r277637, and r283149 (by emaste@). r276485 is the real change here, the rest deal with the fallout of mp_ring's reliance on 64b atomics. Use the incorrectly spelled 'eigth' from struct pkthdr in this branch instead of MFC'ing r261733, which would have renamed the field of a public structure in a -STABLE branch. --- r276480: Temporarily unplug cxgbe(4) from !amd64 builds. r276485: cxgbe(4): major tx rework. a) Front load as much work as possible in if_transmit, before any driver lock or software queue has to get involved. b) Replace buf_ring with a brand new mp_ring (multiproducer ring). This is specifically for the tx multiqueue model where one of the if_transmit producer threads becomes the consumer and other producers carry on as usual. mp_ring is implemented as standalone code and it should be possible to use it in any driver with tx multiqueue. It also has: - the ability to enqueue/dequeue multiple items. This might become significant if packet batching is ever implemented. - an abdication mechanism to allow a thread to give up writing tx descriptors and have another if_transmit thread take over. A thread that's writing tx descriptors can end up doing so for an unbounded time period if a) there are other if_transmit threads continuously feeding the sofware queue, and b) the chip keeps up with whatever the thread is throwing at it. - accurate statistics about interesting events even when the stats come at the expense of additional branches/conditional code. The NIC txq lock is uncontested on the fast path at this point. I've left it there for synchronization with the control events (interface up/down, modload/unload). c) Add support for "type 1" coalescing work request in the normal NIC tx path. This work request is optimized for frames with a single item in the DMA gather list. These are very common when forwarding packets. Note that netmap tx in cxgbe already uses these "type 1" work requests. d) Do not request automatic cidx updates every 32 descriptors. Instead, request updates via bits in individual work requests (still every 32 descriptors approximately). Also, request an automatic final update when the queue idles after activity. This means NIC tx reclaim is still performed lazily but it will catch up quickly as soon as the queue idles. This seems to be the best middle ground and I'll probably do something similar for netmap tx as well. e) Implement a faster tx path for WRQs (used by TOE tx and control queues, _not_ by the normal NIC tx). Allow work requests to be written directly to the hardware descriptor ring if room is available. I will convert t4_tom and iw_cxgbe modules to this faster style gradually. r276498: cxgbe(4): remove buf_ring specific restriction on the txq size. r277225: Make cxgbe(4) buildable with the gcc in base. r277226: Allow cxgbe(4) to be built on i386. Driver attach will succeed only on a subset of i386 systems. r277227: Plug cxgbe(4) back into !powerpc && !arm builds, instead of building it on amd64 only. r277230: Build cxgbe(4) on powerpc64 too. r277637: Make sure the compiler flag to get cxgbe(4) to compile with gcc is used only when gcc is being used. This is what r277225 should have been. diff 284052 Sat Jun 06 09:35:14 MDT 2015 np MFC r276480, r276485, r276498, r277225, r277226, r277227, r277230, r277637, and r283149 (by emaste@). r276485 is the real change here, the rest deal with the fallout of mp_ring's reliance on 64b atomics. Use the incorrectly spelled 'eigth' from struct pkthdr in this branch instead of MFC'ing r261733, which would have renamed the field of a public structure in a -STABLE branch. --- r276480: Temporarily unplug cxgbe(4) from !amd64 builds. r276485: cxgbe(4): major tx rework. a) Front load as much work as possible in if_transmit, before any driver lock or software queue has to get involved. b) Replace buf_ring with a brand new mp_ring (multiproducer ring). This is specifically for the tx multiqueue model where one of the if_transmit producer threads becomes the consumer and other producers carry on as usual. mp_ring is implemented as standalone code and it should be possible to use it in any driver with tx multiqueue. It also has: - the ability to enqueue/dequeue multiple items. This might become significant if packet batching is ever implemented. - an abdication mechanism to allow a thread to give up writing tx descriptors and have another if_transmit thread take over. A thread that's writing tx descriptors can end up doing so for an unbounded time period if a) there are other if_transmit threads continuously feeding the sofware queue, and b) the chip keeps up with whatever the thread is throwing at it. - accurate statistics about interesting events even when the stats come at the expense of additional branches/conditional code. The NIC txq lock is uncontested on the fast path at this point. I've left it there for synchronization with the control events (interface up/down, modload/unload). c) Add support for "type 1" coalescing work request in the normal NIC tx path. This work request is optimized for frames with a single item in the DMA gather list. These are very common when forwarding packets. Note that netmap tx in cxgbe already uses these "type 1" work requests. d) Do not request automatic cidx updates every 32 descriptors. Instead, request updates via bits in individual work requests (still every 32 descriptors approximately). Also, request an automatic final update when the queue idles after activity. This means NIC tx reclaim is still performed lazily but it will catch up quickly as soon as the queue idles. This seems to be the best middle ground and I'll probably do something similar for netmap tx as well. e) Implement a faster tx path for WRQs (used by TOE tx and control queues, _not_ by the normal NIC tx). Allow work requests to be written directly to the hardware descriptor ring if room is available. I will convert t4_tom and iw_cxgbe modules to this faster style gradually. r276498: cxgbe(4): remove buf_ring specific restriction on the txq size. r277225: Make cxgbe(4) buildable with the gcc in base. r277226: Allow cxgbe(4) to be built on i386. Driver attach will succeed only on a subset of i386 systems. r277227: Plug cxgbe(4) back into !powerpc && !arm builds, instead of building it on amd64 only. r277230: Build cxgbe(4) on powerpc64 too. r277637: Make sure the compiler flag to get cxgbe(4) to compile with gcc is used only when gcc is being used. This is what r277225 should have been. diff 284052 Sat Jun 06 09:35:14 MDT 2015 np MFC r276480, r276485, r276498, r277225, r277226, r277227, r277230, r277637, and r283149 (by emaste@). r276485 is the real change here, the rest deal with the fallout of mp_ring's reliance on 64b atomics. Use the incorrectly spelled 'eigth' from struct pkthdr in this branch instead of MFC'ing r261733, which would have renamed the field of a public structure in a -STABLE branch. --- r276480: Temporarily unplug cxgbe(4) from !amd64 builds. r276485: cxgbe(4): major tx rework. a) Front load as much work as possible in if_transmit, before any driver lock or software queue has to get involved. b) Replace buf_ring with a brand new mp_ring (multiproducer ring). This is specifically for the tx multiqueue model where one of the if_transmit producer threads becomes the consumer and other producers carry on as usual. mp_ring is implemented as standalone code and it should be possible to use it in any driver with tx multiqueue. It also has: - the ability to enqueue/dequeue multiple items. This might become significant if packet batching is ever implemented. - an abdication mechanism to allow a thread to give up writing tx descriptors and have another if_transmit thread take over. A thread that's writing tx descriptors can end up doing so for an unbounded time period if a) there are other if_transmit threads continuously feeding the sofware queue, and b) the chip keeps up with whatever the thread is throwing at it. - accurate statistics about interesting events even when the stats come at the expense of additional branches/conditional code. The NIC txq lock is uncontested on the fast path at this point. I've left it there for synchronization with the control events (interface up/down, modload/unload). c) Add support for "type 1" coalescing work request in the normal NIC tx path. This work request is optimized for frames with a single item in the DMA gather list. These are very common when forwarding packets. Note that netmap tx in cxgbe already uses these "type 1" work requests. d) Do not request automatic cidx updates every 32 descriptors. Instead, request updates via bits in individual work requests (still every 32 descriptors approximately). Also, request an automatic final update when the queue idles after activity. This means NIC tx reclaim is still performed lazily but it will catch up quickly as soon as the queue idles. This seems to be the best middle ground and I'll probably do something similar for netmap tx as well. e) Implement a faster tx path for WRQs (used by TOE tx and control queues, _not_ by the normal NIC tx). Allow work requests to be written directly to the hardware descriptor ring if room is available. I will convert t4_tom and iw_cxgbe modules to this faster style gradually. r276498: cxgbe(4): remove buf_ring specific restriction on the txq size. r277225: Make cxgbe(4) buildable with the gcc in base. r277226: Allow cxgbe(4) to be built on i386. Driver attach will succeed only on a subset of i386 systems. r277227: Plug cxgbe(4) back into !powerpc && !arm builds, instead of building it on amd64 only. r277230: Build cxgbe(4) on powerpc64 too. r277637: Make sure the compiler flag to get cxgbe(4) to compile with gcc is used only when gcc is being used. This is what r277225 should have been. diff 284052 Sat Jun 06 09:35:14 MDT 2015 np MFC r276480, r276485, r276498, r277225, r277226, r277227, r277230, r277637, and r283149 (by emaste@). r276485 is the real change here, the rest deal with the fallout of mp_ring's reliance on 64b atomics. Use the incorrectly spelled 'eigth' from struct pkthdr in this branch instead of MFC'ing r261733, which would have renamed the field of a public structure in a -STABLE branch. --- r276480: Temporarily unplug cxgbe(4) from !amd64 builds. r276485: cxgbe(4): major tx rework. a) Front load as much work as possible in if_transmit, before any driver lock or software queue has to get involved. b) Replace buf_ring with a brand new mp_ring (multiproducer ring). This is specifically for the tx multiqueue model where one of the if_transmit producer threads becomes the consumer and other producers carry on as usual. mp_ring is implemented as standalone code and it should be possible to use it in any driver with tx multiqueue. It also has: - the ability to enqueue/dequeue multiple items. This might become significant if packet batching is ever implemented. - an abdication mechanism to allow a thread to give up writing tx descriptors and have another if_transmit thread take over. A thread that's writing tx descriptors can end up doing so for an unbounded time period if a) there are other if_transmit threads continuously feeding the sofware queue, and b) the chip keeps up with whatever the thread is throwing at it. - accurate statistics about interesting events even when the stats come at the expense of additional branches/conditional code. The NIC txq lock is uncontested on the fast path at this point. I've left it there for synchronization with the control events (interface up/down, modload/unload). c) Add support for "type 1" coalescing work request in the normal NIC tx path. This work request is optimized for frames with a single item in the DMA gather list. These are very common when forwarding packets. Note that netmap tx in cxgbe already uses these "type 1" work requests. d) Do not request automatic cidx updates every 32 descriptors. Instead, request updates via bits in individual work requests (still every 32 descriptors approximately). Also, request an automatic final update when the queue idles after activity. This means NIC tx reclaim is still performed lazily but it will catch up quickly as soon as the queue idles. This seems to be the best middle ground and I'll probably do something similar for netmap tx as well. e) Implement a faster tx path for WRQs (used by TOE tx and control queues, _not_ by the normal NIC tx). Allow work requests to be written directly to the hardware descriptor ring if room is available. I will convert t4_tom and iw_cxgbe modules to this faster style gradually. r276498: cxgbe(4): remove buf_ring specific restriction on the txq size. r277225: Make cxgbe(4) buildable with the gcc in base. r277226: Allow cxgbe(4) to be built on i386. Driver attach will succeed only on a subset of i386 systems. r277227: Plug cxgbe(4) back into !powerpc && !arm builds, instead of building it on amd64 only. r277230: Build cxgbe(4) on powerpc64 too. r277637: Make sure the compiler flag to get cxgbe(4) to compile with gcc is used only when gcc is being used. This is what r277225 should have been. diff 284052 Sat Jun 06 09:35:14 MDT 2015 np MFC r276480, r276485, r276498, r277225, r277226, r277227, r277230, r277637, and r283149 (by emaste@). r276485 is the real change here, the rest deal with the fallout of mp_ring's reliance on 64b atomics. Use the incorrectly spelled 'eigth' from struct pkthdr in this branch instead of MFC'ing r261733, which would have renamed the field of a public structure in a -STABLE branch. --- r276480: Temporarily unplug cxgbe(4) from !amd64 builds. r276485: cxgbe(4): major tx rework. a) Front load as much work as possible in if_transmit, before any driver lock or software queue has to get involved. b) Replace buf_ring with a brand new mp_ring (multiproducer ring). This is specifically for the tx multiqueue model where one of the if_transmit producer threads becomes the consumer and other producers carry on as usual. mp_ring is implemented as standalone code and it should be possible to use it in any driver with tx multiqueue. It also has: - the ability to enqueue/dequeue multiple items. This might become significant if packet batching is ever implemented. - an abdication mechanism to allow a thread to give up writing tx descriptors and have another if_transmit thread take over. A thread that's writing tx descriptors can end up doing so for an unbounded time period if a) there are other if_transmit threads continuously feeding the sofware queue, and b) the chip keeps up with whatever the thread is throwing at it. - accurate statistics about interesting events even when the stats come at the expense of additional branches/conditional code. The NIC txq lock is uncontested on the fast path at this point. I've left it there for synchronization with the control events (interface up/down, modload/unload). c) Add support for "type 1" coalescing work request in the normal NIC tx path. This work request is optimized for frames with a single item in the DMA gather list. These are very common when forwarding packets. Note that netmap tx in cxgbe already uses these "type 1" work requests. d) Do not request automatic cidx updates every 32 descriptors. Instead, request updates via bits in individual work requests (still every 32 descriptors approximately). Also, request an automatic final update when the queue idles after activity. This means NIC tx reclaim is still performed lazily but it will catch up quickly as soon as the queue idles. This seems to be the best middle ground and I'll probably do something similar for netmap tx as well. e) Implement a faster tx path for WRQs (used by TOE tx and control queues, _not_ by the normal NIC tx). Allow work requests to be written directly to the hardware descriptor ring if room is available. I will convert t4_tom and iw_cxgbe modules to this faster style gradually. r276498: cxgbe(4): remove buf_ring specific restriction on the txq size. r277225: Make cxgbe(4) buildable with the gcc in base. r277226: Allow cxgbe(4) to be built on i386. Driver attach will succeed only on a subset of i386 systems. r277227: Plug cxgbe(4) back into !powerpc && !arm builds, instead of building it on amd64 only. r277230: Build cxgbe(4) on powerpc64 too. r277637: Make sure the compiler flag to get cxgbe(4) to compile with gcc is used only when gcc is being used. This is what r277225 should have been. diff 284052 Sat Jun 06 09:35:14 MDT 2015 np MFC r276480, r276485, r276498, r277225, r277226, r277227, r277230, r277637, and r283149 (by emaste@). r276485 is the real change here, the rest deal with the fallout of mp_ring's reliance on 64b atomics. Use the incorrectly spelled 'eigth' from struct pkthdr in this branch instead of MFC'ing r261733, which would have renamed the field of a public structure in a -STABLE branch. --- r276480: Temporarily unplug cxgbe(4) from !amd64 builds. r276485: cxgbe(4): major tx rework. a) Front load as much work as possible in if_transmit, before any driver lock or software queue has to get involved. b) Replace buf_ring with a brand new mp_ring (multiproducer ring). This is specifically for the tx multiqueue model where one of the if_transmit producer threads becomes the consumer and other producers carry on as usual. mp_ring is implemented as standalone code and it should be possible to use it in any driver with tx multiqueue. It also has: - the ability to enqueue/dequeue multiple items. This might become significant if packet batching is ever implemented. - an abdication mechanism to allow a thread to give up writing tx descriptors and have another if_transmit thread take over. A thread that's writing tx descriptors can end up doing so for an unbounded time period if a) there are other if_transmit threads continuously feeding the sofware queue, and b) the chip keeps up with whatever the thread is throwing at it. - accurate statistics about interesting events even when the stats come at the expense of additional branches/conditional code. The NIC txq lock is uncontested on the fast path at this point. I've left it there for synchronization with the control events (interface up/down, modload/unload). c) Add support for "type 1" coalescing work request in the normal NIC tx path. This work request is optimized for frames with a single item in the DMA gather list. These are very common when forwarding packets. Note that netmap tx in cxgbe already uses these "type 1" work requests. d) Do not request automatic cidx updates every 32 descriptors. Instead, request updates via bits in individual work requests (still every 32 descriptors approximately). Also, request an automatic final update when the queue idles after activity. This means NIC tx reclaim is still performed lazily but it will catch up quickly as soon as the queue idles. This seems to be the best middle ground and I'll probably do something similar for netmap tx as well. e) Implement a faster tx path for WRQs (used by TOE tx and control queues, _not_ by the normal NIC tx). Allow work requests to be written directly to the hardware descriptor ring if room is available. I will convert t4_tom and iw_cxgbe modules to this faster style gradually. r276498: cxgbe(4): remove buf_ring specific restriction on the txq size. r277225: Make cxgbe(4) buildable with the gcc in base. r277226: Allow cxgbe(4) to be built on i386. Driver attach will succeed only on a subset of i386 systems. r277227: Plug cxgbe(4) back into !powerpc && !arm builds, instead of building it on amd64 only. r277230: Build cxgbe(4) on powerpc64 too. r277637: Make sure the compiler flag to get cxgbe(4) to compile with gcc is used only when gcc is being used. This is what r277225 should have been. diff 284052 Sat Jun 06 09:35:14 MDT 2015 np MFC r276480, r276485, r276498, r277225, r277226, r277227, r277230, r277637, and r283149 (by emaste@). r276485 is the real change here, the rest deal with the fallout of mp_ring's reliance on 64b atomics. Use the incorrectly spelled 'eigth' from struct pkthdr in this branch instead of MFC'ing r261733, which would have renamed the field of a public structure in a -STABLE branch. --- r276480: Temporarily unplug cxgbe(4) from !amd64 builds. r276485: cxgbe(4): major tx rework. a) Front load as much work as possible in if_transmit, before any driver lock or software queue has to get involved. b) Replace buf_ring with a brand new mp_ring (multiproducer ring). This is specifically for the tx multiqueue model where one of the if_transmit producer threads becomes the consumer and other producers carry on as usual. mp_ring is implemented as standalone code and it should be possible to use it in any driver with tx multiqueue. It also has: - the ability to enqueue/dequeue multiple items. This might become significant if packet batching is ever implemented. - an abdication mechanism to allow a thread to give up writing tx descriptors and have another if_transmit thread take over. A thread that's writing tx descriptors can end up doing so for an unbounded time period if a) there are other if_transmit threads continuously feeding the sofware queue, and b) the chip keeps up with whatever the thread is throwing at it. - accurate statistics about interesting events even when the stats come at the expense of additional branches/conditional code. The NIC txq lock is uncontested on the fast path at this point. I've left it there for synchronization with the control events (interface up/down, modload/unload). c) Add support for "type 1" coalescing work request in the normal NIC tx path. This work request is optimized for frames with a single item in the DMA gather list. These are very common when forwarding packets. Note that netmap tx in cxgbe already uses these "type 1" work requests. d) Do not request automatic cidx updates every 32 descriptors. Instead, request updates via bits in individual work requests (still every 32 descriptors approximately). Also, request an automatic final update when the queue idles after activity. This means NIC tx reclaim is still performed lazily but it will catch up quickly as soon as the queue idles. This seems to be the best middle ground and I'll probably do something similar for netmap tx as well. e) Implement a faster tx path for WRQs (used by TOE tx and control queues, _not_ by the normal NIC tx). Allow work requests to be written directly to the hardware descriptor ring if room is available. I will convert t4_tom and iw_cxgbe modules to this faster style gradually. r276498: cxgbe(4): remove buf_ring specific restriction on the txq size. r277225: Make cxgbe(4) buildable with the gcc in base. r277226: Allow cxgbe(4) to be built on i386. Driver attach will succeed only on a subset of i386 systems. r277227: Plug cxgbe(4) back into !powerpc && !arm builds, instead of building it on amd64 only. r277230: Build cxgbe(4) on powerpc64 too. r277637: Make sure the compiler flag to get cxgbe(4) to compile with gcc is used only when gcc is being used. This is what r277225 should have been. diff 284052 Sat Jun 06 09:35:14 MDT 2015 np MFC r276480, r276485, r276498, r277225, r277226, r277227, r277230, r277637, and r283149 (by emaste@). r276485 is the real change here, the rest deal with the fallout of mp_ring's reliance on 64b atomics. Use the incorrectly spelled 'eigth' from struct pkthdr in this branch instead of MFC'ing r261733, which would have renamed the field of a public structure in a -STABLE branch. --- r276480: Temporarily unplug cxgbe(4) from !amd64 builds. r276485: cxgbe(4): major tx rework. a) Front load as much work as possible in if_transmit, before any driver lock or software queue has to get involved. b) Replace buf_ring with a brand new mp_ring (multiproducer ring). This is specifically for the tx multiqueue model where one of the if_transmit producer threads becomes the consumer and other producers carry on as usual. mp_ring is implemented as standalone code and it should be possible to use it in any driver with tx multiqueue. It also has: - the ability to enqueue/dequeue multiple items. This might become significant if packet batching is ever implemented. - an abdication mechanism to allow a thread to give up writing tx descriptors and have another if_transmit thread take over. A thread that's writing tx descriptors can end up doing so for an unbounded time period if a) there are other if_transmit threads continuously feeding the sofware queue, and b) the chip keeps up with whatever the thread is throwing at it. - accurate statistics about interesting events even when the stats come at the expense of additional branches/conditional code. The NIC txq lock is uncontested on the fast path at this point. I've left it there for synchronization with the control events (interface up/down, modload/unload). c) Add support for "type 1" coalescing work request in the normal NIC tx path. This work request is optimized for frames with a single item in the DMA gather list. These are very common when forwarding packets. Note that netmap tx in cxgbe already uses these "type 1" work requests. d) Do not request automatic cidx updates every 32 descriptors. Instead, request updates via bits in individual work requests (still every 32 descriptors approximately). Also, request an automatic final update when the queue idles after activity. This means NIC tx reclaim is still performed lazily but it will catch up quickly as soon as the queue idles. This seems to be the best middle ground and I'll probably do something similar for netmap tx as well. e) Implement a faster tx path for WRQs (used by TOE tx and control queues, _not_ by the normal NIC tx). Allow work requests to be written directly to the hardware descriptor ring if room is available. I will convert t4_tom and iw_cxgbe modules to this faster style gradually. r276498: cxgbe(4): remove buf_ring specific restriction on the txq size. r277225: Make cxgbe(4) buildable with the gcc in base. r277226: Allow cxgbe(4) to be built on i386. Driver attach will succeed only on a subset of i386 systems. r277227: Plug cxgbe(4) back into !powerpc && !arm builds, instead of building it on amd64 only. r277230: Build cxgbe(4) on powerpc64 too. r277637: Make sure the compiler flag to get cxgbe(4) to compile with gcc is used only when gcc is being used. This is what r277225 should have been. diff 245434 Mon Jan 14 20:46:44 MST 2013 np cxgbe(4): Updates to the hardware L2 table management code. - Add full support for IPv6 addresses. - Read the size of the L2 table during attach. Do not assume that PCIe physical function 4 of the card has all of the table to itself. - Use FNV instead of Jenkins to hash L3 addresses and drop the private copy of jhash.h from the driver. MFC after: 1 week diff 245434 Mon Jan 14 20:46:44 MST 2013 np cxgbe(4): Updates to the hardware L2 table management code. - Add full support for IPv6 addresses. - Read the size of the L2 table during attach. Do not assume that PCIe physical function 4 of the card has all of the table to itself. - Use FNV instead of Jenkins to hash L3 addresses and drop the private copy of jhash.h from the driver. MFC after: 1 week |
/freebsd-10.2-release/sys/dev/puc/ | ||
H A D | puc.c | diff 158124 Fri Apr 28 21:21:53 MDT 2006 marcel Rewrite of puc(4). Significant changes are: o Properly use rman(9) to manage resources. This eliminates the need to puc-specific hacks to rman. It also allows devinfo(8) to be used to find out the specific assignment of resources to serial/parallel ports. o Compress the PCI device "database" by optimizing for the common case and to use a procedural interface to handle the exceptions. The procedural interface also generalizes the need to setup the hardware (program chipsets, program clock frequencies). o Eliminate the need for PUC_FASTINTR. Serdev devices are fast by default and non-serdev devices are handled by the bus. o Use the serdev I/F to collect interrupt status and to handle interrupts across ports in priority order. o Sync the PCI device configuration to include devices found in NetBSD and not yet merged to FreeBSD. o Add support for Quatech 2, 4 and 8 port UARTs. o Add support for a couple dozen Timedia serial cards as found in Linux. diff 158124 Fri Apr 28 21:21:53 MDT 2006 marcel Rewrite of puc(4). Significant changes are: o Properly use rman(9) to manage resources. This eliminates the need to puc-specific hacks to rman. It also allows devinfo(8) to be used to find out the specific assignment of resources to serial/parallel ports. o Compress the PCI device "database" by optimizing for the common case and to use a procedural interface to handle the exceptions. The procedural interface also generalizes the need to setup the hardware (program chipsets, program clock frequencies). o Eliminate the need for PUC_FASTINTR. Serdev devices are fast by default and non-serdev devices are handled by the bus. o Use the serdev I/F to collect interrupt status and to handle interrupts across ports in priority order. o Sync the PCI device configuration to include devices found in NetBSD and not yet merged to FreeBSD. o Add support for Quatech 2, 4 and 8 port UARTs. o Add support for a couple dozen Timedia serial cards as found in Linux. diff 152662 Mon Nov 21 20:22:35 MST 2005 jhb Don't enable PUC_FASTINTR by default in the source. Instead, enable it via the DEFAULTS kernel configs. This allows folks to turn it that option off in the kernel configs if desired without having to hack the source. This is especially useful since PUC_FASTINTR hangs the kernel boot on my ultra60 which has two uart(4) devices hung off of a puc(4) device. I did not enable PUC_FASTINTR by default on powerpc since powerpc does not currently allow sharing of INTR_FAST with non-INTR_FAST like the other archs. diff 152662 Mon Nov 21 20:22:35 MST 2005 jhb Don't enable PUC_FASTINTR by default in the source. Instead, enable it via the DEFAULTS kernel configs. This allows folks to turn it that option off in the kernel configs if desired without having to hack the source. This is especially useful since PUC_FASTINTR hangs the kernel boot on my ultra60 which has two uart(4) devices hung off of a puc(4) device. I did not enable PUC_FASTINTR by default on powerpc since powerpc does not currently allow sharing of INTR_FAST with non-INTR_FAST like the other archs. diff 150698 Wed Sep 28 18:06:25 MDT 2005 phk puc(4) does strange things to resources in order to fool the subdrivers to hook up. It should probably be rewritten to implement a simple bus to which the sub drivers attach using some kind of hint. Until then, provide a couple of crutch functions with big warning signs so it can survive the recent changes to struct resource. diff 143142 Fri Mar 04 22:23:21 MST 2005 marius - sparc64/fhc/fhc.c: Change fhc(4) to use IRQ numbers instead of RIDs for allocating the IRQs of children. This works similar to e.g. sbus(4), i.e. add the IRQ resources as fully specified to the resource lists of the children, allocate them like normal. When establishing the interrupt search the interrupt maps of the children for a matching INO to determine which map we need to write the fully specified interrupt number to and to enable the mapping (before the RID was used to indicate which interrupt map to use). - dev/puc/puc.c: Revert rev. 1.38, with the above change fhc(4) no longer needs special treatment for allocating IRQs. Thanks to: joerg for providing access to an E3500 diff 143142 Fri Mar 04 22:23:21 MST 2005 marius - sparc64/fhc/fhc.c: Change fhc(4) to use IRQ numbers instead of RIDs for allocating the IRQs of children. This works similar to e.g. sbus(4), i.e. add the IRQ resources as fully specified to the resource lists of the children, allocate them like normal. When establishing the interrupt search the interrupt maps of the children for a matching INO to determine which map we need to write the fully specified interrupt number to and to enable the mapping (before the RID was used to indicate which interrupt map to use). - dev/puc/puc.c: Revert rev. 1.38, with the above change fhc(4) no longer needs special treatment for allocating IRQs. Thanks to: joerg for providing access to an E3500 diff 143142 Fri Mar 04 22:23:21 MST 2005 marius - sparc64/fhc/fhc.c: Change fhc(4) to use IRQ numbers instead of RIDs for allocating the IRQs of children. This works similar to e.g. sbus(4), i.e. add the IRQ resources as fully specified to the resource lists of the children, allocate them like normal. When establishing the interrupt search the interrupt maps of the children for a matching INO to determine which map we need to write the fully specified interrupt number to and to enable the mapping (before the RID was used to indicate which interrupt map to use). - dev/puc/puc.c: Revert rev. 1.38, with the above change fhc(4) no longer needs special treatment for allocating IRQs. Thanks to: joerg for providing access to an E3500 diff 142531 Sat Feb 26 00:22:52 MST 2005 marius Add a stopgap allowing puc(4) to allocate IRQs on fhc(4). Given that both a scc(4) is under way and fhc(4) will be change to use INOs this shouldn't stay in HEAD for too long but we need a MFC-able solution for FreeBSD 5.4. Discussed with: marcel Tested by: hrs, kris MFC after: 3 days diff 142531 Sat Feb 26 00:22:52 MST 2005 marius Add a stopgap allowing puc(4) to allocate IRQs on fhc(4). Given that both a scc(4) is under way and fhc(4) will be change to use INOs this shouldn't stay in HEAD for too long but we need a MFC-able solution for FreeBSD 5.4. Discussed with: marcel Tested by: hrs, kris MFC after: 3 days diff 142531 Sat Feb 26 00:22:52 MST 2005 marius Add a stopgap allowing puc(4) to allocate IRQs on fhc(4). Given that both a scc(4) is under way and fhc(4) will be change to use INOs this shouldn't stay in HEAD for too long but we need a MFC-able solution for FreeBSD 5.4. Discussed with: marcel Tested by: hrs, kris MFC after: 3 days diff 142531 Sat Feb 26 00:22:52 MST 2005 marius Add a stopgap allowing puc(4) to allocate IRQs on fhc(4). Given that both a scc(4) is under way and fhc(4) will be change to use INOs this shouldn't stay in HEAD for too long but we need a MFC-able solution for FreeBSD 5.4. Discussed with: marcel Tested by: hrs, kris MFC after: 3 days |
/freebsd-10.2-release/sys/sparc64/pci/ | ||
H A D | psychovar.h | diff 225931 Sun Oct 02 23:27:20 MDT 2011 marius Make sparc64 compatible with NEW_PCIB and enable it: - Implement bus_adjust_resource() methods as far as necessary and in non-PCI bridge drivers as far as feasible without rototilling them. - As NEW_PCIB does a layering violation by activating resources at layers above pci(4) without previously bubbling up their allocation there, move the assignment of bus tags and handles from the bus_alloc_resource() to the bus_activate_resource() methods like at least the other NEW_PCIB enabled architectures do. This is somewhat unfortunate as previously sparc64 (ab)used resource activation to indicate whether SYS_RES_MEMORY resources should be mapped into KVA, which is only necessary if their going to be accessed via the pointer returned from rman_get_virtual() but not for bus_space(9) as the later always uses physical access on sparc64. Besides wasting KVA if we always map in SYS_RES_MEMORY resources, a driver also may deliberately not map them in if the firmware already has done so, possibly in a special way. So in order to still allow a driver to decide whether a SYS_RES_MEMORY resource should be mapped into KVA we let it indicate that by calling bus_space_map(9) with BUS_SPACE_MAP_LINEAR as actually documented in the bus_space(9) page. This is implemented by allocating a separate bus tag per SYS_RES_MEMORY resource and passing the resource via the previously unused bus tag cookie so we later on can call rman_set_virtual() in sparc64_bus_mem_map(). As a side effect this now also allows to actually indicate that a SYS_RES_MEMORY resource should be mapped in as cacheable and/or read-only via BUS_SPACE_MAP_CACHEABLE and BUS_SPACE_MAP_READONLY respectively. - Do some minor cleanup like taking advantage of rman_init_from_resource(), factor out the common part of bus tag allocation into a newly added sparc64_alloc_bus_tag(), hook up some missing newbus methods and replace some homegrown versions with the generic counterparts etc. - While at it, let apb_attach() (which can't use the generic NEW_PCIB code as APB bridges just don't have the base and limit registers implemented) regarding the config space registers cached in pcib_softc and the SYSCTL reporting nodes set up. diff 220147 Tue Mar 29 19:56:15 MDT 2011 marius Allocate memory for a DMA method table only in case we need to override the iommu(4) provided one, i.e. in case of Hummingbird and Sabre bridges, otherwise just use the iommu(4) one. This also fixes a bug introduced in r220039 which caused an empty DMA method table to be used for the second of a pair of Psycho bridges. diff 220147 Tue Mar 29 19:56:15 MDT 2011 marius Allocate memory for a DMA method table only in case we need to override the iommu(4) provided one, i.e. in case of Hummingbird and Sabre bridges, otherwise just use the iommu(4) one. This also fixes a bug introduced in r220039 which caused an empty DMA method table to be used for the second of a pair of Psycho bridges. diff 190109 Thu Mar 19 21:00:40 MDT 2009 marius - Ensure we find no unexpected partner. - Failing to register as interrupt controller during attach shouldn't be fatal so just inform about this instead of panicing. - Disable rerun of the streaming cache as workaround for a silicon bug of certain Psycho versions. - Remove the comment regarding lack of newbus'ified bus_dma(9) as being able to associate a DMA tag with a device would allow to implement CDMA flushing/syncing in bus_dmamap_sync(9) but that would totally kill performance. Given that for devices not behind a PCI-PCI bridge the host-to-PCI bridges also only do CDMA flushing/syncing based on interrupts there's no additional disadvantage for polling(4) callbacks in the case schizo(4) has to do the CDMA flushing/syncing but rather a general problem. - Don't panic if the power failure, power management or over-temperature interrupts doesn't exist as these aren't mandatory and not available with all controllers (not even Psychos). [1] - Take advantage of KOBJMETHOD_END. - Remove some redundant variables. - Add missing const. PR: 131371 [1] diff 190109 Thu Mar 19 21:00:40 MDT 2009 marius - Ensure we find no unexpected partner. - Failing to register as interrupt controller during attach shouldn't be fatal so just inform about this instead of panicing. - Disable rerun of the streaming cache as workaround for a silicon bug of certain Psycho versions. - Remove the comment regarding lack of newbus'ified bus_dma(9) as being able to associate a DMA tag with a device would allow to implement CDMA flushing/syncing in bus_dmamap_sync(9) but that would totally kill performance. Given that for devices not behind a PCI-PCI bridge the host-to-PCI bridges also only do CDMA flushing/syncing based on interrupts there's no additional disadvantage for polling(4) callbacks in the case schizo(4) has to do the CDMA flushing/syncing but rather a general problem. - Don't panic if the power failure, power management or over-temperature interrupts doesn't exist as these aren't mandatory and not available with all controllers (not even Psychos). [1] - Take advantage of KOBJMETHOD_END. - Remove some redundant variables. - Add missing const. PR: 131371 [1] diff 178279 Thu Apr 17 12:38:00 MDT 2008 marius On sparc64 machines with multiple host-PCI-bridges these bridges have separate configuration spaces so by definition they implement different PCI domains. Thus change psycho(4) to use PCI domains instead of reenumerating all PCI busses so they have globally unique bus numbers and drop support for reenumerating busses in the OFW PCI code. According to CVS history reenumeration was also required in order to get some E450 to boot but given that no other open source kernel changes the PCI bus numbers assigned by the firmware I believe the real problem was that the old code used the bus number as the device number for the PCI busses and unlike most of the other machines the firmwares of the problematic ones don't use disjoint PCI bus numbers across the host-PCI-bridges. MFC after: 1 month diff 174117 Fri Nov 30 23:02:42 MST 2007 marius - Add the PCI side of the HOST-PCI bridge itself to the bus. This is required by the X.Org PCI domains code and additionally needs a workaround for Hummingbird and Sabre bridges as these don't allow their config headers to be read at any width, which is an unusual behavior. - In psycho(4) take advantage of DEFINE_CLASS_0 and use more appropriate types for some softc members. MFC after: 3 days diff 170851 Sat Jun 16 23:46:41 MDT 2007 marius - Use the newly introduced pcib_mtx spin lock to lock psycho_ce(), allowing it to be a filter/"fast" handler. Locking the interrupt handlers with a spin lock is mainly a requirement in schizo(4) but as we ought to register the spin lock anyway it should not hurt to take advantage of it in psycho(4). - Pass both a driver_filter_t and a driver_intr_t argument to psycho_set_intr(), allowing to get rid of the FAST interrupt flag hack. - Don't register the over-temperature interrupt handler as filter/ "fast" handler so shutdown_nice() can acquire the process lock. - Use bus_{read,write}_8() instead of bus_space_{read,write}_8() in order to get rid of sc_bushandle and sc_bustag in the softc. - Correct the debug output for adjusting the subordinate bus number. - Remove the banal and outdated above psycho_filter_stub(). - Fix some white space nits. diff 170851 Sat Jun 16 23:46:41 MDT 2007 marius - Use the newly introduced pcib_mtx spin lock to lock psycho_ce(), allowing it to be a filter/"fast" handler. Locking the interrupt handlers with a spin lock is mainly a requirement in schizo(4) but as we ought to register the spin lock anyway it should not hurt to take advantage of it in psycho(4). - Pass both a driver_filter_t and a driver_intr_t argument to psycho_set_intr(), allowing to get rid of the FAST interrupt flag hack. - Don't register the over-temperature interrupt handler as filter/ "fast" handler so shutdown_nice() can acquire the process lock. - Use bus_{read,write}_8() instead of bus_space_{read,write}_8() in order to get rid of sc_bushandle and sc_bustag in the softc. - Correct the debug output for adjusting the subordinate bus number. - Remove the banal and outdated above psycho_filter_stub(). - Fix some white space nits. diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) diff 167308 Wed Mar 07 21:13:51 MST 2007 marius Rototill the sparc64 nexus(4) (actually this brings in the code the sun4v nexus(4) in turn is based on): o Change nexus(4) to manage the resources of its children so the respective device drivers don't need to figure them out of OFW themselves. o Change nexus(4) to provide the ofw_bus KOBJ interface instead of using IVARs for supplying the OFW node and the subset of standard properties of its children. Together with the previous change this also allows to fully take advantage of newbus in that drivers like fhc(4), which attach on multiple parent busses, no longer require different bus front-ends as obtaining the OFW node and properties as well as resource allocation works the same for all supported busses. As such this change also is part 4/4 of allowing creator(4) to work in USIII-based machines as it allows this driver to attach on both nexus(4) and upa(4). On the other hand removing these IVARs breaks API compatibility with the powerpc nexus(4) but which isn't that bad as a) sparc64 currently doesn't share any device driver hanging off of nexus(4) with powerpc and b) they were no longer compatible regarding OFW-related extensions at the pci(4) level since quite some time. o Provide bus_get_dma_tag methods in nexus(4) and its children in order to handle DMA tags in a hierarchical way and get rid of the sparc64_root_dma_tag kludge. Together with the previous two items this changes also allows to completely get rid of the nexus(4) IVAR interface. It also includes: - pushing the constraints previously specified by the nexus_dmatag down into the DMA tags of psycho(4) and sbus(4) as it's their IOMMUs which induce these restrictions (and nothing at the nexus(4) or anything that would warrant specifying them there), - fixing some obviously wrong constraints of the psycho(4) and sbus(4) DMA tags, which happened to not actually be used with the sparc64_root_dma_tag kludge in place and therefore didn't cause problems so far, - replacing magic constants for constraints with macros as far as it is obvious as to where they come from. This doesn't include taking advantage of the newbus way to get the parent DMA tags implemented by this change in order to divorce the IOTSBs of the PCI and SBus IOMMUs or for implementing the workaround for the DMA sync bug in Sabre (and Tomatillo) bridges, yet, though. o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied from ofw_upa.h) and renaming its content, which actually applies to all of Fireplane/Safari, JBus and UPA (in the host bus case), as appropriate. o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for allocating the device info for the children of nexus(4). This is done in order to not need to export M_NEXUS when deriving drivers for subordinate busses from the nexus(4) class. o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so we can derive subclasses from it. o Const'ify the nexus_excl_name and nexus_excl_type arrays as well as add 'associations' and 'rsc', which are pseudo-devices without resources and therefore of no real interest for nexus(4), to the former. o Let the nexus(4) device memory rman manage the entire 64-bit address space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as Fireplane/Safari- and JBus-based machines use multiple ranges, which can't be as easily divided as in the case of UPA (limiting the address space only served for sanity checking anyway). o Use M_WAITOK instead of M_NOWAIT when allocating the device info for children of nexus(4) in order to give one less opportunity for adding devices to nexus(4) to fail. o While adapting the drivers affected by the above nexus(4) changes, change them to take advantage of rman_get_rid() instead of caching the RIDs assigned to allocated resources, now that the RIDs of resources are correctly set. o In iommu(4) and nexus(4) replace hard-coded functions names, which actually became outdated in several places, in panic strings and status massages with __func__. [1] o Use driver_filter_t in prototypes where appropriate. o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and sbus(4) as I changed considerable amounts of these drivers as well as added a bunch of new features, workarounds for silicon bugs etc. o Fix some white space nits. Due to lack of access to Exx00 hardware, these changes, i.e. central(4) and fhc(4), couldn't be runtime tested on such a machine. Exx00 are currently reported to panic before trying to attach nexus(4) anyway though. PR: 76052 [1] Approved by: re (kensmith) |
/freebsd-10.2-release/sys/dev/cxgbe/tom/ | ||
H A D | t4_ddp.c | diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) |
H A D | t4_cpl_io.c | diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) diff 270297 Thu Aug 21 20:04:07 MDT 2014 np MFC r266571, r266757, r268536, r269076, r269364, r269366, r269411, r269413, r269428, r269440, r269537, r269644, r269731, and the cxgbe portion of r270063. r266571: cxgbe(4): Remove stray if_up from the code that creates the tracing ifnet. r266757: cxgbe(4): netmap support for Terminator 5 (T5) based 10G/40G cards. Netmap gets its own hardware-assisted virtual interface and won't take over or disrupt the "normal" interface in any way. You can use both simultaneously. For kernels with DEV_NETMAP, cxgbe(4) carves out an ncxl<N> interface (note the 'n' prefix) in the hardware to accompany each cxl<N> interface. These two ifnet's per port share the same wire but really are separate interfaces in the hardware and software. Each gets its own L2 MAC addresses (unicast and multicast), MTU, checksum caps, etc. You should run netmap on the 'n' interfaces only, that's what they are for. With this, pkt-gen is able to transmit > 45Mpps out of a single 40G port of a T580 card. 2 port tx is at ~56Mpps total (28M + 28M) as of now. Single port receive is at 33Mpps but this is very much a work in progress. I expect it to be closer to 40Mpps once done. In any case the current effort can already saturate multiple 10G ports of a T5 card at the smallest legal packet size. T4 gear is totally untested. trantor:~# ./pkt-gen -i ncxl0 -f tx -D 00:07:43:ab:cd:ef 881.952141 main [1621] interface is ncxl0 881.952250 extract_ip_range [275] range is 10.0.0.1:0 to 10.0.0.1:0 881.952253 extract_ip_range [275] range is 10.1.0.1:0 to 10.1.0.1:0 881.962540 main [1804] mapped 334980KB at 0x801dff000 Sending on netmap:ncxl0: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (00:00:00:00:00:00 -> 00:07:43:ab:cd:ef) 881.962562 main [1882] Sending 512 packets every 0.000000000 s 881.962563 main [1884] Wait 2 secs for phy reset 884.088516 main [1886] Ready... 884.088535 nm_open [457] overriding ifname ncxl0 ringid 0x0 flags 0x1 884.088607 sender_body [996] start 884.093246 sender_body [1064] drop copy 885.090435 main_thread [1418] 45206353 pps (45289533 pkts in 1001840 usec) 886.091600 main_thread [1418] 45322792 pps (45375593 pkts in 1001165 usec) 887.092435 main_thread [1418] 45313992 pps (45351784 pkts in 1000834 usec) 888.094434 main_thread [1418] 45315765 pps (45406397 pkts in 1002000 usec) 889.095434 main_thread [1418] 45333218 pps (45378551 pkts in 1001000 usec) 890.097434 main_thread [1418] 45315247 pps (45405877 pkts in 1002000 usec) 891.099434 main_thread [1418] 45326515 pps (45417168 pkts in 1002000 usec) 892.101434 main_thread [1418] 45333039 pps (45423705 pkts in 1002000 usec) 893.103434 main_thread [1418] 45324105 pps (45414708 pkts in 1001999 usec) 894.105434 main_thread [1418] 45318042 pps (45408723 pkts in 1002001 usec) 895.106434 main_thread [1418] 45332430 pps (45377762 pkts in 1001000 usec) 896.107434 main_thread [1418] 45338072 pps (45383410 pkts in 1001000 usec) ... r268536: cxgbe(4): Add an iSCSI softc to the adapter structure. r269076: Some hooks in cxgbe(4) for the offloaded iSCSI driver. r269364: Improve compliance with style.Makefile(5). r269366: List one file per line in the Makefiles. This makes it easier to read diffs when a file is added or removed. r269411: cxgbe(4): minor optimizations in ingress queue processing. Reorganize struct sge_iq. Make the iq entry size a compile time constant. While here, eliminate RX_FL_ESIZE and use EQ_ESIZE directly. r269413: cxgbe(4): Fix an off by one error when looking for the BAR2 doorbell address of an egress queue. r269428: cxgbe(4): some optimizations in freelist handling. r269440: cxgbe(4): Remove an unused version of t4_enable_vi. r269537: cxgbe(4): Do not run any sleepable code in the SIOCSIFFLAGS handler when IFF_PROMISC or IFF_ALLMULTI is being flipped. bpf(4) holds its global mutex around ifpromisc in at least the bpf_dtor path. r269644: cxgbe(4): Let caller specify whether it's ok to sleep in t4_sched_config and t4_sched_params. r269731: cxgbe(4): Do not poke T4-only registers on a T5 (and vice versa). Relnotes: Yes (native netmap support for Chelsio T4/T5 cards) |
/freebsd-10.2-release/sys/dev/nvme/ | ||
H A D | nvme_ns.c | diff 254389 Thu Aug 15 23:03:14 MDT 2013 ken Change the way that unmapped I/O capability is advertised. The previous method was to set the D_UNMAPPED_IO flag in the cdevsw for the driver. The problem with this is that in many cases (e.g. sa(4)) there may be some instances of the driver that can handle unmapped I/O and some that can't. The isp(4) driver can handle unmapped I/O, but the esp(4) driver currently cannot. The cdevsw is shared among all driver instances. So instead of setting a flag on the cdevsw, set a flag on the cdev. This allows drivers to indicate support for unmapped I/O on a per-instance basis. sys/conf.h: Remove the D_UNMAPPED_IO cdevsw flag and replace it with an SI_UNMAPPED cdev flag. kern_physio.c: Look at the cdev SI_UNMAPPED flag to determine whether or not a particular driver can handle unmapped I/O. geom_dev.c: Set the SI_UNMAPPED flag for all GEOM cdevs. Since GEOM will create a temporary mapping when needed, setting SI_UNMAPPED unconditionally will work. Remove the D_UNMAPPED_IO flag. nvme_ns.c: Set the SI_UNMAPPED flag on cdevs created here if NVME_UNMAPPED_BIO_SUPPORT is enabled. vfs_aio.c: In aio_qphysio(), check the SI_UNMAPPED flag on a cdev instead of the D_UNMAPPED_IO flag on the cdevsw. sys/param.h: Bump __FreeBSD_version to 1000045 for the switch from setting the D_UNMAPPED_IO flag in the cdevsw to setting SI_UNMAPPED in the cdev. Reviewed by: kib, jimharris MFC after: 1 week Sponsored by: Spectra Logic diff 254389 Thu Aug 15 23:03:14 MDT 2013 ken Change the way that unmapped I/O capability is advertised. The previous method was to set the D_UNMAPPED_IO flag in the cdevsw for the driver. The problem with this is that in many cases (e.g. sa(4)) there may be some instances of the driver that can handle unmapped I/O and some that can't. The isp(4) driver can handle unmapped I/O, but the esp(4) driver currently cannot. The cdevsw is shared among all driver instances. So instead of setting a flag on the cdevsw, set a flag on the cdev. This allows drivers to indicate support for unmapped I/O on a per-instance basis. sys/conf.h: Remove the D_UNMAPPED_IO cdevsw flag and replace it with an SI_UNMAPPED cdev flag. kern_physio.c: Look at the cdev SI_UNMAPPED flag to determine whether or not a particular driver can handle unmapped I/O. geom_dev.c: Set the SI_UNMAPPED flag for all GEOM cdevs. Since GEOM will create a temporary mapping when needed, setting SI_UNMAPPED unconditionally will work. Remove the D_UNMAPPED_IO flag. nvme_ns.c: Set the SI_UNMAPPED flag on cdevs created here if NVME_UNMAPPED_BIO_SUPPORT is enabled. vfs_aio.c: In aio_qphysio(), check the SI_UNMAPPED flag on a cdev instead of the D_UNMAPPED_IO flag on the cdevsw. sys/param.h: Bump __FreeBSD_version to 1000045 for the switch from setting the D_UNMAPPED_IO flag in the cdevsw to setting SI_UNMAPPED in the cdev. Reviewed by: kib, jimharris MFC after: 1 week Sponsored by: Spectra Logic diff 254389 Thu Aug 15 23:03:14 MDT 2013 ken Change the way that unmapped I/O capability is advertised. The previous method was to set the D_UNMAPPED_IO flag in the cdevsw for the driver. The problem with this is that in many cases (e.g. sa(4)) there may be some instances of the driver that can handle unmapped I/O and some that can't. The isp(4) driver can handle unmapped I/O, but the esp(4) driver currently cannot. The cdevsw is shared among all driver instances. So instead of setting a flag on the cdevsw, set a flag on the cdev. This allows drivers to indicate support for unmapped I/O on a per-instance basis. sys/conf.h: Remove the D_UNMAPPED_IO cdevsw flag and replace it with an SI_UNMAPPED cdev flag. kern_physio.c: Look at the cdev SI_UNMAPPED flag to determine whether or not a particular driver can handle unmapped I/O. geom_dev.c: Set the SI_UNMAPPED flag for all GEOM cdevs. Since GEOM will create a temporary mapping when needed, setting SI_UNMAPPED unconditionally will work. Remove the D_UNMAPPED_IO flag. nvme_ns.c: Set the SI_UNMAPPED flag on cdevs created here if NVME_UNMAPPED_BIO_SUPPORT is enabled. vfs_aio.c: In aio_qphysio(), check the SI_UNMAPPED flag on a cdev instead of the D_UNMAPPED_IO flag on the cdevsw. sys/param.h: Bump __FreeBSD_version to 1000045 for the switch from setting the D_UNMAPPED_IO flag in the cdevsw to setting SI_UNMAPPED in the cdev. Reviewed by: kib, jimharris MFC after: 1 week Sponsored by: Spectra Logic diff 253474 Fri Jul 19 21:34:20 MDT 2013 jimharris Fix nvme(4) and nvd(4) to support non 512-byte sector sizes. Recent testing with QEMU that has variable sector size support for NVMe uncovered some of these issues. Chatham prototype boards supported only 512 byte sectors. Sponsored by: Intel Reviewed by: carl MFC after: 3 days diff 253474 Fri Jul 19 21:34:20 MDT 2013 jimharris Fix nvme(4) and nvd(4) to support non 512-byte sector sizes. Recent testing with QEMU that has variable sector size support for NVMe uncovered some of these issues. Chatham prototype boards supported only 512 byte sectors. Sponsored by: Intel Reviewed by: carl MFC after: 3 days diff 248977 Mon Apr 01 16:35:11 MDT 2013 jimharris Add unmapped bio support to nvme(4) and nvd(4). Sponsored by: Intel diff 248977 Mon Apr 01 16:35:11 MDT 2013 jimharris Add unmapped bio support to nvme(4) and nvd(4). Sponsored by: Intel diff 248746 Tue Mar 26 20:02:39 MDT 2013 jimharris Add controller reset capability to nvme(4) and ability to explicitly invoke it from nvmecontrol(8). Controller reset will be performed in cases where I/O are repeatedly timing out, the controller reports an unrecoverable condition, or when explicitly requested via IOCTL or an nvme consumer. Since the controller may be in such a state where it cannot even process queue deletion requests, we will perform a controller reset without trying to clean up anything on the controller first. Sponsored by: Intel Reviewed by: carl 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> |
H A D | nvme_ns_cmd.c | diff 253474 Fri Jul 19 21:34:20 MDT 2013 jimharris Fix nvme(4) and nvd(4) to support non 512-byte sector sizes. Recent testing with QEMU that has variable sector size support for NVMe uncovered some of these issues. Chatham prototype boards supported only 512 byte sectors. Sponsored by: Intel Reviewed by: carl MFC after: 3 days diff 253474 Fri Jul 19 21:34:20 MDT 2013 jimharris Fix nvme(4) and nvd(4) to support non 512-byte sector sizes. Recent testing with QEMU that has variable sector size support for NVMe uncovered some of these issues. Chatham prototype boards supported only 512 byte sectors. Sponsored by: Intel Reviewed by: carl MFC after: 3 days diff 248977 Mon Apr 01 16:35:11 MDT 2013 jimharris Add unmapped bio support to nvme(4) and nvd(4). Sponsored by: Intel diff 248977 Mon Apr 01 16:35:11 MDT 2013 jimharris Add unmapped bio support to nvme(4) and nvd(4). Sponsored by: Intel 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> 240616 Mon Sep 17 19:31:27 MDT 2012 jimharris This is the first of several commits which will add NVM Express (NVMe) support to FreeBSD. A full description of the overall functionality being added is below. nvmexpress.org defines NVM Express as "an optimized register interface, command set and feature set fo PCI Express (PCIe)-based Solid-State Drives (SSDs)." This commit adds nvme(4) and nvd(4) driver source code and Makefiles to the tree. Full NVMe functionality description: Add nvme(4) and nvd(4) drivers and nvmecontrol(8) for NVM Express (NVMe) device support. There will continue to be ongoing work on NVM Express support, but there is more than enough to allow for evaluation of pre-production NVM Express devices as well as soliciting feedback. Questions and feedback are welcome. nvme(4) implements NVMe hardware abstraction and is a provider of NVMe namespaces. The closest equivalent of an NVMe namespace is a SCSI LUN. nvd(4) is an NVMe consumer, surfacing NVMe namespaces as GEOM disks. nvmecontrol(8) is used for NVMe configuration and management. The following are currently supported: nvme(4) - full mandatory NVM command set support - per-CPU IO queues (enabled by default but configurable) - per-queue sysctls for statistics and full command/completion queue dumps for debugging - registration API for NVMe namespace consumers - I/O error handling (except for timeoutsee below) - compilation switches for support back to stable-7 nvd(4) - BIO_DELETE and BIO_FLUSH (if supported by controller) - proper BIO_ORDERED handling nvmecontrol(8) - devlist: list NVMe controllers and their namespaces - identify: display controller or namespace identify data in human-readable or hex format - perftest: quick and dirty performance test to measure raw performance of NVMe device without userspace/physio/GEOM overhead The following are still work in progress and will be completed over the next 3-6 months in rough priority order: - complete man pages - firmware download and activation - asynchronous error requests - command timeout error handling - controller resets - nvmecontrol(8) log page retrieval This has been primarily tested on amd64, with light testing on i386. I would be happy to provide assistance to anyone interested in porting this to other architectures, but am not currently planning to do this work myself. Big-endian and dmamap sync for command/completion queues are the main areas that would need to be addressed. The nvme(4) driver currently has references to Chatham, which is an Intel-developed prototype board which is not fully spec compliant. These references will all be removed over time. Sponsored by: Intel Contributions from: Joe Golio/EMC <joseph dot golio at emc dot com> |
/freebsd-10.2-release/tools/tools/cxgbetool/ | ||
H A D | cxgbetool.c | diff 269357 Thu Jul 31 23:17:55 MDT 2014 np MFC r269106: Add a 'raw' parameter to the 'modinfo' subcommand. This is handy when trying to figure out why a QSFP+/SFP+ connector or cable wasn't identified correctly by cxgbe(4). Its output looks like this: # cxgbetool t5nex0 modinfo 0 raw 00: 03 04 21 00 00 00 00 00 ..!. .... 08: 04 00 00 00 67 00 00 00 .... g... 10: 00 00 05 00 41 6d 70 68 .... Amph 18: 65 6e 6f 6c 20 20 20 20 enol 20: 20 20 20 20 00 41 50 48 .APH 28: 35 37 31 35 34 30 30 30 5715 4000 30: 33 20 20 20 20 20 20 20 3 38: 4b 20 20 20 01 00 00 fa K .... 40: 00 00 00 00 41 50 46 31 .... APF1 48: 30 30 34 30 30 33 30 30 0040 0300 50: 30 33 20 20 31 30 30 31 03 1001 58: 33 30 20 20 00 00 00 97 30 .... diff 269357 Thu Jul 31 23:17:55 MDT 2014 np MFC r269106: Add a 'raw' parameter to the 'modinfo' subcommand. This is handy when trying to figure out why a QSFP+/SFP+ connector or cable wasn't identified correctly by cxgbe(4). Its output looks like this: # cxgbetool t5nex0 modinfo 0 raw 00: 03 04 21 00 00 00 00 00 ..!. .... 08: 04 00 00 00 67 00 00 00 .... g... 10: 00 00 05 00 41 6d 70 68 .... Amph 18: 65 6e 6f 6c 20 20 20 20 enol 20: 20 20 20 20 00 41 50 48 .APH 28: 35 37 31 35 34 30 30 30 5715 4000 30: 33 20 20 20 20 20 20 20 3 38: 4b 20 20 20 01 00 00 fa K .... 40: 00 00 00 00 41 50 46 31 .... APF1 48: 30 30 34 30 30 33 30 30 0040 0300 50: 30 33 20 20 31 30 30 31 03 1001 58: 33 30 20 20 00 00 00 97 30 .... diff 259142 Mon Dec 09 22:53:32 MST 2013 np MFC r257654, r257772, r258441, r258689, r258698, r258879, r259048, and r259103. r257654: cxgbe(4): Exclude MPS_RPLC_MAP_CTL (0x11114) from the register dump. Turns out it's a write-only register with strange side effects on read. r257772: cxgbe(4): Tidy up the display for payload memory statistics (pm_stats). r258441: cxgbe(4): update the internal list of device features. r258689: Disable an assertion that relies on some code[1] that isn't in HEAD yet. r258698: cxgbetool: "modinfo" command to display SFP+ module information. r258879: cxgbe(4): T4_SET_SCHED_CLASS and T4_SET_SCHED_QUEUE ioctls to program scheduling classes in the chip and to bind tx queue(s) to a scheduling class respectively. These can be used for various kinds of tx traffic throttling (to force selected tx queues to drain at a fixed Kbps rate, or a % of the port's total bandwidth, or at a fixed pps rate, etc.). r259048: Two new cxgbetool subcommands to set up scheduler classes and to bind them to NIC queues. r259103: cxgbe(4): save a copy of the RSS map for each port for the driver's use. diff 259142 Mon Dec 09 22:53:32 MST 2013 np MFC r257654, r257772, r258441, r258689, r258698, r258879, r259048, and r259103. r257654: cxgbe(4): Exclude MPS_RPLC_MAP_CTL (0x11114) from the register dump. Turns out it's a write-only register with strange side effects on read. r257772: cxgbe(4): Tidy up the display for payload memory statistics (pm_stats). r258441: cxgbe(4): update the internal list of device features. r258689: Disable an assertion that relies on some code[1] that isn't in HEAD yet. r258698: cxgbetool: "modinfo" command to display SFP+ module information. r258879: cxgbe(4): T4_SET_SCHED_CLASS and T4_SET_SCHED_QUEUE ioctls to program scheduling classes in the chip and to bind tx queue(s) to a scheduling class respectively. These can be used for various kinds of tx traffic throttling (to force selected tx queues to drain at a fixed Kbps rate, or a % of the port's total bandwidth, or at a fixed pps rate, etc.). r259048: Two new cxgbetool subcommands to set up scheduler classes and to bind them to NIC queues. r259103: cxgbe(4): save a copy of the RSS map for each port for the driver's use. diff 259142 Mon Dec 09 22:53:32 MST 2013 np MFC r257654, r257772, r258441, r258689, r258698, r258879, r259048, and r259103. r257654: cxgbe(4): Exclude MPS_RPLC_MAP_CTL (0x11114) from the register dump. Turns out it's a write-only register with strange side effects on read. r257772: cxgbe(4): Tidy up the display for payload memory statistics (pm_stats). r258441: cxgbe(4): update the internal list of device features. r258689: Disable an assertion that relies on some code[1] that isn't in HEAD yet. r258698: cxgbetool: "modinfo" command to display SFP+ module information. r258879: cxgbe(4): T4_SET_SCHED_CLASS and T4_SET_SCHED_QUEUE ioctls to program scheduling classes in the chip and to bind tx queue(s) to a scheduling class respectively. These can be used for various kinds of tx traffic throttling (to force selected tx queues to drain at a fixed Kbps rate, or a % of the port's total bandwidth, or at a fixed pps rate, etc.). r259048: Two new cxgbetool subcommands to set up scheduler classes and to bind them to NIC queues. r259103: cxgbe(4): save a copy of the RSS map for each port for the driver's use. diff 259142 Mon Dec 09 22:53:32 MST 2013 np MFC r257654, r257772, r258441, r258689, r258698, r258879, r259048, and r259103. r257654: cxgbe(4): Exclude MPS_RPLC_MAP_CTL (0x11114) from the register dump. Turns out it's a write-only register with strange side effects on read. r257772: cxgbe(4): Tidy up the display for payload memory statistics (pm_stats). r258441: cxgbe(4): update the internal list of device features. r258689: Disable an assertion that relies on some code[1] that isn't in HEAD yet. r258698: cxgbetool: "modinfo" command to display SFP+ module information. r258879: cxgbe(4): T4_SET_SCHED_CLASS and T4_SET_SCHED_QUEUE ioctls to program scheduling classes in the chip and to bind tx queue(s) to a scheduling class respectively. These can be used for various kinds of tx traffic throttling (to force selected tx queues to drain at a fixed Kbps rate, or a % of the port's total bandwidth, or at a fixed pps rate, etc.). r259048: Two new cxgbetool subcommands to set up scheduler classes and to bind them to NIC queues. r259103: cxgbe(4): save a copy of the RSS map for each port for the driver's use. diff 259142 Mon Dec 09 22:53:32 MST 2013 np MFC r257654, r257772, r258441, r258689, r258698, r258879, r259048, and r259103. r257654: cxgbe(4): Exclude MPS_RPLC_MAP_CTL (0x11114) from the register dump. Turns out it's a write-only register with strange side effects on read. r257772: cxgbe(4): Tidy up the display for payload memory statistics (pm_stats). r258441: cxgbe(4): update the internal list of device features. r258689: Disable an assertion that relies on some code[1] that isn't in HEAD yet. r258698: cxgbetool: "modinfo" command to display SFP+ module information. r258879: cxgbe(4): T4_SET_SCHED_CLASS and T4_SET_SCHED_QUEUE ioctls to program scheduling classes in the chip and to bind tx queue(s) to a scheduling class respectively. These can be used for various kinds of tx traffic throttling (to force selected tx queues to drain at a fixed Kbps rate, or a % of the port's total bandwidth, or at a fixed pps rate, etc.). r259048: Two new cxgbetool subcommands to set up scheduler classes and to bind them to NIC queues. r259103: cxgbe(4): save a copy of the RSS map for each port for the driver's use. diff 253691 Fri Jul 26 22:11:14 MDT 2013 np Add support for packet-sniffing tracers to cxgbe(4). This works with all T4 and T5 based cards and is useful for analyzing TSO, LRO, TOE, and for general purpose monitoring without tapping any cxgbe or cxl ifnet directly. Tracers on the T4/T5 chips provide access to Ethernet frames exactly as they were received from or transmitted on the wire. On transmit, a tracer will capture a frame after TSO segmentation, hw VLAN tag insertion, hw L3 & L4 checksum insertion, etc. It will also capture frames generated by the TCP offload engine (TOE traffic is normally invisible to the kernel). On receive, a tracer will capture a frame before hw VLAN extraction, runt filtering, other badness filtering, before the steering/drop/L2-rewrite filters or the TOE have had a go at it, and of course before sw LRO in the driver. There are 4 tracers on a chip. A tracer can trace only in one direction (tx or rx). For now cxgbetool will set up tracers to capture the first 128B of every transmitted or received frame on a given port. This is a small subset of what the hardware can do. A pseudo ifnet with the same name as the nexus driver (t4nex0 or t5nex0) will be created for tracing. The data delivered to this ifnet is an additional copy made inside the chip. Normal delivery to cxgbe<n> or cxl<n> will be made as usual. /* watch cxl0, which is the first port hanging off t5nex0. */ # cxgbetool t5nex0 tracer 0 tx0 (watch what cxl0 is transmitting) # cxgbetool t5nex0 tracer 1 rx0 (watch what cxl0 is receiving) # cxgbetool t5nex0 tracer list # tcpdump -i t5nex0 <== all that cxl0 sees and puts on the wire If you were doing TSO, a tcpdump on cxl0 may have shown you ~64K "frames" with no L3/L4 checksum but this will show you the frames that were actually transmitted. /* all done */ # cxgbetool t5nex0 tracer 0 disable # cxgbetool t5nex0 tracer 1 disable # cxgbetool t5nex0 tracer list # ifconfig t5nex0 destroy diff 253691 Fri Jul 26 22:11:14 MDT 2013 np Add support for packet-sniffing tracers to cxgbe(4). This works with all T4 and T5 based cards and is useful for analyzing TSO, LRO, TOE, and for general purpose monitoring without tapping any cxgbe or cxl ifnet directly. Tracers on the T4/T5 chips provide access to Ethernet frames exactly as they were received from or transmitted on the wire. On transmit, a tracer will capture a frame after TSO segmentation, hw VLAN tag insertion, hw L3 & L4 checksum insertion, etc. It will also capture frames generated by the TCP offload engine (TOE traffic is normally invisible to the kernel). On receive, a tracer will capture a frame before hw VLAN extraction, runt filtering, other badness filtering, before the steering/drop/L2-rewrite filters or the TOE have had a go at it, and of course before sw LRO in the driver. There are 4 tracers on a chip. A tracer can trace only in one direction (tx or rx). For now cxgbetool will set up tracers to capture the first 128B of every transmitted or received frame on a given port. This is a small subset of what the hardware can do. A pseudo ifnet with the same name as the nexus driver (t4nex0 or t5nex0) will be created for tracing. The data delivered to this ifnet is an additional copy made inside the chip. Normal delivery to cxgbe<n> or cxl<n> will be made as usual. /* watch cxl0, which is the first port hanging off t5nex0. */ # cxgbetool t5nex0 tracer 0 tx0 (watch what cxl0 is transmitting) # cxgbetool t5nex0 tracer 1 rx0 (watch what cxl0 is receiving) # cxgbetool t5nex0 tracer list # tcpdump -i t5nex0 <== all that cxl0 sees and puts on the wire If you were doing TSO, a tcpdump on cxl0 may have shown you ~64K "frames" with no L3/L4 checksum but this will show you the frames that were actually transmitted. /* all done */ # cxgbetool t5nex0 tracer 0 disable # cxgbetool t5nex0 tracer 1 disable # cxgbetool t5nex0 tracer list # ifconfig t5nex0 destroy diff 248925 Sat Mar 30 02:34:15 MDT 2013 np cxgbe(4): Add support for Chelsio's Terminator 5 (aka T5) ASIC. This includes support for the NIC and TOE features of the 40G, 10G, and 1G/100M cards based on the T5. The ASIC is mostly backward compatible with the Terminator 4 so cxgbe(4) has been updated instead of writing a brand new driver. T5 cards will show up as cxl (short for cxlgb) ports attached to the t5nex bus driver. Sponsored by: Chelsio diff 248925 Sat Mar 30 02:34:15 MDT 2013 np cxgbe(4): Add support for Chelsio's Terminator 5 (aka T5) ASIC. This includes support for the NIC and TOE features of the 40G, 10G, and 1G/100M cards based on the T5. The ASIC is mostly backward compatible with the Terminator 4 so cxgbe(4) has been updated instead of writing a brand new driver. T5 cards will show up as cxl (short for cxlgb) ports attached to the t5nex bus driver. Sponsored by: Chelsio diff 248925 Sat Mar 30 02:34:15 MDT 2013 np cxgbe(4): Add support for Chelsio's Terminator 5 (aka T5) ASIC. This includes support for the NIC and TOE features of the 40G, 10G, and 1G/100M cards based on the T5. The ASIC is mostly backward compatible with the Terminator 4 so cxgbe(4) has been updated instead of writing a brand new driver. T5 cards will show up as cxl (short for cxlgb) ports attached to the t5nex bus driver. Sponsored by: Chelsio |
/freebsd-10.2-release/sbin/mdconfig/ | ||
H A D | Makefile | diff 157160 Sun Mar 26 23:21:11 MST 2006 wkoszek Teach md(4) and mdconfig(8) how to understand XML. Right now there won't be a problem with listing large number of md(4) devices. Either 'list' or 'query' mode uses XML. Additionally, new functionality was introduced. It's possible to pass multiple devices to -u: # ./mdconfig -l -u md0,md1 Approved by: cognet (mentor) diff 157160 Sun Mar 26 23:21:11 MST 2006 wkoszek Teach md(4) and mdconfig(8) how to understand XML. Right now there won't be a problem with listing large number of md(4) devices. Either 'list' or 'query' mode uses XML. Additionally, new functionality was introduced. It's possible to pass multiple devices to -u: # ./mdconfig -l -u md0,md1 Approved by: cognet (mentor) diff 135340 Thu Sep 16 21:32:13 MDT 2004 pjd - Make md(4) 64-bit clean. After this change it should be possible to use very big md(4) devices. - Clean up and simplify the code a bit. - Use humanize_number(3) to print size of md(4) devices. - Add 't' suffix which stands for terabyte. - Make '-S' to really work with all types of devices. - Other minor changes. diff 135340 Thu Sep 16 21:32:13 MDT 2004 pjd - Make md(4) 64-bit clean. After this change it should be possible to use very big md(4) devices. - Clean up and simplify the code a bit. - Use humanize_number(3) to print size of md(4) devices. - Add 't' suffix which stands for terabyte. - Make '-S' to really work with all types of devices. - Other minor changes. diff 135340 Thu Sep 16 21:32:13 MDT 2004 pjd - Make md(4) 64-bit clean. After this change it should be possible to use very big md(4) devices. - Clean up and simplify the code a bit. - Use humanize_number(3) to print size of md(4) devices. - Add 't' suffix which stands for terabyte. - Make '-S' to really work with all types of devices. - Other minor changes. diff 74047 Fri Mar 09 20:09:28 MST 2001 phk Make md(4) and mdconfig(8) take over the role of vn(4) and vnconfig(8) entirely as previously advertised. md(4) adopted all assets of vn(4) some time back and has proper devfs support and cloning abilities to boot. diff 74047 Fri Mar 09 20:09:28 MST 2001 phk Make md(4) and mdconfig(8) take over the role of vn(4) and vnconfig(8) entirely as previously advertised. md(4) adopted all assets of vn(4) some time back and has proper devfs support and cloning abilities to boot. diff 74047 Fri Mar 09 20:09:28 MST 2001 phk Make md(4) and mdconfig(8) take over the role of vn(4) and vnconfig(8) entirely as previously advertised. md(4) adopted all assets of vn(4) some time back and has proper devfs support and cloning abilities to boot. diff 74047 Fri Mar 09 20:09:28 MST 2001 phk Make md(4) and mdconfig(8) take over the role of vn(4) and vnconfig(8) entirely as previously advertised. md(4) adopted all assets of vn(4) some time back and has proper devfs support and cloning abilities to boot. 70448 Thu Dec 28 20:57:57 MST 2000 phk Preliminary scaffolding for the new integrated vn+md device driver. I decided to work on the md(4) driver and integrate the vn(4) functionality into it mainly based on the name being more suitable. Ideally 'vd' as in "virtual disk" would probably be the most logical but our sound-master pointed out that this would cause uncontrollable fits of giggles in the brits. Another complication would the needed changes to the ramdisk boot/root functionality. The vn driver will stay around for some time after I complete this merge for transition reasons, and I'll make it whine to people that they should migrate to the md(4) driver for some time before it dies. The kernel part of the new md(4) driver will be committed after more testing. 70448 Thu Dec 28 20:57:57 MST 2000 phk Preliminary scaffolding for the new integrated vn+md device driver. I decided to work on the md(4) driver and integrate the vn(4) functionality into it mainly based on the name being more suitable. Ideally 'vd' as in "virtual disk" would probably be the most logical but our sound-master pointed out that this would cause uncontrollable fits of giggles in the brits. Another complication would the needed changes to the ramdisk boot/root functionality. The vn driver will stay around for some time after I complete this merge for transition reasons, and I'll make it whine to people that they should migrate to the md(4) driver for some time before it dies. The kernel part of the new md(4) driver will be committed after more testing. 70448 Thu Dec 28 20:57:57 MST 2000 phk Preliminary scaffolding for the new integrated vn+md device driver. I decided to work on the md(4) driver and integrate the vn(4) functionality into it mainly based on the name being more suitable. Ideally 'vd' as in "virtual disk" would probably be the most logical but our sound-master pointed out that this would cause uncontrollable fits of giggles in the brits. Another complication would the needed changes to the ramdisk boot/root functionality. The vn driver will stay around for some time after I complete this merge for transition reasons, and I'll make it whine to people that they should migrate to the md(4) driver for some time before it dies. The kernel part of the new md(4) driver will be committed after more testing. 70448 Thu Dec 28 20:57:57 MST 2000 phk Preliminary scaffolding for the new integrated vn+md device driver. I decided to work on the md(4) driver and integrate the vn(4) functionality into it mainly based on the name being more suitable. Ideally 'vd' as in "virtual disk" would probably be the most logical but our sound-master pointed out that this would cause uncontrollable fits of giggles in the brits. Another complication would the needed changes to the ramdisk boot/root functionality. The vn driver will stay around for some time after I complete this merge for transition reasons, and I'll make it whine to people that they should migrate to the md(4) driver for some time before it dies. The kernel part of the new md(4) driver will be committed after more testing. |
/freebsd-10.2-release/sys/dev/iicbus/ | ||
H A D | iiconf.c | diff 228257 Sun Dec 04 12:00:45 MST 2011 adrian Allow the i2c node requirements to be slightly relaxed. These realtek switch PHYs speak a variant of i2c with some slightly modified handling. From the submitter, slightly modified now that some further digging has been done: The I2C framework makes a assumption that the read/not-write bit of the first byte (the address) indicates whether reads or writes are to follow. The RTL8366 family uses the bus: after sending the address+read/not-write byte, two register address bytes are sent, then the 16-bit register value is sent or received. While the register write access can be performed as a 4-byte write, the read access requires the read bit to be set, but the first two bytes for the register address then need to be transmitted. This patch maintains the i2c protocol behaviour but allows it to be relaxed (for these kinds of switch PHYs, and whatever else Realtek may do with this almost-but-not-quite i2c bus) - by setting the "strict" hint to 0. The "strict" hint defaults to 1. Submitted by: Stefan Bethke <stb@lassitu.de> diff 181304 Mon Aug 04 21:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. diff 181304 Mon Aug 04 21:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. diff 181304 Mon Aug 04 21:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. diff 181304 Mon Aug 04 21:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. diff 181304 Mon Aug 04 21:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. diff 181304 Mon Aug 04 21:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. diff 181304 Mon Aug 04 21:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. diff 181304 Mon Aug 04 21:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. diff 181304 Mon Aug 04 21:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. diff 181304 Mon Aug 04 21:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. diff 181304 Mon Aug 04 21:16:00 MDT 2008 jhb Add locking to the core iicbus(4) drivers: - Add an sx lock to the iic(4) driver to serialize open(), close(), read(), and write and to protect sc_addr and sc_count in the softc. - Use cdev->si_drv1 instead of using the minor number of the cdev to lookup the softc via newbus in iic(4). - Store the device_t in the softc to avoid a similar detour via minor numbers in iic(4). - Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4) instance, and do it in the child driver. - Add a mutex to the iicbus(4) softc to synchronize the request/release bus stuff. - Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own. - Add a mutex to the iicsmb(4) softc to protect softc state updated in the interrupt handler. - Remove Giant from all the smbus methods in iicsmb(4) now that all the iicbus(4) backend is locked. |
/freebsd-10.2-release/etc/etc.mips/ | ||
H A D | ttys | diff 203068 Wed Jan 27 12:01:18 MST 2010 ed Remove pseudo-terminals from ttys(5). When we had utmp(5), we had to list all the psuedo-terminals in ttys(5) to make ttyslot(3) function properly. Now that pututxline(3) deals with slot allocation internally (not based on TTY names), we don't need to list all the TTYs on the system in ttys(5) to make user accounting work properly. This patch removes all the entries from the /etc/ttys files, but also the pts(4) entries that were appended implicitly, which was added in r154838. diff 199243 Fri Nov 13 06:06:38 MST 2009 ed Switch the default terminal emulation style to xterm for most platforms. Right now syscons(4) uses a cons25-style terminal emulator. The disadvantages of that are: - Little compatibility with embedded devices with serial interfaces. - Bad bandwidth efficiency, mainly because of the lack of scrolling regions. - A very hard transition path to support for modern character sets like UTF-8. Our terminal emulation library, libteken, has been supporting xterm-style terminal emulation for months, so flip the switch and make everyone use an xterm-style console driver. I still have to enable this on i386. Right now pc98 and i386 share the same /etc/ttys file. I'm not going to switch pc98, because it uses its own Kanji-capable cons25 emulator. IMPORTANT: What to do if things go wrong (i.e. graphical artifacts): - Run the application inside script(1), try to reduce the problem and send me the log file. - In the mean time, you can run `vidcontrol -T cons25' and `export TERM=cons25' so you can run applications the same way you did before. You can also build your kernel with `options TEKEN_CONS25' to make all virtual terminals use the cons25 emulator by default. Discussed on: current@ diff 188535 Thu Feb 12 19:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys. Even though I increased the amount of pts(4) entries in /etc/ttys some time ago, I didn't realize back then those entries shouldn't have been there in the first place. I just looked at the getttyent() source code and it turns out when you call setttyent(), it walks through /dev/pts and looks for the device with the highest number. After you receive EOF's from getttyent(), it makes up entries for pts(4) devices. This means that adding entries for pts(4) is somewhat harmful, because if you now traverse the list, you get redundant entries, so just remove them. diff 188535 Thu Feb 12 19:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys. Even though I increased the amount of pts(4) entries in /etc/ttys some time ago, I didn't realize back then those entries shouldn't have been there in the first place. I just looked at the getttyent() source code and it turns out when you call setttyent(), it walks through /dev/pts and looks for the device with the highest number. After you receive EOF's from getttyent(), it makes up entries for pts(4) devices. This means that adding entries for pts(4) is somewhat harmful, because if you now traverse the list, you get redundant entries, so just remove them. diff 188535 Thu Feb 12 19:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys. Even though I increased the amount of pts(4) entries in /etc/ttys some time ago, I didn't realize back then those entries shouldn't have been there in the first place. I just looked at the getttyent() source code and it turns out when you call setttyent(), it walks through /dev/pts and looks for the device with the highest number. After you receive EOF's from getttyent(), it makes up entries for pts(4) devices. This means that adding entries for pts(4) is somewhat harmful, because if you now traverse the list, you get redundant entries, so just remove them. diff 188535 Thu Feb 12 19:35:47 MST 2009 ed Remove pts(4) entries from /etc/ttys. Even though I increased the amount of pts(4) entries in /etc/ttys some time ago, I didn't realize back then those entries shouldn't have been there in the first place. I just looked at the getttyent() source code and it turns out when you call setttyent(), it walks through /dev/pts and looks for the device with the highest number. After you receive EOF's from getttyent(), it makes up entries for pts(4) devices. This means that adding entries for pts(4) is somewhat harmful, because if you now traverse the list, you get redundant entries, so just remove them. diff 182104 Sun Aug 24 08:50:42 MDT 2008 ed Restore 256 pty(4) entries. As discussed with Robert Watson on the src-committers list, it is safer to keep at least some pty(4) entries in /etc/ttys, for applications that roll their own PTY allocation routine and only search for BSD-style PTY's. This means we've now just toggled the amount of entries for pts(4) and pty(4). Requested by: rwatson diff 182104 Sun Aug 24 08:50:42 MDT 2008 ed Restore 256 pty(4) entries. As discussed with Robert Watson on the src-committers list, it is safer to keep at least some pty(4) entries in /etc/ttys, for applications that roll their own PTY allocation routine and only search for BSD-style PTY's. This means we've now just toggled the amount of entries for pts(4) and pty(4). Requested by: rwatson diff 182104 Sun Aug 24 08:50:42 MDT 2008 ed Restore 256 pty(4) entries. As discussed with Robert Watson on the src-committers list, it is safer to keep at least some pty(4) entries in /etc/ttys, for applications that roll their own PTY allocation routine and only search for BSD-style PTY's. This means we've now just toggled the amount of entries for pts(4) and pty(4). Requested by: rwatson diff 182104 Sun Aug 24 08:50:42 MDT 2008 ed Restore 256 pty(4) entries. As discussed with Robert Watson on the src-committers list, it is safer to keep at least some pty(4) entries in /etc/ttys, for applications that roll their own PTY allocation routine and only search for BSD-style PTY's. This means we've now just toggled the amount of entries for pts(4) and pty(4). Requested by: rwatson |
Completed in 353 milliseconds