Add preliminary support for some newer RTL8111/8168 Express Gigabit Ethe... #2

victoredwardocallaghan · 2013-10-22T14:44:57Z

If someone could review this please, it needs better testing. I was only really initially trying to fix my own bug: http://www.freebsd.org/cgi/query-pr.cgi?pr=183167

Kind Regards,

Signed-off-by: Edward O'Callaghan [email protected]

…thernet controllers such as the one found in PR183167. Signed-off-by: Edward O'Callaghan <[email protected]>

uqs · 2013-10-22T14:55:23Z

Hey Edward, please submit this as a PR or talk to one of the
committers that are active in that area directly. We don't (yet?) use
github for this kind of thing, sorry.

Cheers,
Uli

2013/10/22 victoredwardocallaghan [email protected]:

If someone could review this please, it needs better testing. I was only
really initially trying to fix my own bug:
http://www.freebsd.org/cgi/query-pr.cgi?pr=183167

Kind Regards,

Signed-off-by: Edward O'Callaghan [email protected]

You can merge this Pull Request by running

git pull https://github.com/victoredwardocallaghan/freebsd pr183167

Or view, comment on, or merge it at:

#2

Commit Summary

Add preliminary support for some newer RTL8111/8168 Express Gigabit Ethernet
controllers such as the one found in PR183167.

File Changes

M sys/dev/re/if_re.c (6)
M sys/pci/if_rlreg.h (3)

Patch Links:

https://github.com/freebsd/freebsd/pull/2.patch
https://github.com/freebsd/freebsd/pull/2.diff

Signed-off-by: Edward O'Callaghan <[email protected]>

drm_le_cmp() (qsort_r()'s callback) receives pointers to elements in the array passed to qsort_r(), not the elements themselves. Before this fix, the use of qsort_r() shuffled the array, not sorted it, because the compare callback accessed random memory locations, not the expected elements. This bug triggered an infinite loop in KDE/xserver: 1. KDE has a kded module called "randrmonitor" which queries xserver for current monitors at startup and then listens to RandR notifications from xserver. 2. xserver handles the query from "randrmonitor" by polling the video device using the "drm_mode_getconnector()" ioctl. This ioctl returns a list of connectors and, for those with a connected monitor, the available modes. Each modes list is sorted by the kernel before returning. When xserver gets the connectors list, it sorts the modes lists again. In the case of this bug, when two modes are equal (in xserver's compare function PoV), their order is kept stable (ie. the kernel order is kept for those two modes). And because the list was shuffled by the kernel, the order of two equal modes was frequently changed in the final modes list in xserver. 3. xserver compares the returned connectors list with the list obtained earlier. In particular, it compares the sorted modes lists for each connector. If a property of a connector changes (eg. modes), xserver sends a "RRNotify_OutputChange" notification. Because of the change of order between equal modes, xserver sent a notification after each polling of the connectors. 4. "randrmonitor" receives a notification, triggered by its query. The notification doesn't contain the new connectors list, therefore, it asks for the new list using the same function: go back to step #2. MFC after: 3 days

