Return-Path: owner-linux-activists@joker.cs.hut.fi
Return-Path: <owner-linux-activists@joker.cs.hut.fi>
Received: from kruuna.helsinki.fi by hydra.Helsinki.FI (4.1/SMI-4.1/36)
	id AA11458; Sat, 16 Jan 93 04:31:43 +0200
Received: from joker.cs.hut.fi by kruuna.helsinki.fi with SMTP id AA06486
  (5.65c8/IDA-1.4.4 for <wirzeniu@cc.helsinki.fi>); Sat, 16 Jan 1993 04:31:42 +0200
Received: from joker.cs.hut.fi by niksula.hut.fi id <61664-5>; Sat, 16 Jan 1993 04:30:36 +0200
From: "Linux Activists" <linux-activists@joker.cs.hut.fi>
To: "Linux-Activists" <linux-activists@joker.cs.hut.fi>
Reply-To: "Linux-Activists" <linux-activists@joker.cs.hut.fi>
X-Note1: Remember to put 'X-Mn-Key: NORMAL' to your mail body or header
Subject: Linux-Activists - Channel NORMAL digest. 93-0-15-23:4
X-Mn-Key: NORMAL
Sender: owner-linux-activists@joker.cs.hut.fi
Message-Id: <93Jan16.043036eet.61664-5@niksula.hut.fi>
Date: Sat, 16 Jan 1993 04:30:30 +0200
X-Charset: LATIN1
X-Char-Esc: 29
Status: RO
X-Status: 


Topics:
	 Recompiling Kernel...
	 New FAQ on kernel panics
	 setjmp.h IS FIXED.
	 Re: New FAQ on kernel panics
	 0.99pl3 Makefile?


----------------------------------------------------------------------

From: Troy Morrison <morrison@sunrfe.arc.nasa.gov>
Subject: Recompiling Kernel...
Date: Fri, 15 Jan 1993 23:24:02 +0200



I hope I don't make too much of a fool of myself with this message, but
I'm a particularly experienced UNIX guru, and I can't seem to get this to
work for myself.

Question:  How do you install Linux 0.99pl3?  I have a 386SX-25 that I have
  partitioned and installed the MCC-Interim 0.97pl2 on.  I grabbed the source
  code to 0.99pl3, and installed it in /usr/src/linux/.  I followed the instr-
  uctions in the README file that came with the source and did the following:

     o  Edited the Makefile for my VGA, Ramdisk (none) and root partition.

     o  Make the symbolic links (I forget the exact directories, but I did it).

     o  Ran "make clean", than "make config", then "make dep".

     o  Finally, I put a clean (low level formatted) disk in the A: drive and
        ran "make disk".  

No matter what I seem to answer in the "make config" part, I get the same
results.  The floppy boots, displays "Loading.... [etc]", prints some stuff
about the configuration, then flips out displaying something similar to:

floating point emulation not enabled and no coprocessor found
killing init.
floating point emulation not enabled and no coprocessor found
killing init.

(and on and on...)

I've tried answering "Kernel math emulation (default n):" as yes and no
with "make config" as well as "enable -m486 specific optimizations" as both
yes and no (although I do **not** have a 486, so I expect this should be no).

