camcontrol: Force a rescan of the lun after firmware download.

[imp]

Summary

After downloading the firmware to a device, it's inquiry data likely
will change. Force a rescan of the lun with the CAM_EXPECT_INQ_CHANGE
flag to get it to record the new inqury data as being expected. This
avoids a 'camcontrol rescan' on the device which will (uselessly?)
detach/attach 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.

I've also successfully updated root drive firmware w/o crashing the
system for the first time.

Sponsored by: Netflix

Test Plan

As an experiment, I updated 10 m600 drives (2 are root in a mirror) on a Netflix machine serving about 8Gbps of traffic in parallel.
The box survived, but the drive terminated all the outstanding I/O when the drive restarted with the new firmware.
The normal retry / recovery mechanism rescheduled it them all that I/O and life went on with only a 3s hiccup while the drive was flashing the new firmware.
The 3s pause wasn't enough to cause any observable problems with the metrics we report, but maybe I was just lucky...

[mav]

sbin/camcontrol/fwdownload.c

777

Does firmware update works in context of LUN or target? What should we expect from dual-LUN disks here?

781

I don't think rescan needs timeout.

791

Combining two error scenarios you may reporting between confusing and wrong.

[imp]

sbin/camcontrol/fwdownload.c

777

The dual actuators we have, from two different vendors, only support firmware upgrade on LUN 0. However, one of them said, in an off hand way, that the standard allows any lun to work.

Having said that, perhaps I should do a SCAN_BUS here with lun any, eh?

That might make the ata drives work... right now, they won't rescan until I do a camcontrol rescan by hand afterwards (but the CAM_EXPECT_INQ_CHANGE flag causes the PROBE_NO_ANNOUNCE flag to get set, and it appears that it is never cleared.

781

OK. I just copied this code from the rescan camcontrol code... But camcontrol could use a lot of cleanup

791

copied directly fromfw_download_img, but I'm happy to separate them out here (and there)/ But I'd like to do the latter as a followup cleanup series.

[mav]

sbin/camcontrol/fwdownload.c

777

I was thinking about XPT_SCAN_TGT. Bus is definitely too wide.

[imp]

Update per mav's suggestion to use XPT_SCAN_TGT

However, of ata devices (and maybe scsi too), don't have the b:t:l filled into
the cam_device structure. So do a XPT_GDEVLIST to get them in all cases and use
those for the rescan.

Also, I'd forgotten XPT_SCAN_* can only be sent via /dev/xpt, and the prior
version had a premature optimization to use cam_send_ccb rather than to do a
pass through command via xpt. Restore that so the scan actually happens.

[imp]

remove stray n

Also, the prior update, since I have to do this one, also improved the error
reporting to be less confusing...