Red Hat Bugzilla – Bug 625996
Memory for crash kernel (0x0 to 0x0) notwithin permissible range
Last modified: 2010-11-09 07:58:02 EST
+++ This bug was initially created as a clone of Bug #431584 +++ Description of problem: every time i boot 5.5 i get the error "Memory for crash kernel (0x0 to 0x0) notwithin permissible range" Version-Release number of selected component (if applicable): 5.1 How reproducible: every time Steps to Reproduce: 1. install 5.1 (without enabling kdump) 2. reboot 3. watch startup screen Actual results: "Memory for crash kernel (0x0 to 0x0) notwithin permissible range" Expected results: "kdump disabled" Additional info: --- Additional comment from james.antill@redhat.com on 2008-02-05 12:38:07 EST --- I assume this was a mistake making this against zsh? Reassigning, and tweaking the summary. --- Additional comment from cdredhat@oths.co.uk on 2008-02-05 12:46:00 EST --- yes you're right thanks - i didn't realise kdump was actually listed as kexec-kdump --- Additional comment from nhorman@redhat.com on 2008-02-06 10:26:50 EST --- Its not a bug, its just an informative message, indicating that you haven't specified an area of memory to reserve during boot up for use by the kdump kernel. You can specify it using the crashkernel=X@Y commandline parameter --- Additional comment from cdredhat@oths.co.uk on 2008-02-07 06:44:38 EST --- if crashkernel=0x0@0x0 is not the "correct way" to disable kdump what is ? and why doesn't install program use this "other way" instead ? --- Additional comment from nhorman@redhat.com on 2008-02-07 07:02:16 EST --- The correct way to disable kdump is to not start the kdump service. Adding a crashkernel line to the kernel command line won't enable or disable kdump at all, that just reserves memory for use by kdump to use. Sepcifying crashkernel=0@0 is exactly the same as not specifying a crashkernel parameter at all. You'll still get the warning in the logs, which is there to inform you that, even if you try to start the kdump service, it will fail. --- Additional comment from cdredhat@oths.co.uk on 2008-02-07 08:55:03 EST --- sorry to keep going on a bit more but does this mean the installer is doing the wrong thing if you untick the enable kdump box ! http://www.flickr.com/photos/osde-info/2241815136/ BTW even if i # chkconfig kdump off and reboot i still see this message on the boot up screen ! so does this make this is an grub/installer issue rather than kdump issue ? --- Additional comment from nhorman@redhat.com on 2008-02-07 10:05:01 EST --- No, there is no issue. Kdump requires that a large chunk of contiguous memory be reseerved for its use. This chunk is sufficiently large that it can't be allocated dynamically in a runing system. As such we reserve it on bootup. This process is 100% separate from the starting of the kdump service . It will be reserved weather or not you start the kdump service later in the boot process. conversely, if you do not select any memory, you won't be able to use kdump if you try to start the service. unchecking the box in the initial install prevents the kdump service from starting, and thats working just fine. But the kernel has no knoweldge of that decision as early in the boot process as we need to reserve that memory. As such we need to issue a warning indicating that non crash kernel memory is reserved, even if we don't intend to start the kdump service later consider the converse situation. if you had intended to start the kdump service later, but didn't specify a valid crashkernel memory range, this warning provides a red flag as to what has gone wrong with the process. If you don't intend to start kdump, then you can safely ignore this warning. This is working exactly the way its supposed to. --- Additional comment from cdredhat@oths.co.uk on 2008-02-07 12:13:33 EST --- thanks --- Additional comment from uleman@acm.org on 2009-04-06 11:53:53 EDT --- "Its not a bug, its just an informative message, ..." "No, there is no issue." "This is working exactly the way its supposed to." Despite the helpful explanations, Neil's responses are also a bit too much of the variety, "We developers know what we mean, but you users are just not getting it." Clearly, there is an issue: several people have stumbled over this (google it). In my work as a software developer, anything that generates customer support calls (or forum entries, as the case may be) is a bug, though you can argue over the severity. In this case, I think it's pretty obvious what the defect is: the message is poorly worded (not to mention poorly typed), causing it to be misleading and alarming (not "informative"). So I think a few edits would help. Note that I know nothing about kexec/kdump, nor anything about constraints on boot messages (lengthwise or otherwise). But I'm looking for these improvements: 1) If there's a more or less accepted way to indicate that this is just an informational message and not indicative of a failure, use it. (Info: or Warning:?) 2) Indicate that this has something to do with kdump (kexec?), so you can go look for instructions if you want to learn more. 3) While alerting the user to the fact that insufficient memory has been allocated for kdump, suggest that this is only relevant if you actually want to use kdump. For example: "Info: Memory for crash kernel (0x0 to 0x0) insufficient for kdump. Allocate more if using kdump." What do you think? --- Additional comment from gerrit.slomma@itsslomma.de on 2009-06-30 17:39:51 EDT --- Sounds good. Furthermore i would rather have the message disappear if - and only if - the memory-amount for crashkernel is set to "0x0 to 0x0" since this only means the crashkernel-feature is set to off by intention. Must be a rather simple "if-then-else" statement surrounding the statement that prints this message. --- Additional comment from bugzilla@leenukes.co.uk on 2009-06-30 18:57:11 EDT --- (In reply to comment #10) > Sounds good. Furthermore i would rather have the message disappear if - and > only if - the memory-amount for crashkernel is set to "0x0 to 0x0" since this > only means the crashkernel-feature is set to off by intention. Must be a rather > simple "if-then-else" statement surrounding the statement that prints this > message. I would also prefer it to not report anything or at least reword it if this isn't a problem. "not within permissible range" gives the impression something is broken. --- Additional comment from rjones@gannett.com on 2009-09-16 09:36:58 EDT --- Yeah, this was the first time I ever came across that, i thought for sure I had bad hardware or messed up the install or found a bug in 5.4. Would be nice if when you go to install a server and turn off kdump, it disabled this message or gave a better worded message like "kdump disabled, not configured" --- Additional comment from charles@dwhs.net on 2010-03-27 20:53:58 EDT --- I thought this was a hardware issue as well, good to know it's just a alert. --- Additional comment from bug@sas.upenn.edu on 2010-04-26 09:41:20 EDT --- Please reword this "alert". It is unnecessarily alarming and generates many help requests. I think many people are tired of explaining this to alarmed users. It only teaches users to ignore real errors, which is a VERY BAD THING. --- Additional comment from lutz.willek@science-computing.de on 2010-06-24 11:24:24 EDT --- (In reply to comment #7) > No, there is no issue. Take a step back, try to understand, here is an issue. Hundreds of thousands people wasting time by searching informations about a stupid warning message. Please disable this warning, if no crashkernel=xy line is provided and: > consider the converse situation. if you had intended to start the kdump service > later, but didn't specify a valid crashkernel memory range, this warning > provides a red flag as to what has gone wrong with the process. If you don't > intend to start kdump, then you can safely ignore this warning. later, if you try to start kdump check for a valid cmdline "crashkernel=xy". --- Additional comment from nicolai@dufva.net on 2010-08-19 15:03:15 EDT --- I notice that this is a closed ticket so I am not sure if this is even read or considered by the developers but I fail to understand why this is even reported by the kernel. As I understand it the reasoning is: "If you ever want to enable kdump later this may be a problem at that time so we tell you now". That is just confusing people. Why isn't it kdump that gives this error, as in: if (no-enough-memory-reserved-for-crash-kernel) { fail("Not enough memory reserved. Please add more memory using the crashkernel=X@Y kernel parameter"); } As others have said, this is a defect since it is causing confusion for end-users. Gerrit Slomma: Cloned the bug since i think no developer is reading closed bugs anymore. Rebased to RHEL 5.5, wasn't able to rebase the initial bug, so the clone was necessary.
many thanks for cloning i still get this 'error' everytime i boot any of my rhel 5.5 instances
I think this issues has been fairly well explained as an informative message and not a bug, so I'm going to close it again.
Then why not make the message you receive be worded more as an informative message rather than it seeming like there is a problem/config issue on the server? That's all everyone is asking for here, and guessing by the amount of search results returned when you search for this, I think the need for a rewording is proven.
Neil, I think you must be using a different definition of "informative". With the amount of people coming here looking to know why they get an error during startup, the message has clearly failed in its purpose and is thus a defect. Again, I fail to see why the message is even shown during kernel startup. Why is it not kdump that fails with a message if it startup of kdump is attempted without a crash kernel configured?
This is a bad joke! People are being bothered by this and you are saying it is no bug? I have the kdump-service disabled - hence no need to inform me that # grep "permissible" /var/log/dmesg Memory for crash kernel (0x0 to 0x0) notwithin permissible range Againg the kdump-service should check this when starting and give the message as well as a hint how to enable memory for crash-kernel. From wikipedia about bugs: http://en.wikipedia.org/wiki/Software_bug "A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. Most bugs arise from mistakes and errors made by people in either a program's source code or its design, and a few are caused by compilers producing incorrect code. A program that contains a large number of bugs, and/or bugs that seriously interfere with its functionality, is said to be buggy. Reports detailing bugs in a program are commonly known as bug reports, fault reports, problem reports, trouble reports, change requests, and so forth."
Reopened since this is a bug by definition and - as explained by the responsibilities - the exact false position to complain about that setting. In fact when setting memory for crash kernel to 0 MB and deactivating kdump-service the memory for crash kernel is well within permissible range - 0 MB to be exact.
I'm done wasting my time on this. I grant you that the language isn't great, but its usefull to get a note in the message log when you forget to reserve crashkernel memory so you can tell whats causing kdump to not startup. I'll tell you what, I'll make you a deal. Open up a support issue, and if you can convince the support organization that this needs to change for 5.7, they'll attach your support issue to this ticket, and I'll change it.
I tell you i would file a support issue if i could file a support issue. I do have an account as well as the password and 56 active subscriptions. But i can't i am only the administrator and we are a large company with around 20000 employees of which 1200 in the computers-branch. There is no workflow yet to file support issues and i am suffering from this: One opens a bug report only to see it closed with the remark: "File an support issue". Bottom line is i would get into hells kitchen if I open support issues on behalf of myself. I even had an personal subscription at home - RHEL 5 Desktop - but did not continued it after two years when two support issues were not handled to my satisfaction for RHEL but where included into Fedora based from bugzilla.
I'm sorry, I'm really not following you. You have an account and password for our support portal, but can't open an issue, because why? because theres no workflow for doing so? The landing page for filing a support issue is right here: https://access.redhat.com/support/cases If you're saying that your company has no workflow yet for opening support issues, well, I'm sure that will get sorted out soon. Until then, I'll attach a patch and you can use that until you can get a support issue opened up.
Created attachment 448805 [details] patch to squash the lack of crashkernel option here, I'm not committing this, nor am I committing to this, but until such time as you get a support issue open, and convince someone here that this is a good idea, you can use this to build a one-off kernel and get by if you're users are giving you that much pain over it.
No response in over a month. Closing.