Re: kernel debugging question
Giorgos Keramidas wrote:
On 2006-01-07 17:17, Tofik Suleymanov <[EMAIL PROTECTED]> wrote:
Reading through http://www.netbsd.org i've met this:
Forcing code to enter DDB
Ensure your kernel config file contains '|options DDB|', the file has
'|#include "opt_ddb.h"|', then use '|Debugger()|'.
...
Does this work on FreeBSD also ?
This is slightly different in FreeBSD. You have to call:
#include
kdb_enter(NULL); /* Enter without a message */
or
#include
kdb_enter("Forced into debugger by Giorgos");
Thank you :)
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel debugging question
On 2006-01-07 17:17, Tofik Suleymanov <[EMAIL PROTECTED]> wrote:
> Reading through http://www.netbsd.org i've met this:
>
>Forcing code to enter DDB
>
> Ensure your kernel config file contains '|options DDB|', the file has
> '|#include "opt_ddb.h"|', then use '|Debugger()|'.
>
> ...
>
> Does this work on FreeBSD also ?
This is slightly different in FreeBSD. You have to call:
#include
kdb_enter(NULL);/* Enter without a message */
or
#include
kdb_enter("Forced into debugger by Giorgos");
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kernel debugging question
Reading through http://www.netbsd.org i've met this: Forcing code to enter DDB Ensure your kernel config file contains '|options DDB|', the file has '|#include "opt_ddb.h"|', then use '|Debugger()|'. ... Does this work on FreeBSD also ? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel debugging question
On Friday 23 April 2004 00:42, Greg 'groggy' Lehey wrote:
> [Format recovered--see http://www.lemis.com/email/email-format.html]
>
> Wrapped text still broken.
>
> On Thursday, 22 April 2004 at 16:45:11 +0200, Jorn Argelo wrote:
> > On Thursday, 22 April 2004 at 4:18:52 +0200, Gregg 'groggy' Lehey wrote:
> >> On Monday, 19 April 2004 at 14:46:57 +0200, Jorn Argelo wrote:
> >>> I currently have a backtrace, a chunk of source code which probably
> >>> causes the panic, and some register output. I haven't read all 99
> >>> pages of your documentation, but hopefully it'll be enough. Send me
> >>> a mail when you have time, and I'll mail you the contents. (The
> >>> source code is quite long, so posting everything in a single mail is
> >>> not a good idea). I can drop a mail at the current folks as well, if
> >>> you prefer that.
> >>
> >> Put it on the -questions list for now. It could be instructive.
> >
> > Alright, I've added the below mentioned information (backtrace,
> > register info and the chunk of source code) as an attachment(34KB)
> > It also contains an ps -ax output, and some other kernel messages
> > which might be of use.
> >
> >
> > Thanks Greg, I look forward to your reply.
> >
> > Jorn
> >
> > P.S: I did notice your signature, but I thought about it the moment
> > I pressed the send button. Sorry about that. I'll make sure everything
> > will remain as it was.
>
> You seem to have missed (again):
Excuse my, perhaps dumb, remark, but I kept everything the way it was. I don't
understand what I'm doing wrong then. I used Outlook (bad me) before, but I'm
using KMail now. Perhaps something went wrong with the format which I am
unaware of. Hopefully things will go better now.
> >>> When replying to this message, please copy the original recipients.
> >>> If you don't, I may ignore the reply or reply to the original
> >>> recipients.
> >>> For more information, see http://www.lemis.com/questions.html
> >
> > [EMAIL PROTECTED] ~/dump# gdb -k /boot/kernel/kernel.debug
> > /usr/home/jorn/dump/vmcore.0 ...
> > (kgdb) bt
> >
> > #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
> > #1 0xc0520da2 in boot (howto=256) at
> > /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc05210d7 in panic () at
> > /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc0647866 in trap_fatal
> > (frame=0xcdcb7bac, eva=0)
> > at /usr/src/sys/i386/i386/trap.c:821
> > #4 0xc0646f13 in trap (frame=
> > {tf_fs = -1066532840, tf_es = 16, tf_ds = -1066991600, tf_edi =
> > -1049879296, tf_esi = 1, tf_ebp = -842302460, tf_isp = -842302504, tf_ebx
> > = -842302241, tf_edx = -1066500160, tf_ecx = -1049858920, tf_eax = 0,
> > tf_trapno = 12, tf_err = 2, tf_eip = -842302481, tf_cs = 8, tf_eflags =
> > 67714, tf_esp = -1049902208, tf_ss = 0}) at
> > /usr/src/sys/i386/i386/trap.c:250 #5 0xc0638f48 in calltrap () at
> > {standard input}:94
> > #6 0xc064a209 in clkintr (frame=0xcdcb7cdf)
> > at /usr/src/sys/i386/isa/clock.c:193
> > #7 0xc063d078 in intr_execute_handlers (isrc=0xc06d9fe0, iframe=0x1)
> > at /usr/src/sys/i386/i386/intr_machdep.c:192
> > #8 0xc0649d1f in atpic_handle_intr (iframe=
> > {if_vec = 0, if_fs = 24, if_es = 16, if_ds = -1026949104, if_edi =
> > -1026910720, if_esi = -1026910696, if_ebp = -842302280, if_ebx =
> > -1049871268, if_edx = 0, if_ecx = -1026910048, if_eax = 1, if_eip =
> > -1063719291, if_cs = 8, if_eflags = 582, if_esp = -842302232, if_ss =
> > -1063719867}) at /usr/src/sys/i386/isa/atpic.c:368
> > #9 0xc0649e7e in Xatpic_intr0 () at {standard input}:32
> > #10 0xc098ec45 in acpi_cpu_idle () at
> > /usr/src/sys/dev/acpica/acpi_cpu.c:830 #11 0xc063f3af in cpu_idle () at
> > /usr/src/sys/i386/i386/machdep.c:1074 #12 0xc050da48 in idle_proc
> > (dummy=0x0) at /usr/src/sys/kern/kern_idle.c:86 #13 0xc050d7ee in
> > fork_exit (callout=0xc050da30 , arg=0x0, frame=0x0) at
> > /usr/src/sys/kern/kern_fork.c:793
>
> Interesting one. You've had a trap in the clock interrupt code, which
> suggests some type of memory corruption. This could be difficult to
> debug.
>
> > (kgdb) l
> > 235 static void
> > 236 doadump(void)
> > 237 {
> > 238
> > 239 savectx(&dumppcb);
> > 240 dumping++;
> > 241 dumpsys(&dumper);
> > 242 }
>
> As shown on page 45 and 46, the frame you're looking for is the one
> below trap. This is the code at frame 0, showing how the system
> dumps. It's not related to the problem. Take a look at page 46 and
> send me the information for frame 6.
Hopefully I'm doing it right like this. I'm not sure if you just wanted one
list as mentioned below or the entire source code.
(kgdb) f 6
#6 0xc064a209 in clkintr (frame=0xcdcb7cdf)
at /usr/src/sys/i386/isa/clock.c:193
193 timer_func(frame);
Current language: auto; currently c
(kgdb) l
188 i8254_lastcount = 0;
189 }
190 clkintr_pending = 0;
191 mtx_unlock_spin(&clock_lock);
Re: Kernel debugging question
[Format recovered--see http://www.lemis.com/email/email-format.html]
Wrapped text still broken.
On Thursday, 22 April 2004 at 16:45:11 +0200, Jorn Argelo wrote:
> On Thursday, 22 April 2004 at 4:18:52 +0200, Gregg 'groggy' Lehey wrote:
>> On Monday, 19 April 2004 at 14:46:57 +0200, Jorn Argelo wrote:
>>> I currently have a backtrace, a chunk of source code which probably
>>> causes the panic, and some register output. I haven't read all 99
>>> pages of your documentation, but hopefully it'll be enough. Send me
>>> a mail when you have time, and I'll mail you the contents. (The
>>> source code is quite long, so posting everything in a single mail is
>>> not a good idea). I can drop a mail at the current folks as well, if
>>> you prefer that.
>
>> Put it on the -questions list for now. It could be instructive.
>
> Alright, I've added the below mentioned information (backtrace,
> register info and the chunk of source code) as an attachment(34KB)
> It also contains an ps -ax output, and some other kernel messages
> which might be of use.
>
>
> Thanks Greg, I look forward to your reply.
>
> Jorn
>
> P.S: I did notice your signature, but I thought about it the moment
> I pressed the send button. Sorry about that. I'll make sure everything
> will remain as it was.
You seem to have missed (again):
>>> When replying to this message, please copy the original recipients.
>>> If you don't, I may ignore the reply or reply to the original
>>> recipients.
>>> For more information, see http://www.lemis.com/questions.html
> [EMAIL PROTECTED] ~/dump# gdb -k /boot/kernel/kernel.debug
> /usr/home/jorn/dump/vmcore.0
> ...
> (kgdb) bt
>
> #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
> #1 0xc0520da2 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
> #2 0xc05210d7 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
> #3 0xc0647866 in trap_fatal (frame=0xcdcb7bac, eva=0)
> at /usr/src/sys/i386/i386/trap.c:821
> #4 0xc0646f13 in trap (frame=
> {tf_fs = -1066532840, tf_es = 16, tf_ds = -1066991600, tf_edi = -1049879296,
> tf_esi = 1, tf_ebp = -842302460, tf_isp = -842302504, tf_ebx = -842302241, tf_edx =
> -1066500160, tf_ecx = -1049858920, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip =
> -842302481, tf_cs = 8, tf_eflags = 67714, tf_esp = -1049902208, tf_ss = 0}) at
> /usr/src/sys/i386/i386/trap.c:250
> #5 0xc0638f48 in calltrap () at {standard input}:94
> #6 0xc064a209 in clkintr (frame=0xcdcb7cdf)
> at /usr/src/sys/i386/isa/clock.c:193
> #7 0xc063d078 in intr_execute_handlers (isrc=0xc06d9fe0, iframe=0x1)
> at /usr/src/sys/i386/i386/intr_machdep.c:192
> #8 0xc0649d1f in atpic_handle_intr (iframe=
> {if_vec = 0, if_fs = 24, if_es = 16, if_ds = -1026949104, if_edi =
> -1026910720, if_esi = -1026910696, if_ebp = -842302280, if_ebx = -1049871268, if_edx
> = 0, if_ecx = -1026910048, if_eax = 1, if_eip = -1063719291, if_cs = 8, if_eflags =
> 582, if_esp = -842302232, if_ss = -1063719867})
> at /usr/src/sys/i386/isa/atpic.c:368
> #9 0xc0649e7e in Xatpic_intr0 () at {standard input}:32
> #10 0xc098ec45 in acpi_cpu_idle () at /usr/src/sys/dev/acpica/acpi_cpu.c:830
> #11 0xc063f3af in cpu_idle () at /usr/src/sys/i386/i386/machdep.c:1074
> #12 0xc050da48 in idle_proc (dummy=0x0) at /usr/src/sys/kern/kern_idle.c:86
> #13 0xc050d7ee in fork_exit (callout=0xc050da30 , arg=0x0,
> frame=0x0) at /usr/src/sys/kern/kern_fork.c:793
Interesting one. You've had a trap in the clock interrupt code, which
suggests some type of memory corruption. This could be difficult to
debug.
> (kgdb) l
> 235 static void
> 236 doadump(void)
> 237 {
> 238
> 239 savectx(&dumppcb);
> 240 dumping++;
> 241 dumpsys(&dumper);
> 242 }
As shown on page 45 and 46, the frame you're looking for is the one
below trap. This is the code at frame 0, showing how the system
dumps. It's not related to the problem. Take a look at page 46 and
send me the information for frame 6.
I'm omitting the dmesg output, the log file extract and the ps output.
None are interesting at this stage.
Greg
--
When replying to this message, please take care not to mutilate the
original text.
For more information, see http://www.lemis.com/email.html
Note: I discard all HTML mail unseen.
Finger [EMAIL PROTECTED] for PGP public key.
See complete headers for address and phone numbers.
pgp0.pgp
Description: PGP signature
FW: Kernel debugging question
Alright, I've added the below mentioned information (backtrace, register info and the chunk of source code) as an attachment(34KB) It also contains an ps -ax output, and some other kernel messages which might be of use. Thanks Greg, I look forward to your reply. Jorn P.S: I did notice your signature, but I thought about it the moment I pressed the send button. Sorry about that. I'll make sure everything will remain as it was. On Thursday, 22 April 2004 at 4:18:52 +0200, Gregg 'groggy' Lehey wrote: >[Format recovered--see http://www.lemis.com/email/email-format.html] >Quoted text wrapped incorrectly. >On Monday, 19 April 2004 at 14:46:57 +0200, Jorn Argelo wrote: >> On Monday, 19 April 2004 at 12:56:56 +0200, Jorn Argelo wrote: >>> [snip] >> #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 >> (kgdb) > You want at least a backtrace. How do I do that? I'm sorry, but I've never done a kernel debug or anything. >> >>> That's why I pointed you to the documentation explaining what to do: >> >> Sorry, I didn't see that in your previous mail. > >Looks like you didn't see this either: > >> When replying to this message, please copy the original recipients. >> If you don't, I may ignore the reply or reply to the original recipients. >> For more information, see http://www.lemis.com/questions.html > >> I must say your documentation looks very well, though it goes far >> above my level. (Wouldn't be too healthy for a 17 year old kid to >> do some kernel debugging already, no?) > >Younger people have done it. Our record for the youngest committer is >something like 14. > >> I currently have a backtrace, a chunk of source code which probably >> causes the panic, and some register output. I haven't read all 99 >> pages of your documentation, but hopefully it'll be enough. Send me >> a mail when you have time, and I'll mail you the contents. (The >> source code is quite long, so posting everything in a single mail is >> not a good idea). I can drop a mail at the current folks as well, if >> you prefer that. >Put it on the -questions list for now. It could be instructive. >Greg >-- >When replying to this message, please take care not to mutilate the >original text. >For more information, see http://www.lemis.com/email.html >Note: I discard all HTML mail unseen. >Finger [EMAIL PROTECTED] for PGP public key. >See complete headers for address and phone numbers. [EMAIL PROTECTED] ~/dump# gdb -k /boot/kernel/kernel.debug /usr/home/jorn/dump/vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or 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. This GDB was configured as "i386-unknown-freebsd"... panic: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x8:0xcdcb7bef stack pointer = 0x10:0xcdcb7bec frame pointer = 0x10:0xcdcb7c04 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 11 (idle) trap number = 12 panic: page fault syncing disks, buffers remaining... 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 giving up on 1594 buffers Uptime: 4h26m37s Dumping 255 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- warning: cannot find file for module nvidia.ko Error while mapping shared library sections: nvidia.ko: No such file or directory. Error while reading shared library symbols: nvidia.ko: No such file or directory. Reading symbols from /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/linux/linux.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/linux/linux.ko.debug Reading symbols from /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/acpi/acpi.ko.debug Reading symbols from /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/smbfs/smbfs.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/smbfs/smbfs.ko.debug Reading symbols from /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/libiconv/libiconv.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/libiconv/libiconv.ko.debug Reading symbols from /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/li---Type to continue, or q to quit--- bmchain/libmchain.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/
Re: Kernel debugging question
[Format recovered--see http://www.lemis.com/email/email-format.html] Quoted text wrapped incorrectly. On Monday, 19 April 2004 at 14:46:57 +0200, Jorn Argelo wrote: > On Monday, 19 April 2004 at 12:56:56 +0200, Jorn Argelo wrote: >> [snip] > #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 > (kgdb) >>> You want at least a backtrace. >>> >>> How do I do that? I'm sorry, but I've never done a kernel debug or >>> anything. > >> That's why I pointed you to the documentation explaining what to do: > > Sorry, I didn't see that in your previous mail. Looks like you didn't see this either: > When replying to this message, please copy the original recipients. > If you don't, I may ignore the reply or reply to the original recipients. > For more information, see http://www.lemis.com/questions.html > I must say your documentation looks very well, though it goes far > above my level. (Wouldn't be too healthy for a 17 year old kid to > do some kernel debugging already, no?) Younger people have done it. Our record for the youngest committer is something like 14. > I currently have a backtrace, a chunk of source code which probably > causes the panic, and some register output. I haven't read all 99 > pages of your documentation, but hopefully it'll be enough. Send me > a mail when you have time, and I'll mail you the contents. (The > source code is quite long, so posting everything in a single mail is > not a good idea). I can drop a mail at the current folks as well, if > you prefer that. Put it on the -questions list for now. It could be instructive. Greg -- When replying to this message, please take care not to mutilate the original text. For more information, see http://www.lemis.com/email.html Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Fw: Re: Kernel debugging question
- Forwarded message from Greg 'groggy' Lehey <[EMAIL PROTECTED]> - From: "Greg 'groggy' Lehey" <[EMAIL PROTECTED]> Date: Mon, 19 Apr 2004 19:36:45 +0930 To: Jorn Argelo <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: Kernel debugging question User-Agent: Mutt/1.4.1i Organization: The FreeBSD Project On Monday, 19 April 2004 at 11:45:37 +0200, Jorn Argelo wrote: > On Monday 19 April 2004 00:48, you wrote: >> On Sunday, 18 April 2004 at 20:01:46 +0200, Jorn Argelo wrote: >>> Hey folks, >>> >>> I've been trying to debug my kernel. I've successfully extracted a kernel >>> dump as described in the development handbook. However, as soon as I come >>> across this step, I don't know how to continue: >>> >>> # cd /usr/obj/usr/src/sys/KERNCONF >>> # gdb -k /boot/kernel/kernel.debug /var/crash/vmcore.0 >>> >>> The problem is, kernel.debug doesn't exist at all. >> >> This means you didn't build one. > > I forgot to add the following kernel option: > > makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbol That's about right. > I did enable the rest though. This is the output of the debugging, What is the output of the "debugging"? Your message contained only the panic message and the gdb prompt: > #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 > (kgdb) You want at least a backtrace. > though it seems somewhat different then the output on the FreeBSD > page. Do you think the folks at current or hackers can do something > with this? Yes. > Or am I forgetting something? Yes. Debugging crash dumps is work. People occasionally do work for free, but I'd be very surprised if you found somebody to help you with this one, especially without a debug kernel or even a backtrace. I'd suggest you catch another dump after you've booted your debug kernel, then post the backtrace. That way we'll have something to go on. If I have time, I'll reply with a preliminary analysis. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. - End forwarded message - -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel debugging question
On Monday, 19 April 2004 at 12:56:56 +0200, Jorn Argelo wrote: > [snip] > >> >>> I did enable the rest though. This is the output of the debugging, >> >> What is the output of the "debugging"? Your message contained only >> the panic message and the gdb prompt: > > I used the gdb -k /boot/kernel/kernel.debug /home/jorn/dump/vmcore.0 command, > and the output with the previous mail was the output of that command. A > small, perhaps irrelevant sidenote, is that the kernel.debug file was only > located in the /usr/obj/usr/src/sys/KERNCONF, and not in /boot/kernel as > described in the documentation of FreeBSD. The location of the file isn't important, but it must be the same kernel which caused the dump. >>> #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 >>> (kgdb) > >> You want at least a backtrace. > > How do I do that? I'm sorry, but I've never done a kernel debug or > anything. That's why I pointed you to the documentation explaining what to do: On Mon, 19 Apr 2004 08:18:37 +0930, Greg 'groggy' Lehey wrote: > You might take a look at > http://www.lemis.com/papers/Taiwan/tutorial.pdf, which is a little > more up to date. Note, though, that it's still a draft. If you see > any mistakes, please contact me. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: Kernel debugging question
[snip] > > > I did enable the rest though. This is the output of the debugging, > > What is the output of the "debugging"? Your message contained only > the panic message and the gdb prompt: I used the gdb -k /boot/kernel/kernel.debug /home/jorn/dump/vmcore.0 command, and the output with the previous mail was the output of that command. A small, perhaps irrelevant sidenote, is that the kernel.debug file was only located in the /usr/obj/usr/src/sys/KERNCONF, and not in /boot/kernel as described in the documentation of FreeBSD. > > #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 > > (kgdb) > You want at least a backtrace. How do I do that? I'm sorry, but I've never done a kernel debug or anything. > > Or am I forgetting something? > > Yes. > > Debugging crash dumps is work. People occasionally do work for free, > but I'd be very surprised if you found somebody to help you with this > one, especially without a debug kernel or even a backtrace. > > I'd suggest you catch another dump after you've booted your debug > kernel, then post the backtrace. That way we'll have something to go > on. If I have time, I'll reply with a preliminary analysis. Thanks Greg, I would really appreciate that. It's rather frustrating to see your once rock-solid machine freezing frequently. > Greg > -- > When replying to this message, please copy the original recipients. > If you don't, I may ignore the reply or reply to the original recipients. > For more information, see http://www.lemis.com/questions.html > Note: I discard all HTML mail unseen. > Finger [EMAIL PROTECTED] for PGP public key. > See complete headers for address and phone numbers. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel debugging question
On Monday, 19 April 2004 at 11:45:37 +0200, Jorn Argelo wrote: > On Monday 19 April 2004 00:48, you wrote: >> On Sunday, 18 April 2004 at 20:01:46 +0200, Jorn Argelo wrote: >>> Hey folks, >>> >>> I've been trying to debug my kernel. I've successfully extracted a kernel >>> dump as described in the development handbook. However, as soon as I come >>> across this step, I don't know how to continue: >>> >>> # cd /usr/obj/usr/src/sys/KERNCONF >>> # gdb -k /boot/kernel/kernel.debug /var/crash/vmcore.0 >>> >>> The problem is, kernel.debug doesn't exist at all. >> >> This means you didn't build one. > > I forgot to add the following kernel option: > > makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbol That's about right. > I did enable the rest though. This is the output of the debugging, What is the output of the "debugging"? Your message contained only the panic message and the gdb prompt: > #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 > (kgdb) You want at least a backtrace. > though it seems somewhat different then the output on the FreeBSD > page. Do you think the folks at current or hackers can do something > with this? Yes. > Or am I forgetting something? Yes. Debugging crash dumps is work. People occasionally do work for free, but I'd be very surprised if you found somebody to help you with this one, especially without a debug kernel or even a backtrace. I'd suggest you catch another dump after you've booted your debug kernel, then post the backtrace. That way we'll have something to go on. If I have time, I'll reply with a preliminary analysis. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: Kernel debugging question
Hey Greg, I forgot to add the following kernel option: makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbol I did enable the rest though. This is the output of the debugging, though it seems somewhat different then the output on the FreeBSD page. Do you think the folks at current or hackers can do something with this? Or am I forgetting something? Thanks, Jorn [EMAIL PROTECTED] ~# gdb -k /boot/kernel/kernel.debug /home/jorn/dump/vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or 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. This GDB was configured as "i386-unknown-freebsd"... panic: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x8:0xcdcb7bef stack pointer = 0x10:0xcdcb7bec frame pointer = 0x10:0xcdcb7c04 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 11 (idle) trap number = 12 panic: page fault syncing disks, buffers remaining... 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 2107 giving up on 1594 buffers Uptime: 4h26m37s Dumping 255 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- warning: cannot find file for module nvidia.ko Error while mapping shared library sections: nvidia.ko: No such file or directory. Error while reading shared library symbols: nvidia.ko: No such file or directory. Reading symbols from /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/linux/linux.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/linux/linux.ko.debug Reading symbols from /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/acpi/acpi.ko.debug Reading symbols from /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/smbfs/smbfs.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/smbfs/smbfs.ko.debug Reading symbols from /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/libiconv/libiconv.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/libiconv/libiconv.ko.debug Reading symbols from /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/libmchain/libmchain.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/smeagol/modules/usr/src/sys/modules/libmchain/libmchain.ko.debug #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 (kgdb) On Monday 19 April 2004 00:48, you wrote: > On Sunday, 18 April 2004 at 20:01:46 +0200, Jorn Argelo wrote: > > Hey folks, > > > > I've been trying to debug my kernel. I've successfully extracted a kernel > > dump as described in the development handbook. However, as soon as I come > > across this step, I don't know how to continue: > > > > # cd /usr/obj/usr/src/sys/KERNCONF > > # gdb -k /boot/kernel/kernel.debug /var/crash/vmcore.0 > > > > The problem is, kernel.debug doesn't exist at all. > > This means you didn't build one. > > > I did an locate.updatedb as root and try to find it then, but I > > still couldn't find it. Hopefully somebody can point me into the > > right direction > > First you need to build a debug kernel. This probably means that the > dump you have is "the one that got away". You could do some limited > analysis of the stripped kernel, but that's Deep Magic. > > > (I used > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kern > >eldebug.html) > > You might take a look at > http://www.lemis.com/papers/Taiwan/tutorial.pdf, which is a little > more update. Note, though, that it's still a draft. If you see any > mistakes, please contact me. > > Greg > -- > When replying to this message, please copy the original recipients. > If you don't, I may ignore the reply or reply to the original recipients. > For more information, see http://www.lemis.com/questions.html > Note: I discard all HTML mail unseen. > Finger [EMAIL PROTECTED] for PGP public key. > See complete headers for address and phone numbers. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel debugging question
On Sunday, 18 April 2004 at 20:01:46 +0200, Jorn Argelo wrote: > Hey folks, > > I've been trying to debug my kernel. I've successfully extracted a kernel dump > as described in the development handbook. However, as soon as I come across > this step, I don't know how to continue: > > # cd /usr/obj/usr/src/sys/KERNCONF > # gdb -k /boot/kernel/kernel.debug /var/crash/vmcore.0 > > The problem is, kernel.debug doesn't exist at all. This means you didn't build one. > I did an locate.updatedb as root and try to find it then, but I > still couldn't find it. Hopefully somebody can point me into the > right direction First you need to build a debug kernel. This probably means that the dump you have is "the one that got away". You could do some limited analysis of the stripped kernel, but that's Deep Magic. > (I used > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html) You might take a look at http://www.lemis.com/papers/Taiwan/tutorial.pdf, which is a little more update. Note, though, that it's still a draft. If you see any mistakes, please contact me. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Kernel debugging question
Hey folks, I've been trying to debug my kernel. I've successfully extracted a kernel dump as described in the development handbook. However, as soon as I come across this step, I don't know how to continue: # cd /usr/obj/usr/src/sys/KERNCONF # gdb -k /boot/kernel/kernel.debug /var/crash/vmcore.0 The problem is, kernel.debug doesn't exist at all. I did an locate.updatedb as root and try to find it then, but I still couldn't find it. Hopefully somebody can point me into the right direction (I used http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html) Thanks in advance, Jorn ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
