Differential D33783
cam: Include more statuses as errors for CAM_IO_STATS Authored by imp on Jan 7 2022, 6:15 PM. Tags None Referenced Files
Details
Tag more status return values as an error for the Sponsored by: Netflix
Diff Detail
Event TimelineComment Actions A selection timeout means we can't talk to the drive at all. The terminology comes from Parallel SCSI, but it is an error that generally results in the drive going away. A command timeout means that the drive hasn't completed a command within the timeout period. That typically would result in a retry. Comment Actions Yea, I thought that would be a good one to include in the error count, but it's meaning is a bit fuzzy in my mind... Comment Actions Does it make sense to include any of these additional errors for the CAM_IO_STATS in sys/cam/nvme/nvme_da.c and sys/cam/ata/ata_da.c? Comment Actions nvme_da doesn't have these errors. ata_da already lists CAM_ATA_STATUS_ERROR. I needed to add it to SCSI because we do a lot with ATA passthrough commands that might result in this. I'm on the fence about adding CAM_SMP_STATUS_ERROR to ata_da.c, like I was in adding it here. It's more of a management thing and I've not audited all the commands both send to see if it's possible... CAM_SEL_TIMEOUT is generated by the ata SIMs, so maybe it should be on the list there (nvme_sim doesn't generate this). Whether it should count as a timeout or an error I was also on the fence about, but came down more on the side of an error since it's more of a device isn't there at all signal, rather than a command submitted to a device hasn't completed error, though I could be pushed one way or the other. Comment Actions Though thinking about it, I've not verified that the SEL_TIMEOUT error would make it here at all... Comment Actions CAM_SMP_STATUS_ERROR is only going to come back from SMP commands, and those aren't sent by the da(4) driver currently. They don't make any sense in ada(4), because that isn't going to be talking to a SAS controller. They are directed to an SMP target, which is contained inside an expander. Usually the expander has an enclosure processor target and an SMP target in it, and so we direct SMP commands via passthrough to the SES devices. e.g.: camcontrol smpplist ses0 -v If there isn't a visible enclosure processor for the expander that has the SMP target you want to talk to, you can direct the SMP command to a disk device, and the mps(4) or mpr(4) driver will actually send it to the parent device in the topology, which would be the expander. So in those cases, you would do: camcontrol smpplist da5 -v This stuff is necessary because SMP isn't a first class protocol in CAM with its own specific XPT routines, probe code, etc. I added it primarily to allow turning PHYs on and off which makes disk arrival and departure testing much easier. Comment Actions Remove SEL_TIMEOUT. Those errors aren't loggged to devctl. |