Re: Some embedded topics

Re: Some embedded topics

[Paul Gortmaker]

On Tue, May 27, 2008 at 5:57 PM, David VomLehn <dvomlehn-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> wrote:
> Since I'm at least partially to blame for creation of this mailing list (I
> asked Andrew Morton for one at the CELF Conference), I thought I might as
> well stir things up by throwing a few features out there that I think would
> improve the Linux kernel for use in the embedded world:
>

[...]

>
> On-line Disk Partitioning
> -------------------------
> Server and desktop systems partition their disks at installation time, but
> some applications require that partitioning be done after we are already
> using a root filesystem on disk. We only have one disk and the driver
> specifically prevents changing the partitioning while a disk partition is in
> use. Note that we don't want to change the root partition, just other
> partitions. This drives the need for some sort of on-line partitioning that
> allows changing partitions that aren't in use.

Interestingly enough,  I remember when this sort of thing used to just
simply work as-is.  Meaning that if you weren't shuffling partitions that
were actively in use, then all was well.   I've no idea when it became
"broken", but there have been times when I've wanted to do just this
sort of thing, and it hasn't been specific to an embedded target.  It sounds
like a reasonable thing to have on the radar.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Some embedded topics

[Rob Landley]

On Tuesday 27 May 2008 17:31:42 T Ziomek wrote:
> If I understand correctly David is talking about logging some trace-like
> info (so it exists before a HW watchdog expires), and having it somewhere
> "safe" from being disturbed by a HW reset.

The standard way of doing this is to use the mem= kernel command line 
parameter to tell the system it has less memory than it does, and using 
what's left as a ramdisk.  Years ago I saw some userspace thing running as 
root mmap() /dev/mem (or whatever they're calling it these days) and log to 
it.  In theory you could even set the dmesg buffer up at the end of physical 
memory with a smallish kernel patch, make it big, and set the kernel to doing 
verbose printks.

The trick is A) knowing the absolute physical address at which your debug 
buffer lives so you can find it after the reboot, B) convincing the system to 
do something useful with it on reboot rather than just overwriting it with 
fresh log data.

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Some embedded topics

[Mike Frysinger]

On Wed, May 28, 2008 at 11:01 PM, Rob Landley wrote:
> On Tuesday 27 May 2008 17:31:42 T Ziomek wrote:
>> If I understand correctly David is talking about logging some trace-like
>> info (so it exists before a HW watchdog expires), and having it somewhere
>> "safe" from being disturbed by a HW reset.
>
> The standard way of doing this is to use the mem= kernel command line
> parameter to tell the system it has less memory than it does, and using
> what's left as a ramdisk.  Years ago I saw some userspace thing running as
> root mmap() /dev/mem (or whatever they're calling it these days) and log to
> it.  In theory you could even set the dmesg buffer up at the end of physical
> memory with a smallish kernel patch, make it big, and set the kernel to doing
> verbose printks.
>
> The trick is A) knowing the absolute physical address at which your debug
> buffer lives so you can find it after the reboot, B) convincing the system to
> do something useful with it on reboot rather than just overwriting it with
> fresh log data.

how about the fact that when the core resets, the memory controller is
often reset as well ?  that external memory is going to degrade.  or
do we just bite our thumb and weather the few random bit errors ?
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Some embedded topics

[Wolfgang Denk]

In message <8bd0f97a0805282121j10a99bb7ve92efc6a8dc8bbb1-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> you wrote:
>
> how about the fact that when the core resets, the memory controller is
> often reset as well ?  that external memory is going to degrade.  or
> do we just bite our thumb and weather the few random bit errors ?

It depends. In all cases we tested  so  far  we  have  never  seen  a
corrupton because the hardware and U-Boot were quick enough to get at
least refresh running again in time.

If you are really concerned, there are other options. For example  on
systems  that  have  OCM or SRAM you can put the log buffer there. We
did this in a project on 440EPx.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd-ynQEQJNshbs@public.gmane.org
To be awake is to be alive.        - Henry David Thoreau, in "Walden"
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Some embedded topics

