events/0 process usage
 

Does anyone know what the events/0 process or events/1 process is for? Mine are running at 90% cpu usage, and although i can still do things (maybe because I have a duo core processor) I'm not confident that it's any good.

IIRC the events threads process pending events in the kernel generated by drivers and the like. 90% CPU seems rather high. What kind of workload is your system experiencing?

Well this is the thing, because I have an intel duo core processor, it seems fine until I do things like play music or watch films. I've booted the kernel using the nosmp option and this made performance drop severely, causing me to forcefully reboot.

I've tried rmmod on various module but nothing seems to shift it. I'm worried that kernel support for these new processors is what is causing the problem.

OK, I've made some progress in that I have made linux boot without the high event/0 usage. GRUB broke so I ran the SUSE isntallation CD rescue system: this booted without causing the problem.

The problem is that I do not know how. How can I compare what the rescue system loads with what SUSE normally boots? Also, udevd fails to load normally during boot, but once in linux it is running. Could this be the issue?

Thanks.

Fixed!
 

Finally I have managed to fix the problem. I went into the bios and disabled all of the hardware on my laptop and it worked. I gradually re-enabled things (USB, WLAN, etc) until it happened again...the culprit is my LAN card, which uses the sky2 module.

I'm in the process of finding a fix so that I don't have to leave it disabled. At least I am now linuxing again :)

How did you fix the problem with sky2 module
 

Please let me know how you fixed the problem! I'd love to linux freely, but I couldn't manage with events/0 taking all the cpu.

In a 2.6 kernel, events/cpu_number is a mechanism (it replaces the old keventd) for handling low-level requests that need to run asynchronously. All sorts of notifications run through there ... it's very ad hoc. So if you're seeing this "pegging the meter," all it's really telling you is that there's a loop somewhere.

Your "eliminate possibilities one-by-one" approach was probably an excellent strategy given the circumstances.

events/0 still
 

Thanks for the explanation! But I still don't know a possible way out. It'd be very helpful to have my computer running at normal speed.

are there other ways of finding why 'events\0' is hogging the cpu? this started on my system about 10 days ago after i got suspend2 stuff to work. could there be a connection?

thanks,

tom arnall
north spit, ca

There can be hundreds upon millions of reasons why a cpu is being hogged. The problem with mine was bad driver support/possible fault LAN card. It works in Windows and passes the workshop tests when I sent it off so apparently it's ok...I'm still not convinced. Either way, I just have it turned of in the BIOS so neither Windows nor Linux are aware that it even exists.

If you want to try and find the cause, have a look at the output of your kernel and the boot process. See if there is any hardware that is throwing up errors. It may not even be a hardware problem, it could be that some software you use is stuck in some lengthy operation, so try updating or downgrading the version of that software. It's a difficult one to solve without knowing the cause.

Some useful commands/files:

1. top = live processor usage
2. dmesg = kernel output
3. /var/log/messages = boot messages (I think)

I'm sure there are more useful tools. At 2:30am it's hard to remember. :)

My laptop shows the same symptoms. Initially I thought this was a cron thing but I'm convinced it was due to my WLAN driver. When I run "/etc/init.d/network restart" the "events/0" process terminates & cpu usage drops to normal. However, the wireless never comes up during network restart. Maybe I need to reload the kernel module?

Have same problem with a HP laptop, use ifup/ifdown to control the network instead of network manager and no more events/0 taking more than 60% of CPU. Running OpenSuse 11.3. With OpenSuse 11.2, this problem was no present on the same computer.