[CentOS] problem with udev when booting kernel 5.3 release 128.4.1

Fri Aug 21 14:19:25 UTC 2009

Tru Huynh wrote:
> On Thu, Aug 20, 2009 at 10:41:55PM -0400, Rob Kampen wrote:
>   
>> Rob Kampen wrote:
>>     
>>> Hi List,
>>> I am running a 64 bit 5.3 kernel on an intel mb and all has been well.
>>> Today I thought it would be okay to reboot so that the latest kernel  
>>> was running - i.e move from 128.2.1 to 128.4.1 release.
>>> The system passes POST fine, grub passes control to the 128.4.1 kernel  
>>> and the boot process is under way.
>>> after some 30 secs the system starts beeping - continuously.
>>> After I hooked up a monitor I find that udev does not come up with OK  
>>> and thats when the system starts the beep beep beep ......
>>>       
> ...
>   
>> Still no joy with the latest kernel - fails at initialization of udevd  
>> with beep beep beep .......
>> I have tried a new version of the rr174x raid controller device driver,  
>> new make and make install but still the same issue. Not sure if this  
>> module is looked at by udev or not - I'm way out of my depth here.
>>
>> Currently server is functioning fine on
>> Linux obfuscated.example.com 2.6.18-128.2.1.el5 #1 SMP Tue Jul 14  
>> 06:36:37 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
>> but I'm perturbed why a simple update of the kernel kills my server -  
>> not what I expected from CentOS / RHEL.
>> What tests / things should I check? I see no files in /etc with dates  
>> after Jul 21 (date I installed 128.2.1 kernel) that appear to contain  
>> any device related changes
>>     
>
> The changelog from 2.6.18-128.2.1.el5 to 2.6.18-128.4.1.el5:
>
> * Fri Jul 24 2009 Don Howard <dhoward at redhat.com> [2.6.18-128.4.1.el5]
> - [fs] ecryptfs: check tag 11 packet literal data buffer size (Eric Sandeen ) [512862 512863] {CVE-2009-2406}
> - [fs] ecryptfs: check tag 3 packet encrypted key size (Eric Sandeen ) [512886 512887] {CVE-2009-2407}
> - [misc] personality handling: fix PER_CLEAR_ON_SETID (Vitaly Mayatskikh ) [511173 508842] {CVE-2009-1895}
> - [xen] HV: remove high latency spin_lock (Chris Lalancette ) [512311 459410]
>
> * Tue Jul 14 2009 Jiri Pirko <jpirko at redhat.com> [2.6.18-128.3.1.el5]
> - [pci] quirk: disable MSI on VIA VT3364 chipsets (Dean Nelson ) [507529 501374]
> - [char] tty: prevent an O_NDELAY writer from blocking (Mauro Carvalho Chehab ) [510239 506806]
> - [misc] hrtimer: fix a soft lockup (Amerigo Wang ) [418061 418071] {CVE-2007-5966}
> - [misc] hrtimer: check relative timeouts for overflow (AMEET M. PARANJAPE ) [510018 492230]
>
> Do you see anything relevant to your hardware?
>
> Since you mention that udev has started, we can rule out the kernelbooting/initrd stage.
>
> Tru
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>   
Thanks for the changelog Tru - I was looking for this.
The mb is Intel S3000AH with I guess intel chipsets and only card is a 
rocketraid rr174x card running RAID 5
It runs a quad core X3220 Intel Xeon processor.
As it is passing POST and kernel 128.2.1 functions fine I have 
confidence the hw is okay.
I do not run encrypted fs nor xen, thus those items should not impact.
No idea what personality handling refers to
I think the pci VIA chip does not apply as this is an intel mb
the [char]tty patch I do not understand
that leaves only the [misc] hrtimer - but I'm out of my depth to know if 
this could apply.
looking in dmesg output of 128.2.1 boot the timer lines read:

Calibrating delay using timer specific routine.. 4802.13 BogoMIPS 
(lpj=2401069)
Using local APIC timer interrupts.
Detected 16.667 MHz APIC timer.
Calibrating delay using timer specific routine.. 4799.55 BogoMIPS 
(lpj=2399777)
Calibrating delay using timer specific routine.. 4799.46 BogoMIPS 
(lpj=2399733)
Calibrating delay using timer specific routine.. 4799.56 BogoMIPS 
(lpj=2399781)
time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
PCI: Setting latency timer of device 0000:00:1c.0 to 64
PCI: Setting latency timer of device 0000:00:1c.4 to 64
PCI: Setting latency timer of device 0000:00:1c.5 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
PCI: Setting latency timer of device 0000:00:1c.0 to 64
PCI: Setting latency timer of device 0000:00:1c.4 to 64
PCI: Setting latency timer of device 0000:00:1c.5 to 64
PCI: Setting latency timer of device 0000:00:1d.7 to 64
PCI: Setting latency timer of device 0000:00:1d.0 to 64
PCI: Setting latency timer of device 0000:00:1d.1 to 64
PCI: Setting latency timer of device 0000:00:1d.2 to 64
PCI: Setting latency timer of device 0000:00:1d.3 to 64
PCI: Setting latency timer of device 0000:00:1f.2 to 64
PCI: Setting latency timer of device 0000:03:00.0 to 64

doesn't appear of much help.
As mentioned, I updated to latest rocketraid software just in case this 
was a problem as the card is a little older, and re did the make and 
make install, this gives me a new initrd in /boot and I guess must be 
working as I get past this in the boot process.
What's next? How do I get more info about the loading of devd?
It does not appear in the normal /etc/init.d/ or /etc/rcX.d/Sxx...... 
thus I am unsure how it is initiated and looking at RH boot docs last 
night did not help.

Thanks
Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rkampen.vcf
Type: text/x-vcard
Size: 196 bytes
Desc: not available
URL: <http://lists.centos.org/pipermail/centos/attachments/20090821/d1a60996/attachment.vcf>