Description of problem: Under the 2.6.38 kernels, udevd is using up to 100% cpu The usage grows the longer the machine is on. Under 2.6.37 kernels this does not occur Version-Release number of selected component (if applicable): current kernel is 2.6.38.8-desktop-2.mga2 How reproducible: Steps to Reproduce: 1. boot in 2.6.38 series kernel > udevd uses increasing cpu 2. boot in 2.6.37 series kernel > no increase in udevd usage over time 3. hardware:- HP TX series laptop dual core AMD
Hello Team Mageia, Since the kernel version 2.6.38.8-4, I have the same problem. "udevd" uses lots of CPU.Before this version was good. https://bugs.mageia.org/show_bug.cgi?id=1525#c32
CC: (none) => geiger.david68210
Can you try kernel-linus-2.6.38.8-1 to see if it is an upstream issue or a mageia added patch...
CC: (none) => tmb
I can confirm not seeing the bug here under 2.6.38.7 and having updated this morning it hasn't re appeared yet under 3.0 rc7 I can confirm it was occuring with 2.6.38.8-desktop-1.mga. Note the updates I've added this morning also include udev 172-2 so udev 172-1 could also be a suspect.
Hello Thomas Backlund, What is the difference between a kernel-desktop, server and linus? What should be the kernel for a laptop?
-linus is vanilla kernel, w/o Mageia patches -server is like name says mostly for servers on laptop you should use -desktop If you have 32-bit system with 4GB of memory and you want to use it all then you may choose -server as -desktop can't use all the memory.
CC: (none) => sander.lepik
Hello Thomas Backlund, I tried with kernel-linus-2.6.38.8-1 and the problem remains the same. [root@david ~]# uname -r 2.6.38.8-1.mga "udevd" still uses a lot of CPU and PC is very hot (~70°).
Hello, I had the same problem after update to kernel 2.6.38-8-desktop-4. The system bloc a long time on "udev" line when it start, and when it is started the process "udevd" take a lot of cpu. I went back to kernel 2.6.38.7 and it is ok. I have also the problem descripted in the bug n° 1525.
CC: (none) => etienne15
CC: (none) => wrw105
Still happening with the latest udev?
CC: (none) => mageia
With Mageia release 1(Official)for x86_64,there is not the latest version of udev. The latest udev is version : 173-3.mga2 And I have this version : $ rpm -qa | grep udev lib64gudev1.0_0-166-5.mga1 libudev0-166-5.mga1 lib64udev0-166-5.mga1 system-config-printer-udev-1.3.1-4.1.mga1 udev-166-5.mga1 libgudev1.0_0-166-5.mga1 Nothing happening for now.
This bug appears to be reported against Cauldron... Either your system is not up-to-date (as you are using an older udev) or your are running mga v1 in which case the version number should be changed in this bug. Now, when you also say "nothing is happening for now" do you mean "the bug is not present any more"? And if so, does this mean the bug can be marked as fixed regardless of which distro it's reported against? I'm a bit confused now, as things are all very much our of sync (comments to the fields of the bug)! If you could clarify I'd be most grateful! Cheers
The bug is obviously present in the Cauldron, but also in Mageia 1. For me with kernel-desktop-2.6.38.8-4 on Mageia release 1(Official)for x86_64 , I have the same problem : "udevd" use a lot of CPU ,and the PC is becoming slower. Yes the bug can be marked as fixed regardless of which distro. So for now I'm forced to use the previous kernel-desktop-2.6.38.7, for to have no problem with "udev" . And with "udev" I have a another problem (which is not resolved) : https://bugs.mageia.org/show_bug.cgi?id=1525 My system is up-to-date ,I use the repo Testing->Core->Nonfree->Tainted. In fact we are a few to have the same problem. Sorry for the confusion, I did not want to open another bug report thinking it was good here.
I'm not sure that this can be marked as fixed, as it's still impossible to run the 2.6.38 series kernel in Mageia 1 without the udev issue cropping up. It definitely is a problem in the 1 release, as is bug 1525 which is preventing burning of CDs/DVDs.
I'm still a little confused: David you said: "The bug is obviously present in the Cauldron, but also in Mageia 1." but then contradicted that with: "Yes the bug can be marked as fixed regardless of which distro." Bill doesn't mention Cauldron but says it's definitely still a problem in mga1. Can you please clarify the status of this bug in Cauldron only (as this is the product this bug is opened against)? If we need to open a bug for mga1 (and it looks like we do) then we will do so, but I want to ensure the facts are all in place before spending time looking into problems that don't exist!
Sorry for my English! I badly expressed. The bug is indeed present with Mageia 1 .So no ,the bug can not be marked as fixed. The problems do exist,so I think this bug can be marked for Mageia Cauldron and also for Mageia 1. As Bill Wilkinson said: it's still impossible to run the 2.6.38 series kernel in Mageia 1 without the udev issue cropping up.
Does kernel-linus-2.6.38.8-1.1.mnb from: http://tmb.mine.nu/Mageia/1/bugs/1954/ http://tmb2.mine.nu/Mageia/1/bugs/1954/ work any better ?
Created attachment 765 [details] Screenshot of process "udevd" Hello,Thomas No,for me,it does not work better with the kernel-linus-2.6.38.8-1.1 . There is always the same problem with the process "udevd". After uptime 1 hour,the process "udevd" use a lot of CPU and CPU temperature is 74°C instead of 48°C with the kernel-desktop-2.6.38.7-1 . $ cat /etc/release Mageia release 1 (Official) for x86_64 $ uname -r 2.6.38.8-1.1.mga $ rpm -qa | grep kernel-linus kernel-linus-devel-latest-2.6.38.8-1.1.mga1 kernel-linus-devel-2.6.38.8-1.1.mga-1-1.mga1 kernel-linus-latest-2.6.38.8-1.1.mga1 kernel-linus-2.6.38.8-1.1.mga-1-1.mga1
Can you attach /var/log/dmesg from both a working 2.6.38.7 and a non-working 2.6.38.8
Can you also try kernel-linus-2.6.38.8-1.2.mga from the same site(s) there is now both i586 and x86_64 sets available
Created attachment 767 [details] dmseg kernel-desktop-2.6.38.7-1
Created attachment 768 [details] dmseg kernel-linus-2.6.38.8-1.2 Hello, With the kernel-linus-2.6.38.8-1.2 ,it still does not work better. $ uname -r 2.6.38.8-1.2.mga $ rpm -qa | grep kernel-linus kernel-linus-2.6.38.8-1.2.mga-1-1.mga1 kernel-linus-devel-latest-2.6.38.8-1.2.mga1 kernel-linus-devel-2.6.38.8-1.2.mga-1-1.mga1 kernel-linus-latest-2.6.38.8-1.2.mga1 the two files "dmesg" attached.
Can you try 2.6.38.8-1.3 and 2.6.38.8-1.4 from the same place.
Tested the kernel-linus-2.6.38.8-1.3 and always the same problem with udevd process. $ cat /etc/issue Mageia release 1 (Official) for x86_64 Kernel 2.6.38.8-1.3.mga on a Dual-processor x86_64 / \l $ rpm -qa | grep kernel-linus kernel-linus-2.6.38.8-1.3.mga-1-1.mga1 kernel-linus-doc-2.6.38.8-1.3.mga1 kernel-linus-latest-2.6.38.8-1.3.mga1 kernel-linus-devel-2.6.38.8-1.3.mga-1-1.mga1 kernel-linus-devel-latest-2.6.38.8-1.3.mga1
Created attachment 791 [details] dmseg kernel-linus-2.6.38.8-1.3
Created attachment 792 [details] dmseg kernel-linus-2.6.38.8-1.4 Tested also the kernel-linus-2.6.38.8-1.4 ,and sorry but the problem still. $ cat /etc/issue Mageia release 1 (Official) for x86_64 Kernel 2.6.38.8-1.4.mga on a Dual-processor x86_64 / \l $ rpm -qa | grep kernel-linus kernel-linus-devel-2.6.38.8-1.4.mga-1-1.mga1 kernel-linus-devel-latest-2.6.38.8-1.4.mga1 kernel-linus-doc-2.6.38.8-1.4.mga1 kernel-linus-latest-2.6.38.8-1.4.mga1 kernel-linus-2.6.38.8-1.4.mga-1-1.mga1
I haven't found this in my logs, but when rebooting out of 2.6.38.8-5 after the udev issue, (and I wrote this quickly from memory), I set the shut down in verbose mode. I received an error on the udev daemon stating net_action exited with status 0x00f (possibly more leading zeroes-didn't have paper handy when I saw the error. Attempting to use the linus kernels has resulted in no device attached to the wireless cards for 2.6.38.8-1.4. Running the setup utility would show :Broadcomm... or :ndiswrapper with no wlan0 in front and an inability to configure the wireless. Hope this helps!
Created attachment 797 [details] dmesg file from 2.6.38.8-5 from updates testing
I also found a number of udevd worker did not accept message [-1] connection refused with what I presume are a number of process IDs. If this is helpful and they're logged somewhere I'd be happy to dig up the logs on these. I'm attaching the dmesg for kernel linus 2.6.38.8-1.3 momentarily.
Created attachment 801 [details] dmesg from kernel-linus 2.6.38.8-1.3
There is now: kernel-linus-2.6.38.8-1.5.mga kernel-linus-2.6.38.8-1.6.mga kernel-linus-2.6.38.8-1.7.mga kernel-linus-2.6.38.8-1.8.mga to test at: http://tmb.mine.nu/Mageia/1/bugs/1954/ http://tmb2.mine.nu/Mageia/1/bugs/1954/ If theese dont work, can you confirm that installing kernel-linus-2.6.38.7-1.mga works too Normally I'd ask you to do a git bisect, but as kernel.org infra is still down, thats a no-go...
Created attachment 828 [details] dmesg kernel-linus-2.6.38.8-1.5 So,tested the kernel-linus-2.6.38.8-1.5.mga and it doesn't work better. $ cat /etc/issue Mageia release 1 (Official) for x86_64 Kernel 2.6.38.8-1.5.mga on a Dual-processor x86_64 / \l
Created attachment 829 [details] dmesg kernel-linus-2.6.38.8-1.6 So also ,tested the kernel-linus-2.6.38.8-1.6.mga and still no better.
Created attachment 830 [details] dmesg kernel-linus-2.6.38.8-1.7 Tested also the kernel-linus-2.6.38.8-1.7.mga and still no better. $ cat /etc/issue Mageia release 1 (Official) for x86_64 Kernel 2.6.38.8-1.7.mga on a Dual-processor x86_64 / \l
Created attachment 831 [details] dmesg kernel-linus-2.6.38.8-1.8 And finally ,tested the kernel-linus-2.6.38.8-1.8.mga and again no better. $ cat /etc/issue Mageia release 1 (Official) for x86_64 Kernel 2.6.38.8-1.8.mga on a Dual-processor x86_64 / \l
Created attachment 832 [details] dmesg kernel-linus-2.6.38.7-1 By cons, I can confirm the kernel-linus-2.6.38.7-1 work perfectly.No problem with the process "udevd". $ cat /etc/issue Mageia release 1 (Official) for x86_64 Kernel 2.6.38.7-1.mga on a Dual-processor x86_64 / \l
Created attachment 833 [details] Screenshot of process "udevd" with kernel-linus-2.6.38.7-1
Ok, nothing realy stands out, so switching to manual bisection... There is now three kernels there on x86_64 kernel-linus-2.6.38.7-136.mga kernel-linus-2.6.38.7-172.mga kernel-linus-2.6.38.7-208.mga Start with -172, if it works, try -208, else try -136
Created attachment 834 [details] dmesg kernel-linus-2.6.38.7-172 Ok, Tested the kernel-linus-2.6.38.7-172.mga and always the same problem, it doesn't work. $ cat /etc/issue Mageia release 1 (Official) for x86_64 Kernel 2.6.38.7-172.mga on a Dual-processor x86_64 / \l
And what about -136 ?
Created attachment 835 [details] dmesg kernel-linus-2.6.38.7-136 Oh, sorry It doesn't work too ,with the kernel-linus-2.6.38.7-136. $ cat /etc/issue Mageia release 1 (Official) for x86_64 Kernel 2.6.38.7-136.mga on a Dual-processor x86_64 / \l
Next rounds of tests... kernel-linus-2.6.38.7-109.mga kernel-linus-2.6.38.7-118.mga kernel-linus-2.6.38.7-127.mga Start with -118, if it works, try -127, else try -109
Created attachment 836 [details] dmesg kernel-linus-2.6.38.7-118 So ,tested the kernel-linus-2.6.38.7-118 and this work perfectly. Bingo :) $ cat /etc/issue Mageia release 1 (Official) for x86_64 Kernel 2.6.38.7-118.mga on a Dual-processor x86_64 / \l
Created attachment 837 [details] dmesg kernel-linus-2.6.38.7-127 But from here begins the problem of process "udevd": Tested the kernel-linus-2.6.38.7-127 and this doesn't work correctly. $ cat /etc/issue Mageia release 1 (Official) for x86_64 Kernel 2.6.38.7-127.mga on a Dual-processor x86_64 / \l I think I do not need to test the kernel-linus-2.6.38.7-109 ? :D
(In reply to comment #42) > > I think I do not need to test the kernel-linus-2.6.38.7-109 ? :D Nope. Ok, we are getting closer... There is now: kernel-linus-2.6.38.7-122.mga kernel-linus-2.6.38.7-123.mga Try -122 first, and if it works, try -123
Created attachment 838 [details] dmesg kernel-linus-2.6.38.7-123 Ok, Tested the kernel-linus-2.6.38.7-122 and this work correctly. $ cat /etc/issue Mageia release 1 (Official) for x86_64 Kernel 2.6.38.7-122.mga on a Dual-processor x86_64 / \l Also,tested the kernel-linus-2.6.38.7-123 and this work correctly too. $ cat /etc/issue Mageia release 1 (Official) for x86_64 Kernel 2.6.38.7-123.mga on a Dual-processor x86_64 / \l
Ok, here is three more to test: kernel-linus-2.6.38.7-124.mga kernel-linus-2.6.38.7-125.mga kernel-linus-2.6.38.7-126.mga Just test them one by one...
Status: NEW => ASSIGNEDHardware: x86_64 => AllVersion: Cauldron => 1Assignee: bugsquad => tmbSource RPM: UDEV => kernel
Created attachment 840 [details] dmesg kernel-linus-2.6.38.7-124 Well here we are : Tested the kernel-linus-2.6.38.7-124 and this work perfectly. $ cat /etc/issue Mageia release 1 (Official) for x86_64 Kernel 2.6.38.7-124.mga on a Dual-processor x86_64 / \l But the kernel-linus-2.6.38.7-125 doesn't work correctly ,the problem is from it. $ cat /etc/issue Mageia release 1 (Official) for x86_64 Kernel 2.6.38.7-125.mga on a Dual-processor x86_64 / \l
Created attachment 841 [details] dmesg kernel-linus-2.6.38.7-125 Thank you very much Thomas Backlund.
Ok, you hit the one I suspected of theese last few ones... There is now a: kernel-linus-2.6.38.8-2.mga Can you confirm that it works too...
Created attachment 842 [details] dmesg kernel-linus-2.6.38.8-2 (In reply to comment #48) > > Can you confirm that it works too... It's the opposite, right? I can confirm with the kernel-linus-2.6.38.8-2 it doesn't work either. The process "udevd" work no correctly. $ cat /etc/issue Mageia release 1 (Official) for x86_64 Kernel 2.6.38.8-2.mga on a Dual-processor x86_64 / \l
Gah.. I forgot the reversion patch... There is now a: kernel-linus-2.6.38.8-3.mga available for test.
Created attachment 844 [details] dmesg kernel-linus-2.6.38.8-3 (In reply to comment #50) > Gah.. > > I forgot the reversion patch... > > There is now a: > > kernel-linus-2.6.38.8-3.mga > > available for test. So Thomas , I can confirm with the kernel-linus-2.6.38.8-3 it work correctly. I think we finally come at the end of this galley. Really excellent Thomas . $ cat /etc/issue Mageia release 1 (Official) for x86_64 Kernel 2.6.38.8-3.mga on a Dual-processor x86_64 / \l
Yep. I have merged the fix in the core kernel and submitted it to updates_testing. After it's available (in ~4+ hours), please test that one too and confirm it works.
(In reply to comment #52) > Yep. > > I have merged the fix in the core kernel and submitted it to updates_testing. > > After it's available (in ~4+ hours), please test that one too and confirm it > works. I use the kernel-server, will he available? or is it the kernel-desktop?
It's queued to become a security update kernel for all users on both i586 and x86_64 so it's a full kernel set with desktop(586), netbook, server, xen-pvops
Ok, thank you I'll test this, Tomorrow night.
Ok, really excellent Thomas. Now it works fine. So, I think the bug is fixed and can be closed. Thomas , I have a another question about this bug: https://bugs.mageia.org/show_bug.cgi?id=1525 Can we also try to solve it together? Thank you very much.
It would be good if Brian Smith, Etienne Etienne and Bill Wilkinson could test the kernel in updates_testing and confirm that the bug is solved for them too.
CC: (none) => stormi
So far so good. On the broken kernels, it was often taking udev on the order of minutes to start on the first boot to a new kernel. It came up in seconds with the -6 release. I've had it up for about an hour and seems to be running smoothly so far. I'll post again this evening (US east coast time) after I've had a bit more of a chance to run it for a while. And, I'll add my voice to David's--Thomas, could you help with 1525? once that one get ironed out, I'll be a happy camper!
As I said in comment 3 This issue disapeared for me (on Cauldron) after the release of the 3.0 RC series kernels. Currently I haven't got mga1 on this machine so I can't test the fix for release mga1. Good work by Thomas and David to track it down and fix it in mga1.
I've been testing by running BOINC calculations for about 4 hours. The system is running like a champ, so it looks to me as if it's fixed.
Ok so closing, thanks to all ! :)
Status: ASSIGNED => NEW
really close now
Status: NEW => RESOLVEDResolution: (none) => FIXED
(In reply to comment #54) > It's queued to become a security update kernel for all users on both i586 and > x86_64 so it's a full kernel set with desktop(586), netbook, server, xen-pvops The xen-pvops rpm packages are missing on i586, as well as the kernel-server-latest and kernel-server-devel-latest.
CC: (none) => davidwhodgins