Comment 36 for bug 1833618

Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote : Re: failing to deploy Ubuntu Disco

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
[<0>] sg_io+0x176/0x460
[<0>] scsi_cmd_ioctl+0x1b9/0x3f0
[<0>] scsi_cmd_blk_ioctl+0x51/0x61
[<0>] sd_ioctl+0xcd/0x1c0
[<0>] blkdev_ioctl+0x4c1/0x9f0
[<0>] block_ioctl+0x3d/0x50
[<0>] do_vfs_ioctl+0xa9/0x640
[<0>] ksys_ioctl+0x67/0x90
[<0>] __x64_sys_ioctl+0x1a/0x20
[<0>] do_syscall_64+0x5a/0x110
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[<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.