© 1995-2008 by The FreeBSD Project. All rights reserved.URL: http://www.FreeBSD.de
bcr 2009-05-14 20:17:02 UTC
FreeBSD German Documentation Repository
Modified files:
books/faq book.sgml
Log:
MFen 1.1060
Revision Changes Path
1.692 +83 -101 de-docproj/books/faq/book.sgml
Index: book.sgml
===================================================================
RCS file: /home/cvs/de-docproj/books/faq/book.sgml,v
retrieving revision 1.691
retrieving revision 1.692
diff -u -I$FreeBSDde.*$ -r1.691 -r1.692
--- book.sgml 11 May 2009 18:58:13 -0000 1.691
+++ book.sgml 14 May 2009 20:17:01 -0000 1.692
@@ -3,9 +3,9 @@
The FreeBSD German Documentation Project
$FreeBSD$
-$FreeBSDde: de-docproj/books/faq/book.sgml,v 1.691 2009/05/11 18:58:13 bcr Exp $
+$FreeBSDde: de-docproj/books/faq/book.sgml,v 1.692 2009/05/14 20:17:01 bcr Exp $
- basiert auf: 1.1059
+ basiert auf: 1.1060
-->
@@ -12271,49 +12271,31 @@
</question>
<answer>
- <para><emphasis>[Dieser Abschnitt wurde von &a.des;, der
- einige Tippfehler korrigiert und die Kommentare in eckigen
- Klammern hinzugefügt hat, aus einer Mail von
- &a.wpaul; in der <link
- linkend="mailing">Mailingliste</link> freebsd-current
- entnommen.]</emphasis></para>
+ <para>Hier ist eine typische Kernel-Panic</para>
- <programlisting>
-From: Bill Paul <wpaul(at)skynet.ctr.columbia.edu>
-Subject: Re: the fs fun never stops
-To: Ben Rosengart
-Date: Sun, 20 Sep 1998 15:22:50 -0400 (EDT)
-Cc: current(at)FreeBSD.org
- </programlisting>
-
- <para><emphasis>[<Ben Rosengart> sendete die
- folgende Panik-Meldung]</emphasis></para>
-
- <programlisting>
-> Fatal trap 12: page fault while in kernel mode
-> fault virtual address = 0x40
-> fault code = supervisor read, page not present
-> instruction pointer = 0x8:0xf014a7e5
- ^^^^^^^^^^
-> stack pointer = 0x10:0xf4ed6f24
-> frame pointer = 0x10:0xf4ed6f28
-> code segment = base 0x0, limit 0xfffff, type 0x1b
-> = DPL 0, pres 1, def32 1, gran 1
-> processor eflags = interrupt enabled, resume, IOPL = 0
-> current process = 80 (mount)
-> interrupt mask =
-> trap number = 12
-> panic: page fault
- </programlisting>
+ <programlisting>Fatal trap 12: page fault while in kernel mode
+
+fault virtual address = 0x40
+fault code = supervisor read, page not present
+instruction pointer = 0x8:0xf014a7e5
+stack pointer = 0x10:0xf4ed6f24
+frame pointer = 0x10:0xf4ed6f28
+code segment = base 0x0, limit 0xfffff, type 0x1b
+ = DPL 0, pres 1, def32 1, gran 1
+processor eflags = interrupt enabled, resume, IOPL = 0
+current process = 80 (mount)
+interrupt mask =
+trap number = 12
+panic: page fault</programlisting>
- <para>[Wenn] Sie eine Meldung wie diese sehen, reicht es
+ <para>Wenn Sie eine Meldung wie diese sehen, reicht es
nicht, sie einfach zu reproduzieren und sie einzusenden.
Der Wert des Instruktionszeigers, den ich oben
hervorgehoben habe, ist wichtig; leider ist er auch
konfigurationsabhängig. Mit anderen Worten variieren
die Werte abhängig von dem Kernel-Image, das Sie
- tatsächlich benutzen. Wenn Sie ein GENERIC
- Kernelimage von einem der Snapshots benutzen, dann ist es
+ tatsächlich benutzen. Wenn Sie ein
+ <filename>GENERIC</filename> Kernelimage von einem der Snapshots benutzen, dann ist es
für jemand anderen möglich, die fehlerhafte
Instruktion herauszufinden, aber wenn Sie einen
angepassten Kernel benutzen, können nur
@@ -12336,7 +12318,7 @@
<para>Tun Sie folgendes, wenn das System
rebootet:</para>
- <screen>&prompt.user; <userinput>nm -n /kernel.that.caused.the.panic | grep f0xxxxxx</userinput></screen>
+ <screen>&prompt.user; <userinput><command>nm</command> <option>-n</option> <replaceable>/kernel.that.caused.the.panic</replaceable> | <command>grep</command> f0xxxxxx</userinput></screen>
<para>wobei <literal>0xf0xxxxxx</literal> der Wert des
Instruktionszeigers ist. Es besteht die
@@ -12349,7 +12331,7 @@
letzten Teil des Werts des Instruktionszeigers weg und
versuchen es noch einmal, z.B.:</para>
- <screen>&prompt.user; <userinput>nm -n /kernel.that.caused.the.panic | grep f0xxxxx</userinput></screen>
+ <screen>&prompt.user; <userinput><command>nm</command> <option>-n</option> <replaceable>/kernel.that.caused.the.panic</replaceable> | <command>grep</command> f0xxxxx</userinput></screen>
<para>Falls das kein Ergebnis liefert, hacken Sie eine
weitere Ziffer ab. Wiederholen Sie die Schritte, bis
@@ -12361,14 +12343,9 @@
</step>
</procedure>
- <para>Ich sehe ständig Leute, die Panik-Meldungen wie
- diese zeigen, aber ich sehe kaum jemanden, der sich die
- Zeit nimmt, den Instruktionszeiger einer Funktion aus der
- Symboltabelle des Kernel zuzuordnen.</para>
-
- <para>Der beste Weg, den Grund für eine Panik
+ <para>Wie dem auch sei, der beste Weg, den Grund für eine Panik
herauszufinden, ist der, einen Crash-Dump festzuhalten und
- dann &man.gdb.1; zu benutzen, um den Stack im Crash-Dump
+ dann &man.kgdb.1; zu benutzen, um den Stack im Crash-Dump
zurückzuverfolgen.</para>
<para>Jedenfalls ist die Methode, die ich normalerweise
@@ -12376,48 +12353,52 @@
<procedure>
<step>
- <para>Richten Sie eine Kernelkonfigurationsdatei ein,
- fügen Sie optional <literal>options DDB</literal>
- hinzu, falls Sie glauben, dass Sie den
- Kerneldebugger benötigen. (Ich benutze ihn
- hauptsächlich zum Setzen von Haltepunkten, wenn
- ich eine Endlosschleife irgendeiner Art
- vermute.)</para>
+ <para>Sorgen Sie dafür, dass die folgende Zeile in der
+ Kernelkonfigurationsdatei
+ (/usr/src/sys/<replaceable>arch</replaceable>/conf/<replaceable>MYKERNEL</replaceable>) enthalten ist:</para>
+ <programlisting>makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols</programlisting>
</step>
<step>
- <para>Benutzen Sie <command>config -g
- <replaceable>KERNELCONFIG</replaceable></command>, um
- das Erstellungsverzeichnis einzurichten.</para>
+ <para>Wechseln Sie in das Verzeichnis
+ <filename role="directory">usr/src</filename>:</para>
+ <screen>&prompt.root; <command>cd</command> <filename role="directory">/usr/src</filename></screen>
</step>
<step>
- <para><command>cd
- /sys/compile/<replaceable>KERNELCONFIG</replaceable>;
- make</command></para>
+ <para>Erstellen Sie den Kernel:</para>
+ <screen>&prompt.root; <command>make</command> <maketarget>buildkernel</maketarget> <makevar>KERNCONFIG</makevar>=<replaceable>MYKERNEL</replaceable></screen>
</step>
<step>
- <para>Warten Sie, bis der Kernel fertig kompiliert
- ist.</para>
+ <para>Warten Sie, bis &man.make.1; den Kernel fertig kompiliert
+ hat.</para>
</step>
<step>
- <para><command>make install</command></para>
+ <screen>&prompt.root; <command>make</command> <maketarget>installkernel</maketarget> <makevar>KERNCONFIG</makevar>=<replaceable>MYKERNEL</replaceable></screen>
</step>
<step>
- <para>reboot</para>
+ <para>Starten Sie das System neu.</para>
</step>
</procedure>
+ <note>
+ <para>Falls Sie die make-Variable <makevar>KERNCONFIG</makevar>
+ nicht verwenden, wird ein <filename>GENERIC</filename> Kernel
+ gebaut und installiert.</para>
+ </note>
+
<para>Der &man.make.1;-Prozess wird zwei Kernel
- erstellt haben: <filename>kernel</filename> und
- <filename>kernel.debug</filename>.
+ erstellt haben:
+ <filename>/usr/obj/usr/src/sys/<replaceable>MYKERNEL</replaceable>/kernel</filename>
+ und
+ <filename>/usr/obj/usr/src/sys/<replaceable>MYKERNEL</replaceable>/kernel.debug</filename>.
<filename>kernel</filename> wurde als
- <filename>/kernel</filename> installiert, während
+ <filename>/boot/kernel</filename> installiert, während
<filename>kernel.debug</filename> als Quelle für
- Debuggersymbole für &man.gdb.1; benutzt werden
+ Debuggersymbole für &man.kgdb.1; benutzt werden
kann.</para>
<para>Um sicherzustellen, dass ein Crash-Dump erhalten
@@ -12436,10 +12417,10 @@
<filename>/var/crash</filename> ablegen.</para>
----------------------------------------------
Diff block truncated. (Max lines = 200)
----------------------------------------------
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-cvs-doc" in the body of the message
Received on Thu 14 May 2009 - 22:17:18 CEST