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.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1833618

Title:
  failing to deploy Ubuntu Disco

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1833618/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to