http://bugzilla.suse.com/show_bug.cgi?id=922405 http://bugzilla.suse.com/show_bug.cgi?id=922405#c22 --- Comment #22 from Alan Ott --- (In reply to Hannes Reinecke from comment #21)

Which is precisely what we do nowadays; with the most recent sg3_utils we're just looking at the respective sysfs attributes, and will not query the device itself. The most recent 55-scsi-sg3_id.rules has eg:

# SCSI EVPD page 0x80 values KERNEL=="sd*[!0-9]|sr*", ENV{ID_SCSI}=="1", ENV{ID_SCSI_SN}=="1", IMPORT{program}="/usr/bin/sg_inq --export --inhex=/sys/block/$kernel/device/vpd_pg80 --raw" KERNEL=="sd*[!0-9]|sr*", ENV{ID_SCSI}=="1", ENV{ID_SCSI_SN}!="1", IMPORT{program}="/usr/bin/sg_inq --export --page=sn $tempnode"

Sorry, I read it wrong. You are right. So right now, the new version does: 1. If /sys/block/$kernel/device/inquiry exists, then assume: /sys/block/$kernel/device/vpd_pg80 and /sys/block/$kernel/device/vpd_pg83 both exist (or can't exist) and use them.... 2. But if /sys/block/$kernel/device/inquiry doesn't exist, then call sg_inq to try to get the data from the device directly. what's the point of #2? What is the use case where this matters? When will a device _not_ have an inquiry sysfs node? If a device doesn't have an inquiry node (meaning the INQUIRY requests to the device by the kernel have all failed), do we really think sending VPD inquiries from user space is guaranteed to not make things worse? The reason I'm asking #2 is because I'm skeptical that there is _any_ reason to be issuing scsi commands from user space (other than testing and debugging). The kernel goes to great lengths to get the proper information from the device, working around many types of buggy devices. The data is either there and can be read from sysfs, or the kernel is unable to get the data, in which case user space shouldn't try it, because you might either get bad data or lock up the device. In my opinion, I'd remove all sg_inq calls in this sysfs file. Either the kernel has read the data or the kernel can't read the data. User space should trust the kernel to interact with scsi devices.

ie we're trying to read from /sys/block/sdX/device/vpg_pg89 (if existing) or, if this doesn't exist, use the sg_inq program to read from device.

You're reading from /sys/.../vpg_pg83 if sys/.../inquiry exists. why not just read from sysfs and call it done? I reiterate that calling scsi commands from user space when the kernel has already decided that these commands aren't going to work doesn't make sense.

We might need to update the sg3_utils package in Leap, though.

Please do. That would seem to fix the immediate problem. Alan. -- You are receiving this mail because: You are on the CC list for the bug.