Bug 435637

hmm. WFM.

What do you have in event.d that's pertinent? Maybe I fiddled with something on
my install and forgot about it.

Sorry, not quite sure what you're asking here.  /etc/event.d/rc1 simply has:

start on runlevel 1

stop on runlevel

console output
script
        set $(runlevel --set 1 || true)
        if [ "$1" != "unknown" ]; then
            PREVLEVEL=$1
            RUNLEVEL=$2
            export PREVLEVEL RUNLEVEL
        fi

        exec /etc/rc.d/rc 1
end script


I will note that upstart got installed as a dependency for
event-compat-sysv-0.3.9-8.fc9.noarch which got pulled in by something else.  So
I didn't explicitly install it, if that makes a difference.

What happens if you boot with 'udevinfo' or 'udevtrace'?

(In reply to comment #3)
> What happens if you boot with 'udevinfo' or 'udevtrace'?

Odd.  Adding udevinfo produces a massive amount of spewage from udev, then it
goes to the prompt as expected.  

[2 minutes]

udevtrace doesn't really produce any output, but it still goes to the prompt as
expected.

[2 minutes]

Just having 'single' there without the udev* additions and it simply sits.

(In reply to comment #4)
> Just having 'single' there without the udev* additions and it simply sits.

After letting it sit a bit longer, eventually it says:

Wait timeout.  Will continue in the backgroun[FAILED]

and doesn't go to the prompt.

(In reply to comment #5)
> (In reply to comment #4)
> > Just having 'single' there without the udev* additions and it simply sits.
> 
> After letting it sit a bit longer, eventually it says:
> 
> Wait timeout.  Will continue in the backgroun[FAILED]
> 
> and doesn't go to the prompt.

And now it just did that without 'single' at all.  udev is messing with my mind.

This appears to be more a udev issue that an upstart issue, but I could be wrong...

I agree.  I'll try again with tomorrow's rawhide and see what happens.

Any news on this?

(In reply to comment #9)
> Any news on this?

I doubt this is an upstart issue.  It's already been moved over to udev.

As for new news, nothing much.  udev still intermittently decided to go to lunch
on my machine and I've not had time to play with it more.

Created attachment 297599 [details]
photo of screen after hitting ctrl+alt+del

I passed 'single udevinfo' on the command line this morning and got the udev
hang.  Then I hit ctrl+alt+del and took a picture.  This is the screen right
after I did the ctrl+alt+del

Created attachment 297600 [details]
screen a bit after

The screen a bit later on

The ctrl-alt-del thing is logged as 435577.

try "udevdebug" instead of "udevinfo"

(In reply to comment #14)
> try "udevdebug" instead of "udevinfo"

http://picasaweb.google.com/jwboyer/Udev

Pretty pictures from the places udev hung when trying with udevdebug instead.  I
apologize in advance for the crappy quality.  If you can't get to them for some
reason, let me know and I'll just attach them here.

Those were the only places where a noticeable delay of any duration was to be
seen.  The rest of the time udevdebug seemed to spew a bunch of output that
scrolled too fast off of the screen.

Let me know if there's more I can do.

Update the title of the bug to reflect reality at this point.  The delays have
happened regardless of the 'single' being present or not.

seems like problems with scsi and/or usb

which devices do you have?

Stock Thinkpad z60m.  I played around a bit with power on/off vs. reboot, etc. 
Nothing to really notice there.  Occasionally it won't hang, but it does for the
most part.

Then I played around with having a USB key or SD card in the built-in reader
during booting.  Again, nothing really noticeable with that.

I'm waiting for it to decide to boot so I can give you a smolts.org URL.

http://www.smolts.org/show?uuid=pub_f7e62da4-3fee-42c1-8049-e59e8a564dc1

udev-118-9.fc9 now has support for a "modprobedebug" kernel command line, which
may identify a kernel module causing the delay.

you also may try the new "udevnopersist" kernel command line.

http://koji.fedoraproject.org/koji/buildinfo?buildID=42806

any news on this?

(In reply to comment #22)
> any news on this?

Sorry.  It's magically gone away with either the newer udev or a newer kernel. 
I tried for an afternoon last week to get it to hang through various
reboot/power-off,power-on combinations and it doesn't happen any longer.

Bill, have you had any kind of recreates?

No, the virt image where I saw it seems to work now. 

I think we can either close this as WORKSFORME or RAWHIDE.  If it happens again,
I'll try to capture debug output with the new options and reopen.

Hm, I was just caught by a multiminute udev delay with
kernel-2.6.25-0.172.rc7.git4.fc9.x86_64 and udev-118-11.fc9.x86_64.
It eventually decided to continue when I was practically ready to hit
a power button.

I tried to reproduce that with "modprobedebug" but without any
success.  One thing is that was "not in a mood" and I did not get
those delays.  The other is that "modprobedebug" produces only
the following on my screen:

Starting udev:
/sbin/start_udev: line 278: find: command not found
Triggering Rest

Line 278 is a closing "fi" of an an "if" starting on line 224.
The problem is really here:

    259                 for i in $(find /sys -name modalias); do
    260                     modules=$(cat $i)
    261                     modprobe -a -v -q $modules
    262                     wait_for_queue $udevtimeout
    263                 done
    264                 echo "Triggering Rest"

'find' is /usr/bin/find and /usr may be not available at all at
this point (as is the case on my system).  I guess that /bin/awk
is already present and "for" could loop through a list produced
in awk with a help of 'stat' and 'chdir' functions.  Not even that
difficult (although not worth to bother if it is not going to
be used).

Do you still want this closed?  It does not look that I can reproduce
the issue on demand.