On 16 May 2011, Kay Sievers stated: > We are sure it's not related to /run? We keep the state there and need > a tmpfs there before udevd is started, and it must not be touched, or > cleaned by some other stuff, that thinks /var/run (bind mount or > symlink) needs to be cleaned during boot. Just to confirm, I'm not cleaning out /run, or touching it at all except to create /run/lock later in boot. > Devtmpfs solves a lot of settle races, yeah. We should run fine on > tmpfs, but it's the only config that is really tested these days, so > it might be a problem nobody else is really seeing. I could turn on devtmpfs, I suppose, except that I have an early userspace and I'm not sure how I'd need to change it: devtmpfs gets mounted on the rootfs, doesn't it? This problem isn't happening on the rootfs, it's on the root filesystem that is overmounted over that. (I'm using busybox mdev to populate the rootfs /dev because it works for such a simple case, and never goes wrong because it's too simple to go wrong. However it's also too simple to be much use for a running system.) > The current settle wakes up in exactly the moment the last event is > gone, instead of it sleep()ing in a loop. It might be a bit earlier, > not really before stuff has settled though. > > Does this work for you? > time (udevadm trigger; udevadm settle) > > It should not return immediately. You can watch the events with: > > udevadm monitor > at the same time and check if it really only returns after the last event. Hm, well, that seems to be working, at least once the system is all the way up. But *something* plainly isn't. On my next boot I'll time the trigger-and-settle pair and see how long it takes... -- NULL && (void) -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
