headers
Tim Bird | 10 Nov 2009 00:08
Picon

[ANNOUNCE] ELC 2010 Call for Presentations

I apologize in advance for this non-technical post...

The CE Linux Forum would like to invite you to make a presentation
at our upcoming Embedded Linux Conference. The conference will be
held April 12-14, 2010 in San Francisco, California.

For general information about the conference, See
  http://embeddedlinuxconference.com/elc_2010/

For information about the call for presentations, see
  http://elinux.org/ELC_2010_Call_for_Presentations

CELF is the primary sponsor of this event, which is open to the
public.  Please note that the conference will be co-located with
the Linux Foundation Spring Collaboration Summit (April 14-16)
and it should be a very exciting event.

= Guidelines =
Presentations should be of a technical nature, covering topics
related to use of Linux in embedded systems. The CE Linux Forum
is focused on the use of Linux in consumer electronics products,
but presentations may cover use of Linux in other embedded
areas, as long as the topic is of general relevance to most
embedded developers.

Presentations that are commercial advertisements or sales
pitches are not appropriate for this conference.

Presentations on the following topics are encouraged:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Francesco VIRLINZI | 11 Nov 2009 08:54

Re: [Proposal] [PATCH] generic clock framework

Hi Tim
Thanks for your feedback.
ARM mail list was already involved.

Regards
  Francesco
On 11/10/2009 07:08 PM, Tim Bird wrote:
> Francesco VIRLINZI wrote:
>    
>> Hi all
>>
>> I'm Francesco and I work in STMicroelectronics
>>
>> In the last ELC-E_2009 I spoke on a generic clock framework I'm working on
>>   (see
>> http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2009Presentations?action=AttachFile&do=view&target=ELC_E_2009_Generic_Clock_Framework.pdf).
>>
>>
>> I wrote the gcf to manage both clocks the platform_devices during a
>> clock operation.
>>      
> This looks good to me, in principle, but I'm not a clock or PM
> expert.  I would recommend sending this to the linux-kernel and
> linux-pm lists as well.  I think you'll get a wider audience for
> feedback.
>   -- Tim
>
> =============================
> Tim Bird
> Architecture Group Chair, CE Linux Forum
(Continue reading)

Permalink | Reply | 0 comments |
headers
David VomLehn | 12 Nov 2009 03:13
Picon
Favicon

[PATCH, RFC] panic-note: Annotation from user space for panics

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 RFC is that I'm uncomfortable with
putting the pseudo-file that holds the annotation information in /proc.
Different layers of the software stack may drop dynamic information, such
as DHCP-supplied IP addresses, in here as they come up. This means it's
necessary to be able to append to the end of the annotation, so this looks
much more like a real file than a sysctl file.  It also has multiple lines,
which doesn't look a sysctl file. Annotation can be viewed as a debug thing,
so maybe it belongs in debugfs, but people seem to be doing somewhat different
things with that filesystem.

So, suggestions on this issue, and any others are most welcome. If there a
better way to do this, I'll be happy to use it.

Signed-off-by: David VomLehn <dvomlehn <at> cisco.com>
---
 fs/proc/Makefile       |    1 +
 fs/proc/panic-note.c   |  293 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/kernel.h |    7 +
 kernel/panic.c         |    1 +
 lib/Kconfig.debug      |    8 ++
 5 files changed, 310 insertions(+), 0 deletions(-)

diff --git a/fs/proc/Makefile b/fs/proc/Makefile
index 11a7b5c..486d273 100644
--- a/fs/proc/Makefile
(Continue reading)

Permalink | Reply | 30 comments |
headers
Paul Gortmaker | 12 Nov 2009 20:50
Favicon

Re: [PATCH, RFC] panic-note: Annotation from user space for panics

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 RFC is that I'm uncomfortable with
> putting the pseudo-file that holds the annotation information in /proc.
> Different layers of the software stack may drop dynamic information, such
> as DHCP-supplied IP addresses, in here as they come up. This means it's
> necessary to be able to append to the end of the annotation, so this looks
> much more like a real file than a sysctl file.  It also has multiple lines,
> which doesn't look a sysctl file. Annotation can be viewed as a debug thing,
> so maybe it belongs in debugfs, but people seem to be doing somewhat different
> things with that filesystem.
> 
> So, suggestions on this issue, and any others are most welcome. If there a
> better way to do this, I'll be happy to use it.
> 
> Signed-off-by: David VomLehn <dvomlehn <at> cisco.com>
> ---

> --- a/kernel/panic.c
> +++ b/kernel/panic.c
>  <at>  <at>  -70,6 +70,7  <at>  <at>  NORET_TYPE void panic(const char * fmt, ...)
>  	vsnprintf(buf, sizeof(buf), fmt, args);
>  	va_end(args);
>  	printk(KERN_EMERG "Kernel panic - not syncing: %s\n",buf);
> +	panic_note_print();
>  #ifdef CONFIG_DEBUG_BUGVERBOSE
(Continue reading)

Permalink | Reply | 2 comments |
headers
David VomLehn | 12 Nov 2009 22:56
Picon
Favicon

Re: [PATCH, RFC] panic-note: Annotation from user space for panics

(Switched from top posting)

