From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation
Date: Fri, 24 Jun 2011 19:51:07 +0100 [thread overview]
Message-ID: <20110624185107.GP9449@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024D6C2F56@dbde02.ent.ti.com>
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...
next prev parent reply other threads:[~2011-06-24 18:51 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-24 13:53 [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation Sanjeev Premi
2011-06-24 13:59 ` Premi, Sanjeev
2011-06-24 14:01 ` Russell King - ARM Linux
2011-06-24 14:09 ` Premi, Sanjeev
2011-06-24 14:14 ` Russell King - ARM Linux
2011-06-24 15:12 ` Russell King - ARM Linux
2011-06-24 15:34 ` Premi, Sanjeev
2011-06-24 17:50 ` Premi, Sanjeev
2011-06-24 18:51 ` Russell King - ARM Linux [this message]
2011-06-24 20:14 ` Kevin Hilman
2011-06-25 16:20 ` Premi, Sanjeev
2011-06-24 18:48 ` Santosh Shilimkar
2011-06-25 18:53 ` Premi, Sanjeev
2011-06-25 19:09 ` Russell King - ARM Linux
2011-06-27 4:54 ` Premi, Sanjeev
2011-06-27 7:40 ` Russell King - ARM Linux
2011-06-24 14:35 ` Santosh Shilimkar
2011-06-24 14:40 ` Premi, Sanjeev
2011-06-24 14:47 ` Santosh Shilimkar
2011-06-28 22:29 ` Colin Cross
2011-06-28 22:45 ` Santosh Shilimkar
2011-06-28 22:56 ` Colin Cross
[not found] ` <CAMbhsRRctHC2wSi7cWjO2Fn_rM7=dMtTrt6PbsVehrgx9SKwzw@mail.gmail.com>
2011-06-28 23:00 ` Santosh Shilimkar
2011-06-28 23:04 ` Santosh Shilimkar
2011-06-28 23:03 ` Russell King - ARM Linux
2011-06-28 23:07 ` Santosh Shilimkar
2011-06-28 22:55 ` Russell King - ARM Linux
2011-06-28 22:58 ` Colin Cross
2011-06-28 23:17 ` Russell King - ARM Linux
2011-06-28 23:37 ` Colin Cross
2011-06-28 23:46 ` Russell King - ARM Linux
2011-06-28 23:59 ` Colin Cross
2011-06-29 14:00 ` Russell King - ARM Linux
2011-06-29 16:57 ` Colin Cross
2011-06-29 18:29 ` Stephen Boyd
2011-06-29 18:43 ` Russell King - ARM Linux
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110624185107.GP9449@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).