Re: R: Re: 6.4-RC2 crashes after a few minutes of uptime
Ken,
I built a GENERIC debug kernel, and now have a backtrace that I can
provide related to this problem on 6.4-RC2:
surfer# kgdb /sys/i386/compile/GENERIC/kernel.debug /var/crash/vmcore.1
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 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-marcel-freebsd...
Unread portion of the kernel message buffer:
acd0: WARNING - READ_TOC read data overrun 1812
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x78
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc06d39b9
stack pointer = 0x28:0xca865c10
frame pointer = 0x28:0xca865c14
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 19 (swi6: task queue)
trap number = 12
panic: page fault
Uptime: 16m20s
Physical memory: 179 MB
Dumping 53 MB: 38 22 6
Reading symbols from /boot/kernel/snd_maestro.ko...done.
Loaded symbols for /boot/kernel/snd_maestro.ko
Reading symbols from /boot/kernel/sound.ko...done.
Loaded symbols for /boot/kernel/sound.ko
Reading symbols from /boot/kernel/acpi.ko...done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/mach64.ko...done.
Loaded symbols for /boot/kernel/mach64.ko
Reading symbols from /boot/kernel/drm.ko...done.
Loaded symbols for /boot/kernel/drm.ko
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc06b2e3e in boot (howto=260) at ../../../kern/kern_shutdown.c:410
#2 0xc06b30d4 in panic (fmt=0xc098be6b %s)
at ../../../kern/kern_shutdown.c:566
#3 0xc092b1f4 in trap_fatal (frame=0xca865bd0, eva=120)
at ../../../i386/i386/trap.c:838
#4 0xc092a992 in trap (frame=
{tf_fs = 8, tf_es = -1038352344, tf_ds = -1038352344, tf_edi =
-1033627044, tf_esi = -1038289792, tf_ebp = -897164268, tf_isp =
-897164292, tf_ebx = -1039268288, tf_edx = 0, tf_ecx = 4, tf_eax =
-1038289760, tf_trapno = 12, tf_err = 0, tf_eip = -1066583623, tf_cs =
32, tf_eflags = 589826, tf_esp = -1038289792, tf_ss = -897164232})
at ../../../i386/i386/trap.c:270
#5 0xc0917e2a in calltrap () at ../../../i386/i386/exception.s:139
#6 0xc06d39b9 in turnstile_setowner (ts=0xc20e0640, owner=0x4)
at ../../../kern/subr_turnstile.c:456
#7 0xc06d3d16 in turnstile_wait (lock=0xc2641aa8, owner=0x4, queue=0)
at ../../../kern/subr_turnstile.c:661
#8 0xc06a9d2a in _mtx_lock_sleep (m=0xc2641aa8, tid=3256677504, opts=0,
file=0x0, line=0) at ../../../kern/kern_mutex.c:579
#9 0xc06b2492 in _sema_post (sema=0xc2641aa8, file=0x0, line=0)
at ../../../kern/kern_sema.c:79
#10 0xc04e7c26 in ata_completed (context=0xc2641a5c, dummy=1)
at ../../../dev/ata/ata-queue.c:481
---Type return to continue, or q return to quit---
#11 0xc06d29a3 in taskqueue_run (queue=0xc21c4100)
at ../../../kern/subr_taskqueue.c:257
#12 0xc06d2bb6 in taskqueue_swi_run (dummy=0x0)
at ../../../kern/subr_taskqueue.c:299
#13 0xc069baad in ithread_execute_handlers (p=0xc21ce860, ie=0xc21c4080)
at ../../../kern/kern_intr.c:682
#14 0xc069bbc8 in ithread_loop (arg=0xc214cb60)
at ../../../kern/kern_intr.c:766
#15 0xc069aa34 in fork_exit (callout=0xc069bb74 ithread_loop,
arg=0xc214cb60, frame=0xca865d38) at ../../../kern/kern_fork.c:788
#16 0xc0917e8c in fork_trampoline () at ../../../i386/i386/exception.s:
208
(kgdb) print panicstr
$1 = 0xc0a8d480 page fault
(kgdb)
This panic happened just a few minutes after bootup completed, without
logging on.
Also, I've noticed that sometimes when the panic happens, savecore(8)
seems to be unable to recover the coredump in the swap area. I noticed
that on the bootup, the system seems to engage the swap partition well
before savecore(8) has a chance to scan it. So, I wondered if it's
possible that maybe that when swap is being engaged, it may be writing
something to the swap partition, effectively overwriting the signature
that savecore(8) checks, to detect the existence of a core dump?
To recap (in case this doesn't get attached to the original thread)
As I said in the original message, another odd thing about this, is
that usually after it crashes on the first (and sometimes second) cold
boot, it will remain stable till the machine is shut down.
And as I think I also mentioned, once logged into GNOME, I see that a
blank disc icon flashes off and on on the desktop, as if the system
detects the existence of a CD in the drive, so that might be related.
Though, this also happened with
Re: R: Re: R: Re: 6.4-RC2 crashes after a few minutes of uptime
On 2008-11-24, at 1:51 , Barbara wrote: About kgdb... I never used freebsd-update, so sorry if I'm saying something stupid, but could it be the case that the kernel has been built without debugging symbols or something like that? Does freebsd- update provide a kernel.debug? I haven't had to use a the kernel. debug file in the obj dir in a long time. As far as I know, these days, the GENERIC kernel includes debug symbols. And in cases when there aren't any debug symbols, that shouldn't prevent kgdb from loading, I wouldn't think. Hello, I had a k panic some hours ago but I think that's related to a problem with one of my HDs. I've got a dump in /var/crash, and as you were interested, I run: # kgdb /boot/kernel/kernel /var/crash/vmcore.6 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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- marcel-freebsd...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Terminated I had to pkill kgdb as it was in a loop. Running it against kernel. debug in /usr/obj/usr/src/sys/$KERNCONF/ worked as expected. I've always followed this way, so I don't know if it was working with earlier releases. Ah, well you must not be using GENERIC then, because it does have the debugging symbols. I think this is the setting in the GENERIC config that controls it: makeoptions DEBUG=-g But I guess what you're doing works if you're using a custom kernel that does not have that config setting. - rory I'm not using GENERIC but I have makeoptions DEBUG=-g in my KERNCONF. Barbara, Ah, so you had the exact same results I got, when using /book/kernel/ kernel. So, that answers that question then, apparently I do need to build a kernel.debug to get a backtrace on 6.4. So, it looks like maybe things are different in 6 than I had remembered. I haven't looked at the 6.4-RC2 notebook to see what the kernel directory has, but on my 7.0 server at least, I've noticed that kgdb(1) does work with /book/kernel/kernel, and I think it might have to do with putting the symbols in a separate, kernel.symbols file. So, I assume that this doesn't exist on 6. However I did notice that if I remove that file, and run kgdb again (on 7.0) I also get that structure pointer error that you get, it doesn't lock up.. and I can still get a backtrace, but the output is more terse.. in that it shows function names, but without corresponding source file names and line numbers. So, the addition of the symbols file it seems, adds some some more debugging information than what the kernel provides by itself. So, maybe that makeoptions directive does different things on each version. Thank you for your feedback with this, much appreciated. Now, to see if I can build a kernel.debug on that machine, can get a backtrace -- though it sure sounds like a problem with ata(4). - rory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: R: Re: 6.4-RC2 crashes after a few minutes of uptime
On 2008-11-23, at 18:36 , Barbara wrote: About kgdb... I never used freebsd-update, so sorry if I'm saying something stupid, but could it be the case that the kernel has been built without debugging symbols or something like that? Does freebsd- update provide a kernel.debug? I haven't had to use a the kernel.debug file in the obj dir in a long time. As far as I know, these days, the GENERIC kernel includes debug symbols. And in cases when there aren't any debug symbols, that shouldn't prevent kgdb from loading, I wouldn't think. Hello, I had a k panic some hours ago but I think that's related to a problem with one of my HDs. I've got a dump in /var/crash, and as you were interested, I run: # kgdb /boot/kernel/kernel /var/crash/vmcore.6 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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- marcel-freebsd...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Terminated I had to pkill kgdb as it was in a loop. Running it against kernel.debug in /usr/obj/usr/src/sys/$KERNCONF/ worked as expected. I've always followed this way, so I don't know if it was working with earlier releases. Ah, well you must not be using GENERIC then, because it does have the debugging symbols. I think this is the setting in the GENERIC config that controls it: makeoptions DEBUG=-g But I guess what you're doing works if you're using a custom kernel that does not have that config setting. - rory ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
R: Re: R: Re: 6.4-RC2 crashes after a few minutes of uptime
About kgdb... I never used freebsd-update, so sorry if I'm saying something stupid, but could it be the case that the kernel has been built without debugging symbols or something like that? Does freebsd- update provide a kernel.debug? I haven't had to use a the kernel. debug file in the obj dir in a long time. As far as I know, these days, the GENERIC kernel includes debug symbols. And in cases when there aren't any debug symbols, that shouldn't prevent kgdb from loading, I wouldn't think. Hello, I had a k panic some hours ago but I think that's related to a problem with one of my HDs. I've got a dump in /var/crash, and as you were interested, I run: # kgdb /boot/kernel/kernel /var/crash/vmcore.6 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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- marcel-freebsd...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Terminated I had to pkill kgdb as it was in a loop. Running it against kernel. debug in /usr/obj/usr/src/sys/$KERNCONF/ worked as expected. I've always followed this way, so I don't know if it was working with earlier releases. Ah, well you must not be using GENERIC then, because it does have the debugging symbols. I think this is the setting in the GENERIC config that controls it: makeoptionsDEBUG=-g But I guess what you're doing works if you're using a custom kernel that does not have that config setting. - rory I'm not using GENERIC but I have makeoptions DEBUG=-g in my KERNCONF. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
