Re: LTTng usage issue
Mathieu Desnoyers <[email protected]> Mon, 23 Jul 2007 09:07:45 -0400
| Newsgroups | gmane.linux.kernel.tracing |
|---|---|
| Message-ID | <20070723130745.GA6606@Krystal> |
Good morning ;)
Are lttctl and lttd installed in the path they have been configured to
be make isntall'ed in ?
Also, try running, separately: (notice the 'b' instead of 'd')
lttctl -n trace -b
ls -alR /mnt/debugfs/ltt (to show me the output)
lttd -c /mnt/debugfs/ltt/trace -t /home/sreddy/traceout1 (it will stay
in foreground, not being daemonized)
lttctl -n trace -R
dmesg (show me the end of the dmesg output)
ls -alR /home/sreddy/traceout1
Mathieu
* Srinivasa Reddy ([email protected]) wrote:
> Some one please explain why I am getting that "No channel to read"
> error?
> Please explain what should be there in /mnt/debugfs/ltt folder?
>
> Currently there is no file in that folder in my environment setup.
>
> Please explain what does it's importance?? See below the output messages
> of lttctl......
>
> /home/sreddy # lttctl -n trace -d -l /home/sreddy/ltt -t
> /home/sreddy/trace12 -N 1
> Linux Trace Toolkit Trace Control 0.32-05122006
>
> Controlling trace : trace
>
> /home/sreddy # lttctl -n trace -d -l /mnt/debugfs/ltt -t
> /home/sreddy/trace
> Linux Trace Toolkit Trace Control 0.32-05122006
>
> Controlling trace : trace
>
> ltt_control : trace trace
> Linux Trace Toolkit Trace Daemon 0.32-05122006
>
> Reading from debugfs directory : /mnt/debugfs/ltt/trace
> Writing to trace directory : /home/sreddy/trace
>
> Creating supplementary trace files
> Appending facility file kernel_arch_ppc.xml
> Appending facility file kernel_arch_i386.xml
> Appending facility file fs.xml
> Appending facility file locking.xml
> Appending facility file core.xml
> Appending facility file kernel_arch_x86_64.xml
> Appending facility file stack.xml
> Appending facility file kernel_arch_powerpc.xml
> Appending facility file process.xml
> Appending facility file kernel.xml
> Creating trace subdirectory /home/sreddy/trace
> Adding inotify for channel /mnt/debugfs/ltt/trace/
> Added inotify for channel /mnt/debugfs/ltt/trace/, wd 4294967295
> No channel to read
> Appending facility file kernel_arch_arm.xml
> Appending facility file kernel_arch_c2.xml
> Appending facility file user_generic.xml
> Appending facility file fs_data.xml
> Appending facility file ipc.xml
> Appending facility file statedump.xml
> Appending facility file memory.xml
> Appending facility file timer.xml
> Appending facility file network.xml
> Appending facility file socket.xml
> Appending facility file network_ip_interface.xml
> Appending facility file kernel_arch_mips.xml
> ltt_control : trace trace
> /home/sreddy #
>
> -Srinivas.
>
>
> -----Original Message-----
> From: Mathieu Desnoyers [mailto:[email protected]]
> Sent: Friday, July 20, 2007 7:29 PM
> To: Srinivasa Reddy
> Cc: [email protected]
> Subject: Re: [Ltt-dev] LTTng usage issue
>
> * Srinivasa Reddy ([email protected]) wrote:
> > Yes, I am using that command only.
> >
> > The versions what I am using are:
> >
> > OS : 2.6.19
> > Ltnng : 0.6.47
> > Ltt-control : 0.32
> >
> > I need to work on linux kernel 2.6.19 only. That's why I have
> downloaded
> > the compatible versions of LTTng and Ltt-Control.
> >
> > Today I found one new error when I am trying to execute lttd and
> lttctl
> > separately.
> >
> > My questions are: 1. What should be there in /mnt/debugfs/ltt folder?
> > (currently it's empty).
> >
> > 2. Why it's giving the shared library error? Where we have to keep
> that
> > liblttctl.so.0 file?
> >
> > Please have a look at the below messages.
> >
> > /home/sreddy # lttctl -n trace -d -l /mnt/debugfs/ltt -t /tmp/trace
> > lttctl: error while loading shared libraries: liblttctl.so.0: cannot
> > open shared object file: No such file or directory
> > /home/sreddy #
> >
>
> See where is installed your library, maybe add the target to
> LD_LIBRARY_PATH, or edit /etc/ld.so.conf and run ldconfig.
>
> Else, you may want to install the files in the same directory as they
> will be on the target.
>
> >
> > When I try to execute lttd:
> >
> > /home/sreddy # lttd -t /tmp/trace -c /mnt/debugfs/ltt
> > Linux Trace Toolkit Trace Daemon 0.32-05122006
> >
> > Reading from debugfs directory : /mnt/debugfs/ltt
> > Writing to trace directory : /tmp/trace
> >
> > Creating trace subdirectory /tmp/trace
> > Adding inotify for channel /mnt/debugfs/ltt/
> > Added inotify for channel /mnt/debugfs/ltt/, wd 4294967295
> > No channel to read
> >
> >
> > What is meant by the channel file? Should we keep any file here or LTT
> > will generate these files?
> >
>
> It means that there are no channels active, therefore lttd has nothing
> to read. You should fix your liblttctl.so.0 problem: it is required for
> communication between lttctl and the kernel.
>
> Mathieu
>
> > Please let me know about this.
> >
> > Regards,
> > Srinivas.
> >
> > -----Original Message-----
> > From: Mathieu Desnoyers [mailto:[email protected]]
> > Sent: Friday, July 20, 2007 11:20 AM
> > To: Srinivasa Reddy
> > Cc: [email protected]
> > Subject: Re: [Ltt-dev] LTTng usage issue
> >
> > Weird.. lttd does not run.
> >
> > lttctl -n trace -d -l /mnt/debugfs/ltt -t /tmp/trace should fork a
> lttd
> > daemon which reads the trace channels and dumps them into files. Can
> you
> > chek that this is actually the command you use to start tracing ?
> Also,
> > you might want to try a slightly newer LTTng/ltt-control version.
> >
> > Mathieu
> >
> > * Srinivasa Reddy ([email protected]) wrote:
> > > Hi,
> > >
> > > Thanks for you reply.
> > >
> > > I have given all the commands what ever you suggested.
> > >
> > > Please have a loot at the command and it's output.
> > >
> > > When I gave: lttctl -n trace -R (to stop the tracing)
> > >
> > > /home/sreddy # lttctl -n trace -R
> > > Linux Trace Toolkit Trace Control 0.32-05122006
> > >
> > > Controlling trace : trace
> > >
> > > ltt_control : trace trace
> > > ltt_control : trace trace
> > > LTT : unread channel facilities offset is 65536 and cons_off : 0
> (cpu
> > 0)
> > > LTT : facilities : commit count : 65536, subbuf size 65536
> > > LTT : unread channel interrupts offset is 65536 and cons_off : 0
> (cpu
> > 0)
> > > LTT : interrupts : commit count : 65536, subbuf size 65536
> > > LTT : unread channel processes offset is 262144 and cons_off : 0
> (cpu
> > 0)
> > > LTT : processes : commit count : 262144, subbuf size 262144
> > > LTT : unread channel modules offset is 65536 and cons_off : 0 (cpu
> 0)
> > > LTT : modules : commit count : 65536, subbuf size 65536
> > > LTT : cpu : 8413 events lost in cpu channel (cpu 0).
> > > LTT : unread channel cpu offset is 1048576 and cons_off : 0 (cpu 0)
> > > LTT : cpu : commit count : 1048576, subbuf size 1048576
> > > LTT : unread channel network offset is 65536 and cons_off : 0 (cpu
> 0)
> > > LTT : network : commit count : 65536, subbuf size 65536
> > > /home/sreddy #
> > >
> > >
> > > When I gave : ps aux
> > >
> > >
> > > /tmp/trace # ps aux
> > > USER PID VSZ RSS TTY STAT START TIME COMMAND
> > > root 1 3.4 0.3 1484 500 ? S 00:00 0:14 init
> > [2]
> > >
> > > root 2 0.0 0.0 0 0 ? SWN 00:00 0:00
> > > [ksoftirqd/0]
> > > root 3 0.4 0.0 0 0 ? SW< 00:00 0:01
> > > [events/0]
> > > root 4 0.3 0.0 0 0 ? SW< 00:00 0:01
> > [khelper]
> > > root 5 0.0 0.0 0 0 ? SW< 00:00 0:00
> > [kthread]
> > > root 45 0.0 0.0 0 0 ? SW< 00:00 0:00
> > > [kblockd/0]
> > > root 46 0.2 0.0 0 0 ? SW< 00:00 0:00
> > [kseriod]
> > > root 58 0.0 0.0 0 0 ? SW 00:00 0:00
> > [pdflush]
> > > root 59 0.0 0.0 0 0 ? SW 00:00 0:00
> > [pdflush]
> > > root 60 0.0 0.0 0 0 ? SW< 00:00 0:00
> > [kswapd0]
> > > root 61 0.0 0.0 0 0 ? SW< 00:00 0:00
> [aio/0]
> > > root 176 0.0 0.0 0 0 ? SW 00:00 0:00
> > > [mtdblockd]
> > > root 183 0.0 0.0 0 0 ? SW< 00:00 0:00
> > > [kpsmoused]
> > > root 194 0.0 0.0 0 0 ? SW< 00:00 0:00
> > > [rpciod/0]
> > > root 239 0.0 0.1 1504 200 ? S 00:01 0:00
> > > /sbin/dhcpcd-bin
> > > daemon 244 0.6 0.4 1840 560 ? S 00:01 0:02
> > > /sbin/portmap
> > > root 264 0.8 0.4 1732 592 ? S 00:02 0:02
> > > /usr/sbin/inetd
> > > root 265 3.0 0.5 1960 736 ttyAMA0 S 00:02 0:09 -ash
> > > root 266 0.3 0.3 1488 476 ttyAMA1 S 00:02 0:00
> > > /sbin/getty -L tt
> > > root 267 0.2 0.3 1488 476 tty2 S 00:02 0:00
> > > /sbin/getty -L tt
> > > root 268 0.2 0.3 1488 476 tty3 S 00:02 0:00
> > > /sbin/getty -L tt
> > > root 269 0.2 0.3 1552 456 ? S 00:02 0:00
> /bin/sh
> > > /etc/init
> > > root 274 0.2 0.3 1488 476 tty1 S 00:02 0:00
> > > /sbin/getty -L tt
> > > root 295 99.9 0.6 2688 884 ttyAMA0 R 00:07 0:03 ps
> aux
> > > /tmp/trace #
> > >
> > >
> > > When I gave : dmesg
> > >
> > > /tmp/trace # dmesg
> > > Linux version 2.6.19-arm2 (sreddy@l-blr-devsys) (gcc version 4.1.1
> > > (CodeSourcery ARM Sourcery G++ 2006q3-26)) #13 Wed Jul 18 23:45:22
> IST
> > > 2007
> > > CPU: ARMv6-compatible processor [4107b361] revision 1 (ARMv6TEJ),
> > > cr=00e5387f
> > > Machine: ARM-RealView EB
> > > Memory policy: ECC disabled, Data cache writeback
> > > On node 0 totalpages: 32768
> > > DMA zone: 256 pages used for memmap
> > > DMA zone: 0 pages reserved
> > > DMA zone: 32512 pages, LIFO batch:7
> > > Normal zone: 0 pages used for memmap
> > > CPU0: D VIPT write-back cache
> > > CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
> > > CPU0: D cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
> > > Built 1 zonelists. Total pages: 32512
> > > Kernel command line: root=/dev/nfs
> > > nfsroot=10.162.4.49:/home/rrao/NFS/NFS_test init=/sbin/init ip=dhcp
> > > mem=128M console=ttyAMA0
> > > PID hash table entries: 512 (order: 9, 2048 bytes)
> > > Console: colour dummy device 80x30
> > > Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> > > Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> > > Memory: 128MB = 128MB total
> > > Memory: 127232KB available (2084K code, 472K data, 92K init)
> > > Calibrating delay loop... 20.32 BogoMIPS (lpj=101632)
> > > Mount-cache hash table entries: 512
> > > CPU: Testing write buffer coherency: ok
> > > NET: Registered protocol family 16
> > > NET: Registered protocol family 2
> > > IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> > > TCP established hash table entries: 4096 (order: 2, 16384 bytes)
> > > TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
> > > TCP: Hash tables configured (established 4096 bind 2048)
> > > TCP reno registered
> > > JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
> > > io scheduler noop registered (default)
> > > LTT : ltt-facilities init
> > > LTT : ltt-facility-core init in kernel
> > > LTT : ltt-facility-fs init in kernel
> > > LTT : ltt-facility-fs_data init in kernel
> > > LTT : ltt-facility-ipc init in kernel
> > > LTT : ltt-facility-kernel_arch init in kernel
> > > LTT : ltt-facility-kernel init in kernel
> > > LTT : ltt-facility-memory init in kernel
> > > LTT : ltt-facility-network init in kernel
> > > LTT : ltt-facility-process init in kernel
> > > LTT : ltt-facility-socket init in kernel
> > > LTT : ltt-facility-timer init in kernel
> > > LTT : ltt-facility-statedump init in kernel
> > > LTT : ltt-facility-network_ip_interface init in kernel
> > > LTT : ltt-facility-locking init in kernel
> > > LTT : ltt-heartbeat init
> > > LTT : ltt-relay init
> > > ltt-control init
> > > LTT : ltt-facility-statedump init
> > > CLCD: RealView hardware, VGA display
> > > Clock CLCDCLK: setting VCO reg params: S=1 R=99 V=98
> > > Console: switching to colour frame buffer device 80x30
> > > Serial: AMBA PL011 UART driver
> > > dev:f1: ttyAMA0 at MMIO 0x10009000 (irq = 44) is a AMBA/PL011
> > > dev:f2: ttyAMA1 at MMIO 0x1000a000 (irq = 45) is a AMBA/PL011
> > > dev:f3: ttyAMA2 at MMIO 0x1000b000 (irq = 46) is a AMBA/PL011
> > > fpga:09: ttyAMA3 at MMIO 0x1000c000 (irq = 47) is a AMBA/PL011
> > > smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre <[email protected]>
> > > No IRQF_TRIGGER set_type function for IRQ 60 (GIC)
> > > eth0: SMC91C11xFD (rev 2) at c8866000 IRQ 60 [nowait]
> > > eth0: Ethernet addr: 00:02:f7:00:1e:0e
> > > eth0: PHY LAN83C183 (LAN91C111 Internal)
> > > smsc911x: probe of smsc911x.0 failed with error -16
> > > armflash.0: Found 2 x16 devices at 0x0 in 32-bit bank
> > > Intel/Sharp Extended Query Table at 0x010A
> > > Intel/Sharp Extended Query Table at 0x010A
> > > Intel/Sharp Extended Query Table at 0x010A
> > > Intel/Sharp Extended Query Table at 0x010A
> > > Intel/Sharp Extended Query Table at 0x010A
> > > Using buffer write method
> > > cfi_cmdset_0001: Erase suspend on write enabled
> > > erase region 0: offset=0x0,size=0x10000,blocks=4
> > > erase region 1: offset=0x40000,size=0x40000,blocks=255
> > > armflash.0: 1 set(s) of 2 interleaved chips --> 16 partitions of
> 4096
> > > KiB
> > > RedBoot partition parsing not available
> > > afs partition parsing not available
> > > armflash: probe of armflash.0 failed with error -22
> > > mice: PS/2 mouse device common for all mice
> > > Advanced Linux Sound Architecture Driver Version 1.0.13 (Tue Nov 28
> > > 14:07:24 2006 UTC).
> > > aaci-pl041 fpga:04: ARM AC'97 Interface at 0x0000000010004000, irq
> 51,
> > > fifo 512
> > > atkbd.c: keyboard reset failed on fpga:06
> > > atkbd.c: keyboard reset failed on fpga:07
> > > ALSA device list:
> > > #0: ARM AC'97 Interface at 0x0000000010004000, irq 51
> > > TCP cubic registered
> > > NET: Registered protocol family 1
> > > NET: Registered protocol family 17
> > > VFP support v0.3: implementor 41 architecture 1 part 20 variant b
> rev
> > 0
> > > eth0: link down
> > > Sending DHCP requests .<6>eth0: link up, 100Mbps, full-duplex, lpa
> > > 0x41E1
> > > ....., OK
> > > IP-Config: Got DHCP answer from 0.0.0.0, my address is 10.162.3.173
> > > IP-Config: Complete:
> > > device=eth0, addr=10.162.3.173, mask=255.255.255.0,
> > gw=10.162.3.3,
> > > host=10.162.3.173, domain=asiapac.arm.com, nis-domain=(none),
> > > bootserver=0.0.0.0, rootserver=10.162.4.49, rootpath=
> > > Looking up port of RPC 100003/2 on 10.162.4.49
> > > Looking up port of RPC 100005/1 on 10.162.4.49
> > > VFS: Mounted root (nfs filesystem).
> > > Freeing init memory: 92K
> > > ltt-control ltt_control_input
> > > ltt_control : trace trace
> > > Creating trace trace
> > > ltt-control ltt_control_input
> > > ltt_control : trace trace
> > > Start tracing trace
> > > LTT : ltt-heartbeat trigger
> > > LTT : ltt-heartbeat start
> > > Dumping facility core
> > > Dumping facility timer
> > > Dumping facility socket
> > > Dumping facility locking
> > > Dumping facility kernel_arch
> > > Dumping facility memory
> > > Dumping facility fs
> > > Dumping facility fs_data
> > > Dumping facility network
> > > Dumping facility ipc
> > > Dumping facility kernel
> > > Dumping facility statedump
> > > Dumping facility process
> > > Dumping facility network_ip_interface
> > > ltt_statedump_start
> > > do_ltt_statedump
> > > trace_statedump_statedump_end
> > > ltt-control ltt_control_input
> > > ltt_control : trace trace
> > > Stop tracing trace
> > > LTT : ltt-heartbeat trigger
> > > LTT : ltt-heartbeat stop
> > > ltt-control ltt_control_input
> > > ltt_control : trace trace
> > > Destroying trace trace
> > > LTT : unread channel facilities offset is 65536 and cons_off : 0
> (cpu
> > 0)
> > > LTT : facilities : commit count : 65536, subbuf size 65536
> > > LTT : unread channel interrupts offset is 65536 and cons_off : 0
> (cpu
> > 0)
> > > LTT : interrupts : commit count : 65536, subbuf size 65536
> > > LTT : unread channel processes offset is 262144 and cons_off : 0
> (cpu
> > 0)
> > > LTT : processes : commit count : 262144, subbuf size 262144
> > > LTT : unread channel modules offset is 65536 and cons_off : 0 (cpu
> 0)
> > > LTT : modules : commit count : 65536, subbuf size 65536
> > > LTT : cpu : 8413 events lost in cpu channel (cpu 0).
> > > LTT : unread channel cpu offset is 1048576 and cons_off : 0 (cpu 0)
> > > LTT : cpu : commit count : 1048576, subbuf size 1048576
> > > LTT : unread channel network offset is 65536 and cons_off : 0 (cpu
> 0)
> > > LTT : network : commit count : 65536, subbuf size 65536
> > > /tmp/trace #
> > >
> > >
> > >
> > > Still it's not generating the complete trace information. Not
> getting
> > > where am I doing the mistake.
> > >
> > > Regards,
> > > Srinivas.
> > >
> > > -----Original Message-----
> > > From: Mathieu Desnoyers [mailto:[email protected]]
> > > Sent: Thursday, July 19, 2007 9:00 PM
> > > To: Srinivasa Reddy
> > > Cc: [email protected]
> > > Subject: Re: [Ltt-dev] LTTng usage issue
> > >
> > > Have you issued:
> > >
> > > # lttctl -n trace -R
> > >
> > > to stop tracing and flush subbuffers ?
> > >
> > > Also, can you give the dmesg output ?
> > >
> > > When you take the trace, can you give me an output of "ps aux" ?
> > >
> > > Mathieu
> > >
> > > * Srinivasa Reddy ([email protected]) wrote:
> > > > Hi,
> > > >
> > > > This is Srinivas. I am also working on the same project.
> > > >
> > > > I have give that command as you said and the result is like given
> > > below:
> > > >
> > > > /tmp/foo # ls -aR1
> > > > .:
> > > > .
> > > > ..
> > > > eventdefs
> > > >
> > > > ./eventdefs:
> > > > .
> > > > ..
> > > > compact.xml
> > > > core.xml
> > > > fs.xml
> > > > fs_data.xml
> > > > ipc.xml
> > > > kernel.xml
> > > > kernel_arch_arm.xml
> > > > kernel_arch_c2.xml
> > > > kernel_arch_i386.xml
> > > > kernel_arch_mips.xml
> > > > kernel_arch_powerpc.xml
> > > > kernel_arch_ppc.xml
> > > > kernel_arch_x86_64.xml
> > > > list.xml
> > > > locking.xml
> > > > memory.xml
> > > > mm.xml
> > > > net.xml
> > > > network.xml
> > > > network_ip_interface.xml
> > > > process.xml
> > > > socket.xml
> > > > stack.xml
> > > > stack_arch_i386.xml
> > > > stack_arch_x86_64.xml
> > > > statedump.xml
> > > > timer.xml
> > > > user_generic.xml
> > > > xen.xml
> > > > /tmp/foo #
> > > >
> > > >
> > > > Please let me know why it's not generating the other trace
> > > information.
> > > >
> > > > Regards,
> > > > Srinivas.
> > > >
> > > > -----Original Message-----
> > > > From: [email protected]
> [mailto:[email protected]]
> > > On
> > > > Behalf Of Mathieu Desnoyers
> > > > Sent: Thursday, July 19, 2007 6:30 PM
> > > > To: Raghavendra Rao
> > > > Cc: [email protected]
> > > > Subject: Re: [Ltt-dev] LTTng usage issue
> > > >
> > > > * Raghavendra Rao ([email protected]) wrote:
> > > > > Hi all
> > > > >
> > > > > I am new to lttng/ltt. I am facing problems using lttng while
> > > > generating
> > > > > the trace information.
> > > > > The version details of lttng, OS etc are given below:
> > > > >
> > > > > problem:
> > > > > ===========
> > > > > OS : 2.6.19
> > > > >
> > > > > Ltnng : 0.6.47
> > > > >
> > > > > Ltt-control : 0.32
> > > > >
> > > > >
> > > > > Steps followed:
> > > > > ================
> > > > > 1. started the trace as follows:
> > > > >
> > > > > $ lttctl -n trace -d -l /mnt/debugfs/ltt -t /tmp/trace
> > > > >
> > > > > Linux Trace Toolkit Trace Control 0.32-05122006
> > > > >
> > > > > Controlling trace : trace
> > > > >
> > > > > Ltt_control : trace trace
> > > > > Linux Trace Toolkit Trace Daemon 0.32-05122006
> > > > >
> > > > > Reading from debugfs directory : /mnt/debugfs/ltt/trace
> > > > > Writing to trace directory : /tmp/trace
> > > > >
> > > > > Creating supplementary trace files
> > > > > Appending facility file kernel_arch_ppc.xml
> > > > > Appending facility file kernel_arch_i386.xml
> > > > > Appending facility file compact.xml
> > > > > Appending facility file fs.xml
> > > > > Appending facility file locking.xml
> > > > > Appending facility file list.xml
> > > > > Appending facility file core.xml
> > > > > Appending facility file kernel_arch_x86_64.xml
> > > > > Appending facility file stack.xml
> > > > > Appending facility file kernel_arch_powerpc.xml
> > > > > Appending facility file process.xml
> > > > > Appending facility file kernel.xml
> > > > > Appending facility file kernel_arch_arm.xml
> > > > > Appending facility file kernel_arch_c2.xml
> > > > > Appending facility file user_generic.xml
> > > > > Appending facility file fs_data.xml
> > > > > Appending facility file ipc.xml
> > > > > Appending facility file net.xml
> > > > > Appending facility file statedump.xml
> > > > > Appending facility file mm.xml
> > > > > Appending facility file stack_arch_i386.xml
> > > > > Appending facility file memory.xml
> > > > > Appending facility file xen.xml
> > > > > Appending facility file stack_arch_x86_64.xml
> > > > > Appending facility file timer.xml
> > > > > Appending facility file network.xml
> > > > > Appending facility file socket.xml
> > > > > Appending facility file network_ip_interface.xml
> > > > > Appending facility file kernel_arch_mips.xml
> > > > > ltt_control : trace trace
> > > > >
> > > > > ~#
> > > > >
> > > > > And it's coming out here..
> > > > >
> > > > > It's not generating any info and control information with folder
> > > > > structure which is given in
> > > > >
> > > > >
> > >
> http://ltt.polymtl.ca/svn/ltt/branches/poly/doc/developer/format.html
> > > > >
> > > > > So where am I doing wrong?
> > > > >
> > > > > I would really appreciate any help/pointers in this regard
> > > > >
> > > >
> > > > There may be some unimplemented features.. can you give us a ls
> -aRl
> > > of
> > > > your trace directory ?
> > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > Thanks and regards
> > > > >
> > > > > Raghavendra.
> > > > >
> > > >
> > > > > _______________________________________________
> > > > > Ltt-dev mailing list
> > > > > [email protected]
> > > > > http://listserv.shafik.org/mailman/listinfo/ltt-dev
> > > >
> > > >
> > > > --
> > > > Mathieu Desnoyers
> > > > Computer Engineering Ph.D. Student, Ecole Polytechnique de
> Montreal
> > > > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE
> > 3BAE
> > > > 9A68
> > > > _______________________________________________
> > > > Ltt-dev mailing list
> > > > [email protected]
> > > > http://listserv.shafik.org/mailman/listinfo/ltt-dev
> > > >
> > >
> > > --
> > > Mathieu Desnoyers
> > > Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
> > > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE
> 3BAE
> > > 9A68
> > >
> >
> > --
> > Mathieu Desnoyers
> > Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
> > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE
> > 9A68
> >
>
> --
> Mathieu Desnoyers
> Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE
> 9A68
>
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68