# waiting for uevents to be processed . . .

## Skippy204

Greetings all.

Existing Gentoo box.  I did a emerge -uvND world.  Now system will not boot.  I get:

```

populating /dev with exiting devices through uevents . . .  [ok]

waiting for uevents to be processed . . .

```

Computer then freezes.

I let it run for 20 minutes to see if it eventually completed a task and moved on.  It does not.

I can ctrl+alt+del out.

Kernel is Gentoo-2.6.32.  I'm using a kernel that Pappy configured for me and it has been working just fine.

I can boot with my old Gentoo-2.6.32 kernel that has who knows what all in it that I don't need.

Thus I assume it's a kernel configuration problem?

I added --debug option to /etc/init.d/udev

```

ebegin "Starting udevd"

start-stop-daemon --start --exec /sbin/udevd -- --daemon --debug

eend $?

```

After doing that the last line I get before the computer freezes is:

```

1271229623.135566 [1233] event_queue_delete: seq 1084 done with 0

```

What additional information should I post?

Can anyone advise please.

Thank you!

----------

## depontius

Are you running baselayout-2?  You need to run /etc/init.d/udevd if you're using baselayout-2.  You need to not run /etc/init.d/udevd if you're using baselayout-1.

----------

## Skippy204

 *depontius wrote:*   

> Are you running baselayout-2?  You need to run /etc/init.d/udevd if you're using baselayout-2.  You need to not run /etc/init.d/udevd if you're using baselayout-1.

 

I don't know 100%, but will check as soon as I can.

I'm running unstable x64 and everything is well updated, that's why I *think* I'm on baselayout-2 but will confirm.

Also, surely it must be as I can boot with the other kernel and it's running /etc/init.d/udevd.  Right? 

Thank you. 

Skippy

----------

## depontius

 *Skippy204 wrote:*   

>  *depontius wrote:*   Are you running baselayout-2?  You need to run /etc/init.d/udevd if you're using baselayout-2.  You need to not run /etc/init.d/udevd if you're using baselayout-1. 
> 
> I don't know 100%, but will check as soon as I can.
> 
> I'm running unstable x64 and everything is well updated, that's why I *think* I'm on baselayout-2 but will confirm.
> ...

 

Have you compared your 2 kernel configs?

----------

## Skippy204

baselayout is 2, not 1.  

as to comparing the kernels, yes and no.

Yes in that I know they are different.  The one that doesn't work only has what I need to run my system.  the one that does work is the "default" Gentoo kernel with everything I don't need built in.

No in that I haven't compared them line for line.  Nor am I excited about having to spend days building kernels adding and removing things until I happen to find the right combination that works.

That's why I was hoping the debug option on udev would provide some output that would indicate what the problem might be.

Skippy

----------

## depontius

Don't know about the udev option, since I'm still on baselayout-1.  But as for comparing kernel configs, I might suggest a graphical compare tool like tkdiff or diffuse, as it'll let you quickly skim pass the irrelevant stuff.

----------

## Skippy204

I know what is causing problem now.  It's nvidia-drivers-195.36.15.  When I install that the problem occurs.

It makes sense as that installs a kernel module, so I'm assuming that module is somehow related to the problem.

Skippy

----------

## Smeagel

Seeing a lock up at waiting for uevents after installing nvidia module, on gentoo-sources 2.6.33-r2.  If I delete the module it boots fine.  I can then install the module and startx, etc, everything works fine, no errors to dmesg - but whenever I try to reboot it locks at "waiting for uevents".

I have two Nvidia graphics cards as well as a Tesla card, not sure if that could have an effect.  I don't reboot frequently, but I'd rather not have to delete/reinstall the nvidia driver to reboot every time  :Wink: 

----------

## depontius

 *Smeagel wrote:*   

> Seeing a lock up at waiting for uevents after installing nvidia module, on gentoo-sources 2.6.33-r2.  If I delete the module it boots fine.  I can then install the module and startx, etc, everything works fine, no errors to dmesg - but whenever I try to reboot it locks at "waiting for uevents".

 

I don't know if it's the same thing, but at some point my Thinkpad T61p started acting up.  X would start only once per installation, and never again, not even on power off and reboot.  I "solved" the problem by moving to Nouveau.

How about if you blacklist the nvidia module?  I've been getting another system ready for performance testing, and have blacklisted both nvidia and nouveau.  My thinking was that neither gets loaded at boot time, and the appropriate one would get demand-loaded by X.  It seems to me that blacklisting may be the solution to your problem, too.  Come to think of it, I didn't see a lock-up, I just saw a black screen.  It's been a few months now, so I don't really remember the symptoms.  My needs are 2D, and Nouveau is pretty good at that.

----------

## Skippy204

 *Smeagel wrote:*   

