# Stuck at waiting for uevents to be processed

## marco.difresco

Hi all,

few hours ago I rebooted the PC to activate the new Nvidia drivers, but suddenly I got stuck at "waiting for uevents to be processed".

After few 3 hours attempting (and obviously,since I am here, failing) to find the cause, I had to settle for this workaround:

- I removed xdm from autostarting (rc-update del xdm default) otherwise it would lock the system on the next step (it shows the login screen but the keyboard and mouse are dead);

- when I get stuck at "waiting for uevents to be processed", I press CTRL+C to bypass it;

- I log as root;

- I manually run /etc/init.d/udev;

- I manually run other services that failed because udev (net.eno1, samba, ssh, etc.);

- I manually run /etc/init.d/xdm and login.

After that the system seems to run fine (I have been trying for just few minutes), but obviously the above method isn't right.  :Smile: 

I have sys-fs/udev 216 and kernlel 3.18.11-gentoo 64 bits. I have CONFIG_FHANDLE=y CONFIG_NET=y and CONFIG_DMIID=y 

Here a list of the packages updated since the last successful reboot:

Sat Apr 11 16:12:11 2015 >>> dev-python/pycups-1.9.68

Sat Apr 11 16:12:15 2015 >>> dev-python/pycurl-7.19.3.1-r2

Sat Apr 11 16:12:25 2015 >>> x11-libs/xpyb-1.3.1-r3

Sat Apr 11 16:12:30 2015 >>> dev-python/pycairo-1.10.0-r4

Sat Apr 11 16:12:44 2015 >>> dev-python/pygobject-3.14.0

Sat Apr 11 16:12:51 2015 >>> app-admin/system-config-printer-common-1.4.3

Sun Apr 12 17:32:02 2015 >>> dev-lang/lua-5.1.5-r3

Sun Apr 12 17:32:07 2015 >>> sys-apps/hwids-20150129

Sun Apr 12 17:33:08 2015 >>> media-gfx/nvidia-cg-toolkit-3.1.0013-r3

Sun Apr 12 17:33:22 2015 >>> media-libs/ftgl-2.1.3_rc5

Sun Apr 12 17:33:56 2015 >>> media-libs/libprojectm-2.1.0-r1

Sun Apr 12 17:34:00 2015 >>> media-libs/libreplaygain-477-r1

Sun Apr 12 17:34:04 2015 >>> media-libs/libcuefile-477-r1

Sun Apr 12 17:34:11 2015 >>> media-sound/musepack-tools-465-r1

Sun Apr 12 17:36:18 2015 >>> media-video/vlc-2.1.5-r1

Tue Apr 14 21:23:35 2015 >>> sys-apps/microcode-data-20150121

Tue Apr 14 21:33:26 2015 >>> app-emulation/wine-1.7.40

Wed Apr 15 14:45:17 2015 >>> sys-libs/timezone-data-2015b

Wed Apr 15 14:47:56 2015 >>> x11-drivers/nvidia-drivers-346.59

Wed Apr 15 14:48:36 2015 >>> www-client/google-chrome-42.0.2311.90_p1

Here it is dmesg: http://pastebin.com/Kgtzndhs. The strange thing is that it mention Systemd even if I don't have it.

Any idea?

Thanks in advance.

----------

## DONAHUE

your dmesg does not contain "kernel: devtmpfs: initialized"

From a very old news:  *Quote:*   

> devtmpfs support:
> 
> You need at least version 2.6.32 of the kernel for devtmpfs
> 
> functionality. Once you have this, make sure CONFIG_DEVTMPFS=y is set
> ...

 

If you are not using any recent form of udev; Never mind.

----------

## davidm

Hi, the appearance of "systemd-udev" isd probably no cause for big alarm.  I believe udev eventually merged with systemd and in gentoo they merely extract it modularly so that you only get the udev portion (unless you install systemd or it gets pulled in from something else).  However it still calls itself 'systemd-udev in the logs.

Anyway it seems like a tricky problem.  I see lots of threads with this problem and various causes such as:

https://forums.gentoo.org/viewtopic-p-7638848.html

f the packages you updated since the the last reboot I would say the microcode and nvidia binary are probably the most suspicious.  I will let other much smarter and experienced people/gurus like Neddy or Donahue help you more hopefully but if no one can you might consider switching to eudev or downgrading the microcode and nvidia drivers to the previous versions to see if it resolves it.  Good luck.

edit: I see DONAHUE already replied.  :Smile: 

----------

## marco.difresco

 *DONAHUE wrote:*   

> your dmesg does not contain "kernel: devtmpfs: initialized"
> 
> From a very old news: [...] make sure CONFIG_DEVTMPFS=y
> 
> 

 

I have version 216 of udev; I assume it is recent (according to eix version 217 and newer are still unstable), right?

I checked for devtmpfs and I have it in the kernel:

```

# cat /usr/src/linux/.config | grep CONFIG_DEVTMPFS

CONFIG_DEVTMPFS=y

# CONFIG_DEVTMPFS_MOUNT is not set

```

 *davidm wrote:*   

> 
> 
> Hi, the appearance of "systemd-udev" isd probably no cause for big alarm.  I believe udev eventually merged with systemd and in gentoo they merely extract it modularly so that you only get the udev portion (unless you install systemd or it gets pulled in from something else).  However it still calls itself 'systemd-udev in the logs.
> 
> 

 

Ok, good to know.

 *davidm wrote:*   

> 
> 
> If the packages you updated since the the last reboot I would say the microcode and nvidia binary are probably the most suspicious.
> 
> [...]
> ...

 

I tried with the Nvidia drivers as I found other topics mentioning it, but without success. The version I used to have (346.47) before the update is no longer in the tree - I tried various earlier and newer version than that and than the update (346.59), but I still had the same problem.

Regarding microcode, I have downgraded it and ... I have to verify it when I get at home in a couple of hours (so far I sshed from a remote location), but we may have hit the jackpot since I have gave the reboot command and soon after the system came up again (and it should mean that it did got stuck at the udev events).

I will post later with the confirmation.

Thank you very much for your help.

----------

## marco.difresco

Hi all,

I can confirm that downgrading sys-apps/microcode-data solved the issues.

I have to admit that I have been lucky that the above update happened in conjunction with nvidia drivers and that this time I had issues to reload the drivers without rebooting (for some reason I couldn't rmmod nvidia-uvm because it was in use and therefore I opted for the original reboot that showed the uevents problem); unless there is a kernel update or a a power outage, I usually go a long time between reboots and if it wasn't for that reboot I would have had a lot of updates to test to find the culprit.

----------

## DONAHUE

Good catch davidm.

----------

