On Mon, 2019-03-25 at 17:27 -0500, Benjamin Marzinski wrote: > > > One remark: With the kernel exporting the VPD pages in sysfs > > and my late "multipath -u" patch series, udev should be able to > > process > > uevents for path devices without a single actual device IO. (*) > > While there are still possible causes for udev processing to get > > stuck, > > this would make it much less likely. > > For reasons I don't understand, not all devices get a vpd_pg83 sysfs > file, even though they clearly have a page 0x83, since multipath and > sg_inq can read from it via ioctl. I have a device like this. This > is > quite possibly a kernel issue that should get fixed, but regardless, > it's been there for a while, and I just cheked and it still exists in > the 5.0.0-rc6 kernel. This is intentional. The kernel applies conservative heuristics to determine whether these VPDs are supported. See the comment in scsi_device_supports_vpd(). Sometimes the kernel gets it wrong, usually because the device claims to be a pre-SCSI_SPC_2 device. Such devices should be fixed with the BLIST_TRY_VPD_PAGES device flag if they do support the DI VPD. OPEN-V devices are a notorious example. But meanwhile the blist flags are in place for them. Regards Martin -- Dr. Martin Wilck <mwilck@xxxxxxxx>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel