Bug 496514 - kernel panics, no dump is produced
kernel panics, no dump is produced
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
All Linux
low Severity urgent
: ---
: ---
Assigned To: Neil Horman
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-19 16:22 EDT by GeoffLeach
Modified: 2009-04-21 12:58 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-21 12:58:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output of lshw on subject system (19.53 KB, application/octet-stream)
2009-04-19 16:22 EDT, GeoffLeach
no flags Details

  None (edit)
Description GeoffLeach 2009-04-19 16:22:10 EDT
Created attachment 340255 [details]
Output of lshw on subject system

Description of problem:
kernel panics, no dump is produced

Version-Release number of selected component (if applicable):
2.6.27.12-170.2.5.fc10.i68

How reproducible:
always

Steps to Reproduce:
1.kernel panics
2.reboot (after power cycle)
3.no kerneloops
  
Actual results:
no kerneloops

Expected results:
kerneloops

Additional info:
I'm assuming the the panic does not produce a dump file (/var/log/dump?), so kerneloops has nothing to do. The MB, ASUS P5N7A-VM, is relatively new, so that may be relevant.  lshw attached.
Comment 1 Neil Horman 2009-04-19 20:25:07 EDT
I assume you loaded kdump on this system prior to panicing the kernel.  What was the result of the service kdump start operation?
Comment 2 GeoffLeach 2009-04-19 21:27:20 EDT
You would be assuming to much knowledge on my part :-). But I can do that.

So ..
root@pvr[14]->service kdump start
No kdump initial ramdisk found.                            [WARNING]
Rebuilding /boot/initrd-2.6.27.12-170.2.5.fc10.i686kdump.img
Starting kdump:                                            [FAILED]

kexec-kdump-howto.txt describes a somewhat complex procedure, including grabbing kernel-debuginfo from a debuginfo repo, which is not included with the standard disto. Is all of that required merely to get the kernel to save a dump?

Not to engage in quibbling over semantics, but I did not "panic the kernel"; the kernel paniced. I'm the victim here, not the instigator, if that makes a difference.
Comment 3 Neil Horman 2009-04-20 09:46:27 EDT
>kexec-kdump-howto.txt describes a somewhat complex procedure, including
>grabbing kernel-debuginfo from a debuginfo repo, which is not included with the
>standard disto. Is all of that required merely to get the kernel to save a
>dump?

You don't actually need kernel-debuginfo.  Its optional if you want to implement dump filtering, but in F-10, you shouldn't even need it for that.  Regardless, the minimum you need to do for kdump to work is reserve some crashkernel memory at bootup in the production kernel.  Append this to your normal kernels command line:
crashdump=XM@YM
where X is an amount of memory (usually 64 or 128), and Y is a location in ram.  For x86 kernels I usually recommend:
crashkernel=128M@16M

Reboot, and after that when you run:
service kdump start
the kdump service should start correctly.  From there you can edit /etc/kdump.conf to make the dump capture process more robust, efficient, etc.

>Not to engage in quibbling over semantics, but I did not "panic the kernel";
>the kernel paniced. I'm the victim here, not the instigator, if that makes a
>difference.  
Not for the purpose of this bug, as far as I can see.  Weather the kernel encounters a legitimate error, or you crash it with sysrq-c is irrelevant to kdump.  As I read the initial comment here, you expected to get a dump to analyze the panic and did not, and thats what we're solving here.  If you have a crash that you want fixed, thats fine, we can do that.  I was just trying to solve the problem you documented when you opened this bug :)
Comment 4 GeoffLeach 2009-04-20 21:19:13 EDT
OK. added crashkernel=128M@16M to the kernel command line. Verified that the kdump service was running, did not modify /etc/kdump.conf  Nothing in /var/crash.
Comment 5 Neil Horman 2009-04-21 06:56:22 EDT
Ok, just saying that the core still isn't there isn't enough to go on.  What happened when the system crahsed?  Can you provide a serial console log of the output?
Comment 6 GeoffLeach 2009-04-21 12:58:31 EDT
Forcing a kernel panic produced a vcore in /var/crash. Running memtest86+ shows I have a bad memory module. From this I conclude that the kernel did not panic and therefore did not produce a vcore; rather, it was a hardware fault of some kind.

Thanks for the assistance.

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