This also happens in amd64 (and likely other architectures), only when having "sg3-utils-udev" package installed.
Command "udevadm settle" only returns after the initial "sg_inq" command also returns, raising the question:
(1) Would call "udevmadm settle" before "udevadm info" be enough to get A USB device serial ? (not saying it would be the same serial as it would have been without sg3-utils-udev rules in place).
Another question:
(2) Is this device initialization taking long because of bad "sg3-utils-udev" rules being executed before the initial I/O commands can be submitted to the device ? (very likely).
we are blocked waiting for the VPD (as it was sent through sd_ioctl command to block device layer). I'll trace kernel to check why blk_execute_rq() is taking so long when sg3-utils-udev package is installed (likely command might still be held because device it not yet initialized, due to bad udev rules, "to check").
--
Regarding your concern: YES, it IS A different serial, AND... sometimes, udevadm returns no serial at all (until "udev settle" returns, and this behavior only happens when sg3-utils-udev rules are in place and during the first sg_inq command, suggesting the device is initializing with the bad udev rules).
I'll "bisect" the rules to find the guilty one(s), and, yes, this might be orthogonal to the issue you need, if you need "same serials" in place. For that, you would need a higher priority rule setting SCSI SERIAL based on anything you want (since SCSI SERIAL is not present in USB devices, not the VITAL PRODUCT PAGE, like regular SCSI devices). Likely, the correct thing to do here is to keep the USB serial as the "emulated" (by udev rules) SCSI SERIAL.
This also happens in amd64 (and likely other architectures), only when having "sg3-utils-udev" package installed.
Command "udevadm settle" only returns after the initial "sg_inq" command also returns, raising the question:
(1) Would call "udevmadm settle" before "udevadm info" be enough to get A USB device serial ? (not saying it would be the same serial as it would have been without sg3-utils-udev rules in place).
Another question:
(2) Is this device initialization taking long because of bad "sg3-utils-udev" rules being executed before the initial I/O commands can be submitted to the device ? (very likely).
Stack shows:
[<0>] blk_execute_ rq+0x75/ 0xb0 ioctl+0x1b9/ 0x3f0 blk_ioctl+ 0x51/0x61 ioctl+0x4c1/ 0x9f0 0x3d/0x50 ioctl+0xa9/ 0x640 0x67/0x90 ioctl+0x1a/ 0x20 64+0x5a/ 0x110 64_after_ hwframe+ 0x44/0xa9
[<0>] sg_io+0x176/0x460
[<0>] scsi_cmd_
[<0>] scsi_cmd_
[<0>] sd_ioctl+0xcd/0x1c0
[<0>] blkdev_
[<0>] block_ioctl+
[<0>] do_vfs_
[<0>] ksys_ioctl+
[<0>] __x64_sys_
[<0>] do_syscall_
[<0>] entry_SYSCALL_
[<0>] 0xffffffffffffffff
we are blocked waiting for the VPD (as it was sent through sd_ioctl command to block device layer). I'll trace kernel to check why blk_execute_rq() is taking so long when sg3-utils-udev package is installed (likely command might still be held because device it not yet initialized, due to bad udev rules, "to check").
--
Regarding your concern: YES, it IS A different serial, AND... sometimes, udevadm returns no serial at all (until "udev settle" returns, and this behavior only happens when sg3-utils-udev rules are in place and during the first sg_inq command, suggesting the device is initializing with the bad udev rules).
I'll "bisect" the rules to find the guilty one(s), and, yes, this might be orthogonal to the issue you need, if you need "same serials" in place. For that, you would need a higher priority rule setting SCSI SERIAL based on anything you want (since SCSI SERIAL is not present in USB devices, not the VITAL PRODUCT PAGE, like regular SCSI devices). Likely, the correct thing to do here is to keep the USB serial as the "emulated" (by udev rules) SCSI SERIAL.