From owner-freebsd-hackers Fri Feb 7 11:36:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA14914 for hackers-outgoing; Fri, 7 Feb 1997 11:36:39 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA14906 for ; Fri, 7 Feb 1997 11:36:37 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id GAA14065; Sat, 8 Feb 1997 06:35:14 +1100 Date: Sat, 8 Feb 1997 06:35:14 +1100 From: Bruce Evans Message-Id: <199702071935.GAA14065@godzilla.zeta.org.au> To: gabor@acm.org, joerg_wunsch@uriah.heep.sax.de Subject: Re: Panic in probe, but no dump Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> > 1. Is there a way to load the kernel.debug in gdb and correlate >> > addresses with lines of code? (Like on HP-UX w/ xdb: one can use 'td') >> >> Basically, though a little hard. Please, read the section about >> kernel debugging in the handbook (gdb -k aka. kgdb). > >I did. Before I started all this. It seems that once I can single step >or have a dump it will print the addresses. In xdb I can 'td' (toggle >disassembly) and voila I see the machine instructions with line numbers >next to the ones that start a line. I'm looking for a similar feature. display/i $pc stepi ... >No, it did not. I guess there might be a bug in handling the panic. I >did have a dump device configured. I will triple-check this one. No >need to accuse the designer in case of pilot error. > >> > save the kernel core, or is it already on the swap device? Ie. what >> > macroscopic events would tell me that I got a dump? (Possibly: "core >> > dumped" msg on the console :-) >> >> Almost. Dumping to dev ...., followed by the number of outstanding >> megabytes to be dumped. > >That is good info, I didn't see anything like that. The panic message >printed the current EIP, then "waiting 15 seconds to reboot" or >something like that. It won't dump unless the driver for the dump device has been configured. Don't expect dumps to work if a panic occurs in a device driver probe/ attach. Who needs dumps? Just use remote gdb or (local) ddb on the running kernel. kerneldebug.sgml is a bit out of date - it doesn't mention remote gdb. >> Your best one. Note that you can also force a dump from within DDB by >> saying `panic' (followed by `c'). > >20.3. call diediedie(). I'll try that. ddb looks fairly similar to adb >on HP-UX. Probably share roots, too. Use the builtin panic command. diediedie() doesn't exist. kerneldebug.sgml is more than a bit out of date :-). >> > 7. Why is the "dumps on" feature being deprecated? How else can we get Because it may dump in the wrong place on incompletely configured disks. >> > a dump if the system crashes before dumpon can be executed? BTW, My `call setdumpdev(device_number)' in a debugger might work. Bruce