> -----Original Message----- > From: Hilman, Kevin > Sent: Saturday, June 25, 2011 1:44 AM > To: Russell King - ARM Linux > Cc: Premi, Sanjeev; linux-omap@xxxxxxxxxxxxxxx; > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCHv2] omap2+: pm: cpufreq: Fix > loops_per_jiffy calculation > > Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> writes: > > > On Fri, Jun 24, 2011 at 11:20:44PM +0530, Premi, Sanjeev wrote: > >> I was able to test BogoMIPS calculations via /proc/cpuinfo for > >> both with & without CONFIG_SMP selected. > >> > >> For most part things work fine - but I do notice occassional Oops > >> and segmentation faults while doing "cat /proc/cpuinfo" > >> > >> With CONFIG_SMP enabled, system doesn't recover from the Oops; > >> but without SMP - I noticed segmentation faults/ BUG but system > >> does recover. > >> > >> They could be unrelated - but i didn't see any of these earlier > >> today. I will continue debug on MON. > > > > I don't think these are related to the patch - I think > there's something > > up with your hardware. > > > > Let's take the first. > > > >> [root@OMAP3EVM cpufreq]# cat /proc/cpuinfo > >> [ 73.832366] Internal error: Oops - undefined > instruction: 0 [#1] SMP > > > > Ok an undefined instruction. So... > > > >> [ 73.839019] Modules linked in: > >> [ 73.842193] CPU: 0 Not tainted > (3.0.0-rc3-14002-g40b6752-dirty #21) > >> [ 73.849121] PC is at __do_fault+0x1c0/0x450 > >> [ 73.853485] LR is at __do_fault+0x2b0/0x450 > >> [ 73.857879] pc : [<c010fa18>] lr : [<c010fb08>] > psr: 00000113 > >> [ 73.857879] sp : c7907d48 ip : 00000000 fp : c5d518c0 > >> [ 73.869873] r10: 00000200 r9 : 40214000 r8 : 00000000 > >> [ 73.875335] r7 : c2692f98 r6 : c0ad7600 r5 : 87fb018f > r4 : 00000000 > >> [ 73.882141] r3 : 87fb0a3e r2 : 00000800 r1 : 87fb01cf > r0 : c5d518c0 > >> [ 73.888977] Flags: nzcv IRQs on FIQs on Mode SVC_32 > ISA ARM Segment user > >> [ 73.896423] Control: 10c5387d Table: 8795c019 DAC: 00000015 > >> [ 73.902435] Process cat (pid: 449, stack limit = 0xc79062f8) > > > > ... lets look at the code line: > > > >> [ 74.176879] Code: e1a01005 e3a02000 ebfd1694 e59d0014 (eb07fcba) > > > > and disassemble it: > > > > 0: e1a01005 mov r1, r5 > > 4: e3a02000 mov r2, #0 ; 0x0 > > 8: ebfd1694 bl 0xfff45a60 > > c: e59d0014 ldr r0, [sp, #20] > > 10: eb07fcba bl 0x1ff300 > > > > There is no way that 0xeb07fcba should ever cause an undefined ARM > > instruction on a properly functioning system. > > > > It points at a hardware problem - are you using a socketed SoC? Is > > it properly socketed? Is the socket dirty? And all other questions > > related to hardware integrity... > > And in particular, since we're talking CPUfreq, are you running at a > frequency that the SoC and especially the memory support? Yes. the frequencies are 300 - 800MHz range. The same board is also quite stable for 1GHz operations (tested ARM only) - with sources hosted at: http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary For testing, I was changing frequencies in a tight 'forever' loop. But, as I mentioned earlier that issues could be unrelated. And the loop could be exposing something else. ~sanjeev > > Kevin > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
