diff --git a/en_US.ISO8859-1/books/handbook/Makefile b/en_US.ISO8859-1/books/handbook/Makefile
index 6c2205dd7a..254f1bb2b2 100644
--- a/en_US.ISO8859-1/books/handbook/Makefile
+++ b/en_US.ISO8859-1/books/handbook/Makefile
@@ -1,97 +1,95 @@
#
-# $FreeBSD: doc/en_US.ISO8859-1/books/handbook/Makefile,v 1.39 2001/07/13 22:55:50 murray Exp $
+# $FreeBSD: doc/en_US.ISO8859-1/books/handbook/Makefile,v 1.40 2001/07/17 01:37:39 murray Exp $
#
# Build the FreeBSD Handbook.
#
# ------------------------------------------------------------------------
#
# Handbook-specific variables
#
# WITH_PGPKEYS The print version of the handbook only prints PGP
# fingerprints by default. If you would like for the
# entire key to be displayed, then set this variable.
# This option has no affect on the HTML formats.
#
# ------------------------------------------------------------------------
MAINTAINER=nik@FreeBSD.org
DOC?= book
FORMATS?= html-split
INSTALL_COMPRESSED?= gz
INSTALL_ONLY_COMPRESSED?=
IMAGES = advanced-networking/isdn-bus.eps
IMAGES+= advanced-networking/isdn-twisted-pair.eps
IMAGES+= advanced-networking/natd.eps
#
# SRCS lists the individual SGML files that make up the document. Changes
# to any of these files will force a rebuild
#
# SGML content
SRCS= book.sgml
SRCS+= advanced-networking/chapter.sgml
SRCS+= backups/chapter.sgml
SRCS+= basics/chapter.sgml
SRCS+= bibliography/chapter.sgml
SRCS+= config/chapter.sgml
SRCS+= boot/chapter.sgml
SRCS+= contrib/chapter.sgml
SRCS+= cutting-edge/chapter.sgml
SRCS+= disks/chapter.sgml
SRCS+= eresources/chapter.sgml
SRCS+= install/chapter.sgml
SRCS+= introduction/chapter.sgml
SRCS+= kernelconfig/chapter.sgml
-SRCS+= kernelopts/chapter.sgml
SRCS+= l10n/chapter.sgml
SRCS+= linuxemu/chapter.sgml
SRCS+= mail/chapter.sgml
SRCS+= mirrors/chapter.sgml
SRCS+= pgpkeys/chapter.sgml
SRCS+= ppp-and-slip/chapter.sgml
SRCS+= printing/chapter.sgml
SRCS+= security/chapter.sgml
SRCS+= serialcomms/chapter.sgml
SRCS+= sound/chapter.sgml
-SRCS+= staff/chapter.sgml
SRCS+= users/chapter.sgml
SRCS+= x11/chapter.sgml
SRCS+= ports/chapter.sgml
# Entities
SRCS+= authors.ent
SRCS+= chapters.ent
SYMLINKS= ${DESTDIR} index.html handbook.html
# Turn on all the chapters.
CHAPTERS?= ${SRCS:M*chapter.sgml}
JADEFLAGS+= ${CHAPTERS:S/\/chapter.sgml//:S/^/-i chap./}
# XXX The Handbook build currently overflows some internal, hardcoded
# limits in pdftex. Until we split the Handbook up, build the PDF
# version using ps2pdf instead of pdftex.
book.tex-pdf:
touch book.tex-pdf
book.pdf: book.ps
ps2pdf book.ps book.pdf
DOC_PREFIX?= ${.CURDIR}/../../..
#
# Handbook-specific variables
#
.if defined(WITH_PGPKEYS)
JADEFLAGS+= -V withpgpkeys
.endif
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
diff --git a/en_US.ISO8859-1/books/handbook/kerneldebug/Makefile b/en_US.ISO8859-1/books/handbook/kerneldebug/Makefile
deleted file mode 100644
index a6d190e942..0000000000
--- a/en_US.ISO8859-1/books/handbook/kerneldebug/Makefile
+++ /dev/null
@@ -1,15 +0,0 @@
-#
-# Build the Handbook with just the content from this chapter.
-#
-# $FreeBSD$
-#
-
-CHAPTERS= kerneldebug/chapter.sgml
-
-VPATH= ..
-
-MASTERDOC= ${.CURDIR}/../${DOC}.${DOCBOOKSUFFIX}
-
-DOC_PREFIX?= ${.CURDIR}/../../../..
-
-.include "../Makefile"
diff --git a/en_US.ISO8859-1/books/handbook/kerneldebug/chapter.sgml b/en_US.ISO8859-1/books/handbook/kerneldebug/chapter.sgml
deleted file mode 100644
index d29fc84ca2..0000000000
--- a/en_US.ISO8859-1/books/handbook/kerneldebug/chapter.sgml
+++ /dev/null
@@ -1,638 +0,0 @@
-
-
-
- Kernel Debugging
-
- Contributed by &a.paul; and &a.joerg;
-
-
- Debugging a Kernel Crash Dump with gdb
-
- Here are some instructions for getting kernel debugging working on a
- crash dump. They assume that you have enough swap space for a crash
- dump. If you have multiple swap partitions and the first one is too
- small to hold the dump, you can configure your kernel to use an
- alternate dump device (in the config kernel line), or
- you can specify an alternate using the
- &man.dumpon.8; command. The best way to use &man.dumpon.8; is to set
- the dumpdev variable in
- /etc/rc.conf. Typically you want to specify one of
- the swap devices specified in /etc/fstab. Dumps to
- non-swap devices, tapes for example, are currently not supported. Config
- your kernel using config . See Kernel Configuration for details on
- configuring the FreeBSD kernel.
-
- Use the &man.dumpon.8; command to tell the kernel where to dump to
- (note that this will have to be done after configuring the partition in
- question as swap space via &man.swapon.8;). This is normally arranged
- via /etc/rc.conf and /etc/rc.
- Alternatively, you can hard-code the dump device via the
- dump clause in the config line of
- your kernel config file. This is deprecated and should be used only if
- you want a crash dump from a kernel that crashes during booting.
-
-
- In the following, the term gdb refers to
- the debugger gdb run in kernel debug
- mode. This can be accomplished by starting the
- gdb with the option . In
- kernel debug mode, gdb changes its prompt to
- (kgdb).
-
-
-
- If you are using FreeBSD 3 or earlier, you should make a stripped
- copy of the debug kernel, rather than installing the large debug
- kernel itself:
-
- &prompt.root; cp kernel kernel.debug
-&prompt.root; strip -g kernel
-
- This stage isn't necessary, but it is recommended. (In
- FreeBSD 4 and later releases this step is performed automatically
- at the end of the kernel make process.)
- When the kernel has been stripped, either automatically or by
- using the commands above, you may install it as usual by typing
- make install.
-
- Note that older releases of FreeBSD (up to but not including
- 3.1) used a.out kernels by default, which must have their symbol
- tables permanently resident in physical memory. With the larger
- symbol table in an unstripped debug kernel, this is wasteful.
- Recent FreeBSD releases use ELF kernels where this is no longer a
- problem.
-
-
- If you are testing a new kernel, for example by typing the new
- kernel's name at the boot prompt, but need to boot a different one in
- order to get your system up and running again, boot it only into single
- user state using the flag at the boot prompt, and
- then perform the following steps:
-
- &prompt.root; fsck -p
-&prompt.root; mount -a -t ufs # so your file system for /var/crash is writable
-&prompt.root; savecore -N /kernel.panicked /var/crash
-&prompt.root; exit # ...to multi-user
-
- This instructs &man.savecore.8; to use another kernel for symbol
- name extraction. It would otherwise default to the currently running
- kernel and most likely not do anything at all since the crash dump and
- the kernel symbols differ.
-
- Now, after a crash dump, go to
- /sys/compile/WHATEVER and run
- gdb . From gdb do:
-
- symbol-file kernel.debug
-exec-file /var/crash/kernel.0
-core-file /var/crash/vmcore.0
-
- and voila, you can debug the crash dump using the kernel sources just
- like you can for any other program.
-
- Here is a script log of a gdb session
- illustrating the procedure. Long lines have been folded to improve
- readability, and the lines are numbered for reference. Despite this, it
- is a real-world error trace taken during the development of the pcvt
- console driver.
-
- 1:Script started on Fri Dec 30 23:15:22 1994
- 2:&prompt.root; cd /sys/compile/URIAH
- 3:&prompt.root; gdb -k kernel /var/crash/vmcore.1
- 4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel
-...done.
- 5:IdlePTD 1f3000
- 6:panic: because you said to!
- 7:current pcb at 1e3f70
- 8:Reading in symbols for ../../i386/i386/machdep.c...done.
- 9:(kgdb)where
-10:#0 boot (arghowto=256) (../../i386/i386/machdep.c line 767)
-11:#1 0xf0115159 in panic ()
-12:#2 0xf01955bd in diediedie () (../../i386/i386/machdep.c line 698)
-13:#3 0xf010185e in db_fncall ()
-14:#4 0xf0101586 in db_command (-266509132, -266509516, -267381073)
-15:#5 0xf0101711 in db_command_loop ()
-16:#6 0xf01040a0 in db_trap ()
-17:#7 0xf0192976 in kdb_trap (12, 0, -272630436, -266743723)
-18:#8 0xf019d2eb in trap_fatal (...)
-19:#9 0xf019ce60 in trap_pfault (...)
-20:#10 0xf019cb2f in trap (...)
-21:#11 0xf01932a1 in exception:calltrap ()
-22:#12 0xf0191503 in cnopen (...)
-23:#13 0xf0132c34 in spec_open ()
-24:#14 0xf012d014 in vn_open ()
-25:#15 0xf012a183 in open ()
-26:#16 0xf019d4eb in syscall (...)
-27:(kgdb)up 10
-28:Reading in symbols for ../../i386/i386/trap.c...done.
-29:#10 0xf019cb2f in trap (frame={tf_es = -260440048, tf_ds = 16, tf_\
-30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\
-31:2630396, tf_ebx = -266427884, tf_edx = 12, tf_ecx = -266427884, tf\
-32:_eax = 64772224, tf_trapno = 12, tf_err = -272695296, tf_eip = -26\
-33:6672343, tf_cs = -266469368, tf_eflags = 66066, tf_esp = 3072, tf_\
-34:ss = -266427884}) (../../i386/i386/trap.c line 283)
-35:283 (void) trap_pfault(&frame, FALSE);
-36:(kgdb)frame frame->tf_ebp frame->tf_eip
-37:Reading in symbols for ../../i386/isa/pcvt/pcvt_drv.c...done.
-38:#0 0xf01ae729 in pcopen (dev=3072, flag=3, mode=8192, p=(struct p\
-39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403)
-40:403 return ((*linesw[tp->t_line].l_open)(dev, tp));
-41:(kgdb)list
-42:398
-43:399 tp->t_state |= TS_CARR_ON;
-44:400 tp->t_cflag |= CLOCAL; /* cannot be a modem (:-) */
-45:401
-46:402 #if PCVT_NETBSD || (PCVT_FREEBSD >= 200)
-47:403 return ((*linesw[tp->t_line].l_open)(dev, tp));
-48:404 #else
-49:405 return ((*linesw[tp->t_line].l_open)(dev, tp, flag));
-50:406 #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */
-51:407 }
-52:(kgdb)print tp
-53:Reading in symbols for ../../i386/i386/cons.c...done.
-54:$1 = (struct tty *) 0x1bae
-55:(kgdb)print tp->t_line
-56:$2 = 1767990816
-57:(kgdb)up
-58:#1 0xf0191503 in cnopen (dev=0x00000000, flag=3, mode=8192, p=(st\
-59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c line 126)
-60: return ((*cdevsw[major(dev)].d_open)(dev, flag, mode, p));
-61:(kgdb)up
-62:#2 0xf0132c34 in spec_open ()
-63:(kgdb)up
-64:#3 0xf012d014 in vn_open ()
-65:(kgdb)up
-66:#4 0xf012a183 in open ()
-67:(kgdb)up
-68:#5 0xf019d4eb in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =\
-69: 2158592, tf_esi = 0, tf_ebp = -272638436, tf_isp = -272629788, tf\
-70:_ebx = 7086, tf_edx = 1, tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \
-71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \
-72:= -272638456, tf_ss = 39}) (../../i386/i386/trap.c line 673)
-73:673 error = (*callp->sy_call)(p, args, rval);
-74:(kgdb)up
-75:Initial frame selected; you cannot go up.
-76:(kgdb)quit
-77:&prompt.root; exit
-78:exit
-79:
-80:Script done on Fri Dec 30 23:18:04 1994
- Comments to the above script:
-
-
-
- line 6:
-
-
- This is a dump taken from within DDB (see below), hence the
- panic comment because you said to!, and a rather
- long stack trace; the initial reason for going into DDB has been a
- page fault trap though.
-
-
-
-
- line 20:
-
-
- This is the location of function trap()
- in the stack trace.
-
-
-
-
- line 36:
-
-
- Force usage of a new stack frame; this is no longer necessary
- now. The stack frames are supposed to point to the right
- locations now, even in case of a trap.
- From looking at the code in source line 403, there is a
- high probability that either the pointer access for
- tp was messed up, or the array access was out of
- bounds.
-
-
-
-
- line 52:
-
-
- The pointer looks suspicious, but happens to be a valid
- address.
-
-
-
-
- line 56:
-
-
- However, it obviously points to garbage, so we have found our
- error! (For those unfamiliar with that particular piece of code:
- tp->t_line refers to the line discipline of
- the console device here, which must be a rather small integer
- number.)
-
-
-
-
-
-
- Debugging a Crash Dump with DDD
-
- Examining a kernel crash dump with a graphical debugger like
- ddd is also possible. Add the
- option to the ddd command line you would use
- normally. For example;
-
- &prompt.root; ddd -k /var/crash/kernel.0 /var/crash/vmcore.0
-
- You should then be able to go about looking at the crash dump using
- ddd's graphical interface.
-
-
-
- Post-Mortem Analysis of a Dump
-
- What do you do if a kernel dumped core but you did not expect it,
- and it is therefore not compiled using config -g? Not
- everything is lost here. Do not panic!
-
- Of course, you still need to enable crash dumps. See above on the
- options you have to specify in order to do this.
-
- Go to your kernel config directory
- (/usr/src/sys/arch/conf)
- and edit your configuration file. Uncomment (or add, if it does not
- exist) the following line
-
- makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols
-
- Rebuild the kernel. Due to the time stamp change on the Makefile,
- there will be some other object files rebuild, for example
- trap.o. With a bit of luck, the added
- 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 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.
-
- 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 and repeat the gdb
- session until you know enough.
-
- All this is not guaranteed to work, but it will do it fine in most
- cases.
-
-
-
- On-Line Kernel Debugging Using DDB
-
- While gdb as an off-line debugger provides a very
- high level of user interface, there are some things it cannot do. The
- most important ones being breakpointing and single-stepping kernel
- code.
-
- If you need to do low-level debugging on your kernel, there is an
- on-line debugger available called DDB. It allows to setting
- breakpoints, single-stepping kernel functions, examining and changing
- kernel variables, etc. However, it cannot access kernel source files,
- and only has access to the global and static symbols, not to the full
- debug information like gdb.
-
- To configure your kernel to include DDB, add the option line
-
- options DDB
-
- to your config file, and rebuild. (See Kernel Configuration for details on
- configuring the FreeBSD kernel.
-
-
- If you have an older version of the boot blocks, your
- debugger symbols might not be loaded at all. Update the boot blocks;
- the recent ones load the DDB symbols automagically.)
-
-
- Once your DDB kernel is running, there are several ways to enter
- DDB. The first, and earliest way is to type the boot flag
- right at the boot prompt. The kernel will start up
- in debug mode and enter DDB prior to any device probing. Hence you can
- even debug the device probe/attach functions.
-
- The second scenario is a hot-key on the keyboard, usually
- Ctrl-Alt-ESC. For syscons, this can be remapped; some of the
- distributed maps do this, so watch out. There is an option available
- for serial consoles that allows the use of a serial line BREAK on the
- console line to enter DDB (options BREAK_TO_DEBUGGER
- in the kernel config file). It is not the default since there are a lot
- of low quality serial adapters around that gratuitously generate a BREAK
- condition, for example when pulling the cable.
-
- The third way is that any panic condition will branch to DDB if the
- kernel is configured to use it. For this reason, it is not wise to
- configure a kernel with DDB for a machine running unattended.
-
- The DDB commands roughly resemble some gdb
- commands. The first thing you probably need to do is to set a
- breakpoint:
-
- b function-name
-b address
-
- Numbers are taken hexadecimal by default, but to make them distinct
- from symbol names; hexadecimal numbers starting with the letters
- a-f need to be preceded with 0x
- (this is optional for other numbers). Simple expressions are allowed,
- for example: function-name + 0x103.
-
- To continue the operation of an interrupted kernel, simply
- type:
-
- c
-
- To get a stack trace, use:
-
- trace
-
-
- Note that when entering DDB via a hot-key, the kernel is currently
- servicing an interrupt, so the stack trace might be not of much use
- for you.
-
-
- If you want to remove a breakpoint, use
-
-
- del
-del address-expression
-
- The first form will be accepted immediately after a breakpoint hit,
- and deletes the current breakpoint. The second form can remove any
- breakpoint, but you need to specify the exact address; this can be
- obtained from:
-
- show b
-
- To single-step the kernel, try:
-
- s
-
- This will step into functions, but you can make DDB trace them until
- the matching return statement is reached by:
-
- n
-
-
- This is different from gdb's
- next statement; it is like gdb's
- finish.
-
-
- To examine data from memory, use (for example):
-
- x/wx 0xf0133fe0,40
-x/hd db_symtab_space
-x/bc termbuf,10
-x/s stringbuf
-
- for word/halfword/byte access, and hexadecimal/decimal/character/ string
- display. The number after the comma is the object count. To display
- the next 0x10 items, simply use:
-
- x ,10
-
- Similarly, use
-
- x/ia foofunc,10
-
- to disassemble the first 0x10 instructions of
- foofunc, and display them along with their offset
- from the beginning of foofunc.
-
- To modify memory, use the write command:
-
- w/b termbuf 0xa 0xb 0
-w/w 0xf0010030 0 0
-
- The command modifier
- (b/h/w)
- specifies the size of the data to be written, the first following
- expression is the address to write to and the remainder is interpreted
- as data to write to successive memory locations.
-
- If you need to know the current registers, use:
-
- show reg
-
- Alternatively, you can display a single register value by e.g.
-
- p $eax
-
- and modify it by:
-
- set $eax new-value
-
- Should you need to call some kernel functions from DDB, simply
- say:
-
- call func(arg1, arg2, ...)
-
- The return value will be printed.
-
- For a &man.ps.1; style summary of all running processes, use:
-
- ps
-
- Now you have examined why your kernel failed, and you wish to
- reboot. Remember that, depending on the severity of previous
- malfunctioning, not all parts of the kernel might still be working as
- expected. Perform one of the following actions to shut down and reboot
- your system:
-
- panic
-
- This will cause your kernel to dump core and reboot, so you can
- later analyze the core on a higher level with gdb. This command
- usually must be followed by another continue
- statement.
-
- call boot(0)
-
- Which might be a good way to cleanly shut down the running system,
- sync() all disks, and finally reboot. As long as
- the disk and file system interfaces of the kernel are not damaged, this
- might be a good way for an almost clean shutdown.
-
- call cpu_reset()
-
- is the final way out of disaster and almost the same as hitting the
- Big Red Button.
-
- If you need a short command summary, simply type:
-
- help
-
- However, it is highly recommended to have a printed copy of the
- &man.ddb.4; manual page ready for a debugging
- session. Remember that it is hard to read the on-line manual while
- single-stepping the kernel.
-
-
-
- On-Line Kernel Debugging Using Remote GDB
-
- This feature has been supported since FreeBSD 2.2, and it is
- actually a very neat one.
-
- GDB has already supported remote debugging for
- a long time. This is done using a very simple protocol along a serial
- line. Unlike the other methods described above, you will need two
- machines for doing this. One is the host providing the debugging
- environment, including all the sources, and a copy of the kernel binary
- with all the symbols in it, and the other one is the target machine that
- simply runs a similar copy of the very same kernel (but stripped of the
- debugging information).
-
- You should configure the kernel in question with config
- -g, include into the configuration, and
- compile it as usual. This gives a large blurb of a binary, due to the
- debugging information. Copy this kernel to the target machine, strip
- the debugging symbols off with strip -x, and boot it
- using the boot option. Connect the serial line
- of the target machine that has "flags 080" set on its sio device
- to any serial line of the debugging host.
- Now, on the debugging machine, go to the compile directory of the target
- kernel, and start gdb:
-
- &prompt.user; gdb -k kernel
-GDB is free software and you are welcome to distribute copies of it
- under certain conditions; type "show copying" to see the conditions.
-There is absolutely no warranty for GDB; type "show warranty" for details.
-GDB 4.16 (i386-unknown-freebsd),
-Copyright 1996 Free Software Foundation, Inc...
-(kgdb)
-
- Initialize the remote debugging session (assuming the first serial
- port is being used) by:
-
- (kgdb)target remote /dev/cuaa0
-
- Now, on the target host (the one that entered DDB right before even
- starting the device probe), type:
-
- Debugger("Boot flags requested debugger")
-Stopped at Debugger+0x35: movb $0, edata+0x51bc
-db>gdb
-
- DDB will respond with:
-
- Next trap will enter GDB remote protocol mode
-
- Every time you type gdb, the mode will be toggled
- between remote GDB and local DDB. In order to force a next trap
- immediately, simply type s (step). Your hosting GDB
- will now gain control over the target kernel:
-
- Remote debugging using /dev/cuaa0
-Debugger (msg=0xf01b0383 "Boot flags requested debugger")
- at ../../i386/i386/db_interface.c:257
-(kgdb)
-
- You can use this session almost as any other GDB session, including
- full access to the source, running it in gud-mode inside an Emacs window
- (which gives you an automatic source code display in another Emacs
- window) etc.
-
-
-
- Debugging Loadable Modules Using GDB
-
- 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.
-
- First, you need to build the module(s) with debugging
- information:
-
- &prompt.root; cd /sys/modules/linux
-&prompt.root; make clean; make COPTS=-g
-
- If you are using remote GDB, you can run
- kldstat on the target machine to find out
- where the module was loaded:
-
- &prompt.root; kldstat
-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
-
- If you are debugging a crash dump, you'll need to walk the
- linker_files list, starting at
- linker_files->tqh_first and following the
- link.tqe_next pointers until you find the
- entry with the filename you are looking for.
- The address member of that entry is the load
- address of the module.
-
- Next, you need to find out the offset of the text section
- within the module:
-
- &prompt.root; objdump --section-headers /sys/modules/linux/linux.ko | grep text
- 3 .rel.text 000016e0 000038e0 000038e0 000038e0 2**2
- 10 .text 00007f34 000062d0 000062d0 000062d0 2**2
-
- The one you want is the .text 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
- add-symbol-file command in GDB to tell the
- debugger about the module:
-
- (kgdb)add-symbol-file /sys/modules/linux/linux.ko 0xc0ae22d0
-add symbol table from file "/sys/modules/linux/linux.ko" at text_addr = 0xc0ae22d0?
-(y or n) y
-Reading symbols from /sys/modules/linux/linux.ko...done.
-(kgdb)
-
- You should now have access to all the symbols in the
- module.
-
-
-
- Debugging a Console Driver
-
- Since you need a console driver to run DDB on, things are more
- complicated if the console driver itself is failing. You might remember
- the use of a serial console (either with modified boot blocks, or by
- specifying at the Boot: prompt),
- and hook up a standard terminal onto your first serial port. DDB works
- on any configured console driver, of course also on a serial
- console.
-
-
-
-
-
diff --git a/en_US.ISO8859-1/books/handbook/staff/Makefile b/en_US.ISO8859-1/books/handbook/staff/Makefile
deleted file mode 100644
index 2d9e5275ea..0000000000
--- a/en_US.ISO8859-1/books/handbook/staff/Makefile
+++ /dev/null
@@ -1,15 +0,0 @@
-#
-# Build the Handbook with just the content from this chapter.
-#
-# $FreeBSD$
-#
-
-CHAPTERS= staff/chapter.sgml
-
-VPATH= ..
-
-MASTERDOC= ${.CURDIR}/../${DOC}.${DOCBOOKSUFFIX}
-
-DOC_PREFIX?= ${.CURDIR}/../../../..
-
-.include "../Makefile"
diff --git a/en_US.ISO8859-1/books/handbook/staff/chapter.sgml b/en_US.ISO8859-1/books/handbook/staff/chapter.sgml
deleted file mode 100644
index f806b1f3e5..0000000000
--- a/en_US.ISO8859-1/books/handbook/staff/chapter.sgml
+++ /dev/null
@@ -1,1419 +0,0 @@
-
-
-
-
-
- FreeBSD Project Staff
-
- The FreeBSD Project is managed and operated by the following groups of
- people:
-
-
- The FreeBSD Core Team
-
- The FreeBSD core team constitutes the project's Board of
- Directors, responsible for deciding the project's overall goals
- and direction as well as managing specific
- areas of the FreeBSD project landscape.
-
- (in alphabetical order by last name):
-
-
-
- &a.asami;
-
-
-
- &a.dg;
-
-
-
- &a.jkh;
-
-
-
- &a.grog;
-
-
-
- &a.imp;
-
-
-
- &a.dfr;
-
-
-
- &a.msmith;
-
-
-
- &a.rwatson;
-
-
-
- &a.peter;
-
-
-
-
-
-
-
- The FreeBSD Developers
-
- These are the people who have commit privileges and do the
- engineering work on the FreeBSD source tree. All core team members are
- also developers.
-
-
-
- &a.akiyama;
-
-
-
- &a.jmas;
-
-
-
- &a.will;
-
-
-
- &a.ugen;
-
-
-
- &a.toshi;
-
-
-
- &a.babkin;
-
-
-
- &a.dbaker;
-
-
-
- &a.jhb;
-
-
-
- &a.dmlb;
-
-
-
- &a.mike;
-
-
-
- &a.mbarkah;
-
-
-
- &a.rvb;
-
-
-
- &a.dougb;
-
-
-
- &a.tobez;
-
-
-
- &a.stb;
-
-
-
- &a.pb;
-
-
-
- &a.abial;
-
-
-
- &a.jb;
-
-
-
- &a.nbm;
-
-
-
- &a.mb;
-
-
-
- &a.bbraun;
-
-
-
- &a.jmb;
-
-
-
- &a.torstenb;
-
-
-
- &a.wilko;
-
-
-
- &a.jake;
-
-
-
- &a.dburr;
-
-
-
- &a.adrian;
-
-
-
- &a.dwcjr;
-
-
-
- &a.charnier;
-
-
-
- &a.jon;
-
-
-
- &a.luoqi;
-
-
-
- &a.ache;
-
-
-
- &a.ejc;
-
-
-
- &a.kjc;
-
-
-
- &a.cjh;
-
-
-
- &a.cjc;
-
-
-
- &a.nik;
-
-
-
- &a.archie;
-
-
-
- &a.chris;
-
-
-
- &a.alc;
-
-
-
- &a.cracauer;
-
-
-
- &a.dec;
-
-
-
- &a.pds;
-
-
-
- &a.adam;
-
-
-
- &a.brooks;
-
-
-
- &a.bsd;
-
-
-
- &a.jwd;
-
-
-
- &a.dillon;
-
-
-
- &a.mdodd;
-
-
-
- &a.dd;
-
-
-
- &a.iedowse;
-
-
-
- &a.gad;
-
-
-
- &a.dufault;
-
-
-
- &a.uhclem;
-
-
-
- &a.tegge;
-
-
-
- &a.deischen;
-
-
-
- &a.eivind;
-
-
-
- &a.julian;
-
-
-
- &a.rse;
-
-
-
- &a.ue;
-
-
-
- &a.ru;
-
-
-
- &a.se;
-
-
-
- &a.bde;
-
-
-
- &a.jasone;
-
-
-
- &a.sef;
-
-
-
- &a.jedgar;
-
-
-
- &a.green;
-
-
-
- &a.fenner;
-
-
-
- &a.lioux;
-
-
-
- &a.jfieber;
-
-
-
- &a.jfitz;
-
-
-
- &a.scrappy;
-
-
-
- &a.lars;
-
-
-
- &a.dirk;
-
-
-
- &a.sf;
-
-
-
- &a.shige;
-
-
-
- &a.billf;
-
-
-
- &a.furuta;
-
-
-
- &a.gallatin;
-
-
-
- &a.patrick;
-
-
-
- &a.tg;
-
-
-
- &a.gibbs;
-
-
-
- &a.brandon;
-
-
-
- &a.gioria;
-
-
-
- &a.graichen;
-
-
-
- &a.cg;
-
-
-
- &a.rgrimes;
-
-
-
- &a.jmg;
-
-
-
- &a.hanai;
-
-
-
- &a.roger;
-
-
-
- &a.mharo;
-
-
-
- &a.dannyboy;
-
-
-
- &a.thepish;
-
-
-
- &a.jhay;
-
-
-
- &a.sheldonh;
-
-
-
- &a.mikeh;
-
-
-
- &a.helbig;
-
-
-
- &a.ghelmer;
-
-
-
- &a.erich;
-
-
-
- &a.chm;
-
-
-
- &a.nhibma;
-
-
-
- &a.flathill;
-
-
-
- &a.orion;
-
-
-
- &a.pho;
-
-
-
- &a.horikawa;
-
-
-
- &a.hosokawa;
-
-
-
- &a.jeh;
-
-
-
- &a.hsu;
-
-
-
- &a.foxfair;
-
-
-
- &a.tom;
-
-
-
- &a.mph;
-
-
-
- &a.imura;
-
-
-
- &a.shin;
-
-
-
- &a.itojun;
-
-
-
- &a.iwasaki;
-
-
-
- &a.mjacob;
-
-
-
- &a.keith;
-
-
-
- &a.gj;
-
-
-
- &a.trevor;
-
-
-
- &a.phk;
-
-
-
- &a.tomsoft;
-
-
-
- &a.joe;
-
-
-
- &a.cokane;
-
-
-
- &a.kato;
-
-
-
- &a.kris;
-
-
-
- &a.kiri;
-
-
-
- &a.andreas;
-
-
-
- &a.lkoeller;
-
-
-
- &a.motoyuki;
-
-
-
- &a.jkoshy;
-
-
-
- &a.kuriyama;
-
-
-
- &a.alex;
-
-
-
- &a.chern;
-
-
-
- &a.reg;
-
-
-
- &a.jlemon;
-
-
-
- &a.truckman;
-
-
-
- &a.ijliao;
-
-
-
- &a.lile;
-
-
-
- &a.clive;
-
-
-
- &a.kevlo;
-
-
-
- &a.scottl;
-
-
-
- &a.ade;
-
-
-
- &a.jmacd;
-
-
-
- &a.smace;
-
-
-
- &a.bmah;
-
-
-
- &a.dwmalone;
-
-
-
- &a.mckay;
-
-
-
- &a.mckusick;
-
-
-
- &a.eric;
-
-
-
- &a.ken;
-
-
-
- &a.dinoex;
-
-
-
- &a.hm;
-
-
-
- &a.sanpei;
-
-
-
- &a.bmilekic;
-
-
-
- &a.mita;
-
-
-
- &a.non;
-
-
-
- &a.jim;
-
-
-
- &a.marcel;
-
-
-
- &a.dan;
-
-
-
- &a.tmm;
-
-
-
- &a.amurai;
-
-
-
- &a.markm;
-
-
-
- &a.rich;
-
-
-
- &a.knu;
-
-
-
- &a.nakai;
-
-
-
- &a.max;
-
-
-
- &a.newton;
-
-
-
- &a.rnordier;
-
-
-
- &a.davidn;
-
-
-
- &a.obrien;
-
-
-
- &a.danny;
-
-
-
- &a.okazaki;
-
-
-
- &a.olgeni;
-
-
-
- &a.ljo;
-
-
-
- &a.onoe;
-
-
-
- &a.marko;
-
-
-
- &a.gpalmer;
-
-
-
- &a.fsmp;
-
-
-
- &a.smpatel;
-
-
-
- &a.cp;
-
-
-
- &a.wpaul;
-
-
-
- &a.mp;
-
-
-
- &a.alfred;
-
-
-
- &a.roam;
-
-
-
- &a.wes;
-
-
-
- &a.cpiazza;
-
-
-
- &a.pirzyk;
-
-
-
- &a.jdp;
-
-
-
- &a.bp;
-
-
-
- &a.steve;
-
-
-
- &a.mpp;
-
-
-
- &a.markp;
-
-
-
- &a.darrenr;
-
-
-
- &a.csgr;
-
-
-
- &a.greid;
-
-
-
- &a.martin;
-
-
-
- &a.benno;
-
-
-
- &a.luigi;
-
-
-
- &a.paul;
-
-
-
- &a.roberto;
-
-
-
- &a.chuckr;
-
-
-
- &a.jesusr;
-
-
-
- &a.guido;
-
-
-
- &a.groudier;
-
-
-
- &a.dima;
-
-
-
- &a.asmodai;
-
-
-
- &a.ps;
-
-
-
- &a.sada;
-
-
-
- &a.hrs;
-
-
-
- &a.wsanchez;
-
-
-
- &a.nsayer;
-
-
-
- &a.sos;
-
-
-
- &a.wosch;
-
-
-
- &a.schweikh;
-
-
-
- &a.dick;
-
-
-
- &a.jseger;
-
-
-
- &a.semenu;
-
-
-
- &a.gshapiro;
-
-
-
- &a.shiba;
-
-
-
- &a.tshiozak;
-
-
-
- &a.simokawa;
-
-
-
- &a.vanilla;
-
-
-
- &a.silby;
-
-
-
- &a.shafeeq;
-
-
-
- &a.demon;
-
-
-
- &a.jesper;
-
-
-
- &a.msmith;
-
-
-
- &a.ben;
-
-
-
- &a.nsouch;
-
-
-
- &a.issei;
-
-
-
- &a.des;
-
-
-
- &a.sobomax;
-
-
-
- &a.dcs;
-
-
-
- &a.brian;
-
-
-
- &a.mks;
-
-
-
- &a.stark;
-
-
-
- &a.murray;
-
-
-
- &a.sumikawa;
-
-
-
- &a.gsutter;
-
-
-
- &a.unfurl;
-
-
-
- &a.nyan;
-
-
-
- &a.tanimura;
-
-
-
- &a.taoka;
-
-
-
- &a.mtaylor;
-
-
-
- &a.dt;
-
-
-
- &a.mi;
-
-
-
- &a.yar;
-
-
-
- &a.cwt;
-
-
-
- &a.pst;
-
-
-
- &a.ume;
-
-
-
- &a.rv;
-
-
-
- &a.hoek;
-
-
-
- &a.nectar;
-
-
-
- &a.jayanth;
-
-
-
- &a.wjv;
-
-
-
- &a.bean;
-
-
-
- &a.swallace;
-
-
-
- &a.takawata;
-
-
-
- &a.assar;
-
-
-
- &a.dwhite;
-
-
-
- &a.nate;
-
-
-
- &a.wollman;
-
-
-
- &a.keichii;
-
-
-
- &a.joerg;
-
-
-
- &a.kbyanc;
-
-
-
- &a.uch;
-
-
-
- &a.yokota;
-
-
-
- &a.andy;
-
-
-
- &a.zarzycki;
-
-
-
- &a.phantom;
-
-
-
- &a.jmz;
-
-
-
-
-
-
-
-
- The FreeBSD Documentation Project
-
- The FreeBSD
- Documentation Project is responsible for a number of different
- services, each service being run by an individual and his
- deputies (if any):
-
-
-
- Documentation Project Architect
-
-
- &a.nik;
-
-
-
-
- Handbook Editor
-
-
- &a.jim;
-
-
-
-
- FAQ Editor
-
-
- &a.faq;
-
-
-
-
- News Editor
-
-
- &a.jim;
-
-
-
-
-
- In the Press Editor
-
-
- &a.jkoshy;
-
-
-
-
- FreeBSD Really-Quick NewsLetter Editor
-
-
- Chris Coleman chrisc@vmunix.com
-
-
-
-
- Gallery Editor
-
-
- &a.phantom;
-
-
-
-
- Commercial Editor
-
-
- &a.phantom;
-
-
-
-
- Web Changes Editor
-
-
- &a.www;
-
-
-
-]]>
-
-
- User Groups Editor
-
-
- &a.grog;
-
-
-
-
- FreeBSD Projects and Tasklist Editor
-
-
- &a.asmodai;
-
-
-
-
- FreeBSD Java Project
-
-
- &a.patrick;
-
-
-
-
- LinuxDoc to DocBook conversion
-
-
- &a.nik;
-
-
-
-
-
-
- Who is Responsible for What
-
-
-
- Documentation
- Project Manager
-
-
- &a.nik;
-
-
-
-
- Boot blocks
-
-
- &a.rnordier;, &a.jhb;
-
-
-
-
- Boot loader
-
-
- &a.dcs;
- &a.jhb;
-
-
-
-
- Internationalization
-
-
- &a.ache;
-
-
-
-
- Postmaster
-
-
- &a.jmb;
-
-
-
-
- Release Coordinator
-
-
- &a.jkh;
-
-
-
-
- Public Relations & Corporate Liaison
-
-
- &a.jkh;
-
-
-
-
- Security
- Officer
-
-
- &a.kris;
-
-
-
-
- Source
- Repository Managers
-
-
- Principal: &a.peter;
-
- Assistant: &a.jdp;
-
-
-
-
- Ports
- Manager
-
-
- &a.asami;
-
-
-
-
- Standards
-
-
- &a.wollman;
-
-
-
-
- XFree86 Project, Inc. Liaison
-
-
- &a.rich;
-
-
-
-
- GNATS
- Administrator
-
-
- &a.steve;
-
-
-
-
-
-
-
-
-