On Wed, Nov 18, 2009 at 8:53 AM, David VomLehn dvoml...@cisco.com wrote:
On Tue, Nov 17, 2009 at 04:28:22PM -0800, Eric W. Biederman wrote:
David VomLehn dvoml...@cisco.com writes:
On Tue, Nov 17, 2009 at 10:45:43AM -0500, Eric W. Biederman wrote:
...
Why not use the kdump hook? If you
Eric W. Biederman wrote:
Matt Mackall m...@selenic.com writes:
As much as I like kexec, it loses on memory footprint by about 100x.
It's not appropriate for all use cases, especially things like
consumer-grade wireless access points and phones.
In general I agree. The cost of a second
Tim Bird tim.b...@am.sony.com writes:
Eric W. Biederman wrote:
Matt Mackall m...@selenic.com writes:
As much as I like kexec, it loses on memory footprint by about 100x.
It's not appropriate for all use cases, especially things like
consumer-grade wireless access points and phones.
In
On Tue, 2009-11-17 at 13:45 +0100, Marco Stornelli wrote:
2009/11/17 Artem Bityutskiy dedeki...@gmail.com:
Take a look at my mails where I describe different complications we have
in our system. We really want to have an OOPS/panic + our environment
stuff to go together, at once. This makes
Artem Bityutskiy dedeki...@gmail.com writes:
On Tue, 2009-11-17 at 13:45 +0100, Marco Stornelli wrote:
2009/11/17 Artem Bityutskiy dedeki...@gmail.com:
Take a look at my mails where I describe different complications we have
in our system. We really want to have an OOPS/panic + our
Artem Bityutskiy wrote:
On Tue, 2009-11-17 at 13:45 +0100, Marco Stornelli wrote:
2009/11/17 Artem Bityutskiy dedeki...@gmail.com:
We need to store this information of NAND flash. Implementing logs on
NAND flash is about handling bad blocks, choosing format of records, and
may be even
On Tue, Nov 17, 2009 at 10:45:43AM -0500, Eric W. Biederman wrote:
...
Why not use the kdump hook? If you handle a kernel panic that way
you get enhanced reliability and full user space support. All in a hook
that is already present and already works.
I'm a big fan of avoiding reinvention of
David VomLehn dvoml...@cisco.com writes:
On Tue, Nov 17, 2009 at 10:45:43AM -0500, Eric W. Biederman wrote:
...
Why not use the kdump hook? If you handle a kernel panic that way
you get enhanced reliability and full user space support. All in a hook
that is already present and already
On Tue, Nov 17, 2009 at 04:28:22PM -0800, Eric W. Biederman wrote:
David VomLehn dvoml...@cisco.com writes:
On Tue, Nov 17, 2009 at 10:45:43AM -0500, Eric W. Biederman wrote:
...
Why not use the kdump hook? If you handle a kernel panic that way
you get enhanced reliability and full
On Tue, 2009-11-17 at 16:28 -0800, Eric W. Biederman wrote:
David VomLehn dvoml...@cisco.com writes:
On Tue, Nov 17, 2009 at 10:45:43AM -0500, Eric W. Biederman wrote:
...
Why not use the kdump hook? If you handle a kernel panic that way
you get enhanced reliability and full user space
I think in general the procedure should be: at startup or event (for
example acquired IP address from DHCP) user applications write in flash
(better in persistent ram) a log with a tag or a timestamp or something
like this, when there is a kernel panic, it is captured in a file stored
together the
On Thu, 12 Nov 2009 16:56:49 -0500
David VomLehn dvoml...@cisco.com wrote:
Good question. Some more detail on our application might help. In some
situations, we may have no disk and only enough flash for the bootloader.
The kernel is downloaded over the network. When we get to user space, we
On Thu, 2009-11-12 at 12:06 -0600, Matt Mackall wrote:
On Wed, 2009-11-11 at 21:13 -0500, David VomLehn wrote:
Allows annotation of panics to include platform information. It's no big
deal to collect information, but way helpful when you are collecting
failure reports from a eventual base
On Thu, 2009-11-12 at 23:09 +0100, ext David VomLehn wrote:
On Thu, Nov 12, 2009 at 02:50:41PM -0500, Paul Gortmaker wrote:
David VomLehn wrote:
Allows annotation of panics to include platform information. It's no big
deal to collect information, but way helpful when you are collecting
On Fri, 2009-11-13 at 12:59 +0100, Simon Kagstrom wrote:
(Also fix David Woodhouses address and add Atal)
On Fri, 13 Nov 2009 13:45:48 +0200
Artem Bityutskiy dedeki...@gmail.com wrote:
So we really need to print some user-space supplied information during
the panic, and then we store it
Sincerely, I don't understand why we should involve the kernel to gather
this kind of information when we can use other (user-space) tools, only
to have all in a single report maybe? I think it's a bit weak reason
to include this additional behavior in the kernel.
David VomLehn ha scritto:
On Wed, 2009-11-11 at 21:13 -0500, David VomLehn wrote:
Allows annotation of panics to include platform information. It's no big
deal to collect information, but way helpful when you are collecting
failure reports from a eventual base of millions of systems deployed in
other people's homes.
David VomLehn wrote:
Allows annotation of panics to include platform information. It's no big
deal to collect information, but way helpful when you are collecting
failure reports from a eventual base of millions of systems deployed in
other people's homes.
One of the biggest reasons this is an
On Thu, Nov 12, 2009 at 01:06:51PM -0500, Matt Mackall wrote:
On Wed, 2009-11-11 at 21:13 -0500, David VomLehn wrote:
Allows annotation of panics to include platform information. It's no big
deal to collect information, but way helpful when you are collecting
failure reports from a eventual
On Thu, Nov 12, 2009 at 02:50:41PM -0500, Paul Gortmaker wrote:
David VomLehn wrote:
Allows annotation of panics to include platform information. It's no big
deal to collect information, but way helpful when you are collecting
failure reports from a eventual base of millions of systems
20 matches
Mail list logo
