Skip to contentSkip to conversation

Add EVPD page 0x83 entries to sysfs

PATCH Superseded Hannes Reinecke 4 participants 8 messages Feb 10, 2014 – Feb 11, 2014 SCSI

v2 of 4 Superseded Latest is v4 →

lore
Share & tools
lore

Hannes Reinecke

author
#0 lore raw

PATCH v2 1/1 Add EVPD page 0x83 entries to sysfs

EVPD page 0x83 is used to uniquely identify the device. So instead of having each and every program issue a separate SG_IO call to retrieve this information it does make far more sense to display it in sysfs.

Cc Jeremy Linton <[email protected]>
Cc Doug Gilbert <[email protected]>
Cc Kai Makisara <[email protected]>
Cc Martin K. Petersen <[email protected]>
Signed-off-by Hannes Reinecke <[email protected]>
---
 drivers/scsi/scsi_scan.c   |   3 +
 drivers/scsi/scsi_sysfs.c  | 258 ++++++++++++++++++++++++++++++++++++++++++++-
 include/scsi/scsi.h        |   2 +
 include/scsi/scsi_device.h |   3 +
 4 files changed, 265 insertions(+), 1 deletion(-)
drivers/scsi/scsi_scan.c +3 -0
index 307a811..073fb84 100644
@@ -929,6 +929,9 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned char *inq_result,
 	if (*bflags & BLIST_SKIP_VPD_PAGES)
 		sdev->skip_vpd_pages = 1;
 
