[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150923002001.GB2569@dhcp-17-102.nay.redhat.com>
Date: Wed, 23 Sep 2015 08:20:01 +0800
From: Baoquan He <bhe@...hat.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: yinghai@...nel.org, dyoung@...hat.com, jroedel@...e.de,
tglx@...utronix.de, mingo@...hat.com, hpa@...or.com, bp@...e.de,
linux-kernel@...r.kernel.org
Subject: Re: [Patch v4] Do not reserve crashkernel high memory if crashkernel
low memory reserving failed
On 09/22/15 at 05:08pm, Andrew Morton wrote:
> On Wed, 23 Sep 2015 08:02:55 +0800 Baoquan He <bhe@...hat.com> wrote:
>
> > >
> > > > }
> > > >
> > > > low_base = memblock_find_in_range(low_size, (1ULL<<32),
> > > > low_size, alignment);
> > > >
> > > > if (!low_base) {
> > > > - if (!auto_set)
> > > > - pr_info("crashkernel low reservation failed - No suitable area found.\n");
> > > > -
> > > > - return;
> > > > + pr_info("crashkernel low reservation failed - No suitable area found.\n");
> > >
> > > That's not a terribly useful message. If kdump is now unavailable and
> > > the operator needs to take some remedial action then we should inform
> > > them of this.
> > >
> > > Also, such a message should have higher severity than KERN_INFO?
> >
> > Yes, how about KERN_ERR? It's an unexpected result from kdump side
> > though it doesn't harm the normal kernel.
>
> Sure, KERN_ERR is good. Along with more useful message text.
OK, will do. Thanks for your suggestion.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists