On Mon, May 16, 2011 at 01:47, Nix <nix@xxxxxxxxxxxxx> wrote: > 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. Ok, sounds good. >> 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? If you ask the kernel to do that at compile time or with a parameter, it does that, but only if the rootfs is mounted by the kernel itself, not in any initramfs case. > 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.) With devtmpfs you get the "early" /dev for free, and you preserve the "early" /dev in the real root. Instead of mounting a 'tmpfs' just mount a 'devtmpfs' at /dev, and it will be magically filled already, that's the only difference. When mounting the real root, just mount --move it over to the real root before switching to the real root. >> 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... Good. Maybe you can run: udevadm monitor in the background writing to a file, and get timestamps of your commands too. For testing, you could also add test rules like: KERNEL=="null", PROGRAM="/bin/sleep 10" Which should make settle definitely block for that amount of time. Kay -- 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