drm: Dereference pointers given to qsort_r()'s cmp callback drm_le_cmp() (qsort_r()'s callback) receives pointers to elements in the array passed to qsort_r(), not the elements themselves. Before this fix, the use of qsort_r() shuffled the array, not sorted it, because the compare callback accessed random memory locations, not the expected elements. This bug triggered an infinite loop in KDE/xserver: 1. KDE has a kded module called "randrmonitor" which queries xserver for current monitors at startup and then listens to RandR notifications from xserver. 2. xserver handles the query from "randrmonitor" by polling the video device using the "drm_mode_getconnector()" ioctl. This ioctl returns a list of connectors and, for those with a connected monitor, the available modes. Each modes list is sorted by the kernel before returning. When xserver gets the connectors list, it sorts the modes lists again. In the case of this bug, when two modes are equal (in xserver's compare function PoV), their order is kept stable (ie. the kernel order is kept for those two modes). And because the list was shuffled by the kernel, the order of two equal modes was frequently changed in the final modes list in xserver. 3. xserver compares the returned connectors list with the list obtained earlier. In particular, it compares the sorted modes lists for each connector. If a property of a connector changes (eg. modes), xserver sends a "RRNotify_OutputChange" notification. Because of the change of order between equal modes, xserver sent a notification after each polling of the connectors. 4. "randrmonitor" receives a notification, triggered by its query. The notification doesn't contain the new connectors list, therefore, it asks for the new list using the same function: go back to step #2. Approved by: re (kib)

multiqueue code, this functionality has proven to be more trouble than it was worth. Thanks to Gleb for a second critical look over my code and help in the patches!

Right now the only way to set the chainmask is to set the hardware configured chainmask through capabilities. This is fine for forcing the chainmask to be something other than what the hardware is capable of (eg to reduce TX/RX to one connected antenna) but it does change what the HAL hardware chainmask configuration is. For operational mode changes, it (may?) make sense to separately control the TX/RX chainmask. Right now it's done as part of ar5416_reset.c - ar5416UpdateChainMasks() calculates which TX/RX chainmasks to enable based on the operating mode. (1 for legacy and whatever is supported for 11n operation.) But doing this in the HAL is suboptimal - the driver needs to know the currently configured chainmask in order to correctly enable things for each TX descriptor. This is currently done by overriding the chainmask config in the ar5416 TX routines but this has to disappear - the AR9300 HAL support requires the driver to dynamically set the TX chainmask based on the TX power and TX rate in order to meet mini-PCIe slot power requirements. So: * Introduce a new HAL method to set the operational chainmask variables; * Introduce null methods for the previous generation chipsets; * Add new driver state to record the current chainmask separate from the hardware configured chainmask. Part #2 of this will involve disabling ar5416UpdateChainMasks() and moving it into the driver; as well as properly programming the TX chainmask based on the currently configured HAL chainmask. Tested: * AR5416, STA mode - both legacy (11a/11bg) and 11n rates - verified that AR_SELFGEN_MASK (the chainmask used for self-generated frames like ACKs and RTSes) is correct, as well as the TX descriptor contents is correct.

* Remove ar5416UpdateChainmasks(); * Remove the TX chainmask override code from the ar5416 TX descriptor setup routines; * Write a driver method to calculate the current chainmask based on the operating mode and update the driver state; * Call the HAL chainmask method before calling ath_hal_reset(); * Use the currently configured chainmask in the TX descriptors rather than the hardware TX chainmasks. Tested: * AR5416, STA/AP mode - legacy and 11n modes

would like to disable password management for an account while adding either a user or group. When being prompted to answer questions while adding a group or user, two things are trow: 1. You can hit ENTER to blast through all the questions and in the end, the group or user is created with sensible defaults for all values. 2. You can press ESC during any prompt to cancel the operation as a whole. This fix is shoring up an inconsistency in the latter (#2).

drm: Dereference pointers given to qsort_r()'s cmp callback drm_le_cmp() (qsort_r()'s callback) receives pointers to elements in the array passed to qsort_r(), not the elements themselves. Before this fix, the use of qsort_r() shuffled the array, not sorted it, because the compare callback accessed random memory locations, not the expected elements. This bug triggered an infinite loop in KDE/xserver: 1. KDE has a kded module called "randrmonitor" which queries xserver for current monitors at startup and then listens to RandR notifications from xserver. 2. xserver handles the query from "randrmonitor" by polling the video device using the "drm_mode_getconnector()" ioctl. This ioctl returns a list of connectors and, for those with a connected monitor, the available modes. Each modes list is sorted by the kernel before returning. When xserver gets the connectors list, it sorts the modes lists again. In the case of this bug, when two modes are equal (in xserver's compare function PoV), their order is kept stable (ie. the kernel order is kept for those two modes). And because the list was shuffled by the kernel, the order of two equal modes was frequently changed in the final modes list in xserver. 3. xserver compares the returned connectors list with the list obtained earlier. In particular, it compares the sorted modes lists for each connector. If a property of a connector changes (eg. modes), xserver sends a "RRNotify_OutputChange" notification. Because of the change of order between equal modes, xserver sent a notification after each polling of the connectors. 4. "randrmonitor" receives a notification, triggered by its query. The notification doesn't contain the new connectors list, therefore, it asks for the new list using the same function: go back to step #2.

multiqueue code, this functionality has proven to be more trouble than it was worth. Thanks to Gleb for a second critical look over my code and help in the patches! git-svn-id: svn://svn.freebsd.org/base/head@243716 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f

Right now the only way to set the chainmask is to set the hardware configured chainmask through capabilities. This is fine for forcing the chainmask to be something other than what the hardware is capable of (eg to reduce TX/RX to one connected antenna) but it does change what the HAL hardware chainmask configuration is. For operational mode changes, it (may?) make sense to separately control the TX/RX chainmask. Right now it's done as part of ar5416_reset.c - ar5416UpdateChainMasks() calculates which TX/RX chainmasks to enable based on the operating mode. (1 for legacy and whatever is supported for 11n operation.) But doing this in the HAL is suboptimal - the driver needs to know the currently configured chainmask in order to correctly enable things for each TX descriptor. This is currently done by overriding the chainmask config in the ar5416 TX routines but this has to disappear - the AR9300 HAL support requires the driver to dynamically set the TX chainmask based on the TX power and TX rate in order to meet mini-PCIe slot power requirements. So: * Introduce a new HAL method to set the operational chainmask variables; * Introduce null methods for the previous generation chipsets; * Add new driver state to record the current chainmask separate from the hardware configured chainmask. Part #2 of this will involve disabling ar5416UpdateChainMasks() and moving it into the driver; as well as properly programming the TX chainmask based on the currently configured HAL chainmask. Tested: * AR5416, STA mode - both legacy (11a/11bg) and 11n rates - verified that AR_SELFGEN_MASK (the chainmask used for self-generated frames like ACKs and RTSes) is correct, as well as the TX descriptor contents is correct. git-svn-id: svn://svn.freebsd.org/base/head@247286 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f

* Remove ar5416UpdateChainmasks(); * Remove the TX chainmask override code from the ar5416 TX descriptor setup routines; * Write a driver method to calculate the current chainmask based on the operating mode and update the driver state; * Call the HAL chainmask method before calling ath_hal_reset(); * Use the currently configured chainmask in the TX descriptors rather than the hardware TX chainmasks. Tested: * AR5416, STA/AP mode - legacy and 11n modes git-svn-id: svn://svn.freebsd.org/base/head@247287 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f

Mostly bugfixes or features developed in the past 6 months, so this is a 10.1 candidate. Basically no user API changes (some bugfixes in sys/net/netmap_user.h). In detail: 1. netmap support for virtio-net, including in netmap mode. Under bhyve and with a netmap backend [2] we reach over 1Mpps with standard APIs (e.g. libpcap), and 5-8 Mpps in netmap mode. 2. (kernel) add support for multiple memory allocators, so we can better partition physical and virtual interfaces giving access to separate users. The most visible effect is one additional argument to the various kernel functions to compute buffer addresses. All netmap-supported drivers are affected, but changes are mechanical and trivial 3. (kernel) simplify the prototype for *txsync() and *rxsync() driver methods. All netmap drivers affected, changes mostly mechanical. 4. add support for netmap-monitor ports. Think of it as a mirroring port on a physical switch: a netmap monitor port replicates traffic present on the main port. Restrictions apply. Drive carefully. 5. if_lem.c: support for various paravirtualization features, experimental and disabled by default. Most of these are described in our ANCS'13 paper [1]. Paravirtualized support in netmap mode is new, and beats the numbers in the paper by a large factor (under qemu-kvm, we measured gues-host throughput up to 10-12 Mpps). A lot of refactoring and additional documentation in the files in sys/dev/netmap, but apart from freebsd#2 and freebsd#3 above, almost nothing of this stuff is visible to other kernel parts. Example programs in tools/tools/netmap have been updated with bugfixes and to support more of the existing features. This is meant to go into 10.1 so we plan an MFC before the Aug.22 deadline. A lot of this code has been contributed by my colleagues at UNIPI, including Giuseppe Lettieri, Vincenzo Maffione, Stefano Garzarella. MFC after: 3 days.

Add new functions to manipulate these mode & state, instead of calling kbdd_ioctl() everyhere. This fixes at least two bugs: 1. The state of the Scroll Lock LED and the state of scroll mode could be out-of-sync. For instance, if one enables scroll mode on window #1 and switches to window #2, the LED would remain on, but the window wouldn't be in scroll mode. Similarily, when switching between a console and an X.Org session, the LED states could be inconsistent with the real state. 2. When exiting from an X.Org session, the user could be unable to type anything. The workaround was to switch to another console window and come back. Differential Revision: https://reviews.freebsd.org/D821 Reviewed by: ray@ Approved by: ray@ Tested by: kwm@ MFC after: 3 days git-svn-id: svn+ssh://svn.freebsd.org/base/head@272416 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f

Add new functions to manipulate these mode & state, instead of calling kbdd_ioctl() everyhere. This fixes at least two bugs: 1. The state of the Scroll Lock LED and the state of scroll mode could be out-of-sync. For instance, if one enables scroll mode on window #1 and switches to window #2, the LED would remain on, but the window wouldn't be in scroll mode. Similarily, when switching between a console and an X.Org session, the LED states could be inconsistent with the real state. 2. When exiting from an X.Org session, the user could be unable to type anything. The workaround was to switch to another console window and come back. Differential Revision: https://reviews.freebsd.org/D821 Reviewed by: ray@ Approved by: ray@ Tested by: kwm@ MFC after: 3 days

(MFC of r272416) Add new functions to manipulate these mode & state, instead of calling kbdd_ioctl() everyhere. This fixes at least two bugs: 1. The state of the Scroll Lock LED and the state of scroll mode could be out-of-sync. For instance, if one enables scroll mode on window #1 and switches to window #2, the LED would remain on, but the window wouldn't be in scroll mode. Similarily, when switching between a console and an X.Org session, the LED states could be inconsistent with the real state. 2. When exiting from an X.Org session, the user could be unable to type anything. The workaround was to switch to another console window and come back. Differential Revision: https://reviews.freebsd.org/D821 Reviewed by: ray@ Approved by: ray@ Tested by: kwm@

MF10: r273036 MFC: r272416 Add new functions to manipulate these mode & state, instead of calling kbdd_ioctl() everyhere. This fixes at least two bugs: 1. The state of the Scroll Lock LED and the state of scroll mode could be out-of-sync. For instance, if one enables scroll mode on window #1 and switches to window #2, the LED would remain on, but the window wouldn't be in scroll mode. Similarily, when switching between a console and an X.Org session, the LED states could be inconsistent with the real state. 2. When exiting from an X.Org session, the user could be unable to type anything. The workaround was to switch to another console window and come back. Differential Revision: https://reviews.freebsd.org/D821 Reviewed by: ray@ Approved by: re (marius), ray@ Tested by: kwm@

The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week git-svn-id: svn+ssh://svn.freebsd.org/base/head@286965 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f

The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic MFC after: 1 week

------------------------------------------------------------------------ r286965 | ken | 2015-08-20 10:07:51 -0600 (Thu, 20 Aug 2015) | 297 lines Revamp camcontrol(8) fwdownload support and add the opcodes subcommand. The significant changes and bugs fixed here are: 1. Fixed a bug in the progress display code: When the user's filename is too big, or his terminal width is too small, the progress code could wind up using a negative number for the length of the "stars" that it uses to indicate progress. This negative value was assigned to an unsigned variable, resulting in a very large positive value. The result is that we wound up writing garbage from memory to the user's terminal. With an 80 column terminal, a file name length of more than 35 characters would generate this problem. To address this, we now set a minimum progress bar length, and truncate the user's file name as needed. This has been tested with large filenames and small terminals, and at least produces reasonable results. If the terminal is too narrow, the progress display takes up an additional line with each update, but this is more user friendly than writing garbage to the tty. 2. SATA drives connected via a SATA controller didn't have SCSI Inquiry data populated in struct cam_device. This meant that the code in fw_get_vendor() in fwdownload.c would try to match a zero-length vendor ID, and so return the first entry in the vendor table. (Which used to be HITACHI.) Fixed by grabbing identify data, passing the identify buffer into fw_get_vendor(), and matching against the model name. 3. SATA drives connected via a SAS controller do have Inquiry data populated. The table included a couple of entries -- "ATA ST" and "ATA HDS", intended to handle Seagate and Hitachi SATA drives attached via a SAS controller. SCSI to ATA translation layers use a vendor ID of "ATA" (which is standard), and then the model name from the ATA identify data as the SCSI product name when they are returning data on SATA disks. The cam_strmatch code will match the first part of the string (because the length it is given is the length of the vendor, "ATA"), and return 0 (i.e. a match). So all SATA drives attached to a SAS controller would be programmed using the Seagate method (WRITE BUFFER mode 7) of SCSI firmware downloading. 4. Issue #2 above covered up a bug in fw_download_img() -- if the maximum packet size in the vendor table was 0, it tried to default to a packet size of 32K. But then it didn't actually succeed in doing that, because it set the packet size to the value that was in the vendor table (0). Now that we actually have ATA attached drives fall use the VENDOR_ATA case, we need a reasonable default packet size. So this is fixed to properly set the default packet size. 5. Add support for downloading firmware to IBM LTO drives, and add a firmware file validation method to make sure that the firmware file matches the drive type. IBM tape drives include a Load ID and RU name in their vendor-specific VPD page 0x3. Those should match the IDs in the header of the firmware file to insure that the proper firmware file is loaded. 6. This also adds a new -q option to the camcontrol fwdownload subcommand to suppress informational output. When -q is used in combination with -y, the firmware upgrade will happen without prompting and without output except if an error condition occurs. 7. Re-add support for printing out SCSI inquiry information when asking the user to confirm that they want to download firmware, and add printing of ATA Identify data if it is a SATA disk. This was removed in r237281 when support for flashing ATA disks was added. 8. Add a new camcontrol(8) "opcodes" subcommand, and use the underlying code to get recommended timeout values for drive firmware downloads. Many SCSI devices support the REPORT SUPPORTED OPERATION CODES command, and some support the optional timeout descriptor that specifies nominal and recommended timeouts for the commands supported by the device. The new camcontrol opcodes subcommand allows displaying all opcodes supported by a drive, information about which fields in a SCSI CDB are actually used by a given SCSI device, and the nominal and recommended timeout values for each command. Since firmware downloads can take a long time in some devices, and the time varies greatly between different types of devices, take advantage of the infrastructure used by the camcontrol opcodes subcommand to determine the best timeout to use for the WRITE BUFFER command in SCSI device firmware downloads. If the device recommends a timeout, it is likely to be more accurate than the default 50 second timeout used by the firmware download code. If the user specifies a timeout, it will override the default or device recommended timeout. If the device doesn't support timeout descriptors, we fall back to the default. 9. Instead of downloading firmware to SATA drives behind a SAS controller using WRITE BUFFER, use the SCSI ATA PASS-THROUGH command to compose an ATA DOWNLOAD MICROCODE command and it to the drive. The previous version of this code attempted to send a SCSI WRITE BUFFER command to SATA drives behind a SAS controller. Although that is part of the SAT-3 spec, it doesn't work with the parameters used with LSI controllers at least. 10.Add a new mechanism for making common ATA passthrough and ATA-behind-SCSI passthrough commands. The existing camcontrol(8) ATA command mechanism checks the device type on every command executed. That works fine for individual commands, but is cumbersome for things like a firmware download that send a number of commands. The fwdownload code detects the device type up front, and then sends the appropriate commands. 11.In simulation mode (-s), if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. sbin/camcontrol/fwdownload.c: Add a device type to the fw_vendor structure, so that we can specify different download methods for different devices from the same vendor. In this case, IBM hard drives (from when they still made hard drives) and tape drives. Add a tur_status field to the fw_vendor structure so that we can specify whether the drive to be upgraded should be ready, not ready, or whether it doesn't matter. Add the corresponding capability in fw_download_img(). Add comments describing each of the vendor table fields. Add HGST and SmrtStor to the supported SCSI vendors list. In fw_get_vendor(), look at ATA identify data if we have a SATA device to try to identify what the drive vendor is. Add IBM firmware file validation. This gets VPD page 0x3, and compares the Load ID and RU name in the page to the values included in the header. The validation code will refuse to load a firmware file if the values don't match. This does allow the user to attempt a downgrade; whether or not it succeeds will likely depend on the drive settings. Add a -q option, and disable all informative output (progress bars, etc.) when this is enabled. Re-add the inquiry in the confirmation dialog so the user has a better idea of which device he is talking to. Add support for displaying ATA identify data. Don't automatically disable confirmation in simulation (-s) mode. This allows the user to see the inquiry or identify data in the dialog, and see exactly what they would see when the command actually runs. Also, in simulation mode, if the user specifies the -v flag, print out the SCSI CDB or ATA registers that would be sent to the drive. This will aid in debugging any firmware download issues. Add a timeout field and timeout type to the firmware download vendor table. This allows specifying a default timeout and allows specifying whether we should attempt to probe for a recommended timeout from the drive. Add a new fuction, fw_get_timeout(), that will determine which timeout to use for the WRITE BUFFER command. If the user specifies a timeout, we always use that. Otherwise, we will use the drive recommended timeout, if available, and fall back to the default when a drive recommended timeout isn't available. When we prompt the user, tell him what timeout we're going to use, and the source of the timeout. Revamp the way SATA devices are handled. In fwdownload(), use the new get_device_type() function to determine what kind of device we're talking to. Allow firmware downloads to any SATA device, but restrict SCSI downloads to known devices. (The latter is not a change in behavior.) Break out the "ready" check from fw_download_img() into a new subfunction, fw_check_device_ready(). This sends the appropriate command to the device in question -- a TEST UNIT READY or an IDENTIFY. The IDENTIFY for SATA devices a SAT layer is done using the SCSI ATA PASS-THROUGH command. Use the new build_ata_cmd() function to build either a SCSI or ATA I/O CCB to issue the DOWNLOAD MICROCODE command to SATA devices. build_ata_cmd() figures looks at the devtype argument and fills in the correct CCB type and CDB or ATA registers. Revamp the vendor table to remove the previous vendor-specific ATA entries and use a generic ATA vendor placeholder. We currently use the same method for all ATA drives, although we may have to add vendor-specific behavior once we test this with more drives. sbin/camcontrol/progress.c: In progress_draw(), make barlength a signed value so that we can easily detect a negative value. If barlength (the length of the progress bar) would wind up negative due to a small TTY width or a large filename, set the bar length to the new minimum (10 stars) and truncate the user's filename. We will truncate it down to 0 characters if necessary. Calculate a new prefix_len variable (user's filename length) and use it as the precision when printing the filename. sbin/camcontrol/camcontrol.c: Implement a new camcontrol(8) subcommand, "opcodes". The opcodes subcommand allows displaying the entire list of SCSI commands supported by a device, or details on an individual command. In either case, it can display nominal and recommended timeout values. Add the scsiopcodes() function, which calls the new scsigetopcodes() function to fetch opcode data from a drive. Add two new functions, scsiprintoneopcode() and scsiprintopcodes(), which print information about one opcode or all opcodes, respectively. Remove the get_disk_type() function. It is no longer used. Add a new function, dev_has_vpd_page(), that fetches the supported INQUIRY VPD list from a device and tells the caller whether the requested VPD page is available. Add a new function, get_device_type(), that returns a more precise device type than the old get_disk_type() function. The get_disk_type() function only distinguished between SCSI and ATA devices, and SATA devices behind a SCSI to ATA translation layer were considered to be "SCSI". get_device_type() offers a third type, CC_DT_ATA_BEHIND_SCSI. We need to know this to know whether to attempt to send ATA passthrough commands. If the device has the ATA Information VPD page (0x89), then it is an ATA device behind a SCSI to ATA translation layer. Remove the type argument from the fwdownload() subcommand. Add a new function, build_ata_cmd(), that will take one set of common arguments and build either a SCSI or ATA I/O CCB, depending on the device type passed in. sbin/camcontrol/camcontrol.h: Add a prototype for scsigetopcodes(). Add a new enumeration, camcontrol_devtype. Add prototypes for dev_has_vpd_page(), get_device_type() and build_ata_cmd(). Remove the type argument from the fwdownload() subcommand. sbin/camcontrol/camcontrol.8 Explain that the fwdownload subcommand will use the drive recommended timeout if available, and that the user can override the timeout. Document the new opcodes subcommand. Explain that we will attempt to download firmware to any SATA device. Document supported SCSI vendors, and models tested if known. Explain the commands used to download firmware for the three different drive and controller combinations. Document that the -v flag in simulation mode for the fwdownload subcommand will print out the SCSI CDBs or ATA registers that would be used. sys/cam/scsi/scsi_all.h: Add new bit definitions for the one opcode descriptor for the REPORT SUPPORTED OPCODES command. Add a function prototype for scsi_report_supported_opcodes(). sys/cam/scsi/scsi_all.c: Add a new CDB building function, scsi_report_supported_opcodes(). Sponsored by: Spectra Logic

The new load_ma implementation can cause dereferences when used with certain drivers, back it out until the reason is found: Fatal trap 12: page fault while in kernel mode cpuid = 11; apic id = 03 fault virtual address = 0x30 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff808a2d22 stack pointer = 0x28:0xfffffe07cc737710 frame pointer = 0x28:0xfffffe07cc737790 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 13 (g_down) trap number = 12 panic: page fault cpuid = 11 KDB: stack backtrace: #0 0xffffffff80641647 at kdb_backtrace+0x67 #1 0xffffffff80606762 at vpanic+0x182 #2 0xffffffff806067e3 at panic+0x43 #3 0xffffffff8084eef1 at trap_fatal+0x351 #4 0xffffffff8084f0e4 at trap_pfault+0x1e4 #5 0xffffffff8084e82f at trap+0x4bf #6 0xffffffff80830d57 at calltrap+0x8 #7 0xffffffff8063beab at _bus_dmamap_load_ccb+0x1fb #8 0xffffffff8063bc51 at bus_dmamap_load_ccb+0x91 #9 0xffffffff8042dcad at ata_dmaload+0x11d #10 0xffffffff8042df7e at ata_begin_transaction+0x7e #11 0xffffffff8042c18e at ataaction+0x9ce #12 0xffffffff802a220f at xpt_run_devq+0x5bf #13 0xffffffff802a17ad at xpt_action_default+0x94d #14 0xffffffff802c0024 at adastart+0x8b4 #15 0xffffffff802a2e93 at xpt_run_allocq+0x193 #16 0xffffffff802c0735 at adastrategy+0xf5 #17 0xffffffff80554206 at g_disk_start+0x426 Uptime: 2m29s git-svn-id: svn+ssh://svn.freebsd.org/base/head@290005 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f

The new load_ma implementation can cause dereferences when used with certain drivers, back it out until the reason is found: Fatal trap 12: page fault while in kernel mode cpuid = 11; apic id = 03 fault virtual address = 0x30 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff808a2d22 stack pointer = 0x28:0xfffffe07cc737710 frame pointer = 0x28:0xfffffe07cc737790 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 13 (g_down) trap number = 12 panic: page fault cpuid = 11 KDB: stack backtrace: #0 0xffffffff80641647 at kdb_backtrace+0x67 #1 0xffffffff80606762 at vpanic+0x182 #2 0xffffffff806067e3 at panic+0x43 #3 0xffffffff8084eef1 at trap_fatal+0x351 #4 0xffffffff8084f0e4 at trap_pfault+0x1e4 #5 0xffffffff8084e82f at trap+0x4bf #6 0xffffffff80830d57 at calltrap+0x8 #7 0xffffffff8063beab at _bus_dmamap_load_ccb+0x1fb #8 0xffffffff8063bc51 at bus_dmamap_load_ccb+0x91 #9 0xffffffff8042dcad at ata_dmaload+0x11d #10 0xffffffff8042df7e at ata_begin_transaction+0x7e #11 0xffffffff8042c18e at ataaction+0x9ce #12 0xffffffff802a220f at xpt_run_devq+0x5bf #13 0xffffffff802a17ad at xpt_action_default+0x94d #14 0xffffffff802c0024 at adastart+0x8b4 #15 0xffffffff802a2e93 at xpt_run_allocq+0x193 #16 0xffffffff802c0735 at adastrategy+0xf5 #17 0xffffffff80554206 at g_disk_start+0x426 Uptime: 2m29s

When processing loader.conf if console contained an entry for an unsupported console then cons_set would return an error refusing to set any console. This has two side effects: 1. Forth would throw a syntax error and stop processing loader.conf at that point. 2. The value of console is ignored. #1 Means other important loader.conf entries may not be processed, which is clearly undesirable. #2 Means the users preference for console aren't applied even if they did contain valid options. Now we have support for multi boot paths from a single image e.g. bios and efi mode the console preference needs to deal with the need to set preference for more than one source. Fix this by: * Returning CMD_OK where possible from cons_set. * Allowing set with at least one valid console to proceed. Reviewed by: allanjude MFC after: 1 week Sponsored by: Multiplay Differential Revision: https://reviews.freebsd.org/D5018 git-svn-id: svn+ssh://svn.freebsd.org/base/head@294506 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f

When processing loader.conf if console contained an entry for an unsupported console then cons_set would return an error refusing to set any console. This has two side effects: 1. Forth would throw a syntax error and stop processing loader.conf at that point. 2. The value of console is ignored. #1 Means other important loader.conf entries may not be processed, which is clearly undesirable. #2 Means the users preference for console aren't applied even if they did contain valid options. Now we have support for multi boot paths from a single image e.g. bios and efi mode the console preference needs to deal with the need to set preference for more than one source. Fix this by: * Returning CMD_OK where possible from cons_set. * Allowing set with at least one valid console to proceed. Reviewed by: allanjude MFC after: 1 week Sponsored by: Multiplay Differential Revision: https://reviews.freebsd.org/D5018

When processing loader.conf if console contained an entry for an unsupported console then cons_set would return an error refusing to set any console. This has two side effects: 1. Forth would throw a syntax error and stop processing loader.conf at that point. 2. The value of console is ignored. freebsd#1 Means other important loader.conf entries may not be processed, which is clearly undesirable. freebsd#2 Means the users preference for console aren't applied even if they did contain valid options. Now we have support for multi boot paths from a single image e.g. bios and efi mode the console preference needs to deal with the need to set preference for more than one source. Fix this by: * Returning CMD_OK where possible from cons_set. * Allowing set with at least one valid console to proceed. Reviewed by: allanjude MFC after: 1 week Sponsored by: Multiplay Differential Revision: https://reviews.freebsd.org/D5018 git-svn-id: svn+ssh://svn.freebsd.org/base/head@294506 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f

Tested with: * Intel 3945BG, STA mode. * RTL8188EU, IBSS mode. Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5143 git-svn-id: svn+ssh://svn.freebsd.org/base/head@296231 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f

Tested with: * Intel 3945BG, STA mode. * RTL8188EU, IBSS mode. Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5143

Tested with: * Intel 3945BG, STA mode. * RTL8188EU, IBSS mode. Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5143 git-svn-id: svn+ssh://svn.freebsd.org/base/head@296231 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f

After devel/boost-libs is updated to 1.81.0, build fails on -CURRENT because of clang's assertion failure as following. clang-linux.compile.c++ bin.v2/libs/url/build/clang-linux-16/release/link-static/pch-off/threading-multi/visibility-hidden/src.o "c++" -c -x c++ -fvisibility-inlines-hidden -m64 -pthread -O3 -Wall -fvisibility=hidden -Wno-inline -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -DLIBICONV_PLUG -std=gnu++17 -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -DBOOST_ALL_NO_LIB=1 -DBOOST_URL_SOURCE -DBOOST_URL_STATIC_LINK=1 -DNDEBUG -I"." -o "bin.v2/libs/url/build/clang-linux-16/release/link-static/pch-off/threading-multi/visibility-hidden/src.o" "libs/url/src/src.cpp" Assertion failed: (isa<To>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Casting.h, line 579. PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: c++ -c -x c++ -fvisibility-inlines-hidden -m64 -pthread -O3 -Wall -fvisibility=hidden -Wno-inline -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -DLIBICONV_PLUG -std=gnu++17 -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -DBOOST_ALL_NO_LIB=1 -DBOOST_URL_SOURCE -DBOOST_URL_STATIC_LINK=1 -DNDEBUG -I. -o bin.v2/libs/url/build/clang-linux-16/release/link-static/pch-off/threading-multi/visibility-hidden/src.o libs/url/src/src.cpp 1. ./boost/url/impl/segments_view.ipp:33:1: current parser token '{' 2. ./boost/url/impl/segments_view.ipp:17:1: parsing namespace 'boost' 3. ./boost/url/impl/segments_view.ipp:18:1: parsing namespace 'boost::urls' #0 0x00000000058158c1 PrintStackTrace /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:567:13 freebsd#1 0x0000000005813c45 RunSignalHandlers /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:105:18 freebsd#2 0x00000000057bb7cb HandleCrash /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:73:5 freebsd#3 0x00000000057bb7cb CrashRecoverySignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:390:51 freebsd#4 0x000000082a4a9a8f handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3 freebsd#5 0x000000082a4a904b thr_sighandler /usr/src/lib/libthr/thread/thr_sig.c:247:1 freebsd#6 0x000000082802a2d3 ([vdso]+0x2d3) freebsd#7 0x000000082e2a3cda thr_kill /usr/obj/usr/src/amd64.amd64/lib/libc/thr_kill.S:4:0 freebsd#8 0x000000082e21d1f4 raise /usr/src/lib/libc/gen/raise.c:0:10 freebsd#9 0x000000082e2cd3b9 abort /usr/src/lib/libc/stdlib/abort.c:73:17 c++: error: clang frontend command failed with exit code 134 (use -v to see invocation) FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152) Target: x86_64-unknown-freebsd14.0 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/src-00f4ba.cpp c++: note: diagnostic msg: /tmp/src-00f4ba.sh c++: note: diagnostic msg: ******************** ...failed clang-linux.compile.c++ bin.v2/libs/url/build/clang-linux-16/release/link-static/pch-off/threading-multi/visibility-hidden/src.o... So add upstream patch to fix it. PR: 269067 Obtained from: https://reviews.llvm.org/D148474

This reverts commit 64e62bdf04ab8529f45ed0a85122c703035dec3a. This commit ends up causing some lockdep splats due to trying to grab the payload lock while holding the mgr's lock: [ 54.010099] [ 54.011765] ====================================================== [ 54.018670] WARNING: possible circular locking dependency detected [ 54.025577] 5.5.0-rc6-02274-g77381c23ee63 freebsd#47 Not tainted [ 54.031610] ------------------------------------------------------ [ 54.038516] kworker/1:6/1040 is trying to acquire lock: [ 54.044354] ffff888272af3228 (&mgr->payload_lock){+.+.}, at: drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4 [ 54.054957] [ 54.054957] but task is already holding lock: [ 54.061473] ffff888272af3060 (&mgr->lock){+.+.}, at: drm_dp_mst_topology_mgr_set_mst+0x3c/0x2e4 [ 54.071193] [ 54.071193] which lock already depends on the new lock. [ 54.071193] [ 54.080334] [ 54.080334] the existing dependency chain (in reverse order) is: [ 54.088697] [ 54.088697] -> freebsd#1 (&mgr->lock){+.+.}: [ 54.094440] __mutex_lock+0xc3/0x498 [ 54.099015] drm_dp_mst_topology_get_port_validated+0x25/0x80 [ 54.106018] drm_dp_update_payload_part1+0xa2/0x2e2 [ 54.112051] intel_mst_pre_enable_dp+0x144/0x18f [ 54.117791] intel_encoders_pre_enable+0x63/0x70 [ 54.123532] hsw_crtc_enable+0xa1/0x722 [ 54.128396] intel_update_crtc+0x50/0x194 [ 54.133455] skl_commit_modeset_enables+0x40c/0x540 [ 54.139485] intel_atomic_commit_tail+0x5f7/0x130d [ 54.145418] intel_atomic_commit+0x2c8/0x2d8 [ 54.150770] drm_atomic_helper_set_config+0x5a/0x70 [ 54.156801] drm_mode_setcrtc+0x2ab/0x833 [ 54.161862] drm_ioctl+0x2e5/0x424 [ 54.166242] vfs_ioctl+0x21/0x2f [ 54.170426] do_vfs_ioctl+0x5fb/0x61e [ 54.175096] ksys_ioctl+0x55/0x75 [ 54.179377] __x64_sys_ioctl+0x1a/0x1e [ 54.184146] do_syscall_64+0x5c/0x6d [ 54.188721] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 54.194946] [ 54.194946] -> #0 (&mgr->payload_lock){+.+.}: [ 54.201463] [ 54.201463] other info that might help us debug this: [ 54.201463] [ 54.210410] Possible unsafe locking scenario: [ 54.210410] [ 54.217025] CPU0 CPU1 [ 54.222082] ---- ---- [ 54.227138] lock(&mgr->lock); [ 54.230643] lock(&mgr->payload_lock); [ 54.237742] lock(&mgr->lock); [ 54.244062] lock(&mgr->payload_lock); [ 54.248346] [ 54.248346] *** DEADLOCK *** [ 54.248346] [ 54.254959] 7 locks held by kworker/1:6/1040: [ 54.259822] #0: ffff888275c4f528 ((wq_completion)events){+.+.}, at: worker_thread+0x455/0x6e2 [ 54.269451] freebsd#1: ffffc9000119beb0 ((work_completion)(&(&dev_priv->hotplug.hotplug_work)->work)){+.+.}, at: worker_thread+0x455/0x6e2 [ 54.282768] freebsd#2: ffff888272a403f0 (&dev->mode_config.mutex){+.+.}, at: i915_hotplug_work_func+0x4b/0x2be [ 54.293368] freebsd#3: ffffffff824fc6c0 (drm_connector_list_iter){.+.+}, at: i915_hotplug_work_func+0x17e/0x2be [ 54.304061] freebsd#4: ffffc9000119bc58 (crtc_ww_class_acquire){+.+.}, at: drm_helper_probe_detect_ctx+0x40/0xfd [ 54.314855] freebsd#5: ffff888272a40470 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_lock+0x74/0xe2 [ 54.324385] freebsd#6: ffff888272af3060 (&mgr->lock){+.+.}, at: drm_dp_mst_topology_mgr_set_mst+0x3c/0x2e4 [ 54.334597] [ 54.334597] stack backtrace: [ 54.339464] CPU: 1 PID: 1040 Comm: kworker/1:6 Not tainted 5.5.0-rc6-02274-g77381c23ee63 freebsd#47 [ 54.348893] Hardware name: Google Fizz/Fizz, BIOS Google_Fizz.10139.39.0 01/04/2018 [ 54.357451] Workqueue: events i915_hotplug_work_func [ 54.362995] Call Trace: [ 54.365724] dump_stack+0x71/0x9c [ 54.369427] check_noncircular+0x91/0xbc [ 54.373809] ? __lock_acquire+0xc9e/0xf66 [ 54.378286] ? __lock_acquire+0xc9e/0xf66 [ 54.382763] ? lock_acquire+0x175/0x1ac [ 54.387048] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4 [ 54.393177] ? __mutex_lock+0xc3/0x498 [ 54.397362] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4 [ 54.403492] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4 [ 54.409620] ? drm_dp_dpcd_access+0xd9/0x101 [ 54.414390] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4 [ 54.420517] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4 [ 54.426645] ? intel_digital_port_connected+0x34d/0x35c [ 54.432482] ? intel_dp_detect+0x227/0x44e [ 54.437056] ? ww_mutex_lock+0x49/0x9a [ 54.441242] ? drm_helper_probe_detect_ctx+0x75/0xfd [ 54.446789] ? intel_encoder_hotplug+0x4b/0x97 [ 54.451752] ? intel_ddi_hotplug+0x61/0x2e0 [ 54.456423] ? mark_held_locks+0x53/0x68 [ 54.460803] ? _raw_spin_unlock_irqrestore+0x3a/0x51 [ 54.466347] ? lockdep_hardirqs_on+0x187/0x1a4 [ 54.471310] ? drm_connector_list_iter_next+0x89/0x9a [ 54.476953] ? i915_hotplug_work_func+0x206/0x2be [ 54.482208] ? worker_thread+0x4d5/0x6e2 [ 54.486587] ? worker_thread+0x455/0x6e2 [ 54.490966] ? queue_work_on+0x64/0x64 [ 54.495151] ? kthread+0x1e9/0x1f1 [ 54.498946] ? queue_work_on+0x64/0x64 [ 54.503130] ? kthread_unpark+0x5e/0x5e [ 54.507413] ? ret_from_fork+0x3a/0x50 The proper fix for this is probably cleanup the VCPI allocations when we're enabling the topology, or on the first payload allocation. For now though, let's just revert. Signed-off-by: Lyude Paul <[email protected]> Fixes: 64e62bdf04ab ("drm/dp_mst: Remove VCPI while disabling topology mgr") Cc: Sean Paul <[email protected]> Cc: Wayne Lin <[email protected]> Reviewed-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

After devel/boost-libs is updated to 1.81.0, build fails on -CURRENT because of clang's assertion failure as following. clang-linux.compile.c++ bin.v2/libs/url/build/clang-linux-16/release/link-static/pch-off/threading-multi/visibility-hidden/src.o "c++" -c -x c++ -fvisibility-inlines-hidden -m64 -pthread -O3 -Wall -fvisibility=hidden -Wno-inline -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -DLIBICONV_PLUG -std=gnu++17 -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -DBOOST_ALL_NO_LIB=1 -DBOOST_URL_SOURCE -DBOOST_URL_STATIC_LINK=1 -DNDEBUG -I"." -o "bin.v2/libs/url/build/clang-linux-16/release/link-static/pch-off/threading-multi/visibility-hidden/src.o" "libs/url/src/src.cpp" Assertion failed: (isa<To>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Casting.h, line 579. PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: c++ -c -x c++ -fvisibility-inlines-hidden -m64 -pthread -O3 -Wall -fvisibility=hidden -Wno-inline -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -DLIBICONV_PLUG -std=gnu++17 -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -DBOOST_ALL_NO_LIB=1 -DBOOST_URL_SOURCE -DBOOST_URL_STATIC_LINK=1 -DNDEBUG -I. -o bin.v2/libs/url/build/clang-linux-16/release/link-static/pch-off/threading-multi/visibility-hidden/src.o libs/url/src/src.cpp 1. ./boost/url/impl/segments_view.ipp:33:1: current parser token '{' 2. ./boost/url/impl/segments_view.ipp:17:1: parsing namespace 'boost' 3. ./boost/url/impl/segments_view.ipp:18:1: parsing namespace 'boost::urls' #0 0x00000000058158c1 PrintStackTrace /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:567:13 freebsd#1 0x0000000005813c45 RunSignalHandlers /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:105:18 freebsd#2 0x00000000057bb7cb HandleCrash /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:73:5 freebsd#3 0x00000000057bb7cb CrashRecoverySignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:390:51 freebsd#4 0x000000082a4a9a8f handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3 freebsd#5 0x000000082a4a904b thr_sighandler /usr/src/lib/libthr/thread/thr_sig.c:247:1 freebsd#6 0x000000082802a2d3 ([vdso]+0x2d3) freebsd#7 0x000000082e2a3cda thr_kill /usr/obj/usr/src/amd64.amd64/lib/libc/thr_kill.S:4:0 freebsd#8 0x000000082e21d1f4 raise /usr/src/lib/libc/gen/raise.c:0:10 freebsd#9 0x000000082e2cd3b9 abort /usr/src/lib/libc/stdlib/abort.c:73:17 c++: error: clang frontend command failed with exit code 134 (use -v to see invocation) FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152) Target: x86_64-unknown-freebsd14.0 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/src-00f4ba.cpp c++: note: diagnostic msg: /tmp/src-00f4ba.sh c++: note: diagnostic msg: ******************** ...failed clang-linux.compile.c++ bin.v2/libs/url/build/clang-linux-16/release/link-static/pch-off/threading-multi/visibility-hidden/src.o... So add upstream patch to fix it. PR: 269067 Obtained from: https://reviews.llvm.org/D148474

Specifically, altering the console list with conscontrol has some weird behavior: 1. If you remove the first configured console, /dev/console will become unconfigured 2. Any console added becomes the /dev/console In a multicons situation, #1 is clearly a bug and #2 is perhaps slightly less clear. If we have ttyu0, ttyv0, then it seems obvious that one would want ttyv0 to take over the console if ttyu0 is removed. If we add ttyu0 back in, then it's debatable whether it should take over the console or not. Fix it now to make the /dev/console selection more FIFO-ish, with respect to how conscontrol affects it. A `primary` verb for conscontrol(8) might be a good addition.

After devel/boost-libs is updated to 1.81.0, build fails on -CURRENT because of clang's assertion failure as following. clang-linux.compile.c++ bin.v2/libs/url/build/clang-linux-16/release/link-static/pch-off/threading-multi/visibility-hidden/src.o "c++" -c -x c++ -fvisibility-inlines-hidden -m64 -pthread -O3 -Wall -fvisibility=hidden -Wno-inline -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -DLIBICONV_PLUG -std=gnu++17 -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -DBOOST_ALL_NO_LIB=1 -DBOOST_URL_SOURCE -DBOOST_URL_STATIC_LINK=1 -DNDEBUG -I"." -o "bin.v2/libs/url/build/clang-linux-16/release/link-static/pch-off/threading-multi/visibility-hidden/src.o" "libs/url/src/src.cpp" Assertion failed: (isa<To>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Casting.h, line 579. PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: c++ -c -x c++ -fvisibility-inlines-hidden -m64 -pthread -O3 -Wall -fvisibility=hidden -Wno-inline -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -DLIBICONV_PLUG -std=gnu++17 -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -DBOOST_ALL_NO_LIB=1 -DBOOST_URL_SOURCE -DBOOST_URL_STATIC_LINK=1 -DNDEBUG -I. -o bin.v2/libs/url/build/clang-linux-16/release/link-static/pch-off/threading-multi/visibility-hidden/src.o libs/url/src/src.cpp 1. ./boost/url/impl/segments_view.ipp:33:1: current parser token '{' 2. ./boost/url/impl/segments_view.ipp:17:1: parsing namespace 'boost' 3. ./boost/url/impl/segments_view.ipp:18:1: parsing namespace 'boost::urls' #0 0x00000000058158c1 PrintStackTrace /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:567:13 freebsd#1 0x0000000005813c45 RunSignalHandlers /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:105:18 freebsd#2 0x00000000057bb7cb HandleCrash /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:73:5 freebsd#3 0x00000000057bb7cb CrashRecoverySignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:390:51 freebsd#4 0x000000082a4a9a8f handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3 freebsd#5 0x000000082a4a904b thr_sighandler /usr/src/lib/libthr/thread/thr_sig.c:247:1 freebsd#6 0x000000082802a2d3 ([vdso]+0x2d3) freebsd#7 0x000000082e2a3cda thr_kill /usr/obj/usr/src/amd64.amd64/lib/libc/thr_kill.S:4:0 freebsd#8 0x000000082e21d1f4 raise /usr/src/lib/libc/gen/raise.c:0:10 freebsd#9 0x000000082e2cd3b9 abort /usr/src/lib/libc/stdlib/abort.c:73:17 c++: error: clang frontend command failed with exit code 134 (use -v to see invocation) FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152) Target: x86_64-unknown-freebsd14.0 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/src-00f4ba.cpp c++: note: diagnostic msg: /tmp/src-00f4ba.sh c++: note: diagnostic msg: ******************** ...failed clang-linux.compile.c++ bin.v2/libs/url/build/clang-linux-16/release/link-static/pch-off/threading-multi/visibility-hidden/src.o... So add upstream patch to fix it. PR: 269067 Obtained from: https://reviews.llvm.org/D148474

Specifically, altering the console list with conscontrol has some weird behavior: 1. If you remove the first configured console, /dev/console will become unconfigured 2. Any console added becomes the /dev/console In a multicons situation, #1 is clearly a bug and freebsd#2 is perhaps slightly less clear. If we have ttyu0, ttyv0, then it seems obvious that one would want ttyv0 to take over the console if ttyu0 is removed. If we add ttyu0 back in, then it's debatable whether it should take over the console or not. Fix it now to make the /dev/console selection more FIFO-ish, with respect to how conscontrol affects it. A `primary` verb for conscontrol(8) might be a good addition. (cherry picked from commit 3aca29f6e98ca4e807d714ad73e322d975073c2f)

After devel/boost-libs is updated to 1.81.0, build fails on -CURRENT because of clang's assertion failure as following. clang-linux.compile.c++ bin.v2/libs/url/build/clang-linux-16/release/link-static/pch-off/threading-multi/visibility-hidden/src.o "c++" -c -x c++ -fvisibility-inlines-hidden -m64 -pthread -O3 -Wall -fvisibility=hidden -Wno-inline -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -DLIBICONV_PLUG -std=gnu++17 -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -DBOOST_ALL_NO_LIB=1 -DBOOST_URL_SOURCE -DBOOST_URL_STATIC_LINK=1 -DNDEBUG -I"." -o "bin.v2/libs/url/build/clang-linux-16/release/link-static/pch-off/threading-multi/visibility-hidden/src.o" "libs/url/src/src.cpp" Assertion failed: (isa<To>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Casting.h, line 579. PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: c++ -c -x c++ -fvisibility-inlines-hidden -m64 -pthread -O3 -Wall -fvisibility=hidden -Wno-inline -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -DLIBICONV_PLUG -std=gnu++17 -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -DBOOST_ALL_NO_LIB=1 -DBOOST_URL_SOURCE -DBOOST_URL_STATIC_LINK=1 -DNDEBUG -I. -o bin.v2/libs/url/build/clang-linux-16/release/link-static/pch-off/threading-multi/visibility-hidden/src.o libs/url/src/src.cpp 1. ./boost/url/impl/segments_view.ipp:33:1: current parser token '{' 2. ./boost/url/impl/segments_view.ipp:17:1: parsing namespace 'boost' 3. ./boost/url/impl/segments_view.ipp:18:1: parsing namespace 'boost::urls' #0 0x00000000058158c1 PrintStackTrace /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:567:13 freebsd#1 0x0000000005813c45 RunSignalHandlers /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:105:18 freebsd#2 0x00000000057bb7cb HandleCrash /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:73:5 freebsd#3 0x00000000057bb7cb CrashRecoverySignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:390:51 freebsd#4 0x000000082a4a9a8f handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3 freebsd#5 0x000000082a4a904b thr_sighandler /usr/src/lib/libthr/thread/thr_sig.c:247:1 freebsd#6 0x000000082802a2d3 ([vdso]+0x2d3) freebsd#7 0x000000082e2a3cda thr_kill /usr/obj/usr/src/amd64.amd64/lib/libc/thr_kill.S:4:0 freebsd#8 0x000000082e21d1f4 raise /usr/src/lib/libc/gen/raise.c:0:10 freebsd#9 0x000000082e2cd3b9 abort /usr/src/lib/libc/stdlib/abort.c:73:17 c++: error: clang frontend command failed with exit code 134 (use -v to see invocation) FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152) Target: x86_64-unknown-freebsd14.0 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/src-00f4ba.cpp c++: note: diagnostic msg: /tmp/src-00f4ba.sh c++: note: diagnostic msg: ******************** ...failed clang-linux.compile.c++ bin.v2/libs/url/build/clang-linux-16/release/link-static/pch-off/threading-multi/visibility-hidden/src.o... So add upstream patch to fix it. PR: 269067 Obtained from: https://reviews.llvm.org/D148474

Specifically, altering the console list with conscontrol has some weird behavior: 1. If you remove the first configured console, /dev/console will become unconfigured 2. Any console added becomes the /dev/console In a multicons situation, #1 is clearly a bug and freebsd#2 is perhaps slightly less clear. If we have ttyu0, ttyv0, then it seems obvious that one would want ttyv0 to take over the console if ttyu0 is removed. If we add ttyu0 back in, then it's debatable whether it should take over the console or not. Fix it now to make the /dev/console selection more FIFO-ish, with respect to how conscontrol affects it. A `primary` verb for conscontrol(8) might be a good addition. (cherry picked from commit f508dfd7e6a70417ceb6393fb136ae17012d261b)

(cherry picked from commit cca14773ebd9272081f115f48e8c10a1d8e607b9)

Add preliminary support for some newer RTL8111/8168 Express Gigabit E…

7d54f47

…thernet controllers such as the one found in PR183167. Signed-off-by: Edward O'Callaghan <[email protected]>

re(4) resync to support 8168G, 8168EP, 8168GU, 8411B and 8106EUS hw rev.

0c20630

Signed-off-by: Edward O'Callaghan <[email protected]>

uqs pushed a commit that referenced this pull request Jan 3, 2015

Finish r275628 #2: remove remaining 'base' references.

01455c8

uqs pushed a commit that referenced this pull request Feb 29, 2016

net80211: split scan_task() (#2) (add scan_end() function)

61cdf21

Tested with: * Intel 3945BG, STA mode. * RTL8188EU, IBSS mode. Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5143

bnovkov referenced this pull request in bnovkov/freebsd-src Jan 10, 2024

vm_compact: defrag loop fixes #2

af14091

kevans91 pushed a commit to kevans91/freebsd that referenced this pull request Mar 31, 2024

squashfs: PR(freebsd#2)

e0cb4f3

kevans91 pushed a commit to kevans91/freebsd that referenced this pull request Jun 10, 2024

squashfs: PR(freebsd#2)

ab23398

(cherry picked from commit cca14773ebd9272081f115f48e8c10a1d8e607b9)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add preliminary support for some newer RTL8111/8168 Express Gigabit Ethe... #2

Add preliminary support for some newer RTL8111/8168 Express Gigabit Ethe... #2

victoredwardocallaghan commented Oct 22, 2013

uqs commented Oct 22, 2013

Add preliminary support for some newer RTL8111/8168 Express Gigabit Ethe... #2

Add preliminary support for some newer RTL8111/8168 Express Gigabit Ethe... #2

Conversation

victoredwardocallaghan commented Oct 22, 2013

uqs commented Oct 22, 2013