From: Clemens Koller <clemens.koller@anagramm.de>
To: Scott Wood <scottwood@freescale.com>
Cc: linuxppc-dev@ozlabs.org, Nathan Lynch <ntl@pobox.com>
Subject: Re: Kernel oops while duming user core.
Date: Sat, 02 Feb 2008 13:05:06 +0100 [thread overview]
Message-ID: <47A45C72.9030004@anagramm.de> (raw)
In-Reply-To: <20080201173834.GD671@ld0162-tx32.am.freescale.net>
Scott Wood schrieb:
> On Thu, Jan 31, 2008 at 10:15:27AM -0600, Nathan Lynch wrote:
>> Rune Torgersen wrote:
>>> I get the following kernel core while a user program I have is dumping
>>> core.
>>> Any DIeas at what to look for? (this is runnign 2.6.24, arch/powerpc on
>>> a 8280)
>>> When runnign the program on 2.6.18 arch/ppc, the program gets a sig 11
>>> and dumps core.
>>> On 2.6.24, I ghet the kernel oops, and then the program hangs sround
>>> forever and is unkillable.
>> Hmm, this is the second report of 2.6.24 crashing in
>> __flush_dcache_icache during a core dump; see:
>> http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048662.html
>>
>> Is this easily recreatable?
>
> Yes, this program does it reliably:
>
> #include <pthread.h>
> #include <stdio.h>
> #include <unistd.h>
> #include <signal.h>
>
> void *threadfn(void *arg)
> {
> fprintf(stderr, "threadfn\n");
> fflush(stderr);
> sleep(1);
> *(char *)0=0;
> return NULL;
> }
>
> int main(void)
> {
> pthread_t thread[4];
> int i;
>
> for (i = 0; i < 4; i++)
> pthread_create(&thread[0], NULL, threadfn, NULL);
>
> for (;;);
> }
Ack!
This is a MPC8540ADS arch/powerpc compatible environment here:
Feb 2 12:59:17 fox_1 kernel: Unable to handle kernel paging request for data at address 0x4802f000
Feb 2 12:59:17 fox_1 kernel: Faulting instruction address: 0xc000d5b8
Feb 2 12:59:17 fox_1 kernel: Oops: Kernel access of bad area, sig: 11 [#1]
Feb 2 12:59:17 fox_1 kernel: MPC85xx ADS
Feb 2 12:59:17 fox_1 kernel: Modules linked in:
Feb 2 12:59:17 fox_1 kernel: NIP: c000d5b8 LR: c0010fb8 CTR: 00000080
Feb 2 12:59:17 fox_1 kernel: REGS: c24abb20 TRAP: 0300 Not tainted (2.6.24)
Feb 2 12:59:17 fox_1 kernel: MSR: 00029000 <EE,ME> CR: 22882222 XER: 00000000
Feb 2 12:59:17 fox_1 kernel: DEAR: 4802f000, ESR: 00000000
Feb 2 12:59:17 fox_1 kernel: TASK = cf894d20[942] 'oops' THREAD: c24aa000
Feb 2 12:59:17 fox_1 kernel: GPR00: c22c7680 c24abbd0 cf894d20 4802f000 00000080 000f8b60 4802f000 ffffffff
Feb 2 12:59:17 fox_1 kernel: GPR08: 00000000 c22c7680 000008d1 00000000 22882222 10018a64 00000006 c035a300
Feb 2 12:59:17 fox_1 kernel: GPR16: 00024000 c0380000 c24aa000 c24abc9c c24abc98 c2570480 c22c7680 c0380000
Feb 2 12:59:17 fox_1 kernel: GPR24: c0390420 cf09d000 c0497b60 c5b63948 4802f000 c24aa000 000000bc c0497b60
Feb 2 12:59:17 fox_1 kernel: NIP [c000d5b8] __flush_dcache_icache+0x14/0x40
Feb 2 12:59:17 fox_1 kernel: LR [c0010fb8] update_mmu_cache+0x94/0x98
Feb 2 12:59:17 fox_1 kernel: Call Trace:
Feb 2 12:59:17 fox_1 kernel: [c24abbd0] [c24aa000] 0xc24aa000 (unreliable)
Feb 2 12:59:17 fox_1 kernel: [c24abbe0] [c005d978] handle_mm_fault+0x374/0x6a4
Feb 2 12:59:17 fox_1 kernel: [c24abc30] [c005ddd0] get_user_pages+0x128/0x384
Feb 2 12:59:17 fox_1 kernel: [c24abc90] [c00a80d8] elf_core_dump+0xab8/0xb74
Feb 2 12:59:17 fox_1 kernel: [c24abd30] [c007718c] do_coredump+0x730/0x758
Feb 2 12:59:17 fox_1 kernel: [c24abe30] [c002eeb0] get_signal_to_deliver+0x244/0x3c4
Feb 2 12:59:17 fox_1 kernel: [c24abe80] [c000782c] do_signal+0x48/0x264
Feb 2 12:59:17 fox_1 kernel: [c24abf40] [c000e4ac] do_user_signal+0x74/0xc4
Feb 2 12:59:17 fox_1 kernel: Instruction dump:
Feb 2 12:59:17 fox_1 kernel: 4d820020 7c8903a6 7c001bac 38630020 4200fff8 7c0004ac 4e800020 60000000
Feb 2 12:59:17 fox_1 kernel: 54630026 38800080 7c8903a6 7c661b78 <7c00186c> 38630020 4200fff8 7c0004ac
Feb 2 12:59:17 fox_1 kernel: ---[ end trace a1d91e665173315a ]---
Feb 2 12:59:17 fox_1 kernel: note: oops[942] exited with preempt_count 1
It does not oops when the core dump is disabled.
Regards,
Clemens
prev parent reply other threads:[~2008-02-02 12:05 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-31 13:45 Kernel oops while duming user core Rune Torgersen
2008-01-31 16:15 ` Nathan Lynch
2008-01-31 16:26 ` Rune Torgersen
2008-01-31 17:40 ` Rune Torgersen
2008-01-31 19:15 ` Kumar Gala
2008-01-31 19:18 ` Rune Torgersen
2008-01-31 20:16 ` Scott Wood
2008-01-31 20:19 ` Rune Torgersen
2008-01-31 20:38 ` Rune Torgersen
2008-01-31 20:41 ` Nathan Lynch
2008-01-31 20:45 ` Rune Torgersen
2008-01-31 20:55 ` Scott Wood
2008-01-31 21:58 ` Scott Wood
2008-01-31 22:10 ` Rune Torgersen
2008-02-03 7:34 ` Benjamin Herrenschmidt
2008-02-04 18:23 ` Kernel oops while dumping " Scott Wood
2008-01-31 19:15 ` Kernel oops while duming " Kumar Gala
2008-01-31 19:23 ` Rune Torgersen
2008-01-31 19:54 ` Nathan Lynch
2008-02-01 17:38 ` Scott Wood
2008-02-02 12:05 ` Clemens Koller [this message]
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=47A45C72.9030004@anagramm.de \
--to=clemens.koller@anagramm.de \
--cc=linuxppc-dev@ozlabs.org \
--cc=ntl@pobox.com \
--cc=scottwood@freescale.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.