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.
I assume you loaded kdump on this system prior to panicing the kernel. What was the result of the service kdump start operation?
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.
>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 :)
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.
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?
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.