Bug 625996 - Memory for crash kernel (0x0 to 0x0) notwithin permissible range
Memory for crash kernel (0x0 to 0x0) notwithin permissible range
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.5
All Linux
medium Severity medium
: rc
: ---
Assigned To: Neil Horman
Red Hat Kernel QE team
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-21 06:55 EDT by Gerrit Slomma
Modified: 2010-11-09 07:58 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 431584
Environment:
Last Closed: 2010-10-25 06:55:37 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)
patch to squash the lack of crashkernel option (3.25 KB, patch)
2010-09-21 16:45 EDT, Neil Horman
no flags Details | Diff

  None (edit)
Description Gerrit Slomma 2010-08-21 06:55:53 EDT
+++ 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.
Comment 1 clive darra 2010-09-20 04:22:31 EDT
many thanks for cloning i still get this 'error' everytime i boot any of my rhel 5.5 instances
Comment 2 Neil Horman 2010-09-20 09:42:29 EDT
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.
Comment 3 rjones 2010-09-20 09:50:13 EDT
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.
Comment 4 Nicolai Nielsen 2010-09-20 10:09:48 EDT
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?
Comment 5 Gerrit Slomma 2010-09-20 19:21:29 EDT
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."
Comment 6 Gerrit Slomma 2010-09-20 19:23:48 EDT
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.
Comment 7 Neil Horman 2010-09-21 07:00:17 EDT
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.
Comment 8 Gerrit Slomma 2010-09-21 16:09:05 EDT
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.
Comment 9 Neil Horman 2010-09-21 16:34:56 EDT
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.
Comment 10 Neil Horman 2010-09-21 16:45:28 EDT
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.
Comment 11 Neil Horman 2010-10-25 06:55:37 EDT
No response in over a month.  Closing.

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