On Fri, Jun 27, 2008 at 6:32 AM, Vivek Goyal [EMAIL PROTECTED] wrote:
On Thu, Jun 26, 2008 at 09:54:08PM +0200, Bernhard Walle wrote:
This patch removes the need of the [EMAIL PROTECTED] parameter to define
a fixed offset for crashkernel reservation. That feature can be used together
with a
Bernhard Walle [EMAIL PROTECTED] writes:
* Yinghai Lu [2008-07-14 00:11]:
should use min_t(u64, 1ULL32, max_low_pfnPAGE_SHIFT) replace ULONG_MAX
Shouldn't we use min_t(u64, ULLONG_MAX, max_low_pfnPAGE_SHIFT), i.e.
should we really limit the crashkernel to a 32 bit address on a 64 bit
On Mon, Jul 14, 2008 at 2:44 AM, Eric W. Biederman
[EMAIL PROTECTED] wrote:
Bernhard Walle [EMAIL PROTECTED] writes:
* Yinghai Lu [2008-07-14 00:11]:
should use min_t(u64, 1ULL32, max_low_pfnPAGE_SHIFT) replace ULONG_MAX
Shouldn't we use min_t(u64, ULLONG_MAX, max_low_pfnPAGE_SHIFT), i.e.
Yinghai Lu [EMAIL PROTECTED] writes:
for 64bit, kdump can start from address above 4g with bzImage?
I think the boot protocol was properly updated for that, it was in the
original drafts. A relocatable kernel with a 64bit entry point.
I do know that the 64bit code is ready to do that.
Eric
Yinghai Lu [EMAIL PROTECTED] writes:
On Mon, Jul 14, 2008 at 10:30 AM, Eric W. Biederman
[EMAIL PROTECTED] wrote:
Yinghai Lu [EMAIL PROTECTED] writes:
for 64bit, kdump can start from address above 4g with bzImage?
I think the boot protocol was properly updated for that, it was in the
* Eric W. Biederman [2008-07-14 11:41]:
Yinghai Lu [EMAIL PROTECTED] writes:
On Mon, Jul 14, 2008 at 10:30 AM, Eric W. Biederman
[EMAIL PROTECTED] wrote:
Yinghai Lu [EMAIL PROTECTED] writes:
for 64bit, kdump can start from address above 4g with bzImage?
I think the boot protocol
Bernhard Walle [EMAIL PROTECTED] writes:
But such checks belong into kexec itself, not into the kernel.
Exactly.
All we should do in the kernel is bias the search for a low address.
As that is more usable.
Eric
___
kexec mailing list
* Bernhard Walle [EMAIL PROTECTED] wrote:
But in general policy should go in userspace (if possible), so I
agree with you that kexec-tools can handle that.
At a quick skim the patch looks good. I thought I had initially
implemented the code to work this way but apparently in all
On Fri, Jun 27, 2008 at 09:32:56AM -0400, Vivek Goyal wrote:
On Thu, Jun 26, 2008 at 09:54:08PM +0200, Bernhard Walle wrote:
This patch removes the need of the [EMAIL PROTECTED] parameter to define
a fixed offset for crashkernel reservation. That feature can be used
together
with a
* Vivek Goyal [2008-06-27 09:42]:
Thinking more about. Let me step back. I think it is not good idea to
take this kernel take decision about the capability of kernel being
loaded. There is no way we can find out now that if a kernel is capable
of running from this memory location or not.
* Vivek Goyal [2008-06-27 10:19]:
On Fri, Jun 27, 2008 at 04:06:56PM +0200, Bernhard Walle wrote:
* Vivek Goyal [2008-06-27 09:42]:
Thinking more about. Let me step back. I think it is not good idea to
take this kernel take decision about the capability of kernel being
loaded.
Bernhard Walle [EMAIL PROTECTED] writes:
Ah, that's true. Only on x86, right? (That would be an alternative for
ia64, too ...)
But in general policy should go in userspace (if possible), so I agree
with you that kexec-tools can handle that.
At a quick skim the patch looks good. I thought
* [EMAIL PROTECTED] (Eric W. Biederman) [2008-06-27 11:00]:
Bernhard Walle [EMAIL PROTECTED] writes:
Ah, that's true. Only on x86, right? (That would be an alternative for
ia64, too ...)
But in general policy should go in userspace (if possible), so I agree
with you that kexec-tools
This patch removes the need of the [EMAIL PROTECTED] parameter to define
a fixed offset for crashkernel reservation. That feature can be used together
with a relocatable kernel where the kexec-tools relocate the kernel and
get the actual offset from /proc/iomem.
The use case is a kernel where the
14 matches
Mail list logo
