mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ndiamond@despammed.com
To: linux-kernel@vger.kernel.org
Subject: Panics need better handling
Date: Sun, 13 Jun 2004 21:23:01 -0500 (CDT)	[thread overview]
Message-ID: <200406140223.i5E2N1k18221@mailout.despammed.com> (raw)

The following information is visible on
a screen after a panic.  Usually even
this amount of information is not
visible.  It was visible because of an
intuitive guess that a panic was going
to happen within minutes of that guess.
A very lucky occurence resulted in one
of the lines being displayed which is
rarely displayed even when other panic
lines are visible.  I am not asking for
help in solving this particular panic,
I am asking for help in general, in
getting information displayed when it
needs to be displayed.

EIP is at __insmod_binfmt_misc_S.data_L548 [binfmt_misc] 0x20e7 (2.4.20-custom)
eax: e47f1600   ebx: e4017e80   ecx: 00000000   edx: e7883000
esi: 04000001   edi: c034df54   ebp: 0000000b   esp: c034df10
ds: 0068   es: 0068   ss: 0068
Process swapper (pid: 0, stackpage=c034d000)
Stack: c010aab5 0000000b e47f1600 c034df54 c036fe80 0000000b c29c6c00 00000580
       c010ac54 0000000b c034df54 c29c6c00 00000000 00000000 00000000 00000000
       c010d768 00000000 00000000 000005c1 00000000 00000000 00000000 c034dfbc
Call Trace:   [<c010aab5>] handle_IRQ_event [kernel] 0x45 (0xc034df10))
[<c010ac54>] do_IRQ [kernel] 0x84 (0xc034df30))
[<c010d768>] call_do_IRQ [kernel] 0x5 (0xc034df50))
[<c0110068>] dump_fpu [kernel] 0x48 (0xc034df70))
[<c01157ee>] apm_bios_call_simple [kernel] 0x8e (0xc034df7c))
[<c0115937>] apm_do_idle [kernel] 0x27 (0xc034dfa8))
[<c0115a8b>] apm_cpu_idle [kernel] 0xbb (0xc034dfc0))
[<c01159d0>] apm_cpu_idle [kernel] 0x0 (0xc034dfc4))
[<c0107040>] default_idle [kernel] 0x0 (0xc034dfd0))
[<c01070f2>] cpu_idle [kernel] 0x42 (0xc034dfd4))
[<c0105000>] stext [kernel] 0x0 (0xc034dfe0))


Code:  Bad EIP value.
 <0>Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
_       <-- (cursor is there)


I'm not sure which of these complaints
to prioritize.

When a panic is visible, there are two
blank lines, a redundant line saying
Kernel panic Aieee, a redundant line
saying In interrupt handler, and a
redundant line with the cursor only.
If these 5 lines were removed, there
could be 5 more lines of trace
information.  Actually there usually
are 5 more lines of trace information,
actually usually more than that, but
they get scrolled off the top of the
screen.  The line saying "EIP is at" is
almost always among the lines that get
scrolled off the screen, but in this
case we were lucky that this line just
barely got a chance to survive.  And
usually the EIP isn't so badly invalid
as this one is, usually it's really
useful information that gets scrolled
off the top of the screen.  Is there
any chance in getting the 24 most
important lines of panic information
displayed last, and putting the cursor
at the end of the 24th line thereof, so
that 24 valuable lines of panic
information can be visible?

Also, usually the panic information
isn't visible at all.  Certain famous
frequent blue screens of death are
famous and frequent partly because of
famous frequent crashes, but also
partly because the kernel puts the
screen back into VGA text mode before
displaying the text.  In Linux, usually
XFree86 is running, and usually the
only visible effect is a freeze.  How
many of these freezes really have panic
information written to an invisible VGA
buffer and never displayed?  When a
panic occurs, we need to shove off
XFree86 and put the display into VGA
text mode.  Even if this makes Linux
black screens of death become as famous
and frequent as certain blue ones, we
need to get the information.

(Apologies if there are editing errors
in the above, which are not visible in
the web interface being used for this
submission.  I used to send submissions
from my real e-mail account, and as a
result was rewarded with 60 spams per
day.  I'm not going to send submissions
from my new real e-mail account.)

             reply	other threads:[~2004-06-14  2:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-14  2:23 ndiamond [this message]
2004-06-14  4:21 ` Willy Tarreau
2004-06-14  4:34   ` Norberto Bensa
2004-06-14 13:46     ` [PATCH] kmsgdump-2.6.6.patch (was: Panics need better handling) Kalin KOZHUHAROV
2004-06-14  7:28 ` Panics need better handling Helge Hafting
2004-06-14  7:44   ` John Bradford
2004-06-14  5:19 ndiamond
2004-06-14  5:45 ` Willy Tarreau
2004-06-14  5:52 ndiamond
2004-06-14 14:20 Cress, Andrew R

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=200406140223.i5E2N1k18221@mailout.despammed.com \
    --to=ndiamond@despammed.com \
    --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

all inboxes | Powered by JetHome®