On Thu, Nov 12, 2009 at 01:00:17PM -0500, Marco Stornelli wrote:
> David VomLehn ha scritto:
> > 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.
> > 
> 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.

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
initialize a number of things dynamically. For example, we dynamically
compute some MAC address, and most of the IP addresses are obtained with
DHCP. This are very useful to have for panic analysis.

Since there is neither flash nor disk, user space has no place to store
this information, should the kernel panic. When we come back up, we will get
different MAC and IP addresses. Storing them in memory is our only hope.

Fortunately, there is a section of RAM that the bootloader promises not
to overwrite. On a panic, we capture the messages written on the console
and store them in the protected area. If the information from the
/proc file is written as part of the panic, we will capture it, too.
(Continue reading)

Permalink | Reply | 20 comments |
headers
David VomLehn | 12 Nov 2009 22:58
Picon
Favicon

Re: [PATCH, RFC] panic-note: Annotation from user space for panics

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 base of millions of systems deployed in
> > other people's homes.
> 
> I'd like to hear a bit more use case motivation on this feature. Also,
> why do you want more than a page?

Hopefully, I have addressed the first question in my previous email. As
for the second, I doubt there is a need for more than a page. I just picked
a value to start developing with. This is still a work in progress...

> http://selenic.com : development and support for Mercurial and Linux

David VL
Permalink | Reply | 0 comments |
headers
David VomLehn | 12 Nov 2009 23:09
Picon
Favicon

Re: [PATCH, RFC] panic-note: Annotation from user space for panics

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 deployed in
>> other people's homes.
...
> Why hook into panic() directly like this, vs. using the panic
> notifier list? If you use that, and then put the data handling
> magic that you need into your own kernel module that knows how
> to interface with the reporting apps that you have, you can
> do the whole thing without having to alter existing code, I think.

I agree--a panic notifier list is probably a better approach.

David VL
Permalink | Reply | 1 comment |
headers
Artem Bityutskiy | 13 Nov 2009 12:35
Picon

Re: [PATCH, RFC] panic-note: Annotation from user space for panics

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 of millions of systems deployed in
> > other people's homes.
> 
> I'd like to hear a bit more use case motivation on this feature. Also,
> why do you want more than a page?

We also need this kind of functionality. The use case is very simple.
Every time the kernel oopeses, we save the oops information on the flash
using mtdoops module. There is even core support, which should be merged
to 2.6.33, see this patch:

http://git.infradead.org/users/dedekind/l2-mtd-2.6.git/commit/832c3d00e82f267316a2b53634631a1821eebae8

(and there was a corresponding discussion on lkml).

And what we want is to dump information about the user-space environment
at the same time to the oops. Specifically, we want to dump information
about what was the SW build number.

And we want this information to be printed at the same time, because we
cannot run any user-space at the panic time. This information is later
read from the flash and sent via the network to the central place. And
by the time it is sent, the user may have already re-flashed his device
with something else.

So I very much appreciate this patch, although I think it should use the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Artem Bityutskiy | 13 Nov 2009 12:45
Picon

Re: [PATCH, RFC] panic-note: Annotation from user space for panics

On Fri, 2009-11-13 at 09:10 +0100, Simon Kagstrom wrote:
> On Thu, 12 Nov 2009 16:56:49 -0500
> David VomLehn <dvomlehn <at> 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
> > initialize a number of things dynamically. For example, we dynamically
> > compute some MAC address, and most of the IP addresses are obtained with
> > DHCP. This are very useful to have for panic analysis.
> > 
> > Since there is neither flash nor disk, user space has no place to store
> > this information, should the kernel panic. When we come back up, we will get
> > different MAC and IP addresses. Storing them in memory is our only hope.
> > 
> > Fortunately, there is a section of RAM that the bootloader promises not
> > to overwrite. On a panic, we capture the messages written on the console
> > and store them in the protected area. If the information from the
> > /proc file is written as part of the panic, we will capture it, too.
> 
> Can't you solve this completely from userspace using phram and mtdoops
> instead? I.e., setup two phram areas
> 
> 	modprobe phram 4K <at> start-of-your-area,4K <at> start-of-your-area+4K    # Can't remember the exact syntax!
> 
> you'll then get /dev/mtdX and /dev/mtdX+1 for these two. You can then do
> 
> 	modprobe mtdoops mtddev=/dev/mtdX+1 dump_oops=0
> 
> to load mtdoops to catch the panic in the second area, and just write
(Continue reading)

Permalink | Reply | 18 comments |
headers
Artem Bityutskiy | 13 Nov 2009 15:16
Picon

Re: [PATCH, RFC] panic-note: Annotation from user space for panics

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 <dedekind1 <at> gmail.com> wrote:
> 
> > So we really need to print some user-space supplied information during
> > the panic, and then we store it on flash with mtdoops, and the later,
> > when the device has network access we send whole bunch of oopses via the
> > network.
> 
> Yes, I see that your case would have to be handled differently. A
> complication (which I believe was discussed before) is that kmsg_dump()
> is done before the panic notifiers are called.
> 
> The reason I put it there is to have it before crash_kexec(), so I
> guess we'll have to take up the discussion on what to do with it. For
> me it now seems like it would be OK to move kmsg_dump() down below the
> panic notifiers.
> 
> If you have a kdump kernel to load, then you will most likely not need
> the kmsg dumped data anyway.

Yeah, I think this is a separate issue which can be fixed separately.

--

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane