On Mon, 3 Jun 2013 11:59:40 -0400
Vivek Goyal wrote:
> On Mon, Jun 03, 2013 at 03:27:18PM +0200, Michael Holzheu wrote:
>
> [..]
> > > If not, how would remap_pfn_range() work with HSA region when
> > > /proc/vmcore is mmaped()?
> >
> > I am no memory management expert, so I discussed that
On Mon, Jun 03, 2013 at 03:27:18PM +0200, Michael Holzheu wrote:
[..]
> > If not, how would remap_pfn_range() work with HSA region when
> > /proc/vmcore is mmaped()?
>
> I am no memory management expert, so I discussed that with Martin
> Schwidefsky (s390 architecture maintainer). Perhaps
On Fri, 31 May 2013 12:01:58 -0400
Vivek Goyal wrote:
> On Fri, May 31, 2013 at 04:21:27PM +0200, Michael Holzheu wrote:
> > On Thu, 30 May 2013 16:38:47 -0400
> > Vivek Goyal wrote:
> >
> > > On Wed, May 29, 2013 at 01:51:44PM +0200, Michael Holzheu wrote:
> > >
[...]
> > For zfcpdump
On Fri, 31 May 2013 12:01:58 -0400
Vivek Goyal vgo...@redhat.com wrote:
On Fri, May 31, 2013 at 04:21:27PM +0200, Michael Holzheu wrote:
On Thu, 30 May 2013 16:38:47 -0400
Vivek Goyal vgo...@redhat.com wrote:
On Wed, May 29, 2013 at 01:51:44PM +0200, Michael Holzheu wrote:
[...]
On Mon, Jun 03, 2013 at 03:27:18PM +0200, Michael Holzheu wrote:
[..]
If not, how would remap_pfn_range() work with HSA region when
/proc/vmcore is mmaped()?
I am no memory management expert, so I discussed that with Martin
Schwidefsky (s390 architecture maintainer). Perhaps something
On Mon, 3 Jun 2013 11:59:40 -0400
Vivek Goyal vgo...@redhat.com wrote:
On Mon, Jun 03, 2013 at 03:27:18PM +0200, Michael Holzheu wrote:
[..]
If not, how would remap_pfn_range() work with HSA region when
/proc/vmcore is mmaped()?
I am no memory management expert, so I discussed that
On Fri, May 31, 2013 at 04:21:27PM +0200, Michael Holzheu wrote:
> On Thu, 30 May 2013 16:38:47 -0400
> Vivek Goyal wrote:
>
> > On Wed, May 29, 2013 at 01:51:44PM +0200, Michael Holzheu wrote:
> >
> > [..]
> > > >>> START QUOTE
> > >
> > > [PATCH v3 1/3] kdump: Introduce ELF header in new
On Thu, 30 May 2013 16:38:47 -0400
Vivek Goyal wrote:
> On Wed, May 29, 2013 at 01:51:44PM +0200, Michael Holzheu wrote:
>
> [..]
> > >>> START QUOTE
> >
> > [PATCH v3 1/3] kdump: Introduce ELF header in new memory feature
> >
> > Currently for s390 we create the ELF core header in the 2nd
On Thu, 30 May 2013 16:38:47 -0400
Vivek Goyal vgo...@redhat.com wrote:
On Wed, May 29, 2013 at 01:51:44PM +0200, Michael Holzheu wrote:
[..]
START QUOTE
[PATCH v3 1/3] kdump: Introduce ELF header in new memory feature
Currently for s390 we create the ELF core header in the 2nd
On Fri, May 31, 2013 at 04:21:27PM +0200, Michael Holzheu wrote:
On Thu, 30 May 2013 16:38:47 -0400
Vivek Goyal vgo...@redhat.com wrote:
On Wed, May 29, 2013 at 01:51:44PM +0200, Michael Holzheu wrote:
[..]
START QUOTE
[PATCH v3 1/3] kdump: Introduce ELF header in new memory
On Wed, May 29, 2013 at 01:51:44PM +0200, Michael Holzheu wrote:
[..]
> >>> START QUOTE
>
> [PATCH v3 1/3] kdump: Introduce ELF header in new memory feature
>
> Currently for s390 we create the ELF core header in the 2nd kernel with
> a small trick. We relocate the addresses in the ELF header
On Wed, May 29, 2013 at 07:12:49PM +0200, Michael Holzheu wrote:
[..]
> > > > So are you saying that s390 is ready to switch to mechanism of
> > > > creating ELF headers in first kernel by kexec-tools and new kernel
> > > > does not have to preare ELF headers?
> > >
> > > No, I meant that
On Wed, May 29, 2013 at 07:12:49PM +0200, Michael Holzheu wrote:
[..]
So are you saying that s390 is ready to switch to mechanism of
creating ELF headers in first kernel by kexec-tools and new kernel
does not have to preare ELF headers?
No, I meant that currently nobody is
On Wed, May 29, 2013 at 01:51:44PM +0200, Michael Holzheu wrote:
[..]
START QUOTE
[PATCH v3 1/3] kdump: Introduce ELF header in new memory feature
Currently for s390 we create the ELF core header in the 2nd kernel with
a small trick. We relocate the addresses in the ELF header in a way
On Wed, 29 May 2013 12:23:26 -0400
Vivek Goyal wrote:
> On Wed, May 29, 2013 at 01:51:44PM +0200, Michael Holzheu wrote:
> > On Tue, 28 May 2013 09:55:01 -0400
> > Vivek Goyal wrote:
> >
> > > On Sat, May 25, 2013 at 02:52:17PM +0200, Michael Holzheu wrote:
> >
> > [snip]
> >
> > > > Besides
On Wed, May 29, 2013 at 01:51:44PM +0200, Michael Holzheu wrote:
> On Tue, 28 May 2013 09:55:01 -0400
> Vivek Goyal wrote:
>
> > On Sat, May 25, 2013 at 02:52:17PM +0200, Michael Holzheu wrote:
>
> [snip]
>
> > > Besides of the newmem mechanism, for completeness, we also
> > > implemented the
On Tue, 28 May 2013 09:55:01 -0400
Vivek Goyal wrote:
> On Sat, May 25, 2013 at 02:52:17PM +0200, Michael Holzheu wrote:
[snip]
> > Besides of the newmem mechanism, for completeness, we also
> > implemented the oldmem ELF header mechansim in kexec. But this is
> > disabled by default.
> >
> >
On Tue, 28 May 2013 09:55:01 -0400
Vivek Goyal vgo...@redhat.com wrote:
On Sat, May 25, 2013 at 02:52:17PM +0200, Michael Holzheu wrote:
[snip]
Besides of the newmem mechanism, for completeness, we also
implemented the oldmem ELF header mechansim in kexec. But this is
disabled by
On Wed, May 29, 2013 at 01:51:44PM +0200, Michael Holzheu wrote:
On Tue, 28 May 2013 09:55:01 -0400
Vivek Goyal vgo...@redhat.com wrote:
On Sat, May 25, 2013 at 02:52:17PM +0200, Michael Holzheu wrote:
[snip]
Besides of the newmem mechanism, for completeness, we also
implemented
On Wed, 29 May 2013 12:23:26 -0400
Vivek Goyal vgo...@redhat.com wrote:
On Wed, May 29, 2013 at 01:51:44PM +0200, Michael Holzheu wrote:
On Tue, 28 May 2013 09:55:01 -0400
Vivek Goyal vgo...@redhat.com wrote:
On Sat, May 25, 2013 at 02:52:17PM +0200, Michael Holzheu wrote:
[snip]
On Sat, May 25, 2013 at 02:52:17PM +0200, Michael Holzheu wrote:
[..]
> Therefore, if necessary, IMHO we can switch to the ELF header memory
> swap mechanism for s390 in the kernel. Of course we would then also
> have to adjust the (disabled) kexec code.
I think it is a good idea to fix it in
On Sat, May 25, 2013 at 02:52:17PM +0200, Michael Holzheu wrote:
> On Sat, 25 May 2013 16:31:58 +0800
> Zhang Yanfei wrote:
>
> [snip]
>
> > For s390, if we put swap info into the elf header, This will
> > change /sbin/kexec. But at this point, copy_oldmem_page is still
> > doing the swap when
On Sat, May 25, 2013 at 02:52:17PM +0200, Michael Holzheu wrote:
On Sat, 25 May 2013 16:31:58 +0800
Zhang Yanfei zhangyanfei@gmail.com wrote:
[snip]
For s390, if we put swap info into the elf header, This will
change /sbin/kexec. But at this point, copy_oldmem_page is still
doing
On Sat, May 25, 2013 at 02:52:17PM +0200, Michael Holzheu wrote:
[..]
Therefore, if necessary, IMHO we can switch to the ELF header memory
swap mechanism for s390 in the kernel. Of course we would then also
have to adjust the (disabled) kexec code.
I think it is a good idea to fix it in s390
Zhang Yanfei writes:
> 于 2013年05月25日 11:01, Eric W. Biederman 写道:
>> Zhang Yanfei writes:
>>
>>> Hello Eric,
>>>
The function copy_oldmem_page also concerns me. I don't have a clue why
we duplicate that function on every architecutre in a slightly different
form. There should
On Fri, 24 May 2013 13:05:07 -0400
Vivek Goyal wrote:
> On Fri, May 24, 2013 at 06:46:53PM +0200, Michael Holzheu wrote:
> > On Fri, 24 May 2013 11:28:49 -0400
> > Vivek Goyal wrote:
> >
> > > On Fri, May 24, 2013 at 05:06:26PM +0200, Michael Holzheu wrote:
> >
> > [snip]
> >
> > > As
On Sat, 25 May 2013 16:31:58 +0800
Zhang Yanfei wrote:
[snip]
> For s390, if we put swap info into the elf header, This will
> change /sbin/kexec. But at this point, copy_oldmem_page is still
> doing the swap when we try to read the pages among [0 - OLDMEM_SIZE]
> and [OLDMEM_BASE - OLDMEM_BASE
于 2013年05月25日 11:01, Eric W. Biederman 写道:
> Zhang Yanfei writes:
>
>> Hello Eric,
>>
>>> The function copy_oldmem_page also concerns me. I don't have a clue why
>>> we duplicate that function on every architecutre in a slightly different
>>> form. There should be enough abstractions in the
于 2013年05月25日 11:01, Eric W. Biederman 写道:
Zhang Yanfei zhangyanfei@gmail.com writes:
Hello Eric,
The function copy_oldmem_page also concerns me. I don't have a clue why
we duplicate that function on every architecutre in a slightly different
form. There should be enough abstractions
On Sat, 25 May 2013 16:31:58 +0800
Zhang Yanfei zhangyanfei@gmail.com wrote:
[snip]
For s390, if we put swap info into the elf header, This will
change /sbin/kexec. But at this point, copy_oldmem_page is still
doing the swap when we try to read the pages among [0 - OLDMEM_SIZE]
and
On Fri, 24 May 2013 13:05:07 -0400
Vivek Goyal vgo...@redhat.com wrote:
On Fri, May 24, 2013 at 06:46:53PM +0200, Michael Holzheu wrote:
On Fri, 24 May 2013 11:28:49 -0400
Vivek Goyal vgo...@redhat.com wrote:
On Fri, May 24, 2013 at 05:06:26PM +0200, Michael Holzheu wrote:
[snip]
Zhang Yanfei zhangyanfei@gmail.com writes:
于 2013年05月25日 11:01, Eric W. Biederman 写道:
Zhang Yanfei zhangyanfei@gmail.com writes:
Hello Eric,
The function copy_oldmem_page also concerns me. I don't have a clue why
we duplicate that function on every architecutre in a slightly
Zhang Yanfei writes:
> Hello Eric,
>
>> The function copy_oldmem_page also concerns me. I don't have a clue why
>> we duplicate that function on every architecutre in a slightly different
>> form. There should be enough abstractions in the kernel to make that
>> unnecessary. I would be glad
Hello Eric,
于 2013年05月25日 06:44, Eric W. Biederman 写道:
> Vivek Goyal writes:
>
>> On Fri, May 24, 2013 at 05:06:26PM +0200, Michael Holzheu wrote:
>>> Hello Vivek,
>>>
>>> On Fri, 24 May 2013 10:36:44 -0400
>>> Vivek Goyal wrote:
>>>
>>> [snip]
>>>
Sorry, I don't understand the problem.
Vivek Goyal writes:
> On Fri, May 24, 2013 at 05:06:26PM +0200, Michael Holzheu wrote:
>> Hello Vivek,
>>
>> On Fri, 24 May 2013 10:36:44 -0400
>> Vivek Goyal wrote:
>>
>> [snip]
>>
>> > Sorry, I don't understand the problem. If we swapped low memory and
>> > crash reserved memory, that
On Fri, May 24, 2013 at 06:46:53PM +0200, Michael Holzheu wrote:
> On Fri, 24 May 2013 11:28:49 -0400
> Vivek Goyal wrote:
>
> > On Fri, May 24, 2013 at 05:06:26PM +0200, Michael Holzheu wrote:
>
> [snip]
>
> > As /proc/vmcore is the most used and useful interface, I prefer that
> > we swap
On Fri, 24 May 2013 11:28:49 -0400
Vivek Goyal wrote:
> On Fri, May 24, 2013 at 05:06:26PM +0200, Michael Holzheu wrote:
[snip]
> As /proc/vmcore is the most used and useful interface, I prefer that
> we swap memory and put that info in elf headers. For /dev/oldme, I
> don't mind if we leave
On Fri, May 24, 2013 at 05:06:26PM +0200, Michael Holzheu wrote:
> Hello Vivek,
>
> On Fri, 24 May 2013 10:36:44 -0400
> Vivek Goyal wrote:
>
> [snip]
>
> > Sorry, I don't understand the problem. If we swapped low memory and
> > crash reserved memory, that should have been taken care by
Hello Vivek,
On Fri, 24 May 2013 10:36:44 -0400
Vivek Goyal wrote:
[snip]
> Sorry, I don't understand the problem. If we swapped low memory and
> crash reserved memory, that should have been taken care by prepared
> ELF headers so that we map the right pfns. In x86 we swap 640K of low
> memory
On Fri, May 24, 2013 at 03:08:07PM +0200, Michael Holzheu wrote:
> Hello Vivek and Hatayama,
>
> Currently the /proc/vmcore mmap patches are not working on s390. The
> problem is that on s390 the kernel in not relocatable and therefore
> always runs in the lower memory area. Therefore for kdump
Hello Vivek and Hatayama,
Currently the /proc/vmcore mmap patches are not working on s390. The
problem is that on s390 the kernel in not relocatable and therefore
always runs in the lower memory area. Therefore for kdump on s390 we
swap the lower memory area with the crashkernel area before
Hello Vivek and Hatayama,
Currently the /proc/vmcore mmap patches are not working on s390. The
problem is that on s390 the kernel in not relocatable and therefore
always runs in the lower memory area. Therefore for kdump on s390 we
swap the lower memory area with the crashkernel area before
On Fri, May 24, 2013 at 03:08:07PM +0200, Michael Holzheu wrote:
Hello Vivek and Hatayama,
Currently the /proc/vmcore mmap patches are not working on s390. The
problem is that on s390 the kernel in not relocatable and therefore
always runs in the lower memory area. Therefore for kdump on
Hello Vivek,
On Fri, 24 May 2013 10:36:44 -0400
Vivek Goyal vgo...@redhat.com wrote:
[snip]
Sorry, I don't understand the problem. If we swapped low memory and
crash reserved memory, that should have been taken care by prepared
ELF headers so that we map the right pfns. In x86 we swap 640K
On Fri, May 24, 2013 at 05:06:26PM +0200, Michael Holzheu wrote:
Hello Vivek,
On Fri, 24 May 2013 10:36:44 -0400
Vivek Goyal vgo...@redhat.com wrote:
[snip]
Sorry, I don't understand the problem. If we swapped low memory and
crash reserved memory, that should have been taken care by
On Fri, 24 May 2013 11:28:49 -0400
Vivek Goyal vgo...@redhat.com wrote:
On Fri, May 24, 2013 at 05:06:26PM +0200, Michael Holzheu wrote:
[snip]
As /proc/vmcore is the most used and useful interface, I prefer that
we swap memory and put that info in elf headers. For /dev/oldme, I
don't mind
On Fri, May 24, 2013 at 06:46:53PM +0200, Michael Holzheu wrote:
On Fri, 24 May 2013 11:28:49 -0400
Vivek Goyal vgo...@redhat.com wrote:
On Fri, May 24, 2013 at 05:06:26PM +0200, Michael Holzheu wrote:
[snip]
As /proc/vmcore is the most used and useful interface, I prefer that
we
Vivek Goyal vgo...@redhat.com writes:
On Fri, May 24, 2013 at 05:06:26PM +0200, Michael Holzheu wrote:
Hello Vivek,
On Fri, 24 May 2013 10:36:44 -0400
Vivek Goyal vgo...@redhat.com wrote:
[snip]
Sorry, I don't understand the problem. If we swapped low memory and
crash reserved
Hello Eric,
于 2013年05月25日 06:44, Eric W. Biederman 写道:
Vivek Goyal vgo...@redhat.com writes:
On Fri, May 24, 2013 at 05:06:26PM +0200, Michael Holzheu wrote:
Hello Vivek,
On Fri, 24 May 2013 10:36:44 -0400
Vivek Goyal vgo...@redhat.com wrote:
[snip]
Sorry, I don't understand the
Zhang Yanfei zhangyanfei@gmail.com writes:
Hello Eric,
The function copy_oldmem_page also concerns me. I don't have a clue why
we duplicate that function on every architecutre in a slightly different
form. There should be enough abstractions in the kernel to make that
unnecessary. I
50 matches
Mail list logo
