Created attachment 315627 [details] boot sequence from syslog Description of problem: With recent rawhide kernels, I'm getting the error "crashkernel reservation failed - memory is in use" and kdump won't work. In my kernel command line I have crashkernel=128M@16M. The machine is a HP Proliant ProLiant BL680c G5 with 16 cores and 16 GB of memory Version-Release number of selected component (if applicable): kernel-2.6.27-0.290.rc5.fc10 Additional info: Attached is an excerpt from the syslog.
It also should be noted that with kernel-2.6.25.14-108.fc9, reserving crashkernel memory workes but actually booting into the crash kernel fails due to bug 459103
try omitting the @16M. It may be that you're getting lots of memory pre-allocated and its happening down in ZONE_NORMAL. IIRC if you omit the @16M, the kernel will search for a free block of memory for you to use.
After omitting @16M (i.e. using only the parameter crashkernel=128M), the memory reservation succeeds. Should this bugzilla be redirected at system-config-kdump (which wrote me this configuration) or is the memory supposed to be available @16M?
The answer to that question is ambiguous I'm afraid. The memory in the area you are looking to reserver for crashkernel space _should_ nominally be available, but is not guaranteed to be available. Several factors define weather or not it will be, and those factors are in turn dependent on configuration, environment and timing. So while its as good a place as any to try to reserve memory, its not guaranteed. And unfortunately some older kernels require that you specify an offset for your memory start point, and s-c-kdump needs to work with those as well. Its safe for s-c-kdump to omit the @offset for rawhide forward, but not any released fedora or RHEL distros. I'd say open a new bug against rawhide s-c-kdump and ask that it be updated only there. Thanks!