4 Jan
2018
4 Jan
'18
1:50 a.m.
03.01.2018 18:57, Paul Neuwirth пишет:
journalctl shows best, that it is in fact udevd..
Actually udevd is probably just the messenger here. Annotated log
Jan 03 11:25:27 kappa kernel: scsi 0:0:3:0:
Direct-Access TEAC
FC-5 HGF 00 RV D PQ: 0 ANSI: 1 CCS
Jan 03 11:25:27 kappa kernel: sd 0:0:3:0: Attached
scsi generic sg4 type 0
Jan 03 11:25:27 kappa kernel: sd 0:0:3:0: Power-on or device reset
occurred
Jan 03 11:25:27 kappa kernel: sd 0:0:3:0: [sdc]
Spinning up disk...
This comes from kernel directly. It does it as the first step when
probing for new SCSI disk. Note that if device explicitly says that
medium is not present, "Spinning up" is skipped.
Jan 03 11:27:08 kappa kernel: sd 0:0:3:0: [sdc] Read
Capacity(10)
failed: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jan 03 11:27:08 kappa kernel: sd 0:0:3:0: [sdc] Sense
Key : Not Ready
[current]
Jan 03 11:27:08 kappa kernel: sd 0:0:3:0: [sdc] Add.
Sense: Logical
unit not ready, cause not reportable
Jan 03 11:27:08 kappa kernel: sd 0:0:3:0: [sdc] Write
Protect is on
Jan 03 11:27:08 kappa kernel: sd 0:0:3:0: [sdc] Mode Sense: 37 88 80 08
Jan 03 11:27:08 kappa kernel: sd 0:0:3:0: [sdc] Asking for cache data
failed
Jan 03 11:27:08 kappa kernel: sd 0:0:3:0: [sdc]
Assuming drive cache:
write through
The above is executed only if driver thinks that medium is present
(otherwise there is no point to even attempt to read capacity). Driver
starts with assumption it is. Again - if device returns proper sense
code indicating no medium is present, this step should have been
skipped. Still, as READ CAPACITY fails we should have reset "medium
present" indication ...
... and we announce block device sdc to user space (i.e. udevd) now. So
udevd spawns handler thread.
Jan 03 11:27:08 kappa kernel: sd 0:0:3:0: [sdc]
Spinning up disk...
Still kernel directly.
Jan 03 11:27:08 kappa kernel: sd 0:0:3:0: [sdc]
Spinning up disk...
And *this* comes from udevd handler trying to open device node. Which
triggers device revalidation. And apparently it also resets "medium not
present" flag back because driver has never received proper response
from device. And because driver flips this flag from TRUE to FALSE it
apparently generates change event. Which spawns yet another udevd
handler which tries to open device node ... notice incrementing event
numbers:
Jan 03 11:28:09 kappa systemd-udevd[613]: seq 2990
'/devices/pci0000:00/0000:00:0a.0/0000:01:
06.0/host0/target0:0:3/0:0:3:0/block/sdc' is taking a long time
Jan 03 11:31:30 kappa systemd-udevd[613]: seq 2991
'/devices/pci0000:00/0000:00:0a.0/0000:01:
06.0/host0/target0:0:3/0:0:3:0/block/sdc' is taking a long time
Jan 03 11:36:31 kappa systemd-udevd[613]: seq 2992
'/devices/pci0000:00/0000:00:0a.0/0000:01:
06.0/host0/target0:0:3/0:0:3:0/block/sdc' is taking a long time
Jan 03 11:41:32 kappa systemd-udevd[613]: seq 2993
'/devices/pci0000:00/0000:00:0a.0/0000:01:
06.0/host0/target0:0:3/0:0:3:0/block/sdc' is taking a long time
Could you please reproduce it once more and provide output of "udevadm
monitor -k" to confirm this.