Comment 61 for bug 1833618

Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :

From, at least, commit:

commit b6e681fea79d3d9b479acca1806f32310199053a
Author: Doug Gilbert <email address hidden>
Date: Mon Sep 18 16:15:01 2017

    https://github.com/hreinecke/sg3_utils branch sles15 synced 20170914; change sg_ll_*() function's 'int noisy' to bool

and beyond we haven't updated sg3-tools. This commit has changed how 55-scsi-sg3_id.rules logic works but not as much as commit:

commit c4c6af020963d11b624da6abb53f792074f943b2
Author: Doug Gilbert <email address hidden>
Date: Tue Mar 26 00:54:53 2019

    sg_inq: update version descriptors to spc5r21; scripts/scsi-sg3_id: update rules; testing folder work

    git-svn-id: svn://localhost/trunk@814 6180dd3e-e324-4e3e-922d-17de1ae2f315

which introduced the latest logic that makes sure not to query - or at least give us a way not to query - devices that don't support VPD 0x80/0x83 :

...

The following comment:

"""
# SCSI INQUIRY values
# If the 'inquiry' sysfs attribute is present the kernel will already
# have scanned for VPD pages, so if the vpd page attribute is not
# present it is not supported (or deemed unsafe to access).
# Hence we can skip the call to sg_inq and avoid I/O altogether.
# Set 'ID_SCSI_INQUIRY=0' in an earlier udev rule if the kernel
# fails to scan VPD pages correctly; the rules will then fall
# back to calling sg_vpd directly.
LABEL="scsi_inquiry"
ENV{ID_SCSI_INQUIRY}=="0", GOTO="sg_inquiry"

# As of 2018/4.15, the kernel doesn't provide VPD pages for "SPC" devices
# (SCSI version 0x03, ANSI INCITS 301-1997) in sysfs.
# It's usually safe to try though (no counter-example is known),
# and for scsi_id compatibility, we have to try.
SUBSYSTEMS=="scsi", ATTRS{scsi_level}=="4", GOTO="sg_inquiry"
"""

in 55-scsi-sg3_id.rules suggests that it is "SAFE" to try getting the VPD pages out of "SPC" devices (SCSI version 0x03, ANSI INCITS 301-1997) - our case - saying no counter-example is known (maybe this is the first ?).

It even says its a "scsi_id" compatibility. Because of that, what I'm suggesting for SRU is to do the VPD 0x80 and fail fast, instead of trying VPD 0x83 right after if 0x80 is not supported. This will keep the same behavior - as we have today - for USB drives supporting VPD pages - external SCSI-enabled USB disk devices - and will keep SPC-only USB devices - pendrives/memory sticks - with correct serial (different that we have today).

Nevertheless, I still have to merge sg3-tools in the next release - as the version we have seems old - and make sure the correct behavior (not attempting 0x83 after a failed 0x80) is done (thus the F-series will continue open).