Bug 119244 - Kernel won't boot; Kernel panic Bad EIP Value
Kernel won't boot; Kernel panic Bad EIP Value
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Dave Anderson
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-03-26 20:22 EST by Mike Andrewjeski
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-26 12:12:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mike Andrewjeski 2004-03-26 20:22:46 EST
Description of problem:

RHEL AS 2.1 on an IBM eserver 345 Bios level = 1.13

Kernel Locked up and on reboot won't come up. Screen output at boot:

EIP: 0060:[<8491a899>] Not tainted 
EFLAGS: 00010246

EIP is at Using_versions[]
eax: 0000003b ebx: f6c4a000 ecx: 00000000 edx: 00000000 
esi: 00008136 edi: 00000296 ebp: 67890000 esp: c8ae7dd0 
ds: 0058 es: 000 ss: 0018 

Process init (pid 25, stackpage=f6a5f000) 

call Trace : 

Code: Bad EIP value 

Kernel Panic: Fatal Exception

Version-Release number of selected component (if applicable):

How reproducible: completely

Steps to Reproduce:
Actual results:
kernel panic

Expected results:

Additional info:
Comment 1 Mike Andrewjeski 2004-03-29 18:24:18 EST
This box is actually RHEL 3.0 and not 2.1
Comment 3 Ernie Petrides 2004-08-25 19:58:58 EDT
Mike, do you have a complete RHEL3 installation on that box?

I couldn't even find a reference to a "Using_versions" symbol
in the latest sources (corresponding to the soon-to-be-released
Update 3).  Does the same problem occur with a more recent RHEL3
installation (such as 2.4.21-15.EL, i.e. Update 2)?
Comment 4 Dave Anderson 2004-08-26 09:06:00 EDT
This must have been a manual copy?  Because it should be
"Using_Versions" (capital "V"), which I believe ends up as
the last kernel symbol stored.  So when a bogus EIP like this
one is encountered, the kernel's ksymoops output typically
consists of "EIP is at Using_Versions+<some bizarre offset>".

So the bogus EIP is 0x8491a899, and when it was cycled through
lookup_symbol(), it looks to have come out as:

  EIP is at Using_Versions+0x8491a898 (2.4.21-4.EL)

or (EIP-1), if it was transposed correctly.  And that doesn't make
any mathematical sense AFAICT.

In any case, like Jason said, there's nothing to work with here.

Comment 5 Mike Andrewjeski 2004-08-26 12:11:47 EDT
Thanks Dave & Ernie,

I appreciate that you've taken this bug even after such a long time.

I do need to let you both know that I have resolved this issue and that 
problem was that init was corrupted. Once we restored a good copy the
machine runs well again. My apologies in not closing this bug out
myself. Can either of close this bug? or tell me how I can?

Once Again thanks for efforts they are greatly appreciated


Note You need to log in before you can comment on or make changes to this bug.