From: Lik L. <lik...@gm...> - 2012-01-09 02:59:06
|
Hi all, I am an oprofile user and I need to profile one of my applications on a TI OMAP4 platform (pandaboard, to be specific). I have ubuntu 11.10 installed. My problem is that oprofile always use the timer interrupt mode but doesn't recognize the hardware counters, which I am sure my platform has. After reading some previous emails from this list my feeling is that I need a linux kernel with oprofile support, and then I can use --vmlinux to get the counter enabled. Is that correct or am I missing the point? If that is the case, given the fact that I don't have much experience building linux kernel, I wonder if there is a pre-built vmlinux file that I can download. If I have to build the kernel by myself, what is the easiest approach? If I misunderstand the issue, would you please correct me? Thanks, Lik |
From: Maynard J. <may...@us...> - 2012-01-09 16:40:28
|
On 01/08/2012 8:58 PM, Lik Lik wrote: > Hi all, > > I am an oprofile user and I need to profile one of my applications on a TI OMAP4 > platform (pandaboard, to be specific). I have ubuntu 11.10 installed. My problem > is that oprofile always use the timer interrupt mode but doesn't recognize the > hardware counters, which I am sure my platform has. Hi, Lik, OProfile userspace support for ARM Cortex-A9 was added by Will Deacon in June 2010. This support is available in OProfile 0.9.7. According to Will's posting, the kernel support was due to be added to Ubuntu Maverick, so I would expect your version should support CA9 out of the box. If not already using oprofile 0.9.7, please upgrade to that version and retry. If it still doesn't work, please re-post with complete information (kernel version, oprofile command output, and contents of /dev/oprofile/cpu_type). -Maynard > > After reading some previous emails from this list my feeling is that I need a > linux kernel with oprofile support, and then I can use --vmlinux to get the > counter enabled. Is that correct or am I missing the point? > > If that is the case, given the fact that I don't have much experience building > linux kernel, I wonder if there is a pre-built vmlinux file that I can download. > If I have to build the kernel by myself, what is the easiest approach? > > If I misunderstand the issue, would you please correct me? > > Thanks, > > Lik > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > > > > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list |
From: Lik L. <lik...@gm...> - 2012-01-09 19:42:27
|
Hi Maynard, Thanks a lot for your quick response. I do have the 0.9.7 version of oprofile. But the cpu_type is set to timertest. Here are some outputs for relevant information: test@test-pandaboard:~$ opcontrol --version opcontrol: oprofile 0.9.7 compiled on Dec 15 2011 17:54:57 test@test-pandaboard:~$ uname -r 3.0.0-1206-omap4 test@test-pandaboard:~$ cat /dev/oprofile/cpu_type timertest I built the oprofile from the source on this OMAP platform directly last month (no cross-compilation). It was just "./configure -disable-werror -with-kernel-support; make; sudo make install" as far as I can remember. Maybe for some reason the cpu_type was set wrong? Is there any way to simply overwrite or refresh it? Or is the problem bigger than that? Thanks, Lik On Mon, Jan 9, 2012 at 8:39 AM, Maynard Johnson <may...@us...> wrote: > On 01/08/2012 8:58 PM, Lik Lik wrote: > >> Hi all, >> >> I am an oprofile user and I need to profile one of my applications on a >> TI OMAP4 >> platform (pandaboard, to be specific). I have ubuntu 11.10 installed. My >> problem >> is that oprofile always use the timer interrupt mode but doesn't >> recognize the >> hardware counters, which I am sure my platform has. >> > Hi, Lik, > OProfile userspace support for ARM Cortex-A9 was added by Will Deacon in > June 2010. This support is available in OProfile 0.9.7. According to > Will's posting, the kernel support was due to be added to Ubuntu Maverick, > so I would expect your version should support CA9 out of the box. If not > already using oprofile 0.9.7, please upgrade to that version and retry. If > it still doesn't work, please re-post with complete information (kernel > version, oprofile command output, and contents of /dev/oprofile/cpu_type). > > -Maynard > > >> After reading some previous emails from this list my feeling is that I >> need a >> linux kernel with oprofile support, and then I can use --vmlinux to get >> the >> counter enabled. Is that correct or am I missing the point? >> >> If that is the case, given the fact that I don't have much experience >> building >> linux kernel, I wonder if there is a pre-built vmlinux file that I can >> download. >> If I have to build the kernel by myself, what is the easiest approach? >> >> If I misunderstand the issue, would you please correct me? >> >> Thanks, >> >> Lik >> >> >> ------------------------------**------------------------------** >> ------------------ >> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex >> infrastructure or vast IT resources to deliver seamless, secure access to >> virtual desktops. With this all-in-one solution, easily deploy virtual >> desktops for less than the cost of PCs and save 60% on VDI infrastructure >> costs. Try it free! http://p.sf.net/sfu/Citrix-**VDIinabox<http://p.sf.net/sfu/Citrix-VDIinabox> >> >> >> >> ______________________________**_________________ >> oprofile-list mailing list >> oprofile-list@lists.**sourceforge.net<opr...@li...> >> https://lists.sourceforge.net/**lists/listinfo/oprofile-list<https://lists.sourceforge.net/lists/listinfo/oprofile-list> >> > > |
From: William C. <wc...@re...> - 2012-01-09 21:27:21
|
On 01/08/2012 09:58 PM, Lik Lik wrote: > Hi all, > > I am an oprofile user and I need to profile one of my applications on a TI OMAP4 platform (pandaboard, to be specific). I have ubuntu 11.10 installed. My problem is that oprofile always use the timer interrupt mode but doesn't recognize the hardware counters, which I am sure my platform has. > > After reading some previous emails from this list my feeling is that I need a linux kernel with oprofile support, and then I can use --vmlinux to get the counter enabled. Is that correct or am I missing the point? > > If that is the case, given the fact that I don't have much experience building linux kernel, I wonder if there is a pre-built vmlinux file that I can download. If I have to build the kernel by myself, what is the easiest approach? > > If I misunderstand the issue, would you please correct me? > > Thanks, > > Lik Hi Lik, What specific kernel is being used? Older versions of the kernel needed the oprofile support to be selected for the particular arm implmentation at compile time. Newer versions of the kernel oprofile driver are built on the kernel perf support. I have noticed this has not been working on the tegra2 processor (linux-3.2.0). If this is a newer kernel that supports perf you might check to see if the perf support works. something simple like: perf stat ls If perf is available on the machine but the above doesn't work then the problem is most likely related to the kernel driver rather than the user-space oprofile package. -Will |
From: Lik L. <lik...@gm...> - 2012-01-09 22:27:51
|
On Mon, Jan 9, 2012 at 1:27 PM, William Cohen <wc...@re...> wrote: > On 01/08/2012 09:58 PM, Lik Lik wrote: > > Hi all, > > > > I am an oprofile user and I need to profile one of my applications on a > TI OMAP4 platform (pandaboard, to be specific). I have ubuntu 11.10 > installed. My problem is that oprofile always use the timer interrupt mode > but doesn't recognize the hardware counters, which I am sure my platform > has. > > > > After reading some previous emails from this list my feeling is that I > need a linux kernel with oprofile support, and then I can use --vmlinux to > get the counter enabled. Is that correct or am I missing the point? > > > > If that is the case, given the fact that I don't have much experience > building linux kernel, I wonder if there is a pre-built vmlinux file that I > can download. If I have to build the kernel by myself, what is the easiest > approach? > > > > If I misunderstand the issue, would you please correct me? > > > > Thanks, > > > > Lik > > Hi Lik, > > What specific kernel is being used? Older versions of the kernel needed > the oprofile support to be selected for the particular arm implmentation at > compile time. Newer versions of the kernel oprofile driver are built on the > kernel perf support. I have noticed this has not been working on the tegra2 > processor (linux-3.2.0). If this is a newer kernel that supports perf you > might check to see if the perf support works. something simple like: > > perf stat ls > > If perf is available on the machine but the above doesn't work then the > problem is most likely related to the kernel driver rather than the > user-space oprofile package. > > -Will > Hi Will, I am not sure about the first question. I don't think there is any specific kernel here. All I did was to get the pre-built binary from here : http://omappedia.org/wiki/Prebuilt_ubuntu_binaries. I think I got "Ubuntu 11.10 Oneiric Ocelot desktop<http://cdimage.ubuntu.com/releases/11.10/release/ubuntu-11.10-preinstalled-desktop-armel+omap4.img.gz>". Here is the output of the perf tool: Performance counter stats for 'ls': 0.518799 task-clock # 0.073 CPUs utilized 1 context-switches # 0.002 M/sec 0 CPU-migrations # 0.000 M/sec 203 page-faults # 0.391 M/sec <not counted> cycles <not counted> stalled-cycles-frontend <not counted> stalled-cycles-backend <not counted> instructions <not counted> branches <not counted> branch-misses 0.007140789 seconds time elapsed With all those <not counted> does it mean the kernel driver is the culprit? Thanks, Lik |
From: William C. <wc...@re...> - 2012-01-10 15:04:27
|
On 01/09/2012 05:27 PM, Lik Lik wrote: > > Hi Will, > > I am not sure about the first question. I don't think there is any specific kernel here. All I did was to get the pre-built binary from here : http://omappedia.org/wiki/Prebuilt_ubuntu_binaries. I think I got "Ubuntu 11.10 Oneiric Ocelot desktop <http://cdimage.ubuntu.com/releases/11.10/release/ubuntu-11.10-preinstalled-desktop-armel+omap4.img.gz>". > > Here is the output of the perf tool: > > Performance counter stats for 'ls': > > 0.518799 task-clock # 0.073 CPUs utilized > 1 context-switches # 0.002 M/sec > 0 CPU-migrations # 0.000 M/sec > 203 page-faults # 0.391 M/sec > <not counted> cycles > <not counted> stalled-cycles-frontend > <not counted> stalled-cycles-backend > <not counted> instructions > <not counted> branches > <not counted> branch-misses > > 0.007140789 seconds time elapsed > > With all those <not counted> does it mean the kernel driver is the culprit? > > Thanks, > > Lik Hi Lik, All the hardware related events: cycles, instructions, branches, branch-misses, etc are <not counted>. This output indicates that the performance monitoring unit hardware is not currently supported with the kernel you are using. The kernel perf support is the culprit. On arm the oprofile driver uses perf. Looks like you are stuck with oprofile using timer interrupts with this particular kernel. -Will |
From: Will D. <wil...@ar...> - 2012-01-09 23:03:38
|
On Mon, Jan 09, 2012 at 04:39:09PM +0000, Maynard Johnson wrote: > On 01/08/2012 8:58 PM, Lik Lik wrote: > > Hi all, Hi guys [adding a bunch of people to CC because this issue is really annoying me now], > > I am an oprofile user and I need to profile one of my applications on a TI OMAP4 > > platform (pandaboard, to be specific). I have ubuntu 11.10 installed. My problem > > is that oprofile always use the timer interrupt mode but doesn't recognize the > > hardware counters, which I am sure my platform has. First and foremost, we can't currently generate PMU interrupts on OMAP4 in mainline. There are some additional patches required for these to work: http://marc.info/?l=linux-arm-kernel&m=131946761428296&w=2 However, as Stephane has pointed out here: http://marc.info/?l=linux-omap&m=132585784125352&w=2 the interrupts still don't seem to work, even with the patches above applied. Ming Lei doesn't seem to be replying to email anymore, so maybe somebody else on linux-omap could please help us? I'm hoping that we're just missing some patches from somewhere, but it would be great if somebody could verify this (and indeed, verify that the interrupts we're registering in the thread above look sane). > OProfile userspace support for ARM Cortex-A9 was added by Will Deacon in June > 2010. This support is available in OProfile 0.9.7. According to Will's > posting, the kernel support was due to be added to Ubuntu Maverick, so I would > expect your version should support CA9 out of the box. If not already using > oprofile 0.9.7, please upgrade to that version and retry. If it still doesn't > work, please re-post with complete information (kernel version, oprofile command > output, and contents of /dev/oprofile/cpu_type). If with the latest OProfile, `timer mode' is still reported then you should check that you have CONFIG_HW_PERF_EVENTS enabled in your kernel. It still won't work though, because of the problems I mentioned above. Cheers, Will |
From: Shilimkar, S. <san...@ti...> - 2012-04-03 09:43:13
|
On Tue, Apr 3, 2012 at 2:55 PM, Will Deacon <wil...@ar...> wrote: > Santosh, > > On Wed, Jan 18, 2012 at 12:33:23PM +0000, Shilimkar, Santosh wrote: >> On Wed, Jan 18, 2012 at 1:24 PM, Ming Lei <min...@ca...> wrote: >> >>> diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c >> >>> b/arch/arm/mach-omap2/clockdomains44xx_data.c >> >>> index 9299ac2..41d2260 100644 >> >>> --- a/arch/arm/mach-omap2/clockdomains44xx_data.c >> >>> +++ b/arch/arm/mach-omap2/clockdomains44xx_data.c >> >>> @@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = { >> >>> .prcm_partition = OMAP4430_PRM_PARTITION, >> >>> .cm_inst = OMAP4430_PRM_EMU_CM_INST, >> >>> .clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS, >> >>> - .flags = CLKDM_CAN_HWSUP, >> >>> + .flags = CLKDM_CAN_SWSUP, >> >>> }; >> >> NAK. >> >> >> >> You don't need this patch. What you saw on CAMERA was indeed >> >> a known bug but emulation domain has no such issues. >> >> >> >> So the accesses to emulation register should continue to work >> >> with the clock-domain being kept under hardware supervision. >> > >> > But why can this patch make omap4 pmu work? Without the patch, >> > there are no CTI interrupts generated for pmu irq. >> > >> Interesting. For me debugger works which also relies on Emulation domain. >> >> Need to see why CTI is behaving like this. > > Did you ever get to the bottom of this? This change really is required in > order to generate PMU interrupts with the CTI and I don't know of any > alternative to the above. > > Any suggestions? > Sorry I lost track of this one. There is one relevant patch in Kevin's queue for 3.4/fixes. [1] which I generated for perf time stamp issue. Can you try that patch and see if it helps the CTI issue as well ? There is an outside chance that it might help. If it doesn't, we should commit Ming Lei patch. Regards Santosh [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/089679.html |
From: Will D. <wil...@ar...> - 2012-04-03 09:48:01
|
On Tue, Apr 03, 2012 at 10:42:30AM +0100, Shilimkar, Santosh wrote: > On Tue, Apr 3, 2012 at 2:55 PM, Will Deacon <wil...@ar...> wrote: > > Did you ever get to the bottom of this? This change really is required in > > order to generate PMU interrupts with the CTI and I don't know of any > > alternative to the above. > > > > Any suggestions? > > > Sorry I lost track of this one. There is one relevant patch in Kevin's queue > for 3.4/fixes. [1] which I generated for perf time stamp issue. Thanks, I'll take a look. > Can you try that patch and see if it helps the CTI issue as well ? There > is an outside chance that it might help. If it doesn't, we should commit > Ming Lei patch. It seems that they're both needed to get reliable PMU operation. Without the CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch below ([1]), it seems that we don't generate enough. So it looks like we need them both. > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/089679.html Cheers, Will |
From: Ming L. <min...@ca...> - 2012-01-09 23:30:16
|
Hi, On Tue, Jan 10, 2012 at 6:49 AM, Will Deacon <wil...@ar...> wrote: > On Mon, Jan 09, 2012 at 04:39:09PM +0000, Maynard Johnson wrote: >> On 01/08/2012 8:58 PM, Lik Lik wrote: >> > Hi all, > > Hi guys [adding a bunch of people to CC because this issue is really > annoying me now], > >> > I am an oprofile user and I need to profile one of my applications on a TI OMAP4 >> > platform (pandaboard, to be specific). I have ubuntu 11.10 installed. My problem >> > is that oprofile always use the timer interrupt mode but doesn't recognize the >> > hardware counters, which I am sure my platform has. > > First and foremost, we can't currently generate PMU interrupts on OMAP4 in > mainline. There are some additional patches required for these to work: > > http://marc.info/?l=linux-arm-kernel&m=131946761428296&w=2 > > However, as Stephane has pointed out here: > > http://marc.info/?l=linux-omap&m=132585784125352&w=2 > > the interrupts still don't seem to work, even with the patches above > applied. > > Ming Lei doesn't seem to be replying to email anymore, so maybe somebody Sorry, I am on a trip now and no pandboard at my hand, so I may have time to verify the latest mainline next week after I return home. I remembered that last time I verified these patches on 3.2-rc2 and 3.2-rc2 next tree, and perf did work well on my pandaboard. Also seems there were reports that omap4 perf may not work on some specific uboot version even with these patches. > else on linux-omap could please help us? I'm hoping that we're just missing > some patches from somewhere, but it would be great if somebody could verify > this (and indeed, verify that the interrupts we're registering in the thread > above look sane). > >> OProfile userspace support for ARM Cortex-A9 was added by Will Deacon in June >> 2010. This support is available in OProfile 0.9.7. According to Will's >> posting, the kernel support was due to be added to Ubuntu Maverick, so I would >> expect your version should support CA9 out of the box. If not already using >> oprofile 0.9.7, please upgrade to that version and retry. If it still doesn't >> work, please re-post with complete information (kernel version, oprofile command >> output, and contents of /dev/oprofile/cpu_type). > > If with the latest OProfile, `timer mode' is still reported then you should > check that you have CONFIG_HW_PERF_EVENTS enabled in your kernel. It still > won't work though, because of the problems I mentioned above. If debug message from 'dmesg' can be provided, maybe we can find clue about the problem. thanks, -- Ming Lei |
From: stephane e. <er...@go...> - 2012-01-10 00:46:25
|
See the dmesg from my 3.2 kernel: [ 0.000000] Booting Linux on physical CPU 0[ 0.000000] Initializing cgroup subsys cpuset[ 0.000000] Initializing cgroup subsys cpu[ 0.000000] Linux version 3.2.0-omap4 (eranian@panda) (gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #9 SMP PR[ 0.000000] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c5387d[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache[ 0.000000] Machine: OMAP4 Panda board[ 0.000000] Reserving 33554432 bytes SDRAM for VRAM[ 0.000000] Memory policy: ECC disabled, Data cache writealloc[ 0.000000] On node 0 totalpages: 239616[ 0.000000] free_area_init_node: node 0, pgdat c077c180, node_mem_map c07f4000[ 0.000000] Normal zone: 1536 pages used for memmap[ 0.000000] Normal zone: 0 pages reserved[ 0.000000] Normal zone: 180736 pages, LIFO batch:31[ 0.000000] HighMem zone: 512 pages used for memmap[ 0.000000] HighMem zone: 56832 pages, LIFO batch:15[ 0.000000] OMAP4430 ES2.2[ 0.000000] PERCPU: Embedded 8 pages/cpu @c0ffc000 s10240 r8192 d14336 u32768[ 0.000000] pcpu-alloc: s10240 r8192 d14336 u32768 alloc=8*4096[ 0.000000] pcpu-alloc: [0] 0 [0] 1[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 237568[ 0.000000] Kernel command line: ro elevator=noop vram=32M mem=456M@0x80000000 mem=512M@0xA0000000 root=UUID=ec3f7a[ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)[ 0.000000] allocated 4194304 bytes of page_cgroup[ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups[ 0.000000] Memory: 456MB 480MB = 936MB total[ 0.000000] Memory: 934980k/934980k available, 56252k reserved, 229376K highmem[ 0.000000] Virtual kernel memory layout:[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)[ 0.000000] vmalloc : 0xf0800000 - 0xf8000000 ( 120 MB)[ 0.000000] lowmem : 0xc0000000 - 0xf0000000 ( 768 MB)[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)[ 0.000000] .text : 0xc0008000 - 0xc06e1134 (7013 kB)[ 0.000000] .init : 0xc06e2000 - 0xc071e800 ( 242 kB)[ 0.000000] .data : 0xc0720000 - 0xc077ecf0 ( 380 kB)[ 0.000000] .bss : 0xc077ed14 - 0xc07f32ec ( 466 kB)[ 0.000000] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1[ 0.000000] Preemptible hierarchical RCU implementation.[ 0.000000] NR_IRQS:410[ 0.000000] omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.[ 0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz[ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms[ 0.000000] Console: colour dummy device 80x30[ 0.000000] console [tty0] enabled[ 0.000213] Calibrating delay loop... 1576.53 BogoMIPS (lpj=6156288)[ 0.070373] pid_max: default: 32768 minimum: 301[ 0.070617] Security Framework initialized[ 0.070678] Smack: Initializing.[ 0.070770] Mount-cache hash table entries: 512[ 0.071807] Initializing cgroup subsys cpuacct[ 0.071868] Initializing cgroup subsys memory[ 0.071929] Initializing cgroup subsys devices[ 0.071929] Initializing cgroup subsys freezer[ 0.071960] Initializing cgroup subsys blkio[ 0.071990] Initializing cgroup subsys perf_event[ 0.072143] CPU: Testing write buffer coherency: ok[ 0.072448] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000[ 0.072509] Calibrating local timer... 386.32MHz.[ 0.117462] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available[ 0.117523] L310 cache controller enabled[ 0.117523] l2x0: 16 ways, CACHE_ID 0x410000c4, AUX_CTRL 0x7e470000, Cache size: 1048576 B[ 0.194000] CPU1: Booted secondary processor[ 0.224121] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001[ 0.224151] CPU1: Unknown IPI message 0x1[ 0.224182] Brought up 2 CPUs[ 0.224212] SMP: Total of 2 processors activated (3115.31 BogoMIPS).[ 0.225097] devtmpfs: initialized[ 0.228820] omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.[ 0.231903] omap_hwmod: dmm: _wait_target_disable failed[ 0.234497] omap_hwmod: emif_fw: _wait_target_disable failed[ 0.237091] omap_hwmod: l3_main_1: _wait_target_disable failed[ 0.239715] omap_hwmod: l3_main_2: _wait_target_disable failed[ 0.242309] omap_hwmod: l4_abe: _wait_target_disable failed[ 0.244903] omap_hwmod: l4_cfg: _wait_target_disable failed[ 0.247528] omap_hwmod: l4_per: _wait_target_disable failed[ 0.250610] omap_hwmod: l4_wkup: _wait_target_disable failed[ 0.253234] omap_hwmod: dma_system: _wait_target_disable failed[ 0.255889] omap_hwmod: dss_core: _wait_target_disable failed[ 0.258514] omap_hwmod: dss_dispc: _wait_target_disable failed[ 0.261108] omap_hwmod: dss_dsi1: _wait_target_disable failed[ 0.263732] omap_hwmod: dss_dsi2: _wait_target_disable failed[ 0.266326] omap_hwmod: dss_hdmi: _wait_target_disable failed[ 0.268920] omap_hwmod: dss_rfbi: _wait_target_disable failed[ 0.271545] omap_hwmod: dss_venc: _wait_target_disable failed[ 0.275054] omap_hwmod: mailbox: _wait_target_disable failed[ 0.277709] omap_hwmod: mcpdm: cannot be enabled (3)[ 0.280487] omap_hwmod: spinlock: _wait_target_disable failed[ 0.282348] print_constraints: dummy:[ 0.282592] NET: Registered protocol family 16[ 0.282775] GPMC revision 6.0[ 0.284332] OMAP GPIO hardware version 0.1 [ 0.285552] omap_mux_init: Add partition: #1: core, flags: 2 [ 0.286468] omap_mux_init: Add partition: #2: wkup, flags: 2 [ 0.291015] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers. [ 0.291015] hw-breakpoint: maximum watchpoint size is 4 bytes. [ 0.291595] RES:0 IRQ:33 [ 0.291595] RES:1 IRQ:34 [ 0.294219] OMAP DMA hardware revision 0.0 [ 0.299591] bio: create slab <bio-0> at 0 [ 0.300109] print_constraints: vwl1271: 1800 mV [ 0.300994] SCSI subsystem initialized [ 0.301239] usbcore: registered new interface driver usbfs [ 0.301300] usbcore: registered new interface driver hub [ 0.301391] usbcore: registered new device driver usb [ 0.315643] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 400 kHz [ 0.316131] Skipping twl internal clock init and using bootloader value (unknown osc rate) [ 0.316619] twl6030: PIH (irq 39) chaining IRQs 368..387 [ 0.316986] print_constraints: VUSB: 3300 mV normal standby [ 0.514312] twl6030_usb twl6030_usb: Initialized TWL6030 USB module [ 0.514648] print_constraints: VMMC: 1200 <--> 3000 mV at 3000 mV normal standby [ 0.515075] print_constraints: VPP: 1800 <--> 2500 mV at 1900 mV normal standby [ 0.515563] print_constraints: VCXIO: 1800 mV normal standby [ 0.515808] print_constraints: VDAC: 1800 mV normal standby [ 0.516174] print_constraints: VAUX2_6030: 1200 <--> 2800 mV at 1800 mV normal standby [ 0.516601] print_constraints: VAUX3_6030: 1000 <--> 3000 mV at 1200 mV normal standby [ 0.516845] print_constraints: CLK32KG: [ 0.517059] print_constraints: VANA: 2100 mV normal standby [ 0.529052] omap_i2c omap_i2c.2: bus 2 rev2.4.0 at 400 kHz [ 0.544281] omap_i2c omap_i2c.3: bus 3 rev2.4.0 at 100 kHz [ 0.559539] omap_i2c omap_i2c.4: bus 4 rev2.4.0 at 400 kHz [ 0.559997] Advanced Linux Sound Architecture Driver Version 1.0.24. [ 0.560516] Bluetooth: Core ver 2.16 [ 0.560577] NET: Registered protocol family 31 [ 0.560577] Bluetooth: HCI device and connection manager initialized [ 0.560607] Bluetooth: HCI socket layer initialized [ 0.560821] cfg80211: Calling CRDA to update world regulatory domain [ 0.561523] NetLabel: Initializing [ 0.561523] NetLabel: domain hash size = 128 [ 0.561553] NetLabel: protocols = UNLABELED CIPSOv4 [ 0.561584] NetLabel: unlabeled traffic allowed by default [ 0.561614] Switching to clocksource 32k_counter [ 0.592681] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host) [ 0.592864] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn [ 0.592926] musb-hdrc: MHDRC RTL version 2.0 [ 0.592926] musb-hdrc: setup fifo_mode 4 [ 0.592956] musb-hdrc: 28/31 max ep, 16384/16384 memory [ 0.593231] musb-hdrc musb-hdrc: USB OTG mode controller at fc0ab000 using DMA, IRQ 124 [ 0.593627] NET: Registered protocol family 2 [ 0.593933] IP route cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.595001] TCP established hash table entries: 131072 (order: 8, 1048576 bytes) [ 0.596923] TCP bind hash table entries: 65536 (order: 7, 786432 bytes) [ 0.598022] TCP: Hash tables configured (established 131072 bind 65536) [ 0.598022] TCP reno registered [ 0.598052] UDP hash table entries: 512 (order: 2, 16384 bytes) [ 0.598083] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes) [ 0.598449] NET: Registered protocol family 1 [ 0.598846] RPC: Registered named UNIX socket transport module. [ 0.598846] RPC: Registered udp transport module. [ 0.598846] RPC: Registered tcp transport module. [ 0.598876] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 0.599121] Trying to unpack rootfs image as initramfs... [ 0.793060] Freeing initrd memory: 2612K [ 0.914703] audit: initializing netlink socket (disabled) [ 0.914764] type=2000 audit(0.921:1): initialized [ 1.053497] highmem bounce pool size: 64 pages [ 1.060485] VFS: Disk quotas dquot_6.5.2 [ 1.060913] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 1.063934] msgmni has been set to 1383 [ 1.065399] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) [ 1.065429] io scheduler noop registered (default) [ 1.065429] io scheduler deadline registered [ 1.065460] io scheduler cfq registered [ 1.066253] OMAP DSS rev 4.0 [ 1.068847] omap_hwmod: dss_core: _wait_target_disable failed [ 1.071716] omap_hwmod: dss_core: _wait_target_disable failed [ 1.074340] omap_hwmod: dss_dispc: _wait_target_disable failed [ 1.077209] omap_hwmod: dss_dispc: _wait_target_disable failed [ 1.079864] omap_hwmod: dss_core: _wait_target_disable failed [ 1.082489] omap_hwmod: dss_dsi1: _wait_target_disable failed [ 1.085266] omap_hwmod: dss_dispc: _wait_target_disable failed [ 1.087890] omap_hwmod: dss_dsi2: _wait_target_disable failed [ 1.091247] omap_hwmod: dss_dispc: _wait_target_disable failed [ 1.093841] omap_hwmod: dss_core: _wait_target_disable failed [ 1.098175] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 104) is a OMAP UART0 [ 1.116394] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 105) is a OMAP UART1 [ 1.139831] omap_uart.2: ttyO2 at MMIO 0x48020000 (irq = 106) is a OMAP UART2 [ 1.257019] omap_uart.3: ttyO3 at MMIO 0x4806e000 (irq = 102) is a OMAP UART3 [ 1.382202] [drm] Initialized drm 1.1.0 20060810 [ 1.382781] brd: module loaded [ 1.386749] loop: module loaded [ 1.386932] (stk) :sysfs entries created [ 1.386962] (stk) : debugfs entries created [ 1.387573] usbcore: registered new interface driver smsc95xx [ 1.387603] cdc_ncm: 04-Aug-2011 [ 1.387695] usbcore: registered new interface driver cdc_ncm [ 1.387786] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 1.387817] ehci_hcd: block sizes: qh 64 qtd 96 itd 160 sitd 96 [ 1.387908] _regulator_get: ehci-omap.0 supply hsusb0 not found, using dummy regulator [ 1.388031] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0 cc=1 pcc=3 ordered ports=3 [ 1.388061] ehci-omap ehci-omap.0: reset hcc_params 20016 thresh 1 uframes 256/512/1024 park LPM [ 1.388061] ehci-omap ehci-omap.0: reset hcc_params 20016 thresh 1 uframes 256/512/1024 park LPM [ 1.388061] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller [ 1.388092] ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1 [ 1.388214] ehci-omap ehci-omap.0: park 0 [ 1.388214] ehci-omap ehci-omap.0: support lpm [ 1.388244] ehci-omap ehci-omap.0: irq 109, io mem 0x4a064c00 [ 1.388275] ehci-omap ehci-omap.0: reset command 0080b02 park=3 ithresh=8 period=1024 Reset HALT [ 1.388305] ehci-omap ehci-omap.0: init command 0010005 (park)=0 ithresh=1 period=512 RUN [ 1.397613] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 [ 1.397735] usb usb1: default language 0x0409 [ 1.397766] usb usb1: udev 1, busnum 1, minor = 0 [ 1.397796] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 1.397796] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 1.397796] usb usb1: Product: OMAP-EHCI Host Controller [ 1.397827] usb usb1: Manufacturer: Linux 3.2.0-omap4 ehci_hcd [ 1.397827] usb usb1: SerialNumber: ehci-omap.0 [ 1.398223] usb usb1: usb_probe_device [ 1.398254] usb usb1: configuration #1 chosen from 1 choice [ 1.398284] usb usb1: adding 1-0:1.0 (config #1, interface 0) [ 1.398406] hub 1-0:1.0: usb_probe_interface [ 1.398406] hub 1-0:1.0: usb_probe_interface - got id [ 1.398437] hub 1-0:1.0: USB hub found [ 1.398437] hub 1-0:1.0: 3 ports detected [ 1.398468] hub 1-0:1.0: standalone hub [ 1.398468] hub 1-0:1.0: individual port power switching [ 1.398468] hub 1-0:1.0: individual port over-current protection [ 1.398498] hub 1-0:1.0: power on to power good time: 20ms [ 1.398498] hub 1-0:1.0: local power source is good [ 1.398529] hub 1-0:1.0: enabling power on all ports [ 1.398712] ehci-omap ehci-omap.0: ...powerup ports... [ 1.428924] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 1.428924] ohci_hcd: block sizes: ed 64 td 64 [ 1.429046] ohci-omap3 ohci-omap3.0: OMAP3 OHCI Host Controller [ 1.429077] ohci-omap3 ohci-omap3.0: new USB bus registered, assigned bus number 2 [ 1.429077] ohci-omap3 ohci-omap3.0: starting OHCI controller [ 1.429168] ohci-omap3 ohci-omap3.0: created debug files [ 1.429199] ohci-omap3 ohci-omap3.0: irq 108, io mem 0x4a064800 [ 1.499206] ehci-omap ehci-omap.0: GetStatus port:1 status 001803 0 ACK POWER sig=j CSC CONNECT [ 1.499237] hub 1-0:1.0: port 1: status 0501 change 0001 [ 1.510986] ohci-omap3 ohci-omap3.0: OHCI controller state [ 1.510986] ohci-omap3 ohci-omap3.0: OHCI 1.0, NO legacy support registers [ 1.511016] ohci-omap3 ohci-omap3.0: control 0x283 RWC HCFS=operational CBSR=3 [ 1.511016] ohci-omap3 ohci-omap3.0: cmdstatus 0x00000 SOC=0 [ 1.511047] ohci-omap3 ohci-omap3.0: intrstatus 0x00000004 SF [ 1.511047] ohci-omap3 ohci-omap3.0: intrenable 0x8000005a MIE RHSC UE RD WDH [ 1.511077] ohci-omap3 ohci-omap3.0: hcca frame #0014 [ 1.511077] ohci-omap3 ohci-omap3.0: roothub.a 0a000203 POTPGT=10 NPS NDP=3(3) [ 1.511108] ohci-omap3 ohci-omap3.0: roothub.b 00000000 PPCM=0000 DR=0000 [ 1.511108] ohci-omap3 ohci-omap3.0: roothub.status 00008000 DRWE [ 1.511108] ohci-omap3 ohci-omap3.0: roothub.portstatus [0] 0x00000100 PPS [ 1.511138] ohci-omap3 ohci-omap3.0: roothub.portstatus [1] 0x00000100 PPS [ 1.511138] ohci-omap3 ohci-omap3.0: roothub.portstatus [2] 0x00000100 PPS [ 1.511199] usb usb2: default language 0x0409 [ 1.511230] usb usb2: udev 1, busnum 2, minor = 128 [ 1.511230] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001 [ 1.511260] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 1.511260] usb usb2: Product: OMAP3 OHCI Host Controller [ 1.511291] usb usb2: Manufacturer: Linux 3.2.0-omap4 ohci_hcd [ 1.511291] usb usb2: SerialNumber: ohci-omap3.0 [ 1.511627] usb usb2: usb_probe_device [ 1.511627] usb usb2: configuration #1 chosen from 1 choice [ 1.511657] usb usb2: adding 2-0:1.0 (config #1, interface 0) [ 1.511779] hub 2-0:1.0: usb_probe_interface [ 1.511779] hub 2-0:1.0: usb_probe_interface - got id [ 1.511779] hub 2-0:1.0: USB hub found [ 1.511810] hub 2-0:1.0: 3 ports detected [ 1.511810] hub 2-0:1.0: standalone hub [ 1.511840] hub 2-0:1.0: no power switching (usb 1.0) [ 1.511840] hub 2-0:1.0: global over-current protection [ 1.511871] hub 2-0:1.0: power on to power good time: 20ms [ 1.511871] hub 2-0:1.0: local power source is good [ 1.511901] hub 2-0:1.0: no over-current condition exists [ 1.511901] hub 2-0:1.0: trying to enable port power on non-switchable hub [ 1.512176] Initializing USB Mass Storage driver... [ 1.512329] usbcore: registered new interface driver usb-storage [ 1.512359] USB Mass Storage support registered. [ 1.512664] mousedev: PS/2 mouse device common for all mice [ 1.515930] twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0 [ 1.516174] i2c /dev entries driver [ 1.516815] Linux video capture interface: v2.00 [ 1.516845] Driver for 1-wire Dallas network protocol. [ 1.516967] 1-Wire driver for the DS2760 battery monitor chip - (c) 2004-2005, Szabolcs Gyurko [ 1.517669] OMAP Watchdog Timer Rev 0x00: initial timeout 60 sec [ 1.517822] Bluetooth: Bluetooth Driver for TI WiLink - Version 1.0 [ 1.517913] cpuidle: using governor ladder [ 1.517944] cpuidle: using governor menu [ 1.519592] _regulator_get: omap_hsmmc.0 supply vmmc_aux not found, using dummy regulator [ 1.522094] _regulator_get: omap_hsmmc.4 supply vmmc_aux not found, using dummy regulator [ 1.592010] Registered led device: pandaboard::status1 [ 1.592102] Registered led device: pandaboard::status2 [ 1.592712] omap-iommu omap-iommu.0: ducati registered [ 1.593780] ALSA device list: [ 1.593780] No soundcards found. [ 1.594940] TCP cubic registered [ 1.595581] NET: Registered protocol family 10 [ 1.598114] NET: Registered protocol family 17 [ 1.598266] lib80211: common routines for IEEE802.11 drivers [ 1.598297] lib80211_crypt: registered algorithm 'NULL' [ 1.598297] Registering the dns_resolver key type [ 1.598327] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 1 [ 1.598358] ThumbEE CPU extension supported. [ 1.598388] Registering SWP/SWPB emulation handler [ 1.600585] omap_vc_i2c_init: I2C config for all channels must match. [ 1.600616] omap_vc_i2c_init: I2C config for all channels must match. [ 1.600799] hub 1-0:1.0: state 7 ports 3 chg 0002 evt 0000 [ 1.600830] hub 1-0:1.0: port 1, status 0501, change 0000, 480 Mb/s [ 1.602111] Power Management for TI OMAP4. [ 1.602142] sr_init: No PMIC hook to init smartreflex [ 1.602294] smartreflex smartreflex.0: omap_sr_probe: SmartReflex driver initialized [ 1.602416] smartreflex smartreflex.1: omap_sr_probe: SmartReflex driver initialized [ 1.602539] smartreflex smartreflex.2: omap_sr_probe: SmartReflex driver initialized [ 1.602691] SmartReflex Class3 initialized [ 1.610168] registered taskstats version 1 [ 1.610321] omapfb omapfb: no driver for display: dvi [ 1.623474] omapdss error: timeout reading edid [ 1.629852] omap_hwmod: dss_hdmi: _wait_target_disable failed [ 1.632507] omap_hwmod: dss_dispc: _wait_target_disable failed [ 1.635131] omap_hwmod: dss_core: _wait_target_disable failed [ 1.653015] Console: switching to colour frame buffer device 80x30 [ 1.658050] omap_hwmod: dss_dispc: _wait_target_disable failed [ 1.660644] omap_hwmod: dss_core: _wait_target_disable failed [ 1.663421] ehci-omap ehci-omap.0: port 1 high speed [ 1.663452] ehci-omap ehci-omap.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT [ 1.665924] omap_hwmod: dss_dispc: _wait_target_disable failed [ 1.668548] omap_hwmod: dss_core: _wait_target_disable failed [ 1.686309] regulator_init_complete: VANA: incomplete constraints, leaving on [ 1.687469] regulator_init_complete: VDAC: incomplete constraints, leaving on [ 1.688049] regulator_init_complete: VUSB: incomplete constraints, leaving on [ 1.688873] twl_rtc twl_rtc: setting system clock to 2012-01-06 11:35:33 UTC (1325849733) [ 1.689300] Freeing init memory: 240K [ 1.725799] usb 1-1: new high-speed USB device number 2 using ehci-omap [ 1.771179] udevd[68]: starting version 173 [ 1.788543] ehci-omap ehci-omap.0: port 1 high speed [ 1.788574] ehci-omap ehci-omap.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT [ 1.882476] usb 1-1: udev 2, busnum 1, minor = 1 [ 1.882507] usb 1-1: New USB device found, idVendor=0424, idProduct=9514 [ 1.882507] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 1.882934] usb 1-1: usb_probe_device [ 1.882934] usb 1-1: configuration #1 chosen from 1 choice [ 1.883117] usb 1-1: adding 1-1:1.0 (config #1, interface 0) [ 1.883239] hub 1-1:1.0: usb_probe_interface [ 1.883270] hub 1-1:1.0: usb_probe_interface - got id [ 1.883270] hub 1-1:1.0: USB hub found [ 1.883453] hub 1-1:1.0: 5 ports detected [ 1.883453] hub 1-1:1.0: compound device; port removable status: FRRRR [ 1.883483] hub 1-1:1.0: individual port power switching [ 1.883483] hub 1-1:1.0: individual port over-current protection [ 1.883636] hub 1-1:1.0: TT per port [ 1.883666] hub 1-1:1.0: TT requires at most 8 FS bit times (666 ns) [ 1.883666] hub 1-1:1.0: power on to power good time: 100ms [ 1.883941] hub 1-1:1.0: local power source is good [ 1.883972] hub 1-1:1.0: enabling power on all ports [ 1.884674] hub 2-0:1.0: state 7 ports 3 chg 0000 evt 0000 [ 1.984588] hub 1-1:1.0: port 1: status 0101 change 0001 [ 2.085235] usb 1-1: link qh256-0001/ef2b23c0 start 1 [1/0 us] [ 2.085296] hub 1-1:1.0: state 7 ports 5 chg 0002 evt 0000 [ 2.085449] hub 1-1:1.0: port 1, status 0101, change 0000, 12 Mb/s [ 2.104522] mmc0: host does not support reading read-only switch. assuming write-enable. [ 2.106475] mmc0: new high speed SDHC card at address 0007 [ 2.107696] mmcblk0: mmc0:0007 SD08G 7.42 GiB [ 2.111999] mmcblk0: p1 p2 [ 2.171325] usb 1-1.1: new high-speed USB device number 3 using ehci-omap [ 2.291595] usb 1-1.1: udev 3, busnum 1, minor = 2 [ 2.291595] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00 [ 2.291625] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 2.291961] usb 1-1.1: usb_probe_device [ 2.291992] usb 1-1.1: configuration #1 chosen from 1 choice [ 2.294281] usb 1-1.1: adding 1-1.1:1.0 (config #1, interface 0) [ 2.294433] smsc95xx 1-1.1:1.0: usb_probe_interface [ 2.294464] smsc95xx 1-1.1:1.0: usb_probe_interface - got id [ 2.294525] smsc95xx v1.0.4 [ 2.422302] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at usb-ehci-omap.0-1.1, smsc95xx USB 2.0 Ethernet, 1a:8b: [ 2.422424] hub 1-1:1.0: state 7 ports 5 chg 0000 evt 0002 [ 2.823638] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null) [ 5.319183] udevd[223]: starting version 173 [ 6.641143] usb 1-1.1: link qh8-0001/eecde0c0 start 2 [1/0 us] [ 8.164916] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 8.581451] EXT4-fs (mmcblk0p2): re-mounted. Opts: errors=remount-ro [ 9.204528] init: failsafe main process (513) killed by TERM signal [ 10.159149] init: apport pre-start process (590) terminated with status 1 [ 10.171966] init: alsa-restore main process (601) terminated with status 19 [ 10.310028] init: apport post-stop process (630) terminated with status 1 [ 16.678833] eth0: no IPv6 routers present [ 18.239624] Adding 524240k swap on /SWAP.swap. Priority:-1 extents:11 across:571384k SS [ 616.003448] omap_hwmod: dss_hdmi: _wait_target_disable failed [ 616.006103] omap_hwmod: dss_dispc: _wait_target_disable failed [ 616.008728] omap_hwmod: dss_core: _wait_target_disable failed On Tue, Jan 10, 2012 at 12:30 AM, Ming Lei <min...@ca...> wrote: > Hi, > > On Tue, Jan 10, 2012 at 6:49 AM, Will Deacon <wil...@ar...> wrote: >> On Mon, Jan 09, 2012 at 04:39:09PM +0000, Maynard Johnson wrote: >>> On 01/08/2012 8:58 PM, Lik Lik wrote: >>> > Hi all, >> >> Hi guys [adding a bunch of people to CC because this issue is really >> annoying me now], >> >>> > I am an oprofile user and I need to profile one of my applications on a TI OMAP4 >>> > platform (pandaboard, to be specific). I have ubuntu 11.10 installed. My problem >>> > is that oprofile always use the timer interrupt mode but doesn't recognize the >>> > hardware counters, which I am sure my platform has. >> >> First and foremost, we can't currently generate PMU interrupts on OMAP4 in >> mainline. There are some additional patches required for these to work: >> >> http://marc.info/?l=linux-arm-kernel&m=131946761428296&w=2 >> >> However, as Stephane has pointed out here: >> >> http://marc.info/?l=linux-omap&m=132585784125352&w=2 >> >> the interrupts still don't seem to work, even with the patches above >> applied. >> >> Ming Lei doesn't seem to be replying to email anymore, so maybe somebody > > Sorry, I am on a trip now and no pandboard at my hand, so I may have > time to verify > the latest mainline next week after I return home. > > I remembered that last time I verified these patches on 3.2-rc2 and > 3.2-rc2 next tree, > and perf did work well on my pandaboard. > > Also seems there were reports that omap4 perf may not work on some specific > uboot version even with these patches. > >> else on linux-omap could please help us? I'm hoping that we're just missing >> some patches from somewhere, but it would be great if somebody could verify >> this (and indeed, verify that the interrupts we're registering in the thread >> above look sane). >> >>> OProfile userspace support for ARM Cortex-A9 was added by Will Deacon in June >>> 2010. This support is available in OProfile 0.9.7. According to Will's >>> posting, the kernel support was due to be added to Ubuntu Maverick, so I would >>> expect your version should support CA9 out of the box. If not already using >>> oprofile 0.9.7, please upgrade to that version and retry. If it still doesn't >>> work, please re-post with complete information (kernel version, oprofile command >>> output, and contents of /dev/oprofile/cpu_type). >> >> If with the latest OProfile, `timer mode' is still reported then you should >> check that you have CONFIG_HW_PERF_EVENTS enabled in your kernel. It still >> won't work though, because of the problems I mentioned above. > > If debug message from 'dmesg' can be provided, maybe we can find clue > about the problem. > > thanks, > -- > Ming Lei |
From: Shilimkar, S. <san...@ti...> - 2012-04-03 10:02:25
|
On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon <wil...@ar...> wrote: > On Tue, Apr 03, 2012 at 10:42:30AM +0100, Shilimkar, Santosh wrote: >> On Tue, Apr 3, 2012 at 2:55 PM, Will Deacon <wil...@ar...> wrote: >> > Did you ever get to the bottom of this? This change really is required in >> > order to generate PMU interrupts with the CTI and I don't know of any >> > alternative to the above. >> > >> > Any suggestions? >> > >> Sorry I lost track of this one. There is one relevant patch in Kevin's queue >> for 3.4/fixes. [1] which I generated for perf time stamp issue. > > Thanks, I'll take a look. > >> Can you try that patch and see if it helps the CTI issue as well ? There >> is an outside chance that it might help. If it doesn't, we should commit >> Ming Lei patch. > > It seems that they're both needed to get reliable PMU operation. Without the > CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch > below ([1]), it seems that we don't generate enough. So it looks like we > need them both. > I see. Can you please confirm if it is still the case with [1]. If yes then am nou sure how to proceed. because permanently setting EMU CD to CLKDM_CAN_SWSUP will break PM. >> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/089679.html > |
From: Will D. <wil...@ar...> - 2012-04-03 12:35:07
|
On Tue, Apr 03, 2012 at 11:01:53AM +0100, Shilimkar, Santosh wrote: > On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon <wil...@ar...> wrote: > > It seems that they're both needed to get reliable PMU operation. Without the > > CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch > > below ([1]), it seems that we don't generate enough. So it looks like we > > need them both. > > > I see. Can you please confirm if it is still the case with [1]. Right, ignore my previous comment, I was using a vanilla 3.3 kernel without realising and therefore what I thought were PMU/CTI interrupts were actually just from a timer. Sorry for the confusion. So I've gone back to basics. Here is a branch containing what I believe should be all the patches required for the OMAP4 PMU: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4 I've omitted the SWSUSP patch since you say it breaks pm, which is clearly not acceptable. The problem is, trying to boot this on my pandaboard results in a hang (see dmesg below). Even worse, the problem isn't easily bisectable since rebuilding a working image can give you something that no longer boots and I haven't found a reliable way to cause the lockup. I'll take JTAG for a whirl to see where we are. If anything looks wrong in my dmesg, please shout (there are plenty of things in there that look like they've gone awry). Will Uncompressing Linux... done, booting the kernel. [ 0.000000] Booting Linux on physical CPU 0 [ 0.000000] Linux version 3.3.0-00005-gcd122ab (will@mudshark) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3) ) #1 SMP Tue Apr 3 13:19:29 BST 2012 [ 0.000000] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine: OMAP4 Panda board [ 0.000000] bootconsole [earlycon0] enabled [ 0.000000] Memory policy: ECC disabled, Data cache writealloc [ 0.000000] OMAP4430 ES2.1 [ 0.000000] PERCPU: Embedded 8 pages/cpu @c1025000 s11072 r8192 d13504 u32768 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129792 [ 0.000000] Kernel command line: console=ttyO2,115200 root=/dev/nfs nfsroot=10.1.79.58:/exports/linaro-11.11,tcp rw earlyprintk ip=dhcp [ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes) [ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Memory: 511MB = 511MB total [ 0.000000] Memory: 506272k/506272k available, 18016k reserved, 0K highmem [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xe0800000 - 0xff000000 ( 488 MB) [ 0.000000] lowmem : 0xc0000000 - 0xe0000000 ( 512 MB) [ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB) [ 0.000000] .text : 0xc0008000 - 0xc05ebf68 (6032 kB) [ 0.000000] .init : 0xc05ec000 - 0xc0639b40 ( 311 kB) [ 0.000000] .data : 0xc063a000 - 0xc06c6d50 ( 564 kB) [ 0.000000] .bss : 0xc06c6d74 - 0xc0c1cb5c (5464 kB) [ 0.000000] Hierarchical RCU implementation. [ 0.000000] NR_IRQS:474 [ 0.000000] omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck. [ 0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz [ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [ 0.000000] Console: colour dummy device 80x30 [ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8 [ 0.000000] ... MAX_LOCK_DEPTH: 48 [ 0.000000] ... MAX_LOCKDEP_KEYS: 8191 [ 0.000000] ... CLASSHASH_SIZE: 4096 [ 0.000000] ... MAX_LOCKDEP_ENTRIES: 16384 [ 0.000000] ... MAX_LOCKDEP_CHAINS: 32768 [ 0.000000] ... CHAINHASH_SIZE: 16384 [ 0.000000] memory used by lock dependency info: 3695 kB [ 0.000000] per task-struct memory footprint: 1152 bytes [ 0.056579] Calibrating delay loop... 2007.19 BogoMIPS (lpj=7839744) [ 0.129791] pid_max: default: 32768 minimum: 301 [ 0.135192] Security Framework initialized [ 0.139678] Mount-cache hash table entries: 512 [ 0.147979] CPU: Testing write buffer coherency: ok [ 0.153961] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.160278] hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available [ 0.168853] Setting up static identity map for 0x8043ce60 - 0x8043ced0 [ 0.175689] L310 cache controller enabled [ 0.179931] l2x0: 16 ways, CACHE_ID 0x410000c4, AUX_CTRL 0x7e470000, Cache size: 1048576 B [ 0.190856] CPU1: Booted secondary processor [ 0.254028] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.254058] CPU1: Unknown IPI message 0x1 [ 0.254180] Brought up 2 CPUs [ 0.254180] SMP: Total of 2 processors activated (4022.78 BogoMIPS). [ 0.286102] omap_hwmod: trace_clk_div_ck: missing clockdomain for trace_clk_div_ck. [ 0.294067] omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck. [ 0.303955] omap_hwmod: l3_instr: _wait_target_disable failed [ 0.322052] omap_hwmod: debugss: softreset failed (waited 10000 usec) [ 0.332824] omap_hwmod: mcpdm: cannot be enabled (3) [ 0.342315] print_constraints: dummy: [ 0.347137] NET: Registered protocol family 16 [ 0.352264] GPMC revision 6.0 [ 0.360229] gpiochip_add: registered GPIOs 0 to 31 on device: gpio [ 0.366912] OMAP GPIO hardware version 0.1 [ 0.371612] gpiochip_add: registered GPIOs 32 to 63 on device: gpio [ 0.378662] gpiochip_add: registered GPIOs 64 to 95 on device: gpio [ 0.385772] gpiochip_add: registered GPIOs 96 to 127 on device: gpio [ 0.392913] gpiochip_add: registered GPIOs 128 to 159 on device: gpio [ 0.400177] gpiochip_add: registered GPIOs 160 to 191 on device: gpio [ 0.410064] omap_mux_init: Add partition: #1: core, flags: 2 [ 0.417327] omap_mux_init: Add partition: #2: wkup, flags: 2 [ 0.423339] error setting wl12xx data: -38 [ 0.430267] _omap_mux_get_by_name: Could not find signal uart1_cts.uart1_cts [ 0.437622] _omap_mux_get_by_name: Could not find signal uart1_cts.uart1_cts [ 0.444946] omap_hwmod_mux_init: Could not allocate device mux entry [ 0.455047] usbhs_omap: alias fck already exists [ 0.463409] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers. [ 0.471710] hw-breakpoint: maximum watchpoint size is 4 bytes. <hangs here. Would usually print something about "OMAP DMA" next> |
From: Shilimkar, S. <san...@ti...> - 2012-04-03 12:41:55
|
On Tue, Apr 3, 2012 at 6:04 PM, Will Deacon <wil...@ar...> wrote: > On Tue, Apr 03, 2012 at 11:01:53AM +0100, Shilimkar, Santosh wrote: >> On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon <wil...@ar...> wrote: >> > It seems that they're both needed to get reliable PMU operation. Without the >> > CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch >> > below ([1]), it seems that we don't generate enough. So it looks like we >> > need them both. >> > >> I see. Can you please confirm if it is still the case with [1]. > > Right, ignore my previous comment, I was using a vanilla 3.3 kernel without > realising and therefore what I thought were PMU/CTI interrupts were actually > just from a timer. Sorry for the confusion. > > So I've gone back to basics. Here is a branch containing what I believe > should be all the patches required for the OMAP4 PMU: > > git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4 > > I've omitted the SWSUSP patch since you say it breaks pm, which is clearly not > acceptable. > > The problem is, trying to boot this on my pandaboard results in a hang (see > dmesg below). Even worse, the problem isn't easily bisectable since rebuilding > a working image can give you something that no longer boots and I haven't found > a reliable way to cause the lockup. > > I'll take JTAG for a whirl to see where we are. If anything looks wrong in > my dmesg, please shout (there are plenty of things in there that look like > they've gone awry). > I don't see anything abnormal in below boot log. Not sure why it hands around there. Regards Santosh |
From: Ming L. <min...@ca...> - 2012-01-18 04:18:52
|
Hi stephane & Will, On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian <er...@go...> wrote: > See the dmesg from my 3.2 kernel: > > > [ 0.000000] Booting Linux on physical CPU 0[ 0.000000] Looks no obvious failure can be found from your 'dmesg'. I have run upstream 3.2 kernel plus 6 omap4 pmu patches below and found perf can work well on my panda board. 0001-arm-introduce-cross-trigger-interface-helpers.patch 0002-arm-pmu-allow-platform-specific-irq-enable-disable-h.patch 0003-arm-omap4-hwmod-introduce-emu-hwmod.patch or Benoit's debugss patch[2] 0004-arm-omap4-create-pmu-device-via-hwmod.patch[3] 0005-arm-omap4-support-pmu.patch[4] 0006-arm-omap4-pmu-support-runtime-pm.patch[5] Could you verify the above patches on 3.2 to see if perf can work well? If it doesn't, I may share my u-boot and mlo for your test if you'd like to do. BTW: #1 and #2 have been in Will's -next tree. thanks, -- Ming Lei [1], uname -a & cat /proc/interrupts [root@root]#uname -a Linux beagleboard 3.2.0+ #480 SMP PREEMPT Wed Jan 18 11:38:33 CST 2012 armv7l GNU/Linux [root@root]#cat /proc/interrupts CPU0 CPU1 29: 29014 17353 GIC twd 33: 56231 0 GIC arm-pmu 34: 0 25778 GIC arm-pmu [2], http://marc.info/?l=linux-omap&m=132162118104901&w=2 [3],http://marc.info/?t=132227621500002&r=1&w=2 [4],http://marc.info/?t=132227621700002&r=1&w=2 [5],http://marc.info/?t=132227621700003&r=1&w=2 |
From: stephane e. <er...@go...> - 2012-01-18 09:54:53
|
On Wed, Jan 18, 2012 at 5:18 AM, Ming Lei <min...@ca...> wrote: > Hi stephane & Will, > > On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian > <er...@go...> wrote: >> See the dmesg from my 3.2 kernel: >> >> >> [ 0.000000] Booting Linux on physical CPU 0[ 0.000000] > > Looks no obvious failure can be found from your 'dmesg'. > > I have run upstream 3.2 kernel plus 6 omap4 pmu patches below and > found perf can work well on my panda board. > > 0001-arm-introduce-cross-trigger-interface-helpers.patch > 0002-arm-pmu-allow-platform-specific-irq-enable-disable-h.patch > 0003-arm-omap4-hwmod-introduce-emu-hwmod.patch or Benoit's debugss patch[2] > 0004-arm-omap4-create-pmu-device-via-hwmod.patch[3] > 0005-arm-omap4-support-pmu.patch[4] > 0006-arm-omap4-pmu-support-runtime-pm.patch[5] > > Could you verify the above patches on 3.2 to see if perf can work well? > If it doesn't, I may share my u-boot and mlo for your test if you'd like to do. > > BTW: #1 and #2 have been in Will's -next tree. > Should I use Will's -next tree as the base instead of Linus'? Given that MARC is shutdown today, would you mind packing those patches into a tarball and sending them to me directly? When you mention Will's -next tree, are you talking about: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf Thanks. > thanks, > -- > Ming Lei > > [1], uname -a & cat /proc/interrupts > [root@root]#uname -a > Linux beagleboard 3.2.0+ #480 SMP PREEMPT Wed Jan 18 11:38:33 CST 2012 > armv7l GNU/Linux > [root@root]#cat /proc/interrupts > CPU0 CPU1 > 29: 29014 17353 GIC twd > 33: 56231 0 GIC arm-pmu > 34: 0 25778 GIC arm-pmu > > [2], http://marc.info/?l=linux-omap&m=132162118104901&w=2 > [3],http://marc.info/?t=132227621500002&r=1&w=2 > [4],http://marc.info/?t=132227621700002&r=1&w=2 > [5],http://marc.info/?t=132227621700003&r=1&w=2 |
From: Russell K. - A. L. <li...@ar...> - 2012-01-18 10:19:31
|
On Wed, Jan 18, 2012 at 10:54:46AM +0100, stephane eranian wrote: > Should I use Will's -next tree as the base instead of Linus'? > Given that MARC is shutdown today, would you mind packing those patches > into a tarball and sending them to me directly? Other archive sites are available. There's my lurker-based archive on the old list server, and there's pipermail on the current list server to name two. |
From: Ming L. <min...@ca...> - 2012-01-18 10:07:21
Attachments:
omap4_pmu.tar.gz
|
Hi, On Wed, Jan 18, 2012 at 5:54 PM, stephane eranian <er...@go...> > Should I use Will's -next tree as the base instead of Linus'? Either one is OK. If you use linus tree as base, you need to apply the #1 and #2 patch manually. > Given that MARC is shutdown today, would you mind packing those patches > into a tarball and sending them to me directly? See attachment, which includes the patches from #3 to #6. > > When you mention Will's -next tree, are you talking about: > git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-next/perf It is perf/omap4 brach, you can pick up the two patches[1][2] directly from the branch. thanks, -- Ming Lei [1], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=7924a3eba0766348d6d6a56cbb9873cdbcab0d8c [2], http://git.kernel.org/?p=linux/kernel/git/will/linux.git;a=commit;h=bde071f005e2dc71378aff69e86b961d8cd7922f |
From: Ming L. <min...@ca...> - 2012-01-18 09:33:37
|
Hi Will and stephane, On Wed, Jan 18, 2012 at 12:18 PM, Ming Lei <min...@ca...> wrote: > Hi stephane & Will, > > On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian > <er...@go...> wrote: >> See the dmesg from my 3.2 kernel: >> >> >> [ 0.000000] Booting Linux on physical CPU 0[ 0.000000] But if you test omap4 perf against -next kernel, pmu won't work because the commit[1] may put 'emu_sys_clkdm' clock domain into HW_AUTO mode, so writing pmu register may not take effect. I have found the similar problem on cam clock domain before[2]. CD_EMU is very simliar with CD_CAM in the point below: CD_EMU has no static or module wake-up dependency with any other clock domain of the device.[3] So the patch[4] can make omap4 pmu work on -next tree. Shilimkar, care to comment on the patch[4]? thanks, -- Ming Lei [1], commit 3c50729b3fa1cd8ca1f347e6caf1081204cf1a7c Author: Santosh Shilimkar <san...@ti...> Date: Wed Jan 5 22:03:17 2011 +0530 ARM: OMAP4: PM: Initialise all the clockdomains to supported states Initialise hardware supervised mode for all clockdomains if it's supported. Initiate sleep transition for other clockdomains, if they are not being used. [2], http://www.spinics.net/lists/linux-omap/msg61911.html [3], 3.6.12.3 of OMAP4 TRM [4], diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c b/arch/arm/mach-omap2/clockdomains44xx_data.c index 9299ac2..41d2260 100644 --- a/arch/arm/mach-omap2/clockdomains44xx_data.c +++ b/arch/arm/mach-omap2/clockdomains44xx_data.c @@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = { .prcm_partition = OMAP4430_PRM_PARTITION, .cm_inst = OMAP4430_PRM_EMU_CM_INST, .clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS, - .flags = CLKDM_CAN_HWSUP, + .flags = CLKDM_CAN_SWSUP, }; static struct clockdomain l3_dma_44xx_clkdm = { |
From: Kevin H. <kh...@ti...> - 2012-04-03 14:28:06
|
Hi Will, Will Deacon <wil...@ar...> writes: > On Tue, Apr 03, 2012 at 11:01:53AM +0100, Shilimkar, Santosh wrote: >> On Tue, Apr 3, 2012 at 3:17 PM, Will Deacon <wil...@ar...> wrote: >> > It seems that they're both needed to get reliable PMU operation. Without the >> > CLKDM_CAN_SWSUP fix, no interrupts are generated at all. Without the patch >> > below ([1]), it seems that we don't generate enough. So it looks like we >> > need them both. >> > >> I see. Can you please confirm if it is still the case with [1]. > > Right, ignore my previous comment, I was using a vanilla 3.3 kernel without > realising and therefore what I thought were PMU/CTI interrupts were actually > just from a timer. Sorry for the confusion. > > So I've gone back to basics. Here is a branch containing what I believe > should be all the patches required for the OMAP4 PMU: > > git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4 > > I've omitted the SWSUSP patch since you say it breaks pm, which is clearly not > acceptable. > > The problem is, trying to boot this on my pandaboard results in a hang (see > dmesg below). Even worse, the problem isn't easily bisectable since rebuilding > a working image can give you something that no longer boots and I haven't found > a reliable way to cause the lockup. > > I'll take JTAG for a whirl to see where we are. If anything looks wrong in > my dmesg, please shout (there are plenty of things in there that look like > they've gone awry). Not sure why it hangs for you, but it worked for me both with your branch on v3.3 and merging with v3.4-rc1[1] Below is a Kconfig snippet[2] which I append to my .config after building omap2plus_defconfig in order to build a perf/trace/PMU enabled kernel for my Panda. Kevin [1] # perf stat sleep 1 Performance counter stats for 'sleep 1': 9.582520 task-clock # 0.009 CPUs utilized 1 context-switches # 0.104 K/sec 0 CPU-migrations # 0.000 K/sec 147 page-faults # 0.015 M/sec 5096283 cycles # 0.532 GHz 607876 stalled-cycles-frontend # 11.93% frontend cycles idle 3285045 stalled-cycles-backend # 64.46% backend cycles idle 2722485 instructions # 0.53 insns per cycle # 1.21 stalled cycles per insn 259247 branches # 27.054 M/sec 84274 branch-misses # 32.51% of all branches 1.015919088 seconds time elapsed [2] CONFIG_ARCH_OMAP2=n CONFIG_ARCH_OMAP3=n # need to disable OMAP3 for CPU_HAS_PMU support, needed for perf on OMAP4 CONFIG_USB_EHCI_HCD=y CONFIG_USB_NET_SMSC95XX=y CONFIG_PROFILING=y CONFIG_HW_PERF_EVENTS=y CONFIG_PERF_EVENTS=y CONFIG_PERF_COUNTERS=y CONFIG_TRACEPOINTS=y CONFIG_TRACING=y CONFIG_GENERIC_TRACER=y CONFIG_FTRACE=y CONFIG_FUNCTION_TRACER=y CONFIG_ENABLE_DEFAULT_TRACERS=y CONFIG_STACK_TRACER=y CONFIG_SCHED_TRACER=y CONFIG_EVENT_POWER_TRACING_DEPRECATED=n |
From: Will D. <wil...@ar...> - 2012-04-03 16:07:28
|
On Tue, Apr 03, 2012 at 03:27:52PM +0100, Kevin Hilman wrote: > Hi Will, Hi Kevin, > Will Deacon <wil...@ar...> writes: > > The problem is, trying to boot this on my pandaboard results in a hang (see > > dmesg below). Even worse, the problem isn't easily bisectable since rebuilding > > a working image can give you something that no longer boots and I haven't found > > a reliable way to cause the lockup. > > > > I'll take JTAG for a whirl to see where we are. If anything looks wrong in > > my dmesg, please shout (there are plenty of things in there that look like > > they've gone awry). > > Not sure why it hangs for you, but it worked for me both with your > branch on v3.3 and merging with v3.4-rc1[1] Thanks for testing that. It turns out that updating my x-loader (it was pretty ancient) fixed the boot hang, though I'm not sure I want to know why! > # perf stat sleep 1 > > Performance counter stats for 'sleep 1': > > 9.582520 task-clock # 0.009 CPUs utilized > 1 context-switches # 0.104 K/sec > 0 CPU-migrations # 0.000 K/sec > 147 page-faults # 0.015 M/sec > 5096283 cycles # 0.532 GHz > 607876 stalled-cycles-frontend # 11.93% frontend cycles idle > 3285045 stalled-cycles-backend # 64.46% backend cycles idle > 2722485 instructions # 0.53 insns per cycle > # 1.21 stalled cycles per insn > 259247 branches # 27.054 M/sec > 84274 branch-misses # 32.51% of all branches Right. Can you confirm whether the PMU/CTI interrupts fire for you please? Just run perf top and look at /proc/interrupts while it's running. You should see a couple of arm-pmu entries in there and hopefully numbers > 0. For me, my earlier mis-diagnosis has turned out to be true and I can only see PMU interrupts if I apply the SWSUSP patch, which Santosh says will break pm. Cheers, Will |
From: Kevin H. <kh...@ti...> - 2012-04-03 23:14:27
|
Will Deacon <wil...@ar...> writes: [...] > Right. Can you confirm whether the PMU/CTI interrupts fire for you please? > Just run perf top and look at /proc/interrupts while it's running. You > should see a couple of arm-pmu entries in there and hopefully numbers > 0. Ah, I see now (I'm a perf newbie.) Indeed, like you, I have to change the EMU clock domain to SWSUP[1] in order to see any interrupts and see anything in perf top. This isn't really a mergeable workaround, so I'll look into this a little closer with Santosh to see what we can do once we fully understand the HW problem. Kevin [1] diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c b/arch/arm/mach-omap2/clockdomains44xx_data.c index 9299ac2..41d2260 100644 --- a/arch/arm/mach-omap2/clockdomains44xx_data.c +++ b/arch/arm/mach-omap2/clockdomains44xx_data.c @@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = { .prcm_partition = OMAP4430_PRM_PARTITION, .cm_inst = OMAP4430_PRM_EMU_CM_INST, .clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS, - .flags = CLKDM_CAN_HWSUP, + .flags = CLKDM_CAN_SWSUP, }; |
From: Paul W. <pa...@pw...> - 2012-04-04 00:00:59
|
On Tue, 3 Apr 2012, Will Deacon wrote: > I'll take JTAG for a whirl to see where we are. If anything looks wrong in > my dmesg, please shout (there are plenty of things in there that look like > they've gone awry). Might be worth booting with initcall_debug on the kernel command line. That will probably be easier than dealing with JTAG. - Paul |
From: Will D. <wil...@ar...> - 2012-04-04 11:07:31
|
Hi Paul, On Wed, Apr 04, 2012 at 01:00:53AM +0100, Paul Walmsley wrote: > On Tue, 3 Apr 2012, Will Deacon wrote: > > > I'll take JTAG for a whirl to see where we are. If anything looks wrong in > > my dmesg, please shout (there are plenty of things in there that look like > > they've gone awry). > > Might be worth booting with initcall_debug on the kernel command line. > That will probably be easier than dealing with JTAG. JTAG is unusable anyway because it requires a new MLO, which makes the problem disappear. Using initcall_debug I tracked the hang down to cti_unlock: val = __raw_readl(base + LOCKSTATUS); causes the board to die, presumably because CoreSight isn't in a fit state to be poked. Will |
From: Shilimkar, S. <san...@ti...> - 2012-01-18 12:09:44
|
On Wed, Jan 18, 2012 at 10:33 AM, Ming Lei <min...@ca...> wrote: > Hi Will and stephane, > > On Wed, Jan 18, 2012 at 12:18 PM, Ming Lei <min...@ca...> wrote: >> Hi stephane & Will, >> >> On Tue, Jan 10, 2012 at 8:46 AM, stephane eranian >> <er...@go...> wrote: >>> See the dmesg from my 3.2 kernel: >>> >>> >>> [ 0.000000] Booting Linux on physical CPU 0[ 0.000000] > > But if you test omap4 perf against -next kernel, pmu won't work because > the commit[1] may put 'emu_sys_clkdm' clock domain into HW_AUTO mode, > so writing pmu register may not take effect. > > I have found the similar problem on cam clock domain before[2]. > CD_EMU is very simliar with CD_CAM in the point below: > > CD_EMU has no static or module wake-up dependency with any other clock > domain of the device.[3] > > So the patch[4] can make omap4 pmu work on -next tree. > > Shilimkar, care to comment on the patch[4]? > > thanks, > -- > Ming Lei > > [1], commit 3c50729b3fa1cd8ca1f347e6caf1081204cf1a7c > Author: Santosh Shilimkar <san...@ti...> > Date: Wed Jan 5 22:03:17 2011 +0530 > > ARM: OMAP4: PM: Initialise all the clockdomains to supported states > > Initialise hardware supervised mode for all clockdomains if it's > supported. Initiate sleep transition for other clockdomains, > if they are not being used. > > [2], http://www.spinics.net/lists/linux-omap/msg61911.html > > [3], 3.6.12.3 of OMAP4 TRM > > [4], > diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c > b/arch/arm/mach-omap2/clockdomains44xx_data.c > index 9299ac2..41d2260 100644 > --- a/arch/arm/mach-omap2/clockdomains44xx_data.c > +++ b/arch/arm/mach-omap2/clockdomains44xx_data.c > @@ -390,7 +390,7 @@ static struct clockdomain emu_sys_44xx_clkdm = { > .prcm_partition = OMAP4430_PRM_PARTITION, > .cm_inst = OMAP4430_PRM_EMU_CM_INST, > .clkdm_offs = OMAP4430_PRM_EMU_CM_EMU_CDOFFS, > - .flags = CLKDM_CAN_HWSUP, > + .flags = CLKDM_CAN_SWSUP, > }; NAK. You don't need this patch. What you saw on CAMERA was indeed a known bug but emulation domain has no such issues. So the accesses to emulation register should continue to work with the clock-domain being kept under hardware supervision. Regards Santosh |