[PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation
Kevin Hilman
khilman at ti.com
Fri Jun 24 16:14:10 EDT 2011
Russell King - ARM Linux <linux at arm.linux.org.uk> 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 at 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?
Kevin
More information about the linux-arm-kernel
mailing list