[Rob Landley]

On Wednesday 28 May 2008 23:21:52 Mike Frysinger wrote:
> On Wed, May 28, 2008 at 11:01 PM, Rob Landley wrote:
> > On Tuesday 27 May 2008 17:31:42 T Ziomek wrote:
> >> If I understand correctly David is talking about logging some trace-like
> >> info (so it exists before a HW watchdog expires), and having it
> >> somewhere "safe" from being disturbed by a HW reset.
> >
> > The standard way of doing this is to use the mem= kernel command line
> > parameter to tell the system it has less memory than it does, and using
> > what's left as a ramdisk.  Years ago I saw some userspace thing running
> > as root mmap() /dev/mem (or whatever they're calling it these days) and
> > log to it.  In theory you could even set the dmesg buffer up at the end
> > of physical memory with a smallish kernel patch, make it big, and set the
> > kernel to doing verbose printks.
> >
> > The trick is A) knowing the absolute physical address at which your debug
> > buffer lives so you can find it after the reboot, B) convincing the
> > system to do something useful with it on reboot rather than just
> > overwriting it with fresh log data.
>
> how about the fact that when the core resets, the memory controller is
> often reset as well ?  that external memory is going to degrade.  or
> do we just bite our thumb and weather the few random bit errors ?
> -mike

Mostly it isn't a problem because DRAM lasts longer than you think it does:
  http://www.securityfocus.com/brief/686

Your memory controller init has to go out of its way to screw it up with a 
memory test or some such.  (That said, some of 'em do...)

The people who pioneered this stuff many moons ago were the big iron guys, and 
when they had that kind of problem they'd use kexec to avoid going back 
through brain-dead firmware that did stupid things to memory:
  http://lwn.net/Articles/108595

This of course assumes you have spare ram for a while second kernel to sit 
around and do nothing until you pass control to it to fetch your diagnostics.  
Most embedded systems don't.

I'd probably start reading at http://lkcd.sf.net/doc/index.html if I wanted to 
come back up to speed on this area.  The "leave a bit of memory free at the 
end with mem=" trick is the easy way to avoid having to include actual 
_infrastructure_ for this stuff.  If you have the memory budget for 
infrastructure, there are people happily to deliver forklifts full...

This doesn't come up much for me.  During development I put /dev/console on a 
serial port and log stuff to that, so I still have it after the box has gone 
south.  By the time a device running from flash winds up in the end user's 
hands, I usually don't even know who they _are_, let alone have enough of a 
relationship with them that they'd want their appliance to spontaneously send 
info to me even if it did start malfunctioning.

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

Re: Some embedded topics

[Mike Frysinger]

On Thu, May 29, 2008 at 1:31 PM, Rob Landley wrote:
> On Wednesday 28 May 2008 23:21:52 Mike Frysinger wrote:
>> On Wed, May 28, 2008 at 11:01 PM, Rob Landley wrote:
>> > On Tuesday 27 May 2008 17:31:42 T Ziomek wrote:
>> >> If I understand correctly David is talking about logging some trace-like
>> >> info (so it exists before a HW watchdog expires), and having it
>> >> somewhere "safe" from being disturbed by a HW reset.
>> >
>> > The standard way of doing this is to use the mem= kernel command line
>> > parameter to tell the system it has less memory than it does, and using
>> > what's left as a ramdisk.  Years ago I saw some userspace thing running
>> > as root mmap() /dev/mem (or whatever they're calling it these days) and
>> > log to it.  In theory you could even set the dmesg buffer up at the end
>> > of physical memory with a smallish kernel patch, make it big, and set the
>> > kernel to doing verbose printks.
>> >
>> > The trick is A) knowing the absolute physical address at which your debug
>> > buffer lives so you can find it after the reboot, B) convincing the
>> > system to do something useful with it on reboot rather than just
>> > overwriting it with fresh log data.
>>
>> how about the fact that when the core resets, the memory controller is
>> often reset as well ?  that external memory is going to degrade.  or
>> do we just bite our thumb and weather the few random bit errors ?
>> -mike
>
> Mostly it isn't a problem because DRAM lasts longer than you think it does:
>  http://www.securityfocus.com/brief/686

