* Fix for kernel 3.8/gcc-4.8 segfault on qemuarm @ 2013-06-18 3:30 Khem Raj 2013-06-18 3:32 ` Bruce Ashfield 2013-06-18 4:37 ` Bruce Ashfield 0 siblings, 2 replies; 7+ messages in thread From: Khem Raj @ 2013-06-18 3:30 UTC (permalink / raw) To: <openembedded-core@lists.openembedded.org> oe-core layer, Bruce Ashfield Cc: yocto@yoctoproject.org (yocto@yoctoproject.org) 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. Let me know how it goes Thanks -Khem ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fix for kernel 3.8/gcc-4.8 segfault on qemuarm 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 2013-06-18 4:37 ` Bruce Ashfield 1 sibling, 0 replies; 7+ messages in thread From: Bruce Ashfield @ 2013-06-18 3:32 UTC (permalink / raw) To: Khem Raj Cc: yocto@yoctoproject.org (yocto@yoctoproject.org), <openembedded-core@lists.openembedded.org> oe-core layer 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fix for kernel 3.8/gcc-4.8 segfault on qemuarm 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 @ 2013-06-18 4:37 ` Bruce Ashfield 2013-06-18 4:41 ` Khem Raj 1 sibling, 1 reply; 7+ messages in thread From: Bruce Ashfield @ 2013-06-18 4:37 UTC (permalink / raw) To: Khem Raj Cc: yocto@yoctoproject.org (yocto@yoctoproject.org), <openembedded-core@lists.openembedded.org> oe-core layer 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 > > There also seems to be a follow up patch: commit 418df63adac56841ef6b0f1fcf435bc64d4ed177 Author: Nicolas Pitre <nicolas.pitre@linaro.org> Date: Tue Mar 12 13:00:42 2013 +0100 ARM: 7670/1: fix the memset fix Commit 455bd4c430b0 ("ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations") attempted to fix a compliance issue with the memset return value. However the memset itself became broken by that patch for misaligned pointers. This fixes the above by branching over the entry code from the misaligned fixup code to avoid reloading the original pointer. Also, because the function entry alignment is wrong in the Thumb mode compilation, that fixup code is moved to the end. While at it, the entry instructions are slightly reworked to help dual issue pipelines. Signed-off-by: Nicolas Pitre <nico@linaro.org> Tested-by: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> :100644 100644 d912e73... 94b0650... M arch/arm/lib/memset.S -------- I've staged it as well, and will do a boot test in the morning once my build has completed. Time to call it a night here. Bruce > 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. > > Let me know how it goes > > Thanks > > -Khem > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fix for kernel 3.8/gcc-4.8 segfault on qemuarm 2013-06-18 4:37 ` Bruce Ashfield @ 2013-06-18 4:41 ` Khem Raj 2013-06-18 4:58 ` Bruce Ashfield 0 siblings, 1 reply; 7+ messages in thread From: Khem Raj @ 2013-06-18 4:41 UTC (permalink / raw) To: Bruce Ashfield Cc: yocto@yoctoproject.org (yocto@yoctoproject.org), <openembedded-core@lists.openembedded.org> oe-core layer On Jun 17, 2013, at 9:37 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote: > 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 >> >> > > There also seems to be a follow up patch: > > commit 418df63adac56841ef6b0f1fcf435bc64d4ed177 > Author: Nicolas Pitre <nicolas.pitre@linaro.org> > Date: Tue Mar 12 13:00:42 2013 +0100 > > ARM: 7670/1: fix the memset fix > > Commit 455bd4c430b0 ("ARM: 7668/1: fix memset-related crashes caused by > recent GCC (4.7.2) optimizations") attempted to fix a compliance issue > with the memset return value. However the memset itself became broken > by that patch for misaligned pointers. > > This fixes the above by branching over the entry code from the > misaligned fixup code to avoid reloading the original pointer. > > Also, because the function entry alignment is wrong in the Thumb mode > compilation, that fixup code is moved to the end. > > While at it, the entry instructions are slightly reworked to help dual > issue pipelines. > > Signed-off-by: Nicolas Pitre <nico@linaro.org> > Tested-by: Alexander Holler <holler@ahsoftware.de> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> > > :100644 100644 d912e73... 94b0650... M arch/arm/lib/memset.S > > -------- > > I've staged it as well, and will do a boot test in the morning once > my build has completed. Time to call it a night here. I did not need anything other than the first patch to get over the segfault. but yes it completes the fix so having both is better > > Bruce > >> 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. >> >> Let me know how it goes >> >> Thanks >> >> -Khem >> > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fix for kernel 3.8/gcc-4.8 segfault on qemuarm 2013-06-18 4:41 ` Khem Raj @ 2013-06-18 4:58 ` Bruce Ashfield 2013-06-18 5:25 ` Khem Raj 0 siblings, 1 reply; 7+ messages in thread From: Bruce Ashfield @ 2013-06-18 4:58 UTC (permalink / raw) To: Khem Raj Cc: yocto@yoctoproject.org (yocto@yoctoproject.org), <openembedded-core@lists.openembedded.org> oe-core layer On 13-06-18 12:41 AM, Khem Raj wrote: > > On Jun 17, 2013, at 9:37 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote: > >> 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 >>> >>> >> >> There also seems to be a follow up patch: >> >> commit 418df63adac56841ef6b0f1fcf435bc64d4ed177 >> Author: Nicolas Pitre <nicolas.pitre@linaro.org> >> Date: Tue Mar 12 13:00:42 2013 +0100 >> >> ARM: 7670/1: fix the memset fix >> >> Commit 455bd4c430b0 ("ARM: 7668/1: fix memset-related crashes caused by >> recent GCC (4.7.2) optimizations") attempted to fix a compliance issue >> with the memset return value. However the memset itself became broken >> by that patch for misaligned pointers. >> >> This fixes the above by branching over the entry code from the >> misaligned fixup code to avoid reloading the original pointer. >> >> Also, because the function entry alignment is wrong in the Thumb mode >> compilation, that fixup code is moved to the end. >> >> While at it, the entry instructions are slightly reworked to help dual >> issue pipelines. >> >> Signed-off-by: Nicolas Pitre <nico@linaro.org> >> Tested-by: Alexander Holler <holler@ahsoftware.de> >> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> >> >> :100644 100644 d912e73... 94b0650... M arch/arm/lib/memset.S >> >> -------- >> >> I've staged it as well, and will do a boot test in the morning once >> my build has completed. Time to call it a night here. > > I did not need anything other than the first patch to get over the segfault. but yes it completes the fix > so having both is better So very strange. I got one segfault, and then this: Linux version 3.8.13-yocto-standard (bruce@yow-bashfiel-d2) (gcc version 4.8.1 (GCC) ) #2 PREEMPT Tue Jun 18 00:36:55 EDT 2013 <snip> qemuarm login: root root@qemuarm:~# uname -a Linux qemuarm 3.8.13-yocto-standard #2 PREEMPT Tue Jun 18 00:36:55 EDT 2013 armv5tejl GNU/Linux ---------------- Which means I may have just been unlucky on my testing with 3.10, or something else is going on. Regardless, this is progress and I'll do some stress testing here and get a pull request out to RP in the next day or so. Bruce > >> >> Bruce >> >>> 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. >>> >>> Let me know how it goes >>> >>> Thanks >>> >>> -Khem >>> >> > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fix for kernel 3.8/gcc-4.8 segfault on qemuarm 2013-06-18 4:58 ` Bruce Ashfield @ 2013-06-18 5:25 ` Khem Raj 2013-06-18 11:12 ` Bruce Ashfield 0 siblings, 1 reply; 7+ messages in thread From: Khem Raj @ 2013-06-18 5:25 UTC (permalink / raw) To: Bruce Ashfield Cc: yocto@yoctoproject.org (yocto@yoctoproject.org), <openembedded-core@lists.openembedded.org> oe-core layer On Jun 17, 2013, at 9:58 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote: > On 13-06-18 12:41 AM, Khem Raj wrote: >> >> On Jun 17, 2013, at 9:37 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote: >> >>> 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 >>>> >>>> >>> >>> There also seems to be a follow up patch: >>> >>> commit 418df63adac56841ef6b0f1fcf435bc64d4ed177 >>> Author: Nicolas Pitre <nicolas.pitre@linaro.org> >>> Date: Tue Mar 12 13:00:42 2013 +0100 >>> >>> ARM: 7670/1: fix the memset fix >>> >>> Commit 455bd4c430b0 ("ARM: 7668/1: fix memset-related crashes caused by >>> recent GCC (4.7.2) optimizations") attempted to fix a compliance issue >>> with the memset return value. However the memset itself became broken >>> by that patch for misaligned pointers. >>> >>> This fixes the above by branching over the entry code from the >>> misaligned fixup code to avoid reloading the original pointer. >>> >>> Also, because the function entry alignment is wrong in the Thumb mode >>> compilation, that fixup code is moved to the end. >>> >>> While at it, the entry instructions are slightly reworked to help dual >>> issue pipelines. >>> >>> Signed-off-by: Nicolas Pitre <nico@linaro.org> >>> Tested-by: Alexander Holler <holler@ahsoftware.de> >>> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> >>> >>> :100644 100644 d912e73... 94b0650... M arch/arm/lib/memset.S >>> >>> -------- >>> >>> I've staged it as well, and will do a boot test in the morning once >>> my build has completed. Time to call it a night here. >> >> I did not need anything other than the first patch to get over the segfault. but yes it completes the fix >> so having both is better > > So very strange. I got one segfault, and then this: > > Linux version 3.8.13-yocto-standard (bruce@yow-bashfiel-d2) (gcc version 4.8.1 (GCC) ) #2 PREEMPT Tue Jun 18 00:36:55 EDT 2013 > > <snip> > > qemuarm login: root > root@qemuarm:~# uname -a > Linux qemuarm 3.8.13-yocto-standard #2 PREEMPT Tue Jun 18 00:36:55 EDT 2013 armv5tejl GNU/Linux > > ---------------- > > Which means I may have just been unlucky on my testing with 3.10, or something > else is going on. Well I have been booting latest linus's (3.10-rc6) master compiled with gcc 4.8 just one patch from linux-yocto see below http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/commit/?h=standard/arm-versatile-926ejs&id=351d133943b50a9dfeee07661d44254722a19f04 I wonder why this patch hasn't made upstream yet. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fix for kernel 3.8/gcc-4.8 segfault on qemuarm 2013-06-18 5:25 ` Khem Raj @ 2013-06-18 11:12 ` Bruce Ashfield 0 siblings, 0 replies; 7+ messages in thread From: Bruce Ashfield @ 2013-06-18 11:12 UTC (permalink / raw) To: Khem Raj Cc: yocto@yoctoproject.org (yocto@yoctoproject.org), <openembedded-core@lists.openembedded.org> oe-core layer On Tue, Jun 18, 2013 at 1:25 AM, Khem Raj <raj.khem@gmail.com> wrote: > > On Jun 17, 2013, at 9:58 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote: > >> On 13-06-18 12:41 AM, Khem Raj wrote: >>> >>> On Jun 17, 2013, at 9:37 PM, Bruce Ashfield <bruce.ashfield@windriver.com> wrote: >>> >>>> 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 >>>>> >>>>> >>>> >>>> There also seems to be a follow up patch: >>>> >>>> commit 418df63adac56841ef6b0f1fcf435bc64d4ed177 >>>> Author: Nicolas Pitre <nicolas.pitre@linaro.org> >>>> Date: Tue Mar 12 13:00:42 2013 +0100 >>>> >>>> ARM: 7670/1: fix the memset fix >>>> >>>> Commit 455bd4c430b0 ("ARM: 7668/1: fix memset-related crashes caused by >>>> recent GCC (4.7.2) optimizations") attempted to fix a compliance issue >>>> with the memset return value. However the memset itself became broken >>>> by that patch for misaligned pointers. >>>> >>>> This fixes the above by branching over the entry code from the >>>> misaligned fixup code to avoid reloading the original pointer. >>>> >>>> Also, because the function entry alignment is wrong in the Thumb mode >>>> compilation, that fixup code is moved to the end. >>>> >>>> While at it, the entry instructions are slightly reworked to help dual >>>> issue pipelines. >>>> >>>> Signed-off-by: Nicolas Pitre <nico@linaro.org> >>>> Tested-by: Alexander Holler <holler@ahsoftware.de> >>>> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> >>>> >>>> :100644 100644 d912e73... 94b0650... M arch/arm/lib/memset.S >>>> >>>> -------- >>>> >>>> I've staged it as well, and will do a boot test in the morning once >>>> my build has completed. Time to call it a night here. >>> >>> I did not need anything other than the first patch to get over the segfault. but yes it completes the fix >>> so having both is better >> >> So very strange. I got one segfault, and then this: >> >> Linux version 3.8.13-yocto-standard (bruce@yow-bashfiel-d2) (gcc version 4.8.1 (GCC) ) #2 PREEMPT Tue Jun 18 00:36:55 EDT 2013 >> >> <snip> >> >> qemuarm login: root >> root@qemuarm:~# uname -a >> Linux qemuarm 3.8.13-yocto-standard #2 PREEMPT Tue Jun 18 00:36:55 EDT 2013 armv5tejl GNU/Linux >> >> ---------------- >> >> Which means I may have just been unlucky on my testing with 3.10, or something >> else is going on. > > Well I have been booting latest linus's (3.10-rc6) master compiled with gcc 4.8 just one patch from linux-yocto see below > Very odd. I would have just done the bisection myself, but my starting known point "good" point .. was a fail. So I've instead been looking at assembly dumps of memory management routines. > http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.8/commit/?h=standard/arm-versatile-926ejs&id=351d133943b50a9dfeee07661d44254722a19f04 > > I wonder why this patch hasn't made upstream yet. It was sent upstream, and rmk wanted to go to ARM ltd to rework the patch after getting some boards specs. Looks like the process is still ongoing. Cheers, Bruce > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-06-18 11:12 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox