From Bugzilla Helper: User-Agent: Mozilla/4.76C-ja [en] (X11; U; FreeBSD 4.2-RELEASE i386) Description of problem: For some strange reason, our web servers that are running Red Hat Linux 7.1 are kernel panicing with this message left on the screen; pmd entry cbfe5000: 0000000000 ... pmd not present! Oops: 0000 CPU: 0 EIP: 0010:[<c01d549c>] EFLAGS:00010246 eax:00e40621 ebx:d0692bd9 ecx:00000001 edx: 00000000 esi:00000000 edi:d06a2aa0 epb:00000003 esp:c026fd8c ds:0018 es:0018 ss:0018 Process swapper (pid: 0, stackpage=c026f000) . . . . . . . . . Stack Call Trace: [<c01d61b6>] I am forced to power cycles the machine, and watch if FCSK our data. Nothing interesting in /var/log/messgaes; /var/log/secure; /var/log/cron. How reproducible: Always Steps to Reproduce: 1. Nothing, but to wait. 2. Watch 3. Notice kernel panic Actual Results: pmd entry cbfe5000: 0000000000 ... pmd not present! Oops: 0000 CPU: 0 EIP: 0010:[<c01d549c>] EFLAGS:00010246 eax:00e40621 ebx:d0692bd9 ecx:00000001 edx: 00000000 esi:00000000 edi:d06a2aa0 epb:00000003 esp:c026fd8c ds:0018 es:0018 ss:0018 Process swapper (pid: 0, stackpage=c026f000) . . . . . . . . . Stack Call Trace: [<c01d61b6>] I am forced to power cycles the machine, and watch if FCSK our data. Expected Results: pmd entry cbfe5000: 0000000000 ... pmd not present! Oops: 0000 CPU: 0 EIP: 0010:[<c01d549c>] EFLAGS:00010246 eax:00e40621 ebx:d0692bd9 ecx:00000001 edx: 00000000 esi:00000000 edi:d06a2aa0 epb:00000003 esp:c026fd8c ds:0018 es:0018 ss:0018 Process swapper (pid: 0, stackpage=c026f000) . . . . . . . . . Stack Call Trace: [<c01d61b6>] I am forced to power cycles the machine, and watch if FCSK our data. Additional info: This started happening after a upgrade from RH 7.0 to RH 7.1. I called Red Hat this week, and they said I needed to move my swap partition from the software raid drive to a real physical partition; which I did. So it's not the swap file problem. Should we upgrade to a newer kernel revision? 2.4.5? Please advise
Could you please try the updated kernel 2.4.3-12 we released last friday ? (sorry for the late response, the release of this kernel was nearly finished when you posted this bug but that got delayed due to certain circumstances)
Don't know if this is the same bug. It would be nice to get a "fixed in kernel" rather than a "try kernel" response. ksymoops 2.4.0 on i686 2.4.2-2. Options used -v /usr/src/linux-2.4.2/vmlinux (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.2-2/ (specified) -m /boot/System.map-2.4.2-2 (specified) -S Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in vmlinux. Ignoring ksyms_base entry Warning (compare_maps): mismatch on symbol mts_list_semaphore , microtek says 508953d8, /lib/modules/2.4.2-2/kernel/drivers/usb/microtek.o says 50895144. Ignoring /lib/modules/2.4.2-2/kernel/drivers/usb/microtek.o entry Warning (compare_maps): mismatch on symbol usb_devfs_handle , usbcore says 508b6120, /lib/modules/2.4.2-2/kernel/drivers/usb/usbcore.o says 508b5c40. Ignoring /lib/modules/2.4.2-2/kernel/drivers/usb/usbcore.o entry Warning (compare_maps): mismatch on symbol proc_scsi , scsi_mod says 5088852c, /lib/modules/2.4.2-2/kernel/drivers/scsi/scsi_mod.o says 50886dfc. Ignoring /lib/modules/2.4.2-2/kernel/drivers/scsi/scsi_mod.o entry Unable to handle kernel NULL pointer dereference at virtual address 00000008 508b9925 Oops: 0000 CPU: 0 EIP: 0010:[<508b9925>] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: 41475a94 ecx: 4dca2000 edx: 41475a9c esi: 00000000 edi: c0010380 ebp: 41475a80 esp: 40237f10 ds: 0018 es: 0018 ss: 0018 Stack: 00000773 4dc8c400 41475a9c 41475a9c 41475a80 00000000 00000000 508bb711 47475a80 00000000 41475a80 00000000 00000001 00000246 00000000 4026d240 0000d400 4dc8f700 04000001 00000005 40237fa8 4010a219 00000005 41475a80 Call Trace: [<508bb711>] [<4010a219>] [<4010a299>] [<40107160>] [<40107160>] [<40108fc4>] [<40107160>] [<40107160>] [<40107183>] [<40107202>] [<40108000>] [<40100191>] Code: 8b 46 08 83 f8 ff 0f 84 cc 00 00 00 3b 04 24 0f 84 c3 00 00 >>EIP; 508b9925 <[usb-uhci]uhci_cleanup_unlink+45/140> <===== Trace; 508bb711 <[usb-uhci]uhci_interrupt+111/130> Trace; 4010a219 <handle_IRQ_event+39/60> Trace; 4010a299 <disable_irq+59/60> Trace; 40107160 <default_idle+0/30> Trace; 40107160 <default_idle+0/30> Trace; 40108fc4 <ret_from_intr+0/20> Trace; 40107160 <default_idle+0/30> Trace; 40107160 <default_idle+0/30> Trace; 40107183 <default_idle+23/30> Trace; 40107202 <cpu_idle+52/70> Trace; 40108000 <sys_rt_sigsuspend+20/f0> Trace; 40100191 <L6+0/2> Code; 508b9925 <[usb-uhci]uhci_cleanup_unlink+45/140> 00000000 <_EIP>: Code; 508b9925 <[usb-uhci]uhci_cleanup_unlink+45/140> 0: 8b 46 08 mov 0x8(%esi),%eax <===== Code; 508b9928 <[usb-uhci]uhci_cleanup_unlink+48/140> 3: 83 f8 ff cmp $0xffffffff,%eax Code; 508b992b <[usb-uhci]uhci_cleanup_unlink+4b/140> 6: 0f 84 cc 00 00 00 je d8 <_EIP+0xd8> 508b99fd <[usb-uhci]uhci_cleanup_unlink+11d/140> Code; 508b9931 <[usb-uhci]uhci_cleanup_unlink+51/140> c: 3b 04 24 cmp (%esp,1),%eax Code; 508b9934 <[usb-uhci]uhci_cleanup_unlink+54/140> f: 0f 84 c3 00 00 00 je d8 <_EIP+0xd8> 508b99fd <[usb-uhci]uhci_cleanup_unlink+11d/140> Kernel panic: Aiee, killing interrupt handler! 4 warnings issued. Results may not be reliable. This is from trying to get a V6USL scanner working over usb, using the microtek.o module. The following from the driver developer: < quote &tg This is the piece of code that kills your box ((urb_priv->started != 0xffffffff) && (urb_priv->started != now))) { The current kernel has a workaround for this. Yet I do not understand how this could become a NULL pointer. < end quote > Also, searching RH for the latest kernel, I get a list of 10 2.2 kernels. Go here: http://www.redhat.com/apps/download/ and search for "kernel" IntelX86. You get stuff like "kernel 2.2.19 - 7.0.8 i686 | 15949k | Jun 21 2001 | Red Hat, Inc" So, that looks like a step backward from 2.4.2-2 (from the 7.1 distro). I understand that 2.4.7 is the latest.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/