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-0005.vcf>