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 <idle_proc>, 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);
192             }
193             timer_func(frame);
194     #ifdef SMP
195             if (timer_func == hardclock)
196                     forward_hardclock();
197     #endif
(kgdb)
>
> I'm omitting the dmesg output, the log file extract and the ps output.
> None are interesting at this stage.

Alright, thanks for all your help so far Greg.

Jorn

> 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] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to