bryan at kadzban.is-a-geek.net
Thu May 12 22:14:43 PDT 2011
DJ Lucas wrote:
> On 05/11/2011 11:14 PM, Bryan Kadzban wrote:
>> Where is your swap?
> /dev/sda3...which gives a much better explanation as to why it works
> with devtmpfs. I did not buy the "faster" bit.
Yeah, that sounds about right.
>> (I'm thinking the kernel isn't sending the event to udev in time
>> after the trigger. There's no way settle can wait for an event
>> that udevd doesn't know about yet.)
> I think you hit the nail on the head there. Have to get logging going
> to same files on a tmpfs to be sure. We are likely talking about a
> very small timing issue. I think, at least in my case, a couple
> hundredth seconds sleep would suffice after trigger...wonder what
> would be worst case scenario on say i586. A tenth second?
Depending on the implementation of sleep(1), fractions might even work...
Yeah, coreutils' sleep seems to take fractional seconds according to its
manpage. So that would at least be possible. I very strongly doubt
that more than about half a second is required, but it depends on
- enumeration speed of kobjects in /sys
- speed of writes to uevent files
(trigger is finished at this point)
- how long the kernel takes to send the first uevent to udev
(the sleep must be at least this long, otherwise settle will never work)
- what the imbalance is between kernel-sent uevents and udev-processed
uevents whenever settle pokes at the counters
Once that imbalance goes to zero, settle will finish. So if uevent
processing is fast but the kernel is slow for some reason, it's entirely
possible that settle will exit early.
It might actually work to just run settle a second time.
> If the event is in queue, I suspect settle will work as expected.
Yeah, it will.
> Alternately, the man page isn't real clear about --seq-end, will
> settle sit there and spin until that event number is reached or
> timeout is reached, or will it check the empty queue and continue? If
> the former, set the value to around 200 and give a really low
> timeout, say 1 second.
Looking at current git sources, --seq-end requires --seq-start. (If end
is provided without start, it'll log an error and exit.) Both also have
to be less than the current kernel sequence number at udevadm startup
time. So you can't use either of them to wait for a seqnum in the
>>> 2. Add a sleep to the end of the udev script (how long?).
>> Not that I like this, but this is what the livecd did. It added a
>> rootdelay=xx, to stuff an extra "sleep xx" in the initramfs.
> Can do a really low value, .1?
Sure, although rootdelay= is an initramfs-specific thing. (We'd need to
add support in the bootscripts for it. And calling it rootdelay is
probably a bad idea as well, since once the bootscripts are running, the
rootfs is already up.)
>> 5. (I really really hate this one...) Bite the bullet and set up a
>> fully dynamic set of bootscripts, interfacing with udev directly.
>> (Because black magic, a la upstart or systemd, is *obviously* the
>> right way to go. Sigh.) So mounting a given filesystem will only
>> happen after the proper device node shows up (and will depend on
>> udev, which will depend on kernel FSes), and then anything that
>> requires that FS will depend on the mounting script.
>> It's a *LOT* of work though, for what I thought was very little
>> gain. However, if upstream has broken settle, we may not have much
>> of a choice... :-(
> No, settle is supposed to work for normal sysv setups. Something must
> have been broken in new trigger.
Have you tried a different kernel version as well? Might be that kernel
timings changed just enough to be a problem.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 261 bytes
Desc: OpenPGP digital signature
More information about the lfs-dev