Bug 519714 - [RHEL5.4][kdump] System can't boot into kexec kernel.
Summary: [RHEL5.4][kdump] System can't boot into kexec kernel.
Keywords:
Status: CLOSED DUPLICATE of bug 510645
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.4
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Jeff Burke
QA Contact: Red Hat Kernel QE team
URL: http://rhts.redhat.com/testlogs/2009/...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-27 14:24 UTC by Jeff Burke
Modified: 2009-08-27 23:59 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-08-27 23:59:43 UTC


Attachments (Terms of Use)

Description Jeff Burke 2009-08-27 14:24:34 UTC
Description of problem:
 When running the kdump testing on RC3 the system dell-pem905-01.rhts.bos.redhat.com could not boot the kexec kernel

Version-Release number of selected component (if applicable):
2.6.18-164.el5

How reproducible:
Always

Steps to Reproduce:
1. Install RHEL5.4-Server-20090819.0 i386 on dell-pem905-01.rhts.bos.redhat.com
2. Setup kdump, Manually crash the system Alt+SysRq+C
  
Actual results:
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Checking 'hlt' instruction... irq 74, desc: c12f5380, depth: 1, count: 0, unhandled: 0
->handle_irq():  c104d84a, handle_bad_irq+0x0/0x1a6
->chip(): c128af80, 0xc128af80
->action(): 00000000
  IRQ_DISABLED set
unexpected IRQ trap at vector 4a
irq 90, desc: c12f5b80, depth: 1, count: 0, unhandled: 0
->handle_irq():  c104d84a, handle_bad_irq+0x0/0x1a6
->chip(): c128af80, 0xc128af80
->action(): 00000000
  IRQ_DISABLED set
unexpected IRQ trap at vector 5a
irq 98, desc: c12f5f80, depth: 1, count: 0, unhandled: 0
->handle_irq():  c104d84a, handle_bad_irq+0x0/0x1a6
->chip(): c128af80, 0xc128af80
->action(): 00000000
  IRQ_DISABLED set
unexpected IRQ trap at vector 62

Expected results:
System should be able to boot the kexec kernel.

Additional info:

This was RHTS job 86631 recipe 25319. Link to the console log.
http://rhts.redhat.com/testlogs/2009/08/86631/253197/2077573/console.txt
If the above link does not work. It may have been gzipped try this link
http://rhts.redhat.com/testlogs/2009/08/86631/253197/2077573/console.txt.gz

Comment 1 Linda Wang 2009-08-27 15:22:38 UTC
any kdump history on this machine would be appreciated.
has it been consistently across all RHEL5.4 build that 
this machine fails? 

When was last time it succeeded? 
Is it a regression from RHEL5.3? Just a few questions
that would help narrow down the cause.

Comment 2 Jeff Burke 2009-08-27 17:29:05 UTC
This is not a regression. The issue does happen with RHEL5.3.

Log snippet
----------------------------------
Linux version 2.6.18-128.el5PAE (mockbuild@hs20-bc1-5.build.redhat.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) #1 SMP Wed Dec 17 12:02:33 EST 2008
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000100 - 00000000000a0000 (usable)
 BIOS-e820: 0000000000100000 - 00000000cfaa0000 (usable)
 BIOS-e820: 00000000cfaa0000 - 00000000cfab6000 (reserved)
 BIOS-e820: 00000000cfab6000 - 00000000cfad5c00 (ACPI data)
 BIOS-e820: 00000000cfad5c00 - 00000000d0000000 (reserved)
 BIOS-e820: 00000000f0000000 - 00000000f8000000 (reserved)
 BIOS-e820: 00000000fe000000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 0000000230000000 (usable)
user-defined physical RAM map:
 user: 0000000000000000 - 00000000000a0000 (usable)
 user: 0000000001000000 - 0000000008f5b000 (usable)
0MB HIGHMEM available.
143MB LOWMEM available.
found SMP MP-table at 000fe710
.
.
.
.
.
.
.
.
Memory: 122584k/146796k available (2119k kernel code, 8304k reserved, 879k data, 228k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
hpet0: at MMIO 0xfed00000 (virtual 0xc9800000), IRQs 2, 8, 31
hpet0: 3 32-bit timers, 25000000 Hz
Using HPET for base-timer
irq 98, desc: c12e7f80, depth: 1, count: 0, unhandled: 0
->handle_irq():  c104b136, handle_bad_irq+0x0/0x1a6
->chip(): c127fd00, 0xc127fd00
->action(): 00000000
  IRQ_DISABLED set
unexpected IRQ trap at vector 62
irq 90, desc: c12e7b80, depth: 1, count: 0, unhandled: 0
->handle_irq():  c104b136, handle_bad_irq+0x0/0x1a6
->chip(): c127fd00, 0xc127fd00
->action(): 00000000
  IRQ_DISABLED set
unexpected IRQ trap at vector 5a

Comment 3 Qian Cai 2009-08-27 23:59:43 UTC
This is a duplication of,

Bug 510645 - Kdump Kernel Stops on Dell Machines at: Checking 'hlt' instruction

*** This bug has been marked as a duplicate of bug 510645 ***


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