+	if (sdev->scsi_level >= SCSI_3)
+		scsi_attach_vpd_ident(sdev);
+
 	transport_configure_device(&sdev->sdev_gendev);
 
 	if (sdev->host->hostt->slave_configure) {
drivers/scsi/scsi_sysfs.c +257 -1

277 lines not on this page · raw message

include/scsi/scsi.h +2 -0
index 0a4edfe..0f1e6bd 100644
@@ -345,6 +345,8 @@ enum scsi_protocol {
 	SCSI_PROTOCOL_SAS = 6,
 	SCSI_PROTOCOL_ADT = 7,	/* Media Changers */
 	SCSI_PROTOCOL_ATA = 8,
+	SCSI_PROTOCOL_UAS = 9,
+	SCSI_PROTOCOL_SOP = 0xa,
 	SCSI_PROTOCOL_UNSPEC = 0xf, /* No specific protocol */
 };
include/scsi/scsi_device.h +3 -0
index dcb2b73..81c7900 100644
@@ -113,6 +113,8 @@ struct scsi_device {
 	const char * vendor;		/* [back_compat] point into 'inquiry' ... */
 	const char * model;		/* ... after scan; point to static string */
 	const char * rev;		/* ... "nullnullnullnull" before scan */
+	unsigned char vpd_ident_len;
+	unsigned char *vpd_ident;
 	struct scsi_target      *sdev_target;   /* used only for single_lun */
 
 	unsigned int	sdev_bflags; /* black/white flags as also found in

@@ -308,6 +310,7 @@ extern int scsi_add_device(struct Scsi_Host *host, uint channel,
 extern int scsi_register_device_handler(struct scsi_device_handler *scsi_dh);
 extern void scsi_remove_device(struct scsi_device *);
 extern int scsi_unregister_device_handler(struct scsi_device_handler *scsi_dh);
+void scsi_attach_vpd_ident(struct scsi_device *sdev);
 
 extern int scsi_device_get(struct scsi_device *);
 extern void scsi_device_put(struct scsi_device *);
Signature · 1 line
1.7.12.4
#1 lore raw
Quoted 7 lines · Hannes Reinecke
drivers/scsi/scsi_sysfs.c +7 -0
+	int vpd_len = 255;
+	unsigned char *buffer;
+retry:
+	buffer = kmalloc(vpd_len, GFP_KERNEL);
+	if (!buffer)
+		return;
+

drivers/scsi/scsi_sysfs.c show_queue_type_field(struct device *dev, struct device_attribute *attr, · line 748

Quoted 10 lines
drivers/scsi/scsi_sysfs.c +10 -0
+	ret = scsi_get_vpd_page(sdev, 0x83, buffer, vpd_len);
+	if (ret) {
+		kfree(buffer);
+		return;
+	}
+
+	vpd_len = (buffer[2] << 8) + buffer[3];
+	if (vpd_len > 255) {
+		kfree(buffer);
+		goto retry;

Won't this create an infinite loop if the VPD is longer than 255 bytes?

author
#2 lore raw
Quoted 12 lines · Christoph Hellwig
Quoted 11 lines · Hannes Reinecke
drivers/scsi/scsi_sysfs.c +11 -0
+	int vpd_len = 255;
+	unsigned char *buffer;
+retry:
+	buffer = kmalloc(vpd_len, GFP_KERNEL);
+	if (!buffer)
+		return;
+
+	ret = scsi_get_vpd_page(sdev, 0x83, buffer, vpd_len);
+	if (ret) {
+		kfree(buffer);
+		return;
Quoted 9 lines

drivers/scsi/scsi_sysfs.c show_queue_type_field(struct device *dev, struct device_attribute *attr, · line 748

Quoted 6 lines
drivers/scsi/scsi_sysfs.c +6 -0
+	}
+
+	vpd_len = (buffer[2] << 8) + buffer[3];
+	if (vpd_len > 255) {
+		kfree(buffer);
+		goto retry;

Won't this create an infinite loop if the VPD is longer than 255 bytes?

Hmm. Sort of.

Gnaa.

Will be redoing the patch.

Cheers,

Hannes

Signature · 8 lines
Dr. Hannes Reinecke		      zSeries & Storage
[email protected]			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tested-by on v2 1/1
#3 lore raw
In reply to Hannes Reinecke
Quoted 3 lines · Hannes Reinecke

EVPD page 0x83 is used to uniquely identify the device. So instead of having each and every program issue a separate SG_IO call to retrieve this information it does make far more sense to display it in sysfs.

Tested-by Jeremy Linton <[email protected]>

So, I just ran it in 3.14-rc2. No OOPS, that is good. It even survived
probing a SPC-2 device without a page 0x83.

I tested it with a fairly narrow set of devices, a couple IBM libraries with LTO/359x and a VTL.

I did notice this on an old IBM raid adapter running in the machine

cat: ident_lun_scsi_name: Invalid argument

(that came from this device)
sg_inq --page=0x83 --hex /dev/sg2
VPD INQUIRY, page code=0x83:

 00     00 83 00 48 01 03 00 08  50 01 0b 90 00 12 1d 90    ...H....P.......
 10     61 93 00 08 50 01 0b 90  00 12 1d 8e 61 94 00 04    a...P.......a...
 20     00 00 00 01 61 a3 00 08  50 01 0b 90 00 12 1d 8d    ....a...P.......
 30     63 a8 00 18 6e 61 61 2e  35 30 30 31 30 42 39 30    c...naa.50010B90
 40     30 30 31 32 31 44 38 44  00 00 00 00                00121D8D....

And there may be a couple descriptors missing here and there. For example 3592E05 is missing the total port count (I think).

VPD INQUIRY, page code=0x83:

 00     01 83 00 5c 02 01 00 24  49 42 4d 20 20 20 20 20    ...\...$IBM
 10     30 33 35 39 32 45 30 35  20 20 20 20 20 20 20 20    03592E05
 20     30 30 30 30 30 37 38 33  36 33 32 33 01 03 00 08    000007836323....
 30     50 05 07 63 02 41 0c 2c  01 13 00 08 50 05 07 63    P..c.A.,....P..c
 40     02 81 0c 2c 01 14 00 04  00 00 00 02 01 23 00 08    ...,.........#..
 50     50 05 07 63 02 41 0c 2c  01 24 00 04 00 00 00 01    P..c.A.,.$......

/sys/class/scsi_tape/nst14/device # ls ident_*
ident_lun_naa ident_lun_t10 ident_port_naa ident_port_relport ident_target_naa

This almost seems like a case where exporting the raw 0x83 data may be better...

Also, as I stated previously, my personal bias is to include the page 0x80 serial number data for tape devices as well. That seems to be the most reliable. Mostly because a lot of the VTLs now just give you the same wwnn/wwpn in 0x83 for multiple LUNs. Meaning you can't uniquely identify the device over different physical ports.

The IBM devices are nice in that they export a T10 Vendor ID with the man/model/serial in 0x83, but that is not common in my experience.

For example (old T10k)
VPD INQUIRY, page code=0x83:

 00     01 83 00 20 01 03 00 08  50 01 04 f0 00 93 ac f6    ... ....P.......
 10     01 13 00 08 50 01 04 f0  00 93 ac f7 01 14 00 04    ....P...........
 20     00 00 00 01                                         ....
#4 lore raw
Quoted 37 lines · Jeremy Linton
Quoted 3 lines · Hannes Reinecke

EVPD page 0x83 is used to uniquely identify the device. So instead of having each and every program issue a separate SG_IO call to retrieve this information it does make far more sense to display it in sysfs.

Tested-by Jeremy Linton <[email protected]>

So, I just ran it in 3.14-rc2. No OOPS, that is good. It even survived
probing a SPC-2 device without a page 0x83.

I tested it with a fairly narrow set of devices, a couple IBM libraries with LTO/359x and a VTL.

I did notice this on an old IBM raid adapter running in the machine

cat: ident_lun_scsi_name: Invalid argument

(that came from this device)
sg_inq --page=0x83 --hex /dev/sg2
VPD INQUIRY, page code=0x83:

  00     00 83 00 48 01 03 00 08  50 01 0b 90 00 12 1d 90    ...H....P.......
  10     61 93 00 08 50 01 0b 90  00 12 1d 8e 61 94 00 04    a...P.......a...
  20     00 00 00 01 61 a3 00 08  50 01 0b 90 00 12 1d 8d    ....a...P.......
  30     63 a8 00 18 6e 61 61 2e  35 30 30 31 30 42 39 30    c...naa.50010B90
  40     30 30 31 32 31 44 38 44  00 00 00 00                00121D8D....

And there may be a couple descriptors missing here and there. For example 3592E05 is missing the total port count (I think).

VPD INQUIRY, page code=0x83:

  00     01 83 00 5c 02 01 00 24  49 42 4d 20 20 20 20 20    ...\...$IBM
  10     30 33 35 39 32 45 30 35  20 20 20 20 20 20 20 20    03592E05
  20     30 30 30 30 30 37 38 33  36 33 32 33 01 03 00 08    000007836323....
  30     50 05 07 63 02 41 0c 2c  01 13 00 08 50 05 07 63    P..c.A.,....P..c
  40     02 81 0c 2c 01 14 00 04  00 00 00 02 01 23 00 08    ...,.........#..
  50     50 05 07 63 02 41 0c 2c  01 24 00 04 00 00 00 01    P..c.A.,.$......
Quoted 7 lines

/sys/class/scsi_tape/nst14/device # ls ident_*
ident_lun_naa ident_lun_t10 ident_port_naa ident_port_relport ident_target_naa

This almost seems like a case where exporting the raw 0x83 data may be better...

I have seen corrupted "di" VPD pages as well. So the order in which you look for designators can be important (and whether you stop on the first error or continue).

$ sg_vpd -e -p 0x83
Matching standard VPD pages:
  di         0x83      Device identification
  di_asis    0x83      Like 'di' but designators ordered as found
  di_lu      0x83      Device identification, lu only
  di_port    0x83      Device identification, target port only
  di_target  0x83      Device identification, target device only

The difference between --page=di and --page=di_asis is that the first looks for lu, followed by port, followed by target device matches. The --page=di_asis prints out the designators as they are found. Finding and decoding anything beyond a corrupted designator is hit or miss.

Quoted 5 lines

Also, as I stated previously, my personal bias is to include the page 0x80 serial number data for tape devices as well. That seems to be the most reliable. Mostly because a lot of the VTLs now just give you the same wwnn/wwpn in 0x83 for multiple LUNs. Meaning you can't uniquely identify the device over different physical ports.

I'm guessing that various companies selling target capable chips also provide generic target code for those chips. Then it is up to the OEM to customize that generic code for their devices. Some do that customization more thoroughly than others.

Doug Gilbert

Quoted 8 lines

The IBM devices are nice in that they export a T10 Vendor ID with the man/model/serial in 0x83, but that is not common in my experience.

For example (old T10k)
VPD INQUIRY, page code=0x83:

  00     01 83 00 20 01 03 00 08  50 01 04 f0 00 93 ac f6    ... ....P.......
  10     01 13 00 08 50 01 04 f0  00 93 ac f7 01 14 00 04    ....P...........
  20     00 00 00 01                                         ....
author
#5 lore raw
Quoted 75 lines · Douglas Gilbert
Quoted 59 lines · Jeremy Linton
Quoted 5 lines · Hannes Reinecke

EVPD page 0x83 is used to uniquely identify the device. So instead of
having each and every program issue a separate SG_IO call to retrieve this
information it does make far more sense to display it in sysfs.

Tested-by Jeremy Linton <[email protected]>

So, I just ran it in 3.14-rc2. No OOPS, that is good. It even
survived
probing a SPC-2 device without a page 0x83.

I tested it with a fairly narrow set of devices, a couple IBM libraries with
LTO/359x and a VTL.

I did notice this on an old IBM raid adapter running in the machine

cat: ident_lun_scsi_name: Invalid argument

(that came from this device)
sg_inq --page=0x83 --hex /dev/sg2
VPD INQUIRY, page code=0x83:
00 00 83 00 48 01 03 00 08 50 01 0b 90 00 12 1d 90
...H....P.......
10 61 93 00 08 50 01 0b 90 00 12 1d 8e 61 94 00 04
a...P.......a...
20 00 00 00 01 61 a3 00 08 50 01 0b 90 00 12 1d 8d
....a...P.......
30 63 a8 00 18 6e 61 61 2e 35 30 30 31 30 42 39 30
c...naa.50010B90
40 30 30 31 32 31 44 38 44 00 00 00 00
00121D8D....

And there may be a couple descriptors missing here and there. For example
3592E05 is missing the total port count (I think).

VPD INQUIRY, page code=0x83:
00 01 83 00 5c 02 01 00 24 49 42 4d 20 20 20 20 20
...\...$IBM

  10     30 33 35 39 32 45 30 35  20 20 20 20 20 20 20 20    03592E05
  20     30 30 30 30 30 37 38 33  36 33 32 33 01 03 00 08

000007836323....
30 50 05 07 63 02 41 0c 2c 01 13 00 08 50 05 07 63
P..c.A.,....P..c
40 02 81 0c 2c 01 14 00 04 00 00 00 02 01 23 00 08
...,.........#..
50 50 05 07 63 02 41 0c 2c 01 24 00 04 00 00 00 01
P..c.A.,.$......

/sys/class/scsi_tape/nst14/device # ls ident_* ident_lun_naa ident_lun_t10 ident_port_naa ident_port_relport ident_target_naa

Quoted 2 lines

This almost seems like a case where exporting the raw 0x83 data may be better...

I have seen corrupted "di" VPD pages as well. So the order in which you look for designators can be important (and whether you stop on the first error or continue).

$ sg_vpd -e -p 0x83
Matching standard VPD pages:
  di         0x83      Device identification
  di_asis    0x83      Like 'di' but designators ordered as found
  di_lu      0x83      Device identification, lu only
  di_port    0x83      Device identification, target port only
  di_target  0x83      Device identification, target device only
Quoted 6 lines

The difference between --page=di and --page=di_asis is that the first looks for lu, followed by port, followed by target device matches. The --page=di_asis prints out the designators as they are found. Finding and decoding anything beyond a corrupted designator is hit or miss.

Yep, true. I'll need to add some boundary checks to the parsing algorithm.

Quoted 9 lines
Quoted 8 lines

Also, as I stated previously, my personal bias is to include the page 0x80
serial number data for tape devices as well. That seems to be the most
reliable. Mostly because a lot of the VTLs now just give you the same wwnn/wwpn in 0x83 for multiple LUNs. Meaning you can't uniquely identify the
device over different physical ports.

Quoted 6 lines

I'm guessing that various companies selling target capable chips also provide generic target code for those chips. Then it is up to the OEM to customize that generic code for their devices. Some do that customization more thoroughly than others.

Indeed. Some have odd ideas what can be put in there. But nevertheless, the page format is reasonably simple, so adding boundary checks isn't a problem.

And if vendors do not adhere to the spec that's tough, but nothing we should code for.

Cheers,

Hannes

Signature · 8 lines
Dr. Hannes Reinecke		      zSeries & Storage
[email protected]			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
author
#6 lore raw
In reply to Jeremy Linton
Quoted 17 lines · Jeremy Linton
Quoted 3 lines · Hannes Reinecke

EVPD page 0x83 is used to uniquely identify the device. So instead of having each and every program issue a separate SG_IO call to retrieve this information it does make far more sense to display it in sysfs.

Tested-by Jeremy Linton <[email protected]>

So, I just ran it in 3.14-rc2. No OOPS, that is good. It even survived
probing a SPC-2 device without a page 0x83.

I tested it with a fairly narrow set of devices, a couple IBM libraries with LTO/359x and a VTL.

I did notice this on an old IBM raid adapter running in the machine

cat: ident_lun_scsi_name: Invalid argument

Quoted 9 lines

(that came from this device)
sg_inq --page=0x83 --hex /dev/sg2
VPD INQUIRY, page code=0x83:

 00     00 83 00 48 01 03 00 08  50 01 0b 90 00 12 1d 90    ...H....P.......
 10     61 93 00 08 50 01 0b 90  00 12 1d 8e 61 94 00 04    a...P.......a...
 20     00 00 00 01 61 a3 00 08  50 01 0b 90 00 12 1d 8d    ....a...P.......
 30     63 a8 00 18 6e 61 61 2e  35 30 30 31 30 42 39 30    c...naa.50010B90
 40     30 30 31 32 31 44 38 44  00 00 00 00                00121D8D....

Yeah, correct. The selection algorithm is a tad flawed. I'll be fixing it up.

Quoted 11 lines

And there may be a couple descriptors missing here and there. For example 3592E05 is missing the total port count (I think).

VPD INQUIRY, page code=0x83:

 00     01 83 00 5c 02 01 00 24  49 42 4d 20 20 20 20 20    ...\...$IBM
 10     30 33 35 39 32 45 30 35  20 20 20 20 20 20 20 20    03592E05
 20     30 30 30 30 30 37 38 33  36 33 32 33 01 03 00 08    000007836323....
 30     50 05 07 63 02 41 0c 2c  01 13 00 08 50 05 07 63    P..c.A.,....P..c
 40     02 81 0c 2c 01 14 00 04  00 00 00 02 01 23 00 08    ...,.........#..
 50     50 05 07 63 02 41 0c 2c  01 24 00 04 00 00 00 01    P..c.A.,.$......
Quoted 3 lines

/sys/class/scsi_tape/nst14/device # ls ident_*
ident_lun_naa ident_lun_t10 ident_port_naa ident_port_relport ident_target_naa

Well, yes, it does, as the missing ident is this:
01 24 00 04 00 00 00 01

Which decodes as 'Association: Target', 'Designator: Relative target port identifier', and is not defined as per spec
(and it doesn't make sense to boot).

As you might've seen I've included only the valid/defined association/designator combinations in the patch.

Quoted 5 lines

This almost seems like a case where exporting the raw 0x83 data may be better...

Hmm. I'd rather have the actual strings in sysfs; the whole idea of this patch was to have strings in sysfs which can be read directly. Having a binary blob only requires you to have yet another tool for parsing that data.

And for XCOPY we need the descriptor anyway, so at one point we need to parse this.

But OTOH there's no reason why we _shouldn't_ export it to sysfs directly. So let's do both.

Quoted 7 lines

Also, as I stated previously, my personal bias is to include the page 0x80 serial number data for tape devices as well. That seems to be the most reliable. Mostly because a lot of the VTLs now just give you the same wwnn/wwpn in 0x83 for multiple LUNs. Meaning you can't uniquely identify the device over different physical ports.

The problem with page 0x80 is that (per spec) it's vendor-defined. So there is no guarantee for it to be unique in any sense. Which makes it rather impractical for normal use.

Hence we typically rely on page 0x83 to identify a device, be it for udev or multipath.

Cheers,

Hannes

Signature · 8 lines
Dr. Hannes Reinecke		      zSeries & Storage
[email protected]			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#7 lore raw
Quoted 6 lines · Hannes Reinecke

The problem with page 0x80 is that (per spec) it's vendor-defined. So there is no guarantee for it to be unique in any sense. Which makes it rather impractical for normal use.

Hence we typically rely on page 0x83 to identify a device, be it for udev or multipath.

AFAIK is not vendor defined page, its just not marked as "mandatory" by T10.
For tape (which I what I thought brought much of this on) it is basically mandatory. Which is another place where the spec doesn't sync with the real world.

That is because it is the _ONLY_ vendor neutral method to autoconfigure tape
libraries. The tape libraries export the drive serial numbers via READ ELEMENT STATUS, dvcid=1. Which means its the de facto method for backup/media manager applications. A tape/media changer device that crashes or fails to return useful 0x80 information will have a very short life in the market.

For sure, it would work better than the existing method being used by udev (for
tape), which fails (per my other posting) because there is often insufficient information in 0x83 to uniquely identify devices.