ive read that article before and i'm aware of real degradation times.
it also points out that "the colder the better" which certainly doesnt
line up with many realistic cases of machines sitting in hot rooms or
in closests.  working off of "well it should be fine most of the time"
isnt nearly as good as "this always works", and all it takes is 1 or 2
bits to be corrupt to significantly change the meaning of a cpu state
dump ...

but as long as things are prefaced this way and people are aware ...
it's better than nothing

> Your memory controller init has to go out of its way to screw it up with a
> memory test or some such.  (That said, some of 'em do...)

as soon as the memory controller stops refreshing, it's a problem.

> This of course assumes you have spare ram for a while second kernel to sit
> around and do nothing until you pass control to it to fetch your diagnostics.
> Most embedded systems don't.

if you communicate the kernel log buffer pointer to u-boot, then you
can just read that directly.
-mike

Re: Some embedded topics

[Wolfgang Denk]

In message <200805282201.48746.rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org> you wrote:
> 
> The standard way of doing this is to use the mem= kernel command line 
> parameter to tell the system it has less memory than it does, and using 
> what's left as a ramdisk.  Years ago I saw some userspace thing running as 
> root mmap() /dev/mem (or whatever they're calling it these days) and log to 
> it.  In theory you could even set the dmesg buffer up at the end of physical 
> memory with a smallish kernel patch, make it big, and set the kernel to doing 
> verbose printks.

That's not theory, but a standard feature in U-Boot. It's called
shared log buffer, as U-Boot can also use this buffer for example for
POST results.

> The trick is A) knowing the absolute physical address at which your debug 
> buffer lives so you can find it after the reboot, B) convincing the system to 
> do something useful with it on reboot rather than just overwriting it with 
> fresh log data.

There is no trickery involved.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd-ynQEQJNshbs@public.gmane.org
My brother sent me a postcard the other day with this  big  sattelite
photo  of the entire earth on it. On the back it said: "Wish you were
here".                                                - Steven Wright
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Some embedded topics

[Geert Uytterhoeven]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1751 bytes --]

On Wed, 28 May 2008, Rob Landley wrote:
> On Tuesday 27 May 2008 17:31:42 T Ziomek wrote:
> > If I understand correctly David is talking about logging some trace-like
> > info (so it exists before a HW watchdog expires), and having it somewhere
> > "safe" from being disturbed by a HW reset.
> 
> The standard way of doing this is to use the mem= kernel command line 
> parameter to tell the system it has less memory than it does, and using 
> what's left as a ramdisk.  Years ago I saw some userspace thing running as 
> root mmap() /dev/mem (or whatever they're calling it these days) and log to 
> it.  In theory you could even set the dmesg buffer up at the end of physical 
> memory with a smallish kernel patch, make it big, and set the kernel to doing 
> verbose printks.
> 
> The trick is A) knowing the absolute physical address at which your debug 
> buffer lives so you can find it after the reboot, B) convincing the system to 
> do something useful with it on reboot rather than just overwriting it with 
> fresh log data.

Yep, we've been doing this on Amiga for more than a decade, when `debug=mem' is
passed. Cfr. arch/m68k/tools/amiga/dmesg.c.

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · BIC GEBABEBB08A · IBAN BE39001382358619

Re: Some embedded topics

[Tim Bird]

Geert Uytterhoeven wrote:
> Yep, we've been doing this on Amiga for more than a decade, when `debug=mem' is
> passed. Cfr. arch/m68k/tools/amiga/dmesg.c.
>

Wow!  If tidbits like these are going to keep surfacing,
I feel like maybe CELF should get someone to just
permanently monitor this list and take interesting
info like the above and put it on the elinux wiki.

There's a lot of interesting stuff flowing out of
people's brains onto the list in the last few
days....  It's great!
  -- Tim

