Re: Understanding LTT

The plan is for this to be part of our release, so the answer is yes.

--
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: Tuesday, August 14, 2007 5:00 AM
> To: VomLehn, David
> Cc: Mathieu Desnoyers; [email protected]
> Subject: Re: [Ltt-dev] Understanding LTT
> 
> VomLehn,
> 
> You have very interesting task. Will you push it to open 
> source when development will be done?
> 
> 
> 
> VomLehn, David wrote:
> 
> >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
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>> 
> >>>
> >>>      
> >>>
> >>    
> >>
>