[EMAIL PROTECTED] (Eric W. Biederman) writes:
> Hirokazu Takahashi <[EMAIL PROTECTED]> writes:
> > > Most of this just results in easier management between the pieces.
> > > Which is a good thing. However at the moment I don't think it
> > > simplifies any of the core problems. I still need to
Hirokazu Takahashi <[EMAIL PROTECTED]> writes:
> Hi,
>
> > > Hi Eric,
> > >
> I see you have.
> And MIPS CPUs doesn't allow kernel pages to be remapped either.
I guess I should add to be relocatable in the general case most
likely requires running a PIC dynamic linker at kernel startup.
If
Hi,
> > Hi Eric,
> >
> > > > Hi Vivek and Eric,
> > > >
> > > > IMHO, why don't we swap not only the contents of the top 640K
> > > > but also kernel working memory for kdump kernel?
> > > >
> > > > I guess this approach has some good points.
> > > >
> > > > 1.Preallocating reserved area is
Hi,
Hi Eric,
Hi Vivek and Eric,
IMHO, why don't we swap not only the contents of the top 640K
but also kernel working memory for kdump kernel?
I guess this approach has some good points.
1.Preallocating reserved area is not mandatory at boot time.
Hirokazu Takahashi [EMAIL PROTECTED] writes:
Hi,
Hi Eric,
I see you have.
And MIPS CPUs doesn't allow kernel pages to be remapped either.
I guess I should add to be relocatable in the general case most
likely requires running a PIC dynamic linker at kernel startup.
If none of the
[EMAIL PROTECTED] (Eric W. Biederman) writes:
Hirokazu Takahashi [EMAIL PROTECTED] writes:
Most of this just results in easier management between the pieces.
Which is a good thing. However at the moment I don't think it
simplifies any of the core problems. I still need to reserve
a
Hi,
On Fri, 04 Feb 2005 08:18:56 +0900
Itsuro Oda <[EMAIL PROTECTED]> wrote:
>
> > > 5) dump kernel: export all valid physical memory (and saved register
> > >information) to the user. (as /dev/oldmem /proc/vmcore ?)
> >
> > Or in user space, by just mmaping /dev/mem. That is part of the
>
Itsuro Oda <[EMAIL PROTECTED]> writes:
> Hi,
>
> On 02 Feb 2005 07:45:11 -0700
> [EMAIL PROTECTED] (Eric W. Biederman) wrote:
>
> >
> > And the feedback begins :)
> >
> > Itsuro Oda <[EMAIL PROTECTED]> writes:
> >
> > > Hi,
> > >
> > > I don't like calling crash_kexec() directly in (ex.)
Itsuro Oda <[EMAIL PROTECTED]> writes:
> Hi,
>
> On 03 Feb 2005 02:00:51 -0700
> [EMAIL PROTECTED] (Eric W. Biederman) wrote:
>
> > > 5) dump kernel: export all valid physical memory (and saved register
> > >information) to the user. (as /dev/oldmem /proc/vmcore ?)
> >
> > Or in user
Hi,
On 02 Feb 2005 07:45:11 -0700
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
>
> And the feedback begins :)
>
> Itsuro Oda <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > I don't like calling crash_kexec() directly in (ex.) panic().
> > It should be call_dump_hook() (or something like this).
Hi,
On 03 Feb 2005 02:00:51 -0700
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
> A better description is probably make a list of memory regions
> using an ELF header data structure in user space.
> Use sys_kexec_load to put that list the dump kernel and a little
> big of glue code in the
On Wed, 2005-02-02 at 21:12, Eric W. Biederman wrote:
> Vivek Goyal <[EMAIL PROTECTED]> writes:
>
> > On Tue, 2005-02-01 at 20:56, Eric W. Biederman wrote:
> > > Vivek Goyal <[EMAIL PROTECTED]> writes:
> >
> > "elfcorehdr=" also looks good.
>
> Then let's go with that for now. It is not
Hirokazu Takahashi <[EMAIL PROTECTED]> writes:
> Hi Eric,
>
> > > Hi Vivek and Eric,
> > >
> > > IMHO, why don't we swap not only the contents of the top 640K
> > > but also kernel working memory for kdump kernel?
> > >
> > > I guess this approach has some good points.
> > >
> > >
Hi Eric,
> > Hi Vivek and Eric,
> >
> > IMHO, why don't we swap not only the contents of the top 640K
> > but also kernel working memory for kdump kernel?
> >
> > I guess this approach has some good points.
> >
> > 1.Preallocating reserved area is not mandatory at boot time.
> >And the
Hirokazu Takahashi <[EMAIL PROTECTED]> writes:
> Hi Vivek,
>
> > > Hi Vivek and Eric,
> > >
> > > IMHO, why don't we swap not only the contents of the top 640K
> > > but also kernel working memory for kdump kernel?
> >
> >
> > Initial patches of kdump had adopted the same approach but given
Hi Vivek,
> > Hi Vivek and Eric,
> >
> > IMHO, why don't we swap not only the contents of the top 640K
> > but also kernel working memory for kdump kernel?
>
>
> Initial patches of kdump had adopted the same approach but given the
> fact devices are not stopped during transition to new kernel
Hirokazu Takahashi <[EMAIL PROTECTED]> writes:
> Hi Vivek and Eric,
>
> IMHO, why don't we swap not only the contents of the top 640K
> but also kernel working memory for kdump kernel?
>
> I guess this approach has some good points.
>
> 1.Preallocating reserved area is not mandatory at boot
Itsuro Oda <[EMAIL PROTECTED]> writes:
> Hi,
>
> On 02 Feb 2005 08:24:03 -0700
> [EMAIL PROTECTED] (Eric W. Biederman) wrote:
> >
> > So the kernel+initrd that captures a crash dump will live and execute
> > in a reserved area of memory. It needs to know which memory regions
> > are valid, and
Hi,
On Thu, 2005-02-03 at 12:32, Hirokazu Takahashi wrote:
> Hi Vivek and Eric,
>
> IMHO, why don't we swap not only the contents of the top 640K
> but also kernel working memory for kdump kernel?
Initial patches of kdump had adopted the same approach but given the
fact devices are not stopped
Hi,
On Thu, 2005-02-03 at 12:32, Hirokazu Takahashi wrote:
Hi Vivek and Eric,
IMHO, why don't we swap not only the contents of the top 640K
but also kernel working memory for kdump kernel?
Initial patches of kdump had adopted the same approach but given the
fact devices are not stopped
Itsuro Oda [EMAIL PROTECTED] writes:
Hi,
On 02 Feb 2005 08:24:03 -0700
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
So the kernel+initrd that captures a crash dump will live and execute
in a reserved area of memory. It needs to know which memory regions
are valid, and it needs to
Hirokazu Takahashi [EMAIL PROTECTED] writes:
Hi Vivek and Eric,
IMHO, why don't we swap not only the contents of the top 640K
but also kernel working memory for kdump kernel?
I guess this approach has some good points.
1.Preallocating reserved area is not mandatory at boot time.
Hi Vivek,
Hi Vivek and Eric,
IMHO, why don't we swap not only the contents of the top 640K
but also kernel working memory for kdump kernel?
Initial patches of kdump had adopted the same approach but given the
fact devices are not stopped during transition to new kernel after a
Hirokazu Takahashi [EMAIL PROTECTED] writes:
Hi Vivek,
Hi Vivek and Eric,
IMHO, why don't we swap not only the contents of the top 640K
but also kernel working memory for kdump kernel?
Initial patches of kdump had adopted the same approach but given the
fact devices are
Hi Eric,
Hi Vivek and Eric,
IMHO, why don't we swap not only the contents of the top 640K
but also kernel working memory for kdump kernel?
I guess this approach has some good points.
1.Preallocating reserved area is not mandatory at boot time.
And the reserved area can be
Hirokazu Takahashi [EMAIL PROTECTED] writes:
Hi Eric,
Hi Vivek and Eric,
IMHO, why don't we swap not only the contents of the top 640K
but also kernel working memory for kdump kernel?
I guess this approach has some good points.
1.Preallocating reserved area is not
On Wed, 2005-02-02 at 21:12, Eric W. Biederman wrote:
Vivek Goyal [EMAIL PROTECTED] writes:
On Tue, 2005-02-01 at 20:56, Eric W. Biederman wrote:
Vivek Goyal [EMAIL PROTECTED] writes:
elfcorehdr= also looks good.
Then let's go with that for now. It is not perfect but it seems
a
Hi,
On 03 Feb 2005 02:00:51 -0700
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
A better description is probably make a list of memory regions
using an ELF header data structure in user space.
Use sys_kexec_load to put that list the dump kernel and a little
big of glue code in the reserved
Hi,
On 02 Feb 2005 07:45:11 -0700
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
And the feedback begins :)
Itsuro Oda [EMAIL PROTECTED] writes:
Hi,
I don't like calling crash_kexec() directly in (ex.) panic().
It should be call_dump_hook() (or something like this).
I think
Itsuro Oda [EMAIL PROTECTED] writes:
Hi,
On 03 Feb 2005 02:00:51 -0700
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
5) dump kernel: export all valid physical memory (and saved register
information) to the user. (as /dev/oldmem /proc/vmcore ?)
Or in user space, by just mmaping
Itsuro Oda [EMAIL PROTECTED] writes:
Hi,
On 02 Feb 2005 07:45:11 -0700
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
And the feedback begins :)
Itsuro Oda [EMAIL PROTECTED] writes:
Hi,
I don't like calling crash_kexec() directly in (ex.) panic().
It should be
Hi,
On Fri, 04 Feb 2005 08:18:56 +0900
Itsuro Oda [EMAIL PROTECTED] wrote:
5) dump kernel: export all valid physical memory (and saved register
information) to the user. (as /dev/oldmem /proc/vmcore ?)
Or in user space, by just mmaping /dev/mem. That is part of the
current
Hi,
On 02 Feb 2005 08:24:03 -0700
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
>
> So the kernel+initrd that captures a crash dump will live and execute
> in a reserved area of memory. It needs to know which memory regions
> are valid, and it needs to know small things like the final register
>
Hi Vivek and Eric,
IMHO, why don't we swap not only the contents of the top 640K
but also kernel working memory for kdump kernel?
I guess this approach has some good points.
1.Preallocating reserved area is not mandatory at boot time.
And the reserved area can be distributed in small pieces
Vivek Goyal <[EMAIL PROTECTED]> writes:
> On Tue, 2005-02-01 at 20:56, Eric W. Biederman wrote:
> > Vivek Goyal <[EMAIL PROTECTED]> writes:
>
> "elfcorehdr=" also looks good.
Then let's go with that for now. It is not perfect but it seems
a little more self explanatory at first glance.
> > A
Koichi Suzuki <[EMAIL PROTECTED]> writes:
> Itsuro Oda wrote:
> > Hi,
> > I can't understand why ELF format is necessary.
> > I think the only necessary information is "what physical address regions are
> > valid to read". This information is necessary for any
> > sort of dump tools. (and must
And the feedback begins :)
Itsuro Oda <[EMAIL PROTECTED]> writes:
> Hi,
>
> I don't like calling crash_kexec() directly in (ex.) panic().
> It should be call_dump_hook() (or something like this).
>
> I think the necessary modifications of the kernel is only:
> - insert the hooks that calls a
Koichi Suzuki <[EMAIL PROTECTED]> writes:
> I meant with kexec and dump hook, there could be many more things can be done
> in
> addition to full core dump. Initiating failover to other node will be one
> example. Starting with this hook, there must be many good ideas. So my
> idea
> is to
Itsuro Oda <[EMAIL PROTECTED]> writes:
> Hi,
>
> I can't understand why ELF format is necessary.
ELF format is not. However essentially the information an ELF
provides is. So using an ELF header to convey that information
is a sane choice of data structure.
> I think the only necessary
On Tue, 2005-02-01 at 20:56, Eric W. Biederman wrote:
> Vivek Goyal <[EMAIL PROTECTED]> writes:
>
> > Well, trying to put the already discussed ideas together. I was
> > planning to work on following design. Please comment.
> >
> > Crashed Kernel <-->Capture Kernel(or User Space) Interface:
> >
On Tue, 2005-02-01 at 20:56, Eric W. Biederman wrote:
Vivek Goyal [EMAIL PROTECTED] writes:
Well, trying to put the already discussed ideas together. I was
planning to work on following design. Please comment.
Crashed Kernel --Capture Kernel(or User Space) Interface:
Itsuro Oda [EMAIL PROTECTED] writes:
Hi,
I can't understand why ELF format is necessary.
ELF format is not. However essentially the information an ELF
provides is. So using an ELF header to convey that information
is a sane choice of data structure.
I think the only necessary
Koichi Suzuki [EMAIL PROTECTED] writes:
I meant with kexec and dump hook, there could be many more things can be done
in
addition to full core dump. Initiating failover to other node will be one
example. Starting with this hook, there must be many good ideas. So my
idea
is to make
And the feedback begins :)
Itsuro Oda [EMAIL PROTECTED] writes:
Hi,
I don't like calling crash_kexec() directly in (ex.) panic().
It should be call_dump_hook() (or something like this).
I think the necessary modifications of the kernel is only:
- insert the hooks that calls a dump
Koichi Suzuki [EMAIL PROTECTED] writes:
Itsuro Oda wrote:
Hi,
I can't understand why ELF format is necessary.
I think the only necessary information is what physical address regions are
valid to read. This information is necessary for any
sort of dump tools. (and must get it while the
Vivek Goyal [EMAIL PROTECTED] writes:
On Tue, 2005-02-01 at 20:56, Eric W. Biederman wrote:
Vivek Goyal [EMAIL PROTECTED] writes:
elfcorehdr= also looks good.
Then let's go with that for now. It is not perfect but it seems
a little more self explanatory at first glance.
A clarification
Hi Vivek and Eric,
IMHO, why don't we swap not only the contents of the top 640K
but also kernel working memory for kdump kernel?
I guess this approach has some good points.
1.Preallocating reserved area is not mandatory at boot time.
And the reserved area can be distributed in small pieces
Hi,
On 02 Feb 2005 08:24:03 -0700
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
So the kernel+initrd that captures a crash dump will live and execute
in a reserved area of memory. It needs to know which memory regions
are valid, and it needs to know small things like the final register
Itsuro Oda wrote:
Hi,
I can't understand why ELF format is necessary.
I think the only necessary information is "what physical address
regions are valid to read". This information is necessary for any
sort of dump tools. (and must get it while the system is normal.)
The Eric's /proc/cpumem idea
Hi,
I don't like calling crash_kexec() directly in (ex.) panic().
It should be call_dump_hook() (or something like this).
I think the necessary modifications of the kernel is only:
- insert the hooks that calls a dump function when crash occur
- binding interface that binds a dump function to
[EMAIL PROTECTED] wrote:
Koichi Suzuki <[EMAIL PROTECTED]> writes:
Hook in panic code is very good idea and is useful in various scenes. It could
be used to kick RAM dump code, obviously, and also kick the code to initiate
failover, etc. Various use could be possible so I believe that this hook
Hi,
I can't understand why ELF format is necessary.
I think the only necessary information is "what physical address
regions are valid to read". This information is necessary for any
sort of dump tools. (and must get it while the system is normal.)
The Eric's /proc/cpumem idea sounds nice to
Vivek Goyal <[EMAIL PROTECTED]> writes:
> Well, trying to put the already discussed ideas together. I was
> planning to work on following design. Please comment.
>
> Crashed Kernel <-->Capture Kernel(or User Space) Interface:
> --
>
> The
Well, trying to put the already discussed ideas together. I was
planning to work on following design. Please comment.
Crashed Kernel <-->Capture Kernel(or User Space) Interface:
--
The whole idea is that Crash image is represented in ELF
Koichi Suzuki <[EMAIL PROTECTED]> writes:
> Hook in panic code is very good idea and is useful in various scenes. It could
> be used to kick RAM dump code, obviously, and also kick the code to initiate
> failover, etc. Various use could be possible so I believe that this hook
> should be
Hook in panic code is very good idea and is useful in various scenes.
It could be used to kick RAM dump code, obviously, and also kick the
code to initiate failover, etc. Various use could be possible so I
believe that this hook should be prepared for wider use.
--
Koichi Suzuki
NTT DATA
Hook in panic code is very good idea and is useful in various scenes.
It could be used to kick RAM dump code, obviously, and also kick the
code to initiate failover, etc. Various use could be possible so I
believe that this hook should be prepared for wider use.
--
Koichi Suzuki
NTT DATA
Koichi Suzuki [EMAIL PROTECTED] writes:
Hook in panic code is very good idea and is useful in various scenes. It could
be used to kick RAM dump code, obviously, and also kick the code to initiate
failover, etc. Various use could be possible so I believe that this hook
should be prepared for
Well, trying to put the already discussed ideas together. I was
planning to work on following design. Please comment.
Crashed Kernel --Capture Kernel(or User Space) Interface:
--
The whole idea is that Crash image is represented in ELF
Vivek Goyal [EMAIL PROTECTED] writes:
Well, trying to put the already discussed ideas together. I was
planning to work on following design. Please comment.
Crashed Kernel --Capture Kernel(or User Space) Interface:
--
The whole idea
Hi,
I can't understand why ELF format is necessary.
I think the only necessary information is what physical address
regions are valid to read. This information is necessary for any
sort of dump tools. (and must get it while the system is normal.)
The Eric's /proc/cpumem idea sounds nice to me.
[EMAIL PROTECTED] wrote:
Koichi Suzuki [EMAIL PROTECTED] writes:
Hook in panic code is very good idea and is useful in various scenes. It could
be used to kick RAM dump code, obviously, and also kick the code to initiate
failover, etc. Various use could be possible so I believe that this hook
Hi,
I don't like calling crash_kexec() directly in (ex.) panic().
It should be call_dump_hook() (or something like this).
I think the necessary modifications of the kernel is only:
- insert the hooks that calls a dump function when crash occur
- binding interface that binds a dump function to
Itsuro Oda wrote:
Hi,
I can't understand why ELF format is necessary.
I think the only necessary information is what physical address
regions are valid to read. This information is necessary for any
sort of dump tools. (and must get it while the system is normal.)
The Eric's /proc/cpumem idea
Vivek Goyal <[EMAIL PROTECTED]> writes:
> Hi Eric,
>
>
> However for the primary kernel it has no need to know that we
> > even have a backup region, nor does it need to know about the
> > size of the backup region. That can all be handled with the single
> > reservation, we have now.
> >
>
Hi Eric,
However for the primary kernel it has no need to know that we
> even have a backup region, nor does it need to know about the
> size of the backup region. That can all be handled with the single
> reservation, we have now.
>
> /sbin/kexec which makes the backup needs to know about
Hi Eric,
However for the primary kernel it has no need to know that we
even have a backup region, nor does it need to know about the
size of the backup region. That can all be handled with the single
reservation, we have now.
/sbin/kexec which makes the backup needs to know about it and
Vivek Goyal [EMAIL PROTECTED] writes:
Hi Eric,
However for the primary kernel it has no need to know that we
even have a backup region, nor does it need to know about the
size of the backup region. That can all be handled with the single
reservation, we have now.
/sbin/kexec
For the guys on ppc, and other architectures that have all of their
cpu memory behind an iommu. I propose we create a /proc/cpumem
which is the subset of /proc/iomem that deals with RAM. In any event
as something like that is straight forward to implement I will
assume the existence of the
Hi Eric,
It looks like we are looking at things a little differently. I
see a portion of the picture in your mind, but obviously not
entirely.
Perhaps, we need to step back and iron out in specific terms what
the interface between the two kernels should be in the crash dump
case, and the
Hi Eric,
It looks like we are looking at things a little differently. I
see a portion of the picture in your mind, but obviously not
entirely.
Perhaps, we need to step back and iron out in specific terms what
the interface between the two kernels should be in the crash dump
case, and the
Right now I am very frustrated with reviewing any of the crashdump
patches. When I make comments usually things change just enough that
what I said is addressed but things are addressed very much at
a surface level. Which means that if I think any kind of substantial
change is needed the only
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
>
> There is evil intermingling and false dependency sharing between
> the dying kernel and the crash capture kernel in this patch,
yikes! I'll drop it from -mm while we have a rethink.
-
To unsubscribe from this list: send the line "unsubscribe
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
There is evil intermingling and false dependency sharing between
the dying kernel and the crash capture kernel in this patch,
yikes! I'll drop it from -mm while we have a rethink.
-
To unsubscribe from this list: send the line unsubscribe
Right now I am very frustrated with reviewing any of the crashdump
patches. When I make comments usually things change just enough that
what I said is addressed but things are addressed very much at
a surface level. Which means that if I think any kind of substantial
change is needed the only
On Fri, 2005-01-21 at 16:43, Eric W. Biederman wrote:
> On deeper review your patch as it stands is incomplete. In particular
> you don't provide a way to either hardcode or dynamically set
> the area you are attempt to reserve to hold the backup region.
Well. Here is the new patch. This one
On Fri, 2005-01-21 at 16:43, Eric W. Biederman wrote:
On deeper review your patch as it stands is incomplete. In particular
you don't provide a way to either hardcode or dynamically set
the area you are attempt to reserve to hold the backup region.
Well. Here is the new patch. This one steals
On deeper review your patch as it stands is incomplete. In particular
you don't provide a way to either hardcode or dynamically set
the area you are attempt to reserve to hold the backup region.
Vivek Goyal <[EMAIL PROTECTED]> writes:
> On Fri, 2005-01-21 at 13:24, Eric W. Biederman wrote:
> >
On Fri, 2005-01-21 at 13:24, Eric W. Biederman wrote:
> Vivek Goyal <[EMAIL PROTECTED]> writes:
>
> > Hi Andrew,
> >
> > Following patch is against 2.6.11-rc1-mm2.
> >
> > As mentioned by following note from Eric, crashdump code is currently
> > broken.
> > >
> > > The crashdump code is
Vivek Goyal <[EMAIL PROTECTED]> writes:
> Hi Andrew,
>
> Following patch is against 2.6.11-rc1-mm2.
>
> As mentioned by following note from Eric, crashdump code is currently
> broken.
> >
> > The crashdump code is currently slightly broken. I have attempted to
> > minimize the breakage so
Vivek Goyal [EMAIL PROTECTED] writes:
Hi Andrew,
Following patch is against 2.6.11-rc1-mm2.
As mentioned by following note from Eric, crashdump code is currently
broken.
The crashdump code is currently slightly broken. I have attempted to
minimize the breakage so things can quick
On Fri, 2005-01-21 at 13:24, Eric W. Biederman wrote:
Vivek Goyal [EMAIL PROTECTED] writes:
Hi Andrew,
Following patch is against 2.6.11-rc1-mm2.
As mentioned by following note from Eric, crashdump code is currently
broken.
The crashdump code is currently slightly broken.
On deeper review your patch as it stands is incomplete. In particular
you don't provide a way to either hardcode or dynamically set
the area you are attempt to reserve to hold the backup region.
Vivek Goyal [EMAIL PROTECTED] writes:
On Fri, 2005-01-21 at 13:24, Eric W. Biederman wrote:
Why
83 matches
Mail list logo
