https://bugzilla.novell.com/show_bug.cgi?id=308647#c300124 Summary: Support extended syntax for crashkernel bootparameter, so kernels can adjust to changing hardware Product: openSUSE 10.3 Version: Beta 3 Platform: All OS/Version: Linux Status: NEW Severity: Enhancement Priority: P5 - None Component: Kernel AssignedTo: bwalle@novell.com ReportedBy: odabrunz@novell.com QAContact: qa@suse.de CC: juhliarik@novell.com Found By: Development This was discussed in Bug #300124.
bwalle@, what happens if the user removes RAM from the system so that a previously set "crashkernel" value would need to allocate too much RAM during next boot and the system cannot start up? Does the kernel ignore this value then, does it stop booting or does it crash?
Also a good point. ;)
At first, this is architecture specific. Reserving the memory is done in architecutre specific code -- different architectures behave even different when parsing the command line
- PPC64 ignores the offset and always takes 16M - IA64 as architecture with a relocatable kernel since ages can guess an offset ...
I only tested this on x86_64 by accident, so I cannot talk about all possible archs. There are two cases
1. The reserved value es larger or the same as the system memory. Then the kernel crashes at boot with some obscure error.
2. There's some (but too small) memory for the kernel/system. Then the system behaves just as if you try to boot a full features SUSE Linux with 16 MiB of RAM ...
But this is nothing unchangable. I could try to prepare a patch that handles the case better. At least the first case with presenting a clear error message what to do or to just ignore the memory reservation and printing a message in the kernel log.
But the 2nd case is more difficult. It would imply to make policy decisions in kernel space. I don't think that something like "make it impossible to reserve more as 50 % of system RAM for crashkdump" gets accepted upstream.
However, in general I think the case where the user removes that much memory is very rare. Note that we don't talk about "Ließchen Müller" that uses kdump on the laptop but mostly Enterprise server users.
I'll work on the first issue as soon as time permits, though.
Right. Here is what we talked about on the phone: Probably it makes sense to decide in userspace on a policy for the crashkernel value for different RAM-sizes, and then tell the kernel about this policy. In this way, the kernel can still make adequate decisions during boot even when the user removed (or added) RAM. The crashkernel parameter could support an extended syntax (modeled after the netdevice= parameter): crashkernel=<ramsize-range1>:<cksize1>[,<ramsize-range2>:<cksize2>,..] A typical use would be: crashkernel=0-191M:0,192M-511M:64M,512M-1023M:>>3,1G-:128M meaning: 0-191M:0 below 192MiB RAM, set crashkernel to 0 192M-511M:64M from 192MiB to 511MiB RAM, set crashkernel to 64MiB 512M-1023M:>>3 from 512MiB to 1023MiB RAM, set crashkernel to 1/8th of the RAM size (= (ramsize >> 3)) 1G-:128M from 1GiB RAM upwards, set crashkernel to 128MiB This approach solves the problem that when the crashkernel feature is used systems could become unbootable after relatively normal hardware changes. This should also be supported by yast2-kdump then. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.