P.S. Is debug=mem something specific to Amiga?  I find
no mention of it in Documentation/kernel-parameters.txt

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

Re: Some embedded topics

[Jordan Crouse]

On 30/05/08 15:59 -0700, Tim Bird wrote:
> P.S. Is debug=mem something specific to Amiga?  I find
> no mention of it in Documentation/kernel-parameters.txt

It would be interesting to standardize this interface and
extend it to dump logs from the firmware loader / monitor as well. 
I know that coreboot for one has the ability to store logs and
communicate them to the kernel, and I think some of the more
popular embedded loaders support store logs too
(or if they don't, they should).

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.

Re: Some embedded topics

[Josh Boyer]

On Fri, 30 May 2008 15:59:04 -0700
Tim Bird <tim.bird@am.sony.com> wrote:

> Geert Uytterhoeven wrote:
> > Yep, we've been doing this on Amiga for more than a decade, when `debug=mem' is
> > passed. Cfr. arch/m68k/tools/amiga/dmesg.c.
> >
> 
> Wow!  If tidbits like these are going to keep surfacing,
> I feel like maybe CELF should get someone to just
> permanently monitor this list and take interesting
> info like the above and put it on the elinux wiki.

I think that's a great idea.  Perhaps we can discuss some further
things we can do for interaction at the Embedded Linux BOF for those
attending OLS.

josh

Re: Some embedded topics

[Geert Uytterhoeven]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1371 bytes --]

On Fri, 30 May 2008, Tim Bird wrote:
> Geert Uytterhoeven wrote:
> > Yep, we've been doing this on Amiga for more than a decade, when `debug=mem'
> > is
> > passed. Cfr. arch/m68k/tools/amiga/dmesg.c.
> 
> Wow!  If tidbits like these are going to keep surfacing,
> I feel like maybe CELF should get someone to just
> permanently monitor this list and take interesting
> info like the above and put it on the elinux wiki.
> 
> There's a lot of interesting stuff flowing out of
> people's brains onto the list in the last few
> days....  It's great!
>  -- Tim
> 
> P.S. Is debug=mem something specific to Amiga?  I find
> no mention of it in Documentation/kernel-parameters.txt

It's supported on Amiga and Q40, although Q40 is not mentioned in
Documentation/m68k/kernel-options.txt.

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/

Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · BIC GEBABEBB08A · IBAN BE39001382358619

Re: Fwd: Some embedded topics

[Joe MacDonald]

2008/5/28 Marco Stornelli <marco.stornelli-5RgZt0ZUL+KonA0d6jMUrA@public.gmane.org>:
> Joe MacDonald ha scritto:
>>
>> Resending to the whole list since the last time it looks like gmail
>> had decided I wanted to send HTML.
[...]
>> That, and pramfs seems to be largely untouched these days, but since I
>> haven't used it recently, I don't know if the lack of activity is due
>> to neglect or stability.
>>
>
> There's a MontaVista patent on PRAMFS and I think that most of times when a
> company hears this thing it skips quickly this solution. Sometimes ago I
> sent a porting to 2.6.24, but I didn't receive any response.

Really?  I had been signed up for the SF.net mailing lists for a while
now and didn't see it come through, but I might've missed it (the list
does appear to have degenerated to a spam target these days).  I was
interested in pramfs a while back.

I don't know if Steve Longerbeam is on the list here or not, but I had
been talking to him ... maybe a year and a half ago now?  Maybe more
than that.  Anyway, when I was he'd said that he simply hadn't had the
time to keep working on it lately and he didn't think there was all
that much interest in it anymore anyway (IIRC).  If you had an
interest in doing some forward ports you might try pinging him again
or starting up the discussion on the mailing list and see who else
might be doing (or waitng for someone to do) the same thing.

-- 
-Joe.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: Some embedded topics

[Tim Bird]

Marco Stornelli wrote:
> There's a MontaVista patent on PRAMFS and I think that most of times 
> when a company hears this thing it skips quickly this solution.

