(SOLVED)->Process udevd--daemon consuming almost all the CPU

[PacoLM]

Hi,

 I do not know what was exactly the sequence, but I believe that after some upgrade (apt-get upgrade + apt-get update), my guruplug is  behaving different.
 In the init_setup.sh I added a mount command to allow the usb external hard disk to be mounted before starting the rest of applications. Basically, my guruplug is acting as a surveillance system using Zoneminder.
 Now, when I reboot, I get some 'complains' about udevd in the boot log and after the boot is complete, the plug goes really slow. Looking to the processes, there are a lot of udevd--daemon instances, and one of them is consuming almost all the cpu (>90%). Killing the process solves the problem and the guruplug goes to its normal ~35% cpu.

 Any clue?.

 Thanks in advance,

PacoLM

[Confusticated]

Have you tried fixing whatever it is that udev is complaining about ?

[PacoLM]

Newbie question:

 How could I know the device that is causing the problem?.

Thanks in advance,

PacoLM

[Confusticated]

I get some 'complains' about udevd in the boot log

Posting the log would be something....

[PacoLM]

Hi,

 This is the error that it's stuck until I press Ctrl+C in the boot process:

Code:

/var/log/daemon.log:May  5 21:43:15 mygp ata_id[11904]: HDIO_GET_IDENTITY failed for '/tmp/udev.svGStn/.tmp-block-8:32'

Then, the boot continues and everything looks fine, but slow, in the htop processes, there's a udev--daemon, if I killed it, it runs smooth as always. I will try with another hard disk just to see if the error is related with the HD or the library that it's trying to access to it.

 I have reinstalled all the applications removed in my last apt-get autoremove autoclean, rebooted, but behaves the same.

 Thanks in advance,

PacoLM

[Confusticated]

If I have surmised correctly this is a problem with whichever device is being detected as /dev/sdc by the kernel.
eg. If you have an eSATA drive connected (as /dev/sda) this would be the MicroSDHC Flash.
This is a result of asking the device driver for information it doesn't support.
It is most likely a change to udev itself, can you roll back to the previous version ?

[PacoLM]

How could I do the rollback?. I'm not a linux expert....

[apemberton]

'udev' certainly has been going through some updates recently and I have suffered some problems though none catastrophic. However I have found that there have been looooong delays in booting though no actual failure in the boot process when I updated (using kernel 2.6.38.2). If the booting process seems to hang without warning, just leave it for 10 mins and see if it sorts itself out. It did for me.

I'm not sure if you are suffering the same updated udev issues, but I am now booting OK albeit with some wanings from udev which is undoubtedly due to potentially out of date modules. IMHO, thats an issue with Intel/AMD architecture being mainstream and ARM and others lagging behind.

[PacoLM]

Fixed, upgrading the kernel to 2.6.38.8.