kdb kgdb and dump
Computer Protocol
Hi there,
Has anybody got some sort of a kernel debugger working for 386bsd ???
I'm desperate to get dump working. The previously suggested fix of
reducing the number of slaves to 1 doesn't work. I still have got
3 hanging dump processes. One of which is in a noninterruptable
disk i/o wait. For the moment I'm using tar but I would much
prefer dump. Any suggestions please ?!?
BTW where is 0.1 ? 8-(
Regards - Tibor Sashegyi (cpr...@abel.cs.curtin.edu.au)
Brad Parker
Has anybody got some sort of a kernel debugger working for 386bsd ???
no; gdb -k -w works, but you can't (or *I* can't) change any kernel memory
space because the process is not "running".
I'm desperate to get dump working. The previously suggested fix of
reducing the number of slaves to 1 doesn't work. I still have got
3 hanging dump processes. One of which is in a noninterruptable
disk i/o wait. For the moment I'm using tar but I would much
prefer dump. Any suggestions please ?!?
It worked for me! (i.e. changing SLAVES from 3 to 1); make sure you have the
ast fix.
-brad
--
A metaphor is like a simile.
Brad Parker Cayman Systems, Inc., Cambridge, Ma. br...@cayman.com
Mark W. Eichin
Well, Pace Willison <pa...@blitz.com> took the Mach386 Kernel Debugger
("DDB") and ported it to his version of 386BSD (an independent port of
4.3net2 using Mach386 for the hardware-dependent code...) I then took
his changes and got them working under Jolitz-386BSD. The changes went
back to Jolitz, and I've heard that the beta 0.1 release does have
them...
I'd rather see 0.1 come out than have people have to hack
these changes in themselves, but if you really want them now, email me
and I'll see about putting them up for ftp.
_Mark_ <eic...@athena.mit.edu>
MIT Student Information Processing Board
Cygnus Support <eic...@cygnus.com>
Bruce J. Keeler
>...
>I'm desperate to get dump working. The previously suggested fix of
>reducing the number of slaves to 1 doesn't work. I still have got
>3 hanging dump processes. One of which is in a noninterruptable
>disk i/o wait. For the moment I'm using tar but I would much
>prefer dump. Any suggestions please ?!?
>
I too had problems with dump - well rdump actually, though much worse than
hung processes. When I tried it trashed the root partition. Has anyone else
had this problem? Unfortunately I no longer have a 386BSD setup up so I can't
give you sample output (not sure if I would even if I did still have a setup!)
Off the top of my head, I think it mumbled something about bad disklabels,
so that would be the area to look to.
The system was a 486DX, AMI BIOS, WD1007v-se2 (I think) HD controller with
110Meg ESDI disk, 8 Meg ram.
I can't remember the disklabel I used, but it worked just fine otherwise with
no problems (well, after I'd commented out the 'Extra Interrupt' message from
wd.c!)
BTW, it trashed the root partition whether or not it was the root partition
being dumped.
--
Bruce J. Keeler - csc...@lancaster.ac.uk
Greg Lehey
I have a low-level debugger for BSD/386, which is *almost* complete. I
would imagine that it also would work on 386BSD. It is more or less
independent of the kernel, and thus can be used (or will be able to
when I've finished it) to debug just about any part of the kernel. The
down side of this is that it is not source-oriented, though it does
handle symbols.
Here a command summary:
Commands:
b: set breakpoint
b - lists all breakpoints
b <addr> [<type>] [<length>]
set a breakpoint at addr.
type is i (instruction breakpoint, default),
w (memory write breakpoint),
m (memory read/write breakpoint)
length is the number of bytes to be monitored (1, 2 or 4, default 4)
c continue execution. Traps will be handled by Lowbug.
d delete all breakpoints (requires confirmation)
d <num>: delete breakpoint number <num> (numbers listed by b command).
e [+|- <trap number> ...]
enable (+) or disable (-) catching trap <trap number>.
By default, the traps defined in the variable catch_trap are
caught. In any case, list currently caught traps
k connect to kgdb
kp call panic ("Lowbug")
l <n> show local stack frame <n> from esp to ebp inclusive
m [<addr>] [<value>]
modify memory (prompts for inputs, or one can be specified on the command line).
<addr> defaults to last address displayed + 4
n single step one instruction (only if entry via breakpoint)
p [<addr>] [<length>]: print data at <addr> for <length> bytes.
<addr> defaults to last address + 4 referred to by m or p commands.
<length> defaults to 128 initially, does not change implicitly
r display general registers
r <reg> [<value>]
display register contents, prompt for new value if none specified
R display all registers (including cr0-3, gdtr, ldtr, idtr)
s[<seg>] display segment information. Default: current TSS.
si[<seg>] display IDT information. Default: 0
t <num> stack trace from <num>th frame (default 0, maximum 4095)
t <addr> stack trace from <addr> (min 4096)
x exit from trap. A `c' will return to the caller - in the case of a trap, `x' will
return to the trap handler and `c' will return to the stored eip value, normally
invoker of the trap.
:<expr> set ``base'' to <expr>. This is intended to make life easier with 8-digit
addresses: instead of %fe234123, you can do :%fe234000 and then refer to addresses
as :123. Default value is 0xfe000000.
= <expr> evaluate expression and print in hex, decimal and character form
@ <expr> <symbol> Intern <symbol> with value <expr> into symbol list
^D: resume execution
^M (cr) execute last instruction *without operands*
Expressions:
<num> long value (decimal)
0x<num> long value (hex)
%<hexnum> long value (hex)
%<regname> contents of register <regname>
"char" long value (characters)
(<expr>) value of <expr>
*<expr> contents of memory location *<expr>
:<hexnum> ``base'' + <hexnum>
<expr> + <expr> sum
<expr> - <expr> difference
<expr> * <expr> product
<expr> / <expr> quotient (long integer)
<id> value of id
If anybody's interested, please contact me at
grog%le...@germany.eu.net (don't reply to this message, unido does
something horrible to my mail headers).
--
-------------------------------------------------------------------------------
Greg Lehey | Tel: +49-6637-1488
LEMIS | Fax: +49-6637-1489
*** NOTE ***: Headers are mangled - reply to grog%le...@Germany.EU.net
Scott Burris
>I too had problems with dump - well rdump actually, though much worse than
>hung processes. When I tried it trashed the root partition. Has anyone else
>had this problem? Unfortunately I no longer have a 386BSD setup up so I can't
>give you sample output (not sure if I would even if I did still have a setup!)
>Off the top of my head, I think it mumbled something about bad disklabels,
>so that would be the area to look to.
[Hand shoots up, waves widely in the air...]
Yes, I too have trashed my root partition in an attempt to use dump to
a borrowed Maynard 525MB SCSI drive. Got a number of wd: extra interrupt
messages and a bad disk label message. Had to restore from a multifloppy
tar that was, ahem, 2 months old.
On a backup related note, I now have an Archive DAT drive working with Pace's
SCSI driver. The drive will work fine in SCSI-1 mode. I had to make
some changes to get it to work in SCSI-2 mode. I'm not planning on
posting the diffs since I'd like to sync up the 0.1 release when it
comes out. The problem relates to the drive rejecting mode selects
when it has gone into unit attention following power-on.
--
----------
Scott Burris
UCLA Campus Network Services
cne...@oac.ucla.edu (213) 206-4860 - OR - sc...@pita.cns.ucla.edu