aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/esp
diff options
context:
space:
mode:
authorWarner Losh <imp@FreeBSD.org>2022-02-22 17:34:36 +0000
committerWarner Losh <imp@FreeBSD.org>2022-03-09 20:52:22 +0000
commit327da43602cc40836d0858e22e200f5e39edae4b (patch)
tree4b1322adeb81342cf1c0e6fafc374e7f3a90b645 /sys/dev/esp
parent081619a5070f83f4435c4ea4f35f2252e36880f0 (diff)
camcontrol: Force a rescan of the lun after firmware download.
After downloading the firmware to a device, it's inquiry data likely will change. Force a rescan of the target with the CAM_EXPECT_INQ_CHANGE flag to get it to record the new inqury data as being expected. This avoids the need for a 'camcontrol rescan' on the device which detaches and re-attaches the disk (da, ada) device. This brings fwdownload up to nvmecontrol's ability to do the same thing w/o changing the exposed nvme/nvd/nda device. We scan the target and not the LUN because dual actuator drives have multiple LUNs, but the firmware is global across many vendors' drives (and the so far theoretical ones that aren't won't be harmed by the rescan). Since the underlying struct disk is now preserved accross this operation, it's now possible to upgrade firmware of a root device w/o crashing the system. On systems that are quite busy, the worst that happens is that certain operaions are reported cancelled when the new firmware is activated. These operations are retried with the normal CAM recovery mechanisms and will work on the retry. The only visible hiccup is the time that new firmware is flashing / initializing. One should not consider this operation completely risk free, however, since not all drives are well behaved after a firmware download. MFC After: 1 week Relnotes: yes Sponsored by: Netflix Feedback by: mav Differential Revision: https://reviews.freebsd.org/D34325 (cherry picked from commit 9835900cb95bcd068774934961fb1419719d595b)
Diffstat (limited to 'sys/dev/esp')
0 files changed, 0 insertions, 0 deletions