Re: Understanding LTT

I probably haven't been clear enough. I'm working on an embedded system
with a watchdog/deadman timer. If I don't write to the watchdog timer
register often enough, the watchdog resets my system. When my system
resets I do not have the ability to dump core. So, what I want to do
instead is to write tracing information to a reserved section of memory
that will not get overwritten when my system is rebooted. After I
reboot, I can easily dump the contents of the reserved section of memory
to a file.

>From looking at the code, it appears as though it should be relatively
straightforward to replace to relayfs/debugfs transport layer with a
different transport layer that writes to buffers in the reserved section
of memory. In fact, it looks like a good approach is probably to take
the ltt-relay.c code and remove anything which allocates buffers with
kmalloc and just use pointers into the reserved section of memory.
Unfortunately, there is very little documentation in this file, and I am
concerned I may wind up with something that just doesn't work and little
clue on what went wrong.

Documentation on the the following would be helpful:
o	What is a subbuffer and how are they used?
o	What are the parameters and return codes of the functions in
ltt-relay.c?
o	What is the purpose of separate having separate facilities?
o	What is the relationship beteen ltt_channel_struct and
	ltt_channel_buf_struct types?
o	Is it possible to support multiple transport type
simultaneously?
o	Is it possible to independently add and remove multiple probes,
with
	different transports, for a single mark?
--
David VomLehn, Staff O/S Software Engineer
Scientific Atlanta, A Cisco Company
10590 N. Tantau Avenue, Cupertino, CA 95014
[email protected]
voice: 408-777-5052 fax: 408-777-0176
 
 

> -----Original Message-----
> From: Maxim Uvarov [mailto:[email protected]] 
> Sent: Friday, August 10, 2007 10:28 AM
> To: Mathieu Desnoyers
> Cc: VomLehn, David; [email protected]
> Subject: Re: [Ltt-dev] Understanding LTT
> 
> Mathieu Desnoyers wrote:
> 
> >* VomLehn, David ([email protected]) wrote:
> >  
> >
> >>I am looking at LTT as a good starting point to recording 
> traces for 
> >>post-crash analysis. Unlike what most people are doing, I am 
> >>developing for an embedded system which has no place to 
> store a crash 
> >>dump. My approach is to write the traces to "reserved" memory that 
> >>won't be cleared when the system comes back up. To do this, 
> it looks 
> >>like the approach would be to use flight recorder mode on buffers 
> >>allocated in the reserved areas. Trying to figure out where 
> to splice 
> >>into LTT to do this, however, is somewhat time-consuming as 
> there is 
> >>less documentation in the code than I would prefer. From what I can 
> >>gather, the LTT code looks designed so that it might 
> accommodate a new 
> >>transport layer that I could write to do while I want.
> >>
> >>Is there documentation on LTT buffer allocation outside of 
> the code to 
> >>which I might refer, or can someone give me a few tips on where to 
> >>start? Alternatively, is there a better approach that someone can 
> >>think of?
> >>
> >>    
> >>
> >
> >Yep, it seems like MontaVista's work will find quick use.. I 
> put you in 
> >contact with Maxim Uvarov who is currently implementing a 
> kernel crash 
> >dump trace buffers extractor. I worked with him to get the 
> buffer order 
> >right and to create the ltt_write_commit_count() function that will 
> >give the next versions of LTTng the ability to have a 
> readable "last" 
> >buffer,
> >meaning: the last subbuffer being written when the system 
> crash will be 
> >readable by LTTV.
> >
> >Basically, what you want is to take a snapshot of your "hot" memory 
> >once the kernel has rebooted and tweak Maxim's tools to extract the 
> >buffers from the kernel memory dump.
> >
> >Mathieu
> >  
> >
> The best way to do it is to copy ltt buffers from 
> /proc/vmcore. I'v attached cross-crash extension that allows 
> to do it. You can use kdump or lkcd feature to take vmcore.
> 
> >  
> >
> >>--
> >>David VomLehn, Staff O/S Software Engineer Scientific 
> Atlanta, A Cisco 
> >>Company 10590 N. Tantau Avenue, Cupertino, CA 95014 
> >>[email protected] <mailto:[email protected]>
> >>voice: 408-777-5052 fax: 408-777-0176
> >>
> >>
> >>
> >>
> >>
> >>
> >>     - - - - - Appended by Scientific Atlanta, a Cisco 
> company - - - - 
> >>- This e-mail and any attachments may contain information which is 
> >>confidential, proprietary, privileged or otherwise 
> protected by law. 
> >>The information is solely intended for the named addressee (or a 
> >>person responsible for delivering it to the addressee). If 
> you are not 
> >>the intended recipient of this message, you are not authorized to 
> >>read, print, retain, copy or disseminate this message or 
> any part of 
> >>it. If you have received this e-mail in error, please 
> notify the sender immediately by return e-mail and delete it 
> from your computer.
> >>_______________________________________________
> >>Ltt-dev mailing list
> >>[email protected]
> >>http://listserv.shafik.org/mailman/listinfo/ltt-dev
> >>    
> >>
> >
> >
> >  
> >
> 
>