From: Manfred Spraul <manfred@colorfullife.com>
To: Martin Rode <Martin.Rode@programmfabrik.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: BUG in sched.c, Kernel 2.4.1?
Date: Tue, 13 Feb 2001 16:49:41 +0100 [thread overview]
Message-ID: <3A895795.56741320@colorfullife.com> (raw)
In-Reply-To: <3A8942FA.484BE2FC@programmfabrik.de> <3A8944F1.93C252EB@didntduck.org> <3A895194.89D69AE9@programmfabrik.de>
Martin Rode wrote:
>
> >
> > Run this oops message through ksymoops please. It will make debugging
> > it alot easier.
> >
> >
>
> Since I did not compile the kernel myself, ksymoops is not too happy with
> what is has to analyse the dump. I tried compile the Mandrake kernel myself
> but there seems to be something unmatched. See below for what ksymoops
> gives me.
>
looks good.
> Warning (compare_maps): mismatch on symbol vt_cons , ksyms_base says
> c02b06e0, vmlinux says c02ac6e0. Ignoring ksyms_base entry
>
> (I get about > 300 msgs of that kind)
>
> Let me know who I can prepare for the next crash with my own kernel. Are
> there any options I have to turn on for compiling?
>
> kernel BUG at sched.c:714!
> invalid operand: 0000
> CPU: 0
> EIP: 0010:[<c0113781>]
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010282
> eax: 0000001b ebx 00000000 ecx df4f6000 edx 00000001
> esi: 001cffe3 edi db5eede0 ebp dc0e9f40 esp dc0e9ef0
> stack: c01f26f3 c01f2856 000002ca db5eed80 dc0e8000 db5eede0 dc0e9f18
> dc0e8000 000033ba 00000000 00000000 000000e7 0000001c 0000001c
> fffffff3 dc0e8000 00000800 00000000 dc0e8000 dc0e9f68 c0139c44
> d488bf80 00000000
esp is quite high, only 0x110 bytes of the stack are used.
> call trace: [<cc0139c44>] [<c0139d1c>] [<c0130af6>] [<c0108e93>]
^^^^^^^^^
> code: 0f 0b 8d 65 bc 5b 5e 5f 89 ec 5d c3 8d 76 00 55 89 e5 83 ec
>
> >>EIP; c0113781 <schedule+421/430> <=====
> Trace; cc0139c44 <END_OF_CODE+bdf830401/????>
^^^^^^^^^
did you manually copy the oops from the screen?
that value should be c0139c44 <pipe_wait...>
> Trace; c0139d1c <pipe_read+80/238>
> Trace; c0130af6 <sys_read+5e/c4>
> Trace; c0108e93 <system_call+33/40>
>
> [snip]
>
> Kernel panic: Aiee, killing interrupt handler!
>
I don't see that interrupt handler!
it seems to be a normal syscall, just a pipe read that blocks because
the pipe is empty.
Is that the first oops, or was there another oops before this one?
--
Manfred
next prev parent reply other threads:[~2001-02-13 15:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-13 14:21 BUG in sched.c, Kernel 2.4.1? Martin Rode
2001-02-13 14:30 ` Brian Gerst
2001-02-13 15:24 ` Martin Rode
2001-02-13 15:49 ` Manfred Spraul [this message]
2001-02-13 18:59 ` Martin Rode
[not found] ` <3A8956E9.402D0136@didntduck.org>
2001-02-13 17:19 ` Martin Rode
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=3A895795.56741320@colorfullife.com \
--to=manfred@colorfullife.com \
--cc=Martin.Rode@programmfabrik.de \
--cc=linux-kernel@vger.kernel.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