Any suggestions on what I'm doing wrong here?  I've had no problems booting 
from the 0.97pl2 or the 0.98 bootdisk/rootdisk (but since 0.97 was installed,
I'm trying to jump to 0.99...)

Help!

Troy Morrison




------------------------------

From: Matt Welsh <mdw@TC.Cornell.EDU>
Subject: New FAQ on kernel panics
Date: Sat, 16 Jan 1993 00:28:40 +0200


Linus, can we get a Q/A in the next FAQ about how to track down kernel
panic messages with nm? I see a lot of these, and if people would be so
kind as to tell us where the kernel is panicing (instead of just giving us
the panic message) it would help a lot. Basically, a Q/A describing the 
contents of a standard panic message, what it means, etc. would be great.

Thanks.
mdw



------------------------------

From: hlu@eecs.wsu.edu
Subject: setjmp.h IS FIXED.
Date: Sat, 16 Jan 1993 01:08:43 +0200



Please get libc-4.2-fix.TZ from tsx-11 under pub/linux/GCC if you
haven't. I have announced on c.o.l.a/c.o.l. It is also in the
release notes.

H.J.
-- 
School of EECS				Internet: hlu@eecs.wsu.edu
Washington State University		BITNET:   60935893@WSUVM1.BITNET
Pullman, WA 99164			Phone:    (509) 335-6470 (O)
USA						  (509) 334-6315 (H)



------------------------------

From: torvalds@cs.Helsinki.FI (Linus Torvalds)
Subject: Re: New FAQ on kernel panics
Date: Sat, 16 Jan 1993 02:19:37 +0200


Matt Welsh: "New FAQ on kernel panics" (Jan 15, 17:28):
> 
> Linus, can we get a Q/A in the next FAQ about how to track down kernel
> panic messages with nm? I see a lot of these, and if people would be so
> kind as to tell us where the kernel is panicing (instead of just giving us
> the panic message) it would help a lot. Basically, a Q/A describing the 
> contents of a standard panic message, what it means, etc. would be great.

Ok.  Hope somebody can make a FAQ out of this...

The panic message essentially consists of:

 - possible debugging messages printed out by the code before the panic:
   these may be important to tell more closely why the kernel decided to
   panic. 
 - one line of "Kernel panic: " and a small reason string (eg "unable to
   mount root")
 - if the panic happened while running the swapper task (aka idle task,
   aka dummy task), you finally get a line that tells you that the
   kernel is unable to sync any devices ("In swapper task - not
   syncing").  This generally means that the panic happened in a
   interrupt handler, as the idle task should never really panic on it's
   own. 

After a kernel panic, the machine is essentially dead: keyboard
interrupts may still be working, so that you can switch VC's and press
ctrl-alt-del, but no tasks are running. 

More interesting than the actual panic message is usually the debugging
messages prior to a panic.  The debugging messages can happen without
the panic, but most debug messages that remain are pretty severe, so a
panic may be likely.  The most interesting debugging messages have the
form:

 - possible extended explanation (eg "unable to handle kernel paging
   request at address xxxxx").
 - one line of reason + possible error code.  This can look like
   "General protection fault: 0000" or similar: it tells which exception
   happened, and gives the error code.  The error code is mostly zero,
   but can sometimes be non-zero, which usually makes them more
   interesting. 
 - the place the error was reported, in the form "EIP: 0008:xxxxxxxx". 
   This is important: it should be used to later check up in which
   kernel routine the error happened.  The 0008 tells that it happened
   in the kernel code segment (it can be something else, but it probably
   shouldn't happen), and the "xxxxxxxx" is the offset of the offending
   instruction,
 - the value of the 'fs' segment at the time of the exception: this is
   usually 0017, and isn't really interesting any more (it's a leftover
   from much earlier debugging sessions). 
 - the base and limit of the current code segment.  These too are mostly
   leftovers from older kernel versions: in the current kernels these
   are unlikely to have anything important in them (but do report them
   anyway for completeness). 
 - the pid of the current process and the value of the task register at
   this point.  Not generally of any importance.
 - ten hexadecimal values representing the offending instruction. These
   can be used to hand-disassemble what the offending instruction was,
   and sometimes helps pinpoint it a bit more easily than just telling
   where it happened.  This is useful.

When doing a panic report (or a report of just a "normal" kernel error
without an actual panic), the thing to do is:

 (a) write down the above debugging info exactly.  Especially the EIP
     and instruction hex-dump values are important, and need to be
     correct for any kind of debugging. 

 (b) find out where the exception happened.  With earlier kernels (0.12
     and below), the address was generally enough for me: all the
     kernels were generally the same, and I could look at my kernel
     binary to find out where the error occurred.  With newer kernels
     that is no longer possible, so the person who reports the error
     will have to pinpoint it a bit closer with respect to his
     particular kernel version.

There are several ways to find out where the error happened, but the
simplest one is generally the following:

 - get the kernel namelist with 'nm' and sort it according to address.
   This is most easily done with the commands

	# nm /usr/src/linux/tools/system | sort > namelist

   where you have to make sure that the tools/system file actually
   corresponds with the kernel that paniced.

 - search for the place that seems to contain the offending
   instructions.  'grep' is not really an option, as the exact address
   is unlikely to be in the output of 'nm', so you'll have to eyeball
   it.  This is easy enough in a editor or using 'less'. 

 - send along about 10 lines of the nm output from around the offending
   instruction.  Assuming the EIP value reported by the panic was
   00012345, the output of nm that is interesting might look like this:

	00011fd4 T _sys_ssetmask
	00011ff4 T _sys_sigpending
	00012024 T _sys_sigsuspend
	00012084 T _sys_signal
	00012114 T _sys_sigaction
	00012204 T _do_signal
	000124ac T _kernel_mktime
	000124ac t gcc2_compiled.
	000124ac t mktime.o
	00012560 t _get_long
	00012560 t gcc2_compiled.

   where the 00012345 address is in the _do_signal() function that seems
   to extend from 00012204 to 000124ac.  Note the "seems" - I prefer to
   have a couple of lines of context around the offending place as that
   can help pinpoint it a bit more: there may be static functions in the
   kernel between the two addresses that won't show up in the namelist
   or similar.  Also, sending a couple of lines of context means that
   bogus lines can safely be ignored (things like the "gcc2_compiled"
   and "mktime.o" in the example).  But don't try to prune out the bogus
   lines yourself unless you know that you know what you are doing. 

So, the result of it all? A bug-report with only the register dumps and
no other info is generally pretty useless - although if it also tells
what was going on that resulted in the error the bug might still be
possible to find.  Together with a pinpoint where it happened, it's
generally much easier then to find exactly what went wrong, and fix it. 

There are some circumstances where even all the above information won't
help: under some circumstances (a kernel jump to a nonexistent address
etc), the debugging info is simply bogus and not enough.  So always try
to make the bugreport as complete as possible: if you can re-create the
error so that somebody else also can test it, please include that kind
of info ("if I do this, then that, then the kernel will crash with this
error"). 

		Linus



------------------------------

From: Philip Perucci <dsc3pzp@nmrdc1.nmrdc.nnmc.navy.mil>
Subject: 0.99pl3 Makefile?
Date: Sat, 16 Jan 1993 02:26:43 +0200


Is there a problem with the Linux 0.99pl3 Makefile?
I have been happily making my own kernels since 0.98pl6 with NO trouble.
"make" for 0.99pl3 does nothing but compile main.c.
"make all" crashes on something like tools/version.h.
Any feedback, flames, jokes, or floggings greatly appreciated!

===========================================================================
  phil perucci      | "Any opinions expressed are solely my own views and 
  ssb1pzp@digex.com |  do not reflect the position of any organization"
===========================================================================



------------------------------

End of NORMAL Digest
********************
-------
