On 05/03/16 at 11:12am, Russell King - ARM Linux wrote:
> On Tue, May 03, 2016 at 12:24:41PM +0800, Baoquan He wrote:
> > Could you please help tell why arm PAE kernel can be put above 4G?
> > Since the change is related to common code, I am curious about how
> > it's so different with other ARCHs.
On Tue, May 03, 2016 at 12:24:41PM +0800, Baoquan He wrote:
> Could you please help tell why arm PAE kernel can be put above 4G?
> Since the change is related to common code, I am curious about how
> it's so different with other ARCHs.
This is explained in the covering email to the series.
The ex
On 05/03/16 at 11:23am, Pratyush Anand wrote:
> Hi Baoquan,
>
> On 03/05/2016:12:24:41 PM, Baoquan He wrote:
> > Hi Pratyush,
> >
> > Could you please help tell why arm PAE kernel can be put above 4G?
>
> PAE system can have physical addresses above 4G. So, if a CPU is supporting
> the
> LPAE p
Hi Baoquan,
On 03/05/2016:12:24:41 PM, Baoquan He wrote:
> Hi Pratyush,
>
> Could you please help tell why arm PAE kernel can be put above 4G?
PAE system can have physical addresses above 4G. So, if a CPU is supporting the
LPAE page table format then we should be able to access physical addresse
This patch is clearly related to kdump. The prefix of subject should be
changed to kdump. Kexec doesn't need to handle vmcore things.
And patches realted to kexec/kdump should be CCed to Andrew, he usually
picks up and add them into akpm tree.
Hi Pratyush,
Could you please help tell why arm PAE
On Fri, Apr 29, 2016 at 11:36 PM, Russell King - ARM Linux
wrote:
> On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
>> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> wrote:
>> > diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
>> > index 152da4a48867..9f1920d2d0c6 100644
>> > ---
On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> wrote:
> > diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
> > index 152da4a48867..9f1920d2d0c6 100644
> > --- a/kernel/ksysfs.c
> > +++ b/kernel/ksysfs.c
> > @@ -128,8 +128,8 @@ KERNEL
On Fri, Apr 29, 2016 at 8:46 PM, Mark Rutland wrote:
> On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
>> > + phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
>> > + return sprintf(buf, "%pa %x\n", &vmcore_base,
>>
>> Why do we pass &vmcore_base? Shouldn't it be vmcor
On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
> > + phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> > + return sprintf(buf, "%pa %x\n", &vmcore_base,
>
> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?
The %pa* printk format specifiers take the value b
On Thu, Apr 28, 2016 at 2:58 PM, Russell King
wrote:
> On PAE systems (eg, ARM LPAE) the vmcore note may be located above
> 4GB physical on 32-bit architectures, so we need a wider type than
> "unsigned long" here. Arrange for paddr_vmcoreinfo_note() to return
> a phys_addr_t, thereby allowing it
On PAE systems (eg, ARM LPAE) the vmcore note may be located above
4GB physical on 32-bit architectures, so we need a wider type than
"unsigned long" here. Arrange for paddr_vmcoreinfo_note() to return
a phys_addr_t, thereby allowing it to be located above 4GB.
This makes no difference for kexec-
11 matches
Mail list logo
