From: Tony Lindgren <tony@atomide.com>
To: Piotr Haber <phaber@broadcom.com>,
Mike Turquette <mturquette@linaro.org>,
Paul Walmsley <paul@pwsan.com>, Rajendra Nayak <rnayak@ti.com>
Cc: linux-omap@vger.kernel.org
Subject: Re: 3.8 -> 3.9-rc1 upgrade: old configs broken
Date: Wed, 6 Mar 2013 12:33:32 -0800 [thread overview]
Message-ID: <20130306203332.GR11806@atomide.com> (raw)
In-Reply-To: <51376E2F.9090005@broadcom.com>
Hi,
Adding Mike, Paul and Rajendra.
* Piotr Haber <phaber@broadcom.com> [130306 08:30]:
>
> I run into same problem, 3.9-rc1 builds fail to boot on mu panda
> have all the things mentioned above in my .config
...
Hmm this seems to be related to the recent generic clock conversion
and CONFIG_DEBUG_SLAB=y in your .config that exposes the bug.
I get this with DEBUG_LL and earlyprintk enabled:
[ 0.000000] Kernel BUG at c01174f8 [verbose debug info unavailable]
[ 0.000000] Internal error: Oops - BUG: 0 [#1] SMP ARM
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 Not tainted (3.9.0-rc1-12179-g72d48f9 #6)
[ 0.000000] PC is at __kmalloc+0x1d4/0x248
[ 0.000000] LR is at __clk_init+0x2e0/0x364
[ 0.000000] pc : [<c01174f8>] lr : [<c0441f54>] psr: 600001d3
[ 0.000000] sp : c076ff28 ip : c065cefc fp : c0441f54
[ 0.000000] r10: 0000001c r9 : 000080d0 r8 : c076ffd4
[ 0.000000] r7 : c074b578 r6 : c0794d88 r5 : 00000040 r4 : 00000000
[ 0.000000] r3 : 00000000 r2 : c07cac70 r1 : 000080d0 r0 : 0000001c
[ 0.000000] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel
[ 0.000000] Control: 10c53c7d Table: 8000404a DAC: 00000017
[ 0.000000] Process swapper (pid: 0, stack limit = 0xc076e240)
[ 0.000000] Stack: (0xc076ff28 to 0xc0770000)
[ 0.000000] ff20: 22222222 c0794ec8 c06546e8 00000000 00000040 c0794d88
[ 0.000000] ff40: c074b578 c076ffd4 c07951c8 c076e000 00000000 c0441f54 c074b578 c076ffd4
[ 0.000000] ff60: c0793828 00000040 c0794d88 c074b578 c076ffd4 c0776900 c076e000 c07272ac
[ 0.000000] ff80: 2f800000 c074c968 c07f93d0 c0719780 c076ffa0 c076ff98 00000000 00000000
[ 0.000000] ffa0: 00000000 00000000 00000000 00000001 c074cd6c c077b1ec 8000406a c0715724
[ 0.000000] ffc0: 00000000 00000000 00000000 00000000 00000000 c074c968 10c53c7d c0776974
[ 0.000000] ffe0: c074cd6c c077b1ec 8000406a 411fc092 00000000 80008074 00000000 00000000
[ 0.000000] [<c01174f8>] (__kmalloc+0x1d4/0x248) from [<c0441f54>] (__clk_init+0x2e0/0x364)
[ 0.000000] [<c0441f54>] (__clk_init+0x2e0/0x364) from [<c07272ac>] (omap4xxx_clk_init+0xbc/0x140)
[ 0.000000] [<c07272ac>] (omap4xxx_clk_init+0xbc/0x140) from [<c0719780>] (setup_arch+0x15c/0x284)
[ 0.000000] [<c0719780>] (setup_arch+0x15c/0x284) from [<c0715724>] (start_kernel+0x7c/0x334)
[ 0.000000] [<c0715724>] (start_kernel+0x7c/0x334) from [<80008074>] (0x80008074)
[ 0.000000] Code: e5883004 e1a00006 e28dd00c e8bd8ff0 (e7f001f2)
[ 0.000000] ---[ end trace 1b75b31a2719ed1c ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
So basically what's going is that __clk_init() calls kzalloc() before
kmem_cache_init() is done. This happens the first time for sys_clkin_ck
where we do have clk->num_parents.
With CONFIG_DEBUG_SLAB we actually get an error in __find_general_cachep()
as generic caches are not yet initialized.
It seems that in the omap case we need to statically allocate clk->parents
to fix this. I believe we now are overwriting parent clocks..
Regards,
Tony
next prev parent reply other threads:[~2013-03-06 20:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-06 16:26 3.8 -> 3.9-rc1 upgrade: old configs broken Piotr Haber
2013-03-06 20:33 ` Tony Lindgren [this message]
2013-03-08 4:12 ` Rajendra Nayak
-- strict thread matches above, loose matches on Subject: below --
2013-03-04 23:22 Aaro Koskinen
2013-03-05 0:35 ` Tony Lindgren
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=20130306203332.GR11806@atomide.com \
--to=tony@atomide.com \
--cc=linux-omap@vger.kernel.org \
--cc=mturquette@linaro.org \
--cc=paul@pwsan.com \
--cc=phaber@broadcom.com \
--cc=rnayak@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.