From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Khem Raj <raj.khem@gmail.com>
Cc: "yocto@yoctoproject.org \(yocto@yoctoproject.org\)"
<yocto@yoctoproject.org>,
"<openembedded-core@lists.openembedded.org> oe-core layer"
<Openembedded-core@lists.openembedded.org>
Subject: Re: Fix for kernel 3.8/gcc-4.8 segfault on qemuarm
Date: Mon, 17 Jun 2013 23:32:56 -0400 [thread overview]
Message-ID: <51BFD4E8.3020901@windriver.com> (raw)
In-Reply-To: <A6E8629E-ED47-4DD7-8C53-B0D467BADA39@gmail.com>
On 13-06-17 11:30 PM, Khem Raj wrote:
> Hi Bruce and All
>
> Finally after a long innings I have diagnosed the mystery behind the below segfault that we see on kernel 3.8 which compiled with gcc 4.8 but don't show when compiled with gcc 4.7
>
>
> Unable to handle kernel paging request at virtual address ffffffff
> pgd = c0004000
> [ffffffff] *pgd=07ffe831, *pte=00000000, *ppte=00000000
> Internal error: Oops: 17 [#1] PREEMPT ARM
> Modules linked in:
> CPU: 0 Not tainted (3.8.0-yocto-standard+ #32)
> PC is at kmem_cache_alloc+0x38/0x154
> LR is at subsys_system_register+0x34/0xd8
> pc : [<c00bd4d8>] lr : [<c0327244>] psr: a0000153
> sp : c7835ef0 ip : c7904590 fp : 00000000
> r10: c0688dc4 r9 : c06db900 r8 : c0327244
> r7 : 00000000 r6 : 000080d0 r5 : c7801380 r4 : ffffffff
> r3 : 00000000 r2 : 00000078 r1 : 000080d0 r0 : c7801380
> Flags: NzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel
> Control: 00093177 Table: 00004000 DAC: 00000017
> Process swapper (pid: 1, stack limit = 0xc78341b8)
> Stack: (0xc7835ef0 to 0xc7836000)
> 5ee0: c06a5564 c06b8b8c c7834028 00000000
> 5f00: c0680218 c0327244 c7835f28 c06a5564 00000006 c7834028 c06db900 c0688dd4
> 5f20: c7835f28 c00089a0 c0657f44 00000006 c086e561 00000006 00000000 c06a5534
> 5f40: c06a5564 00000006 c06db900 c0680218 c069fd68 0000008e c069fd5c c0680924
> 5f60: 00000006 00000006 c0680218 00000000 00000000 00000000 00000000 00000000
> 5f80: c04f5e68 00000000 00000000 00000000 00000000 00000000 00000000 c04f5e70
> 5fa0: 00000000 00000000 c04f5e68 c000deb0 00000000 00000000 00000000 00000000
> 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [<c00bd4d8>] (kmem_cache_alloc+0x38/0x154) from [<c0327244>] (subsys_system_register+0x34/0xd8)
> [<c0327244>] (subsys_system_register+0x34/0xd8) from [<c0688dd4>] (init_clocksource_sysfs+0x10/0x54)
> [<c0688dd4>] (init_clocksource_sysfs+0x10/0x54) from [<c00089a0>] (do_one_initcall+0x10c/0x17c)
> [<c00089a0>] (do_one_initcall+0x10c/0x17c) from [<c0680924>] (kernel_init_freeable+0x164/0x224)
> [<c0680924>] (kernel_init_freeable+0x164/0x224) from [<c04f5e70>] (kernel_init+0x8/0x150)
> [<c04f5e70>] (kernel_init+0x8/0x150) from [<c000deb0>] (ret_from_fork+0x14/0x24)
> Code: e5934000 e3540000 0a00001a e5953014 (e7941003)
> ---[ end trace f4d187650e17fc5c ]---
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
>
> Please apply the patch below to linux-yocto-3.8
>
> http://sakrah.dontexist.org/files/patches/0001-ARM-7668-1-fix-memset-related-crashes-caused-by-rece.patch
>
> This is a back port from 3.9 therefore safe. The problem is not limited to linux-yocto it also impacts upstream 3.8 stable
> but 3.8 stable is end of life so why bother. If linux-yocto upgrades to 3.9 or 3.10 and drops 3.8 in 1.5 then we are ok too.
>
That's interesting. I got the same crash on linux-yocto-dev, so I kept
debugging here.
Did linux-yocto-dev boot out of the box for you with gcc 4.8 ?
Bruce
> Let me know how it goes
>
> Thanks
>
> -Khem
>
next prev parent reply other threads:[~2013-06-18 3:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-18 3:30 Fix for kernel 3.8/gcc-4.8 segfault on qemuarm Khem Raj
2013-06-18 3:32 ` Bruce Ashfield [this message]
2013-06-18 4:37 ` Bruce Ashfield
2013-06-18 4:41 ` Khem Raj
2013-06-18 4:58 ` Bruce Ashfield
2013-06-18 5:25 ` Khem Raj
2013-06-18 11:12 ` Bruce Ashfield
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=51BFD4E8.3020901@windriver.com \
--to=bruce.ashfield@windriver.com \
--cc=Openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.com \
--cc=yocto@yoctoproject.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