From owner-freebsd-hackers Fri Feb 7 10:23:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA10998 for hackers-outgoing; Fri, 7 Feb 1997 10:23:44 -0800 (PST) Received: from humvee.doit.wisc.edu (humvee.doit.wisc.edu [144.92.9.20]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA10993 for ; Fri, 7 Feb 1997 10:23:42 -0800 (PST) Received: from audumla.students.wisc.edu by humvee.doit.wisc.edu; id MAA78216; 8.7.5/50; Fri, 7 Feb 1997 12:23:35 -0600 Received: from gabor-bsd by audumla.students.wisc.edu; id MAA66696; 8.6.9W/42; Fri, 7 Feb 1997 12:21:06 -0600 Message-ID: <32FB72E0.2781E494@acm.org> Date: Fri, 07 Feb 1997 12:22:24 -0600 From: Gabor Kincses X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 2.1.5-RELEASE i386) MIME-Version: 1.0 To: Joerg Wunsch CC: freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in probe, but no dump References: <32FA29A1.41C67EA6@acm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: > > (Mailing lists trimmed. Whenever you feel like posting to more than > one list, you probably feel wrong. ;-) Desperation speeds up the fingers and slows down the gray stuff. > As Gabor Kincses wrote: > > > The problem I have is to get a dump out of the sound driver probe. I > > pretty much followed the handbook on this. I have set config root on > > wd2 dumps on wd2 in my config file, but no dump occurred (I checked . I > > Well, the normal sequence is to use `dumpon'. This is also supported > by /etc/sysconfig. AFAIK that is not an option here, since we are not executing /etc/rc, yet. > > 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. > > 2. Why am I not getting a core dump? > > No idea. What did the kernel say? Did it say ``dumping to ...''? 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. > > 3. I have turned on savecore in /etc/sysconfig, but I have noticed that > > the swapon gets executed first in /etc/rc before the savecore. Wouldn't > > this wipe out a core in the swap device? > > No. The dump is done to the end of the swap partition. > > > 5. Is my only option left is ddb? > > 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. > > 6. Is a page fault essentially like a segmentation violation in user > > mode? AFAIK on i386 you have to install a page fault handler, which is > > probably what the VM is all about. Is this true? > > Well, basically. A page fault normally tries to see if it has to load > a page from secondary storage. If there's no page to load, it will be > reported. By a SIGSEGV to a user process, by a panic (or a jump into > DDB) in the kernel. > > > 7. Why is the "dumps on" feature being deprecated? How else can we get > > a dump if the system crashes before dumpon can be executed? BTW, My > Thanks for your help. DDB here I come! -- Gabor Kincses (gabor@acm.org)