diff --git a/en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml b/en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml
index c9d8425f50..c5b08f3102 100644
--- a/en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml
+++ b/en_US.ISO8859-1/books/developers-handbook/kerneldebug/chapter.sgml
@@ -442,44 +442,6 @@
       <command>ddd</command>'s graphical interface.</para>
   </sect1>
 
-  <sect1 id="kerneldebug-post-mortem">
-    <title>Post-Mortem Analysis of a Dump</title>
-
-    <para>What do you do if a kernel dumped core but you did not expect it,
-      and it is therefore not compiled using <command>config -g</command>? Not
-      everything is lost here.  Do not panic!</para>
-
-    <para>Of course, you still need to enable crash dumps.  See above for the
-      options you have to specify in order to do this.</para>
-
-    <para>Go to your kernel config directory
-      (<filename>/usr/src/sys/<replaceable>arch</replaceable>/conf</filename>)
-      and edit your configuration file.  Uncomment (or add, if it does not
-      exist) the following line:</para>
-
-    <programlisting>makeoptions    DEBUG=-g                #Build kernel with gdb(1) debug symbols</programlisting>
-
-    <para>Rebuild the kernel.  Due to the time stamp change on the Makefile,
-      some other object files will be rebuilt, for example
-      <filename>trap.o</filename>.  With a bit of luck, the added
-      <option>-g</option> option will not change anything for the generated
-      code, so you will finally get a new kernel with similar code to the
-      faulting one but with some debugging symbols.  You should at least verify the
-      old and new sizes with the &man.size.1; command.  If there is a
-      mismatch, you probably need to give up here.</para>
-
-    <para>Go and examine the dump as described above.  The debugging symbols
-      might be incomplete for some places, as can be seen in the stack trace
-      in the example above where some functions are displayed without line
-      numbers and argument lists.  If you need more debugging symbols, remove
-      the appropriate object files, recompile the kernel again and repeat the
-      <command>gdb <option>-k</option></command>
-      session until you know enough.</para>
-
-    <para>All this is not guaranteed to work, but it will do it fine in most
-      cases.</para>
-  </sect1>
-
   <sect1 id="kerneldebug-online-ddb">
     <title>On-Line Kernel Debugging Using DDB</title>
 
@@ -769,65 +731,6 @@ Debugger (msg=0xf01b0383 "Boot flags requested debugger")
       window), etc.</para>
   </sect1>
 
-  <sect1 id="kerneldebug-kld">
-    <title>Debugging Loadable Modules Using GDB</title>
-
-    <para>When debugging a panic that occurred within a module, or
-      using remote GDB against a machine that uses dynamic modules,
-      you need to tell GDB how to obtain symbol information for those
-      modules.</para>
-
-    <para>First, you need to build the module(s) with debugging
-      information:</para>
-
-    <screen>&prompt.root; <userinput>cd /sys/modules/linux</userinput>
-&prompt.root; <userinput>make clean; make COPTS=-g</userinput></screen>
-
-    <para>If you are using remote GDB, you can run
-      <command>kldstat</command> on the target machine to find out
-      where the module was loaded:</para>
-
-    <screen>&prompt.root; <userinput>kldstat</userinput>
-Id Refs Address    Size     Name
- 1    4 0xc0100000 1c1678   kernel
- 2    1 0xc0a9e000 6000     linprocfs.ko
- 3    1 0xc0ad7000 2000     warp_saver.ko
- 4    1 0xc0adc000 11000    linux.ko</screen>
-
-    <para>If you are debugging a crash dump, you will need to walk the
-      <literal>linker_files</literal> list, starting at
-      <literal>linker_files-&gt;tqh_first</literal> and following the
-      <literal>link.tqe_next</literal> pointers until you find the
-      entry with the <literal>filename</literal> you are looking for.
-      The <literal>address</literal> member of that entry is the load
-      address of the module.</para>
-
-    <para>Next, you need to find out the offset of the text section
-      within the module:</para>
-
-    <screen>&prompt.root; <userinput>objdump --section-headers /sys/modules/linux/linux.ko | grep text</userinput>
-  3 .rel.text     000016e0  000038e0  000038e0  000038e0  2**2
- 10 .text         00007f34  000062d0  000062d0  000062d0  2**2</screen>
-
-    <para>The one you want is the <literal>.text</literal> section,
-      section 10 in the above example.  The fourth hexadecimal field
-      (sixth field overall) is the offset of the text section within
-      the file. Add this offset to the load address of the module to
-      obtain the relocation address for the module's code. In our
-      example, we get 0xc0adc000 + 0x62d0 = 0xc0ae22d0.  Use the
-      <command>add-symbol-file</command> command in GDB to tell the
-      debugger about the module:</para>
-
-    <screen><prompt>(kgdb)</prompt> <userinput>add-symbol-file /sys/modules/linux/linux.ko 0xc0ae22d0</userinput>
-add symbol table from file "/sys/modules/linux/linux.ko" at text_addr = 0xc0ae22d0?
-(y or n) <userinput>y</userinput>
-Reading symbols from /sys/modules/linux/linux.ko...done.
-<prompt>(kgdb)</prompt></screen>
-
-    <para>You should now have access to all the symbols in the
-      module.</para>
-  </sect1>
-
   <sect1 id="kerneldebug-console">
     <title>Debugging a Console Driver</title>