Hmmm.  I don't recall anything about a patent on PRAMFS.

There are lots of issues here, but I think it's OK to use.
At a minimum,  MontaVista's PRAMFS was submitted to the CE Linux Forum
in an older kernel (2.4.20-based).  MontaVista was well-aware
of this submission (although it did not come directly from them).
MV was under an IP agreement with CELF which required them to
disclose such patents to the forum, and none was received.

In any event (and without wanting to start a large off-topic legal
thread here), some lawyers would interpret the knowing publication
of an implementation embodying a patent under the GPL to be an
implicit license of use for the patent.

YMMV. IANAL.  Seek your own counsel on this.

> Sometimes ago I sent a porting to 2.6.24, but I didn't receive any 
> response.

I'd love to see this.  Did this go to LKML?  If so, about when?
(Alternatively, could you make it available somewhere?)

Thanks,
  -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

Re: Fwd: Some embedded topics

[Rob Landley]

On Friday 30 May 2008 17:21:25 Tim Bird wrote:
> Marco Stornelli wrote:
> > There's a MontaVista patent on PRAMFS and I think that most of times
> > when a company hears this thing it skips quickly this solution.
>
> Hmmm.  I don't recall anything about a patent on PRAMFS.
>
> There are lots of issues here, but I think it's OK to use.
> At a minimum,  MontaVista's PRAMFS was submitted to the CE Linux Forum
> in an older kernel (2.4.20-based).  MontaVista was well-aware
> of this submission (although it did not come directly from them).
> MV was under an IP agreement with CELF which required them to
> disclose such patents to the forum, and none was received.
>
> In any event (and without wanting to start a large off-topic legal
> thread here), some lawyers would interpret the knowing publication
> of an implementation embodying a patent under the GPL to be an
> implicit license of use for the patent.

Yup.  Although IBM and Red Hat make this license explicit: you may use (at 
least some of) their patents in code licensed under the terms of GPLv2.  I 
don't know if MontaVista has an explicit license statement or not.

IBM licensed the RCU patents as a condition of the code getting merged into 
Linux, and Red Hat's patent policy is here:
http://www.redhat.com/legal/patent_policy.html

More recently, they all joined the "open invention network" which is a 
mutually assured destruction patent pool thingy:

http://www.ibm.com/news/us/en/2005/11/2005_11_10.html
http://arstechnica.com/news.ars/post/20070807-google-signs-on-with-open-invention-network.html

Beyond all that, there's a legal theory (as yet untested in court) that taking 
patent enforcement action against GPLv2 code is grounds for any copyright 
holder in the GPL project to terminate _your_ right to use that code, because 
it's a direction violation of GPLv2 clause 6 forbidding additional 
restrictions on recipients exercise of rights.  (Fairly straightforward 
argument, really.)

That hasn't been tested in court, and attempts to do so could easily drag on 
for quite a while.  The end result could easily be "nobody can legally 
distribute the version that violates the patent, including the patentholder" 
since GPLv2 is designed to break closed.

