public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@ti.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: "Premi, Sanjeev" <premi@ti.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation
Date: Fri, 24 Jun 2011 13:14:10 -0700	[thread overview]
Message-ID: <87mxh70yy5.fsf@ti.com> (raw)
In-Reply-To: <20110624185107.GP9449@n2100.arm.linux.org.uk> (Russell King's message of "Fri, 24 Jun 2011 19:51:07 +0100")

Russell King - ARM Linux <linux@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@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



  reply	other threads:[~2011-06-24 20:14 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
2011-06-24 20:14             ` Kevin Hilman [this message]
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=87mxh70yy5.fsf@ti.com \
    --to=khilman@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=premi@ti.com \
    /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