On Tue, Feb 19, 2013 at 5:38 PM, Xishi Qiu wrote:
> Seems like a good idea, should we modify
> "\linux\Documentation\kernel-parameters.txt"?
Perhaps in Documentation/kdump/kdump.txt (which the crashkernel entry
in kernel-parameters.txt
points at). The ia64 section of kdump.txt notes that the
On Tue, Feb 19, 2013 at 5:38 PM, Xishi Qiu qiuxi...@huawei.com wrote:
Seems like a good idea, should we modify
\linux\Documentation\kernel-parameters.txt?
Perhaps in Documentation/kdump/kdump.txt (which the crashkernel entry
in kernel-parameters.txt
points at). The ia64 section of kdump.txt
On 2013/2/20 5:56, Tony Luck wrote:
> Foolishly sent an earlier reply from Outlook which appears
> to have mangled/lost it. Trying again ...
>
>> In efi_init() memory aligns in IA64_GRANULE_SIZE(16M). If set
>> "crashkernel=1024M-:600M"
>
> Is this where the real problem begins? Should we
Foolishly sent an earlier reply from Outlook which appears
to have mangled/lost it. Trying again ...
> In efi_init() memory aligns in IA64_GRANULE_SIZE(16M). If set
> "crashkernel=1024M-:600M"
Is this where the real problem begins? Should we insist that users
provide crashkernel
parameters
> In efi_init() memory aligns in IA64_GRANULE_SIZE(16M). If set
> "crashkernel=1024M-:600M"
Is this where the real problem begins? Should we insist that users provide
crashkernel
parameters rounded to GRANULE boundaries?
-Tony
In efi_init() memory aligns in IA64_GRANULE_SIZE(16M). If set
crashkernel=1024M-:600M
Is this where the real problem begins? Should we insist that users provide
crashkernel
parameters rounded to GRANULE boundaries?
-Tony
Foolishly sent an earlier reply from Outlook which appears
to have mangled/lost it. Trying again ...
In efi_init() memory aligns in IA64_GRANULE_SIZE(16M). If set
crashkernel=1024M-:600M
Is this where the real problem begins? Should we insist that users
provide crashkernel
parameters rounded
On 2013/2/20 5:56, Tony Luck wrote:
Foolishly sent an earlier reply from Outlook which appears
to have mangled/lost it. Trying again ...
In efi_init() memory aligns in IA64_GRANULE_SIZE(16M). If set
crashkernel=1024M-:600M
Is this where the real problem begins? Should we insist that
On 2013/2/13 18:07, Matt Fleming wrote:
>> In efi_init() memory aligns in IA64_GRANULE_SIZE(16M). If set
>> "crashkernel=1024M-:600M"
>> and use sparse memory model, when crash kernel booting it changes
>> [128M-728M] to [128M-720M].
>> But initrd memory is in [709M-727M], and virt_addr_valid()
On 2013/2/13 18:07, Matt Fleming wrote:
In efi_init() memory aligns in IA64_GRANULE_SIZE(16M). If set
crashkernel=1024M-:600M
and use sparse memory model, when crash kernel booting it changes
[128M-728M] to [128M-720M].
But initrd memory is in [709M-727M], and virt_addr_valid() *can not*
On Thu, 2013-02-07 at 14:09 +0800, Xishi Qiu wrote:
> > Sorry, this bug will be happen when use Sparse-Memory(section is valid, but
> > last
>
> > several pages are invalid). If use Flat-Memory, crash kernel will boot
> > successfully.
> > I think the following patch would be better.
> >
> >
On Thu, 2013-02-07 at 14:09 +0800, Xishi Qiu wrote:
Sorry, this bug will be happen when use Sparse-Memory(section is valid, but
last
several pages are invalid). If use Flat-Memory, crash kernel will boot
successfully.
I think the following patch would be better.
Hi Andrew, will
On Tue, Feb 12, 2013 at 4:19 PM, Andrew Morton
wrote:
> But, umm, why am I sitting here trying to maintain an ia64 bugfix and
> handling bug reports from the ia64 maintainer? Wanna swap?
That sounds like a plan. I'll look out for a new version with the
missing #include
and less silly global
On Tue, 12 Feb 2013 16:11:33 -0800
Tony Luck wrote:
> Building linux-next today (tag next-20130212) I get the following errors when
> building arch/ia64/configs/{tiger_defconfig, zx1_defconfig, bigsur_defconfig,
> sim_defconfig}
>
> arch/ia64/mm/init.c: In function 'free_initrd_mem':
>
On Tue, 12 Feb 2013 16:11:33 -0800
Tony Luck wrote:
> Building linux-next today (tag next-20130212) I get the following errors when
> building arch/ia64/configs/{tiger_defconfig, zx1_defconfig, bigsur_defconfig,
> sim_defconfig}
>
> arch/ia64/mm/init.c: In function 'free_initrd_mem':
>
Building linux-next today (tag next-20130212) I get the following errors when
building arch/ia64/configs/{tiger_defconfig, zx1_defconfig, bigsur_defconfig,
sim_defconfig}
arch/ia64/mm/init.c: In function 'free_initrd_mem':
arch/ia64/mm/init.c:215: error: 'max_addr' undeclared (first use in
this
Building linux-next today (tag next-20130212) I get the following errors when
building arch/ia64/configs/{tiger_defconfig, zx1_defconfig, bigsur_defconfig,
sim_defconfig}
arch/ia64/mm/init.c: In function 'free_initrd_mem':
arch/ia64/mm/init.c:215: error: 'max_addr' undeclared (first use in
this
On Tue, 12 Feb 2013 16:11:33 -0800
Tony Luck tony.l...@gmail.com wrote:
Building linux-next today (tag next-20130212) I get the following errors when
building arch/ia64/configs/{tiger_defconfig, zx1_defconfig, bigsur_defconfig,
sim_defconfig}
arch/ia64/mm/init.c: In function
On Tue, 12 Feb 2013 16:11:33 -0800
Tony Luck tony.l...@gmail.com wrote:
Building linux-next today (tag next-20130212) I get the following errors when
building arch/ia64/configs/{tiger_defconfig, zx1_defconfig, bigsur_defconfig,
sim_defconfig}
arch/ia64/mm/init.c: In function
On Tue, Feb 12, 2013 at 4:19 PM, Andrew Morton
a...@linux-foundation.org wrote:
But, umm, why am I sitting here trying to maintain an ia64 bugfix and
handling bug reports from the ia64 maintainer? Wanna swap?
That sounds like a plan. I'll look out for a new version with the
missing #include
> Sorry, this bug will be happen when use Sparse-Memory(section is valid, but
> last
> several pages are invalid). If use Flat-Memory, crash kernel will boot
> successfully.
> I think the following patch would be better.
>
> Hi Andrew, will you just ignore the earlier patch and consider the
Sorry, this bug will be happen when use Sparse-Memory(section is valid, but
last
several pages are invalid). If use Flat-Memory, crash kernel will boot
successfully.
I think the following patch would be better.
Hi Andrew, will you just ignore the earlier patch and consider the following
22 matches
Mail list logo