> Seeing a lock up at waiting for uevents after installing nvidia module, on gentoo-sources 2.6.33-r2.  If I delete the module it boots fine.  I can then install the module and startx, etc, everything works fine, no errors to dmesg - but whenever I try to reboot it locks at "waiting for uevents".
> 
> I have two Nvidia graphics cards as well as a Tesla card, not sure if that could have an effect.  I don't reboot frequently, but I'd rather not have to delete/reinstall the nvidia driver to reboot every time 

 

Hey there - I also have 2 Nvidia cards and I'm pretty sure that is somehow related to all of this.  I'm still on xorg-server 1.6.5 because the entire 1.7.x release will not work with two Nvidia cards.  If I only use one card it's fine, but two kill it.  I've not yet tried xorg-server 1.8.

Or rather I tried 1.8 with Nvidia drivers 195.36.24 and that version of the drivers caused the lock up at waiting for uevents as well.  When I have time I'm going to try xorg 1.8 with my current Nvidia drivers and see what happens.

I may end up having to try your method just to keep current.  Whey you say you "delete the module" do you mean you build your kernel without that module selected to be included?

Thanks for posting you experience.

Skippy

----------

## Smeagel

 *Quote:*   

> Whey you say you "delete the module" do you mean you build your kernel without that module selected to be included? 

 

I mean:

cd /lib/modules/2.6.33-gentoo-r2/

sudo rm `find . -name "nvidia.ko"`

A very clear deletion  :Wink: 

The method of blocking the module from being loaded at startup might be the best option.

As it stands it seemed my graphical performance was worse (firefox rendering seemed slower) with 2.6.33, so I just went back to 2.6.30 for now.  My reason for upgrading was for full TRIM support for an SSD, but now that I'm done installing gentoo on it and ready to drop it into my laptop I no longer need 2.6.33.

If anyone has a solution they want me to try, though, I'm still willing to give it a shot.

----------

## VinzC

I have the very same problem but using a Radeon video card. I'm experiencing this issue since I upgraded my kernel to 2.6.34, udev to >= 151 plus other stuff -- that was a big upgrade, always troublesome... I was using 2.6.33 and udev-146 before and that issue didn't occur.

How can I identify the cause?

----------

## Skippy204

My problem seems to have finally gone away with an upgrade to the newest Nvidia drivers.  I still have the problem that X doesn't find my mouse or keyboard, so I'm still working on that.  

But at least I can boot now.   :Smile: 

As to how to identify the cause...  I figured it out by restoring a working file system then emerging one thing at a time, rebooting, then emerging another until I broke it.  Not elegant...  but it worked.  Or didn't work rather.  *haha*

----------

## Muso

 *Skippy204 wrote:*   

> My problem seems to have finally gone away with an upgrade to the newest Nvidia drivers.  I still have the problem that X doesn't find my mouse or keyboard, so I'm still working on that.  

 

emerge xf86-input-evdev

?

----------

## VinzC

In my own case I had already re-emerged all X drivers and rebooted several times. The problem disappeared after a power off  :Shocked:  . Don't ask...  :Very Happy: 

 *Skippy204 wrote:*   

> My problem seems to have finally gone away with an upgrade to the newest Nvidia drivers.  I still have the problem that X doesn't find my mouse or keyboard, so I'm still working on that.  
> 
> But at least I can boot now.  
> 
> As to how to identify the cause...  I figured it out by restoring a working file system then emerging one thing at a time, rebooting, then emerging another until I broke it.  Not elegant...  but it worked.  Or didn't work rather.  *haha*

 

I had that issue as well. To fix the keyboard problem (qwerty despite any possible settings) I downgraded hal to the latest *stable* version and tweaked /etc/hal/fdi/policy/11-x11-synaptics.fdi to add several settings that enable tapping, scrolling and other corner features. Chances are your issue is there too.

----------

## Skippy204

regarding the two post above this one - thank you for your suggestions.  

I will investigate both of those as soon as I can.  I very much appreciate your help.  I'm still using xorg 1.6 as 1.7 and 1.8 have not worked for me yet.

I gotta resolve this issue soon.   :Smile: 

Thank you again - much appreciated.

Skippy

----------

## phosowicz

 *Skippy204 wrote:*   

> baselayout is 2, not 1.
> 
> 

 

How can I check it? I have the same problem as OP.

Regards,

Piotr

----------

## lexming

An 

```
emerge -pv baselayout
```

 will tell you that

----------

## Germanchu

Im having the same issue, my kernel panics after the "Waiting for uevents to be processed" line.

This machine has an Intel D865 motherboard with a Pentium 4 processor (kernel 2.6.39-gentoo-r3).

I fixed the issue by disabling acpi on the kernel command line (acpi=off). I guess that somehow this motherboard's ACPI implementation must be flawed or something.

Best regards!

----------

