[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fwd: Re: film at 11: kernel update breaks udev.

Richard Hally wrote:
Douglas McClendon wrote:
Bill Nottingham wrote:
Richard Hughes (hughsient gmail com) said:
On Sat, 2007-07-21 at 00:55 -0400, Dave Jones wrote:
Argh.  So why _are_ we doing our own special rules instead
of using the upstream ones ?  This isn't the only time I've
run into something like this with udev.
Our udev is about 100x times slower than upstream...

I find it hard to believe it's 100x slower. I've done testing
of it with most of the not-needed-for-booting rules commented out -
execution time only dropped from ~5 to ~3.5 seconds.

This may be something unrelated (qemu bug?), but I feel I should mention-

When I boot livecds that I've spun with livecd-creator in qemu, the udev step takes a painfully long time to complete, and even just hangs a fair percentage of the time.

Has anyone else noticed anything like this? At some point I'll do a little more research and file a proper bug.


yes, on my rawhide box ( a P4 3.2Ghz with H/T) when booting I get to the "starting udev:" and it sits there for 2:44 (that is 2 minutes and 44 seconds)!
then continues booting.

I'm glad I'm not the only one. The main reason, until this thread, that I pegged it for a qemu bug was that I can hit the hang/2:44 scenario, ctrl-c, and restart with the exact same commandline*, and then it will take a slow, but reasonable (~15-30s) time to complete.

* I'm almost positive it has happened at times when I'm either only using cdrom, or using -snapshot. Thus no changed state on the disk file could explain this.

Another reason I suspect qemu, is I see plenty of kernel messages relating to problems with the cdrom drive spewing by, which are otherwise ignorable. I'm assuming those have something to do with the new ata driver stuff in f7, and that I should just wait a little while for other people to iron those things out.

But then, given the topic that started this thread, makes me wonder if tweaking some udev rules wouldn't perhaps workaround this problem. Anybody have any ideas for experiments - either with some debug/verbose setting or alternate rules?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]