Re: LTTng usage issue
"Srinivasa Reddy" <[email protected]> Mon, 23 Jul 2007 16:38:40 +0530
| Newsgroups | gmane.linux.kernel.tracing |
|---|---|
| Message-ID | <[email protected]> |
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