I neither know nor care about GPLv3.  (As with vogon grandmothers, "In brief: 
avoid.")

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

Re: Fwd: Some embedded topics

[Marco Stornelli]

Tim Bird ha scritto:
> Marco Stornelli wrote:
>> There's a MontaVista patent on PRAMFS and I think that most of times 
>> when a company hears this thing it skips quickly this solution.
> 
> Hmmm.  I don't recall anything about a patent on PRAMFS.
> 
> There are lots of issues here, but I think it's OK to use.
> At a minimum,  MontaVista's PRAMFS was submitted to the CE Linux Forum
> in an older kernel (2.4.20-based).  MontaVista was well-aware
> of this submission (although it did not come directly from them).
> MV was under an IP agreement with CELF which required them to
> disclose such patents to the forum, and none was received.
> 
> In any event (and without wanting to start a large off-topic legal
> thread here), some lawyers would interpret the knowing publication
> of an implementation embodying a patent under the GPL to be an
> implicit license of use for the patent.
> 
> YMMV. IANAL.  Seek your own counsel on this.
> 
>> Sometimes ago I sent a porting to 2.6.24, but I didn't receive any 
>> response.
> 
> I'd love to see this.  Did this go to LKML?  If so, about when?
> (Alternatively, could you make it available somewhere?)
> 
> Thanks,
>  -- Tim
> 
> =============================
> Tim Bird
> Architecture Group Chair, CE Linux Forum
> Senior Staff Engineer, Sony Corporation of America
> =============================
> 
> 
 From MontaVista site:

"...File system designed by MontaVista Software for embedded systems - 
MontaVista has a patent pending on this code, but is licensing the 
patent freely for use in GPL software."

I agree with you Tom and Rob but I meant that especially for a little 
company only reading "patent pending" can be dread, and you know that 
legal arguments can be long and expensive.

About my patch, I sent an email to Steve Longerbeam on March because I 
read his name on the pramfs sourceforge project page. Now I haven't the 
patch anymore, however the latest patch is for 2.6.10 and the porting to 
2.6.24 was easy because there weren't a lot of differences.

Regards.

-- 
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it

marco.stornelli@coritel.it
+39 06 72582838

Re: Some embedded topics

[Tim Bird]

Josh Boyer wrote:
> lttng can trace quite a few events.  Interrupts, system calls, etc.
> Might be worth a look, and it's quite well maintained against various
> kernel versions.

It's pretty heavyweight, but you could use filters to cut down on
the events traced.  By default output goes to the file system, which
could be on pramfs.  (Or NFS - I'm sorry I lost track of the original
request - don't know if this is an option or not.)

I'm not sure, however, that the buffers are pushed to user-space,
through the daemon, and back to the file system in an expedient manner.
I agree it might be worth a look for this use case.  We use it at
Sony quite a bit and it's valuable.
  -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

Re: Some embedded topics

[Josh Boyer]

On Fri, 30 May 2008 15:36:14 -0700
Tim Bird <tim.bird@am.sony.com> wrote:

> Josh Boyer wrote:
> > lttng can trace quite a few events.  Interrupts, system calls, etc.
> > Might be worth a look, and it's quite well maintained against various
> > kernel versions.
> 
> It's pretty heavyweight, but you could use filters to cut down on
> the events traced.  By default output goes to the file system, which
> could be on pramfs.  (Or NFS - I'm sorry I lost track of the original
> request - don't know if this is an option or not.)

Indeed, it is fairly heavy in what it traces.  I was just suggesting it
as a starting point.

> I'm not sure, however, that the buffers are pushed to user-space,
> through the daemon, and back to the file system in an expedient manner.
> I agree it might be worth a look for this use case.  We use it at
> Sony quite a bit and it's valuable.

With a little bit of work, you could have it trace into a circular
buffer in DRAM.  Then you can preserve that via mem= reservations,
etc.

josh

Re: Some embedded topics

[Rob Landley]

On Friday 30 May 2008 19:04:23 Josh Boyer wrote:
> > I'm not sure, however, that the buffers are pushed to user-space,
> > through the daemon, and back to the file system in an expedient manner.
> > I agree it might be worth a look for this use case.  We use it at
> > Sony quite a bit and it's valuable.
>
> With a little bit of work, you could have it trace into a circular
> buffer in DRAM.  Then you can preserve that via mem= reservations,
> etc.

At this point, I feel the need to remind people of the time Linus Torvalds got 
a mac mini, tried to get software suspend working on it, and wound up using 
the RTC as a debug register to tell him where it hung/rebooted:

Thread starts here:
https://lists.linux-foundation.org/pipermail/linux-pm/2006-June/008465.html

A few interesting posts in the thread:
https://lists.linux-foundation.org/pipermail/linux-pm/2006-June/008470.html
https://lists.linux-foundation.org/pipermail/linux-pm/2006-June/008475.html
https://lists.linux-foundation.org/pipermail/linux-pm/2006-June/008491.html

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.