20.01.2018 11:51, Paul Neuwirth пишет:
On Sat, 20 Jan 2018 11:18:59 +0300 Andrei Borzenkov <arvidjaar@gmail.com> wrote:
20.01.2018 10:56, Andrei Borzenkov пишет:
20.01.2018 10:41, Paul Neuwirth пишет:
Well, I expect this does not require reboot. Can you confirm that the value is still 0?
# echo 0 > /sys/block/sdc/events_poll_msecs # cat /sys/block/sdc/events_poll_msecs 0 # udevadm monitor monitor will print the received events for: UDEV - the event which udev sends out after rule processing KERNEL - the kernel uevent
KERNEL[523053.824420] change /devices/pci0000:00/0000:00:0a.0/0000:01:06.0/host1/target1:0:3/1:0:3:0/block/sdc (block) KERNEL[523053.834769] change /devices/pci0000:00/0000:00:0a.0/0000:01:06.0/host1/target1:0:3/1:0:3:0/block/sdc (block) UDEV [523154.250415]
Could you run "udevadm monitor -kp" to show event properties, this may give hint?
But I start to suspect that it is indeed triggered by udev opening device.
Try stracing udevd
systemctl show -p MainPID systemd-udevd.service strace -f -o /tmp/udevd.trace -p <Value of MainPID>
for couple of events.
...
596 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7ff6ab15cb90) = 17492 ...> 17492 open("/proc/self/oom_score_adj", O_WRONLY|O_NOCTTY|O_CLOEXEC) = 7 17492 fcntl(7, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE) 17492 fstat(7, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 17492 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff6ab172000 17492 write(7, "0\n", 2) = 2 17492 close(7) = 0 17492 munmap(0x7ff6ab172000, 4096) = 0 17492 open("/dev/sdc", O_RDONLY|O_NONBLOCK|O_NOFOLLOW|O_CLOEXEC <unfinished ...>
That's bad. This open happens at the very beginning, before udev even looks at rules and device properties. It only checks at this point whether this is block device or not. It means there is no feasible way to disable (further) event processing using udev rules. I believe I now understand at least how the problem is triggered. Could you collect slightly more verbose kernel logging by setting SCSI log level: scsi_logging_level -s -H 7 reproduce it once more (just a couple of events) and provide again "journalctl -b" output. I'll try to send it to linux-scsi with my theory. Do not forget to reset log level back to 0 as soon as you stopped collecting data. Otherwise logs will grow rather fast. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org