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@xxxxxxxxxx> [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@xxxxxxxxxx> [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@xxxxxxxxxx
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
begin:vcard
fn:Rob Kampen
n:Kampen;Rob
email;internet:rkampen@xxxxxxxxxxxxxxxxx
tel;work:407-896-9556 x6344
tel;fax:407-896-7607
tel;home:407-876-4854
tel;cell:407-341-3815
version:2.1
end:vcard
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
