On 9/22/20 7:44 AM, Lennart Poettering wrote:
On Mo, 21.09.20 19:03, Alan Perry (alanp@xxxxxxxxxxxxx) wrote:
Hi,
I am trying to understand behavior that I am seeing with udev and eMMC
partition devices and was hoping that someone here could help.
The system that I am running has an eMMC device with something like 7-8
partitions. The kernel does add block events for the device and each of it
partitions and the logs show them being queued up by udevd. Then things get
interesting. Sometimes processing of the add event for the device itself
gets to a probe step and, in the time frame of the logs that I have, never
gets further in that processing and the add block device events for the
partitions are never processed. However, usually, it will process the add
block device event for the entire device and after that (as per the
implementation of is_devpath_busy()) start processing the add block events
for the partition devices. Often times, the processing of the partition
device add events will get stuck at the probe step.
"Get stuck"? What does that mean? What is it actually doing? What does
a stack trace say? Anything in the logs?
When this happens, the last thing seen in the log for those devices is
the probe ("probe /dev/mmcblk0<part> raid offset=0").
I have been given a bunch of logs and have yet to be able to reproduce
the problem myself. I got additional hints for reproducing the problem
last night and am putting together a systemd with additional diagnostic
output in the code that does the probe.
The partition devices
stuck at the probe are then "waiting" and the services that depend on them
blocked.
Can anyone here give me some insight into what is going on, in particular,
how there is such difference in behavior between test runs on the same
system?
Have you checked the logs?
Yes. I have been trying to debug the problem by log output and code
analysis.
I had initially thought that the problem was somewhere else, but now the
logs are pointing me towards the probe.
Please always start with saying which systemd version this is, and
which distro, otherwise it's very hard to grok what your setup is
like?
Good point. Sorry. I think it is v239 systemd plus a lot of patches. The
distro is an internal Microsoft one based on the 5.4 kernel.
Maybe the eMMC driver has issues and simply hangs? dmesg might show
something in that case.
Thanks. I don't have dmesg output associated with most of the logs. But
I will be sure to look there once I am able to reproduce it myself.
alan
Lennart
--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
