Unable to get crash dump

2012-08-24 Thread Rick Miller
Hi All,

Running 8.3-STABLE 5/21/2012 on HP DL360.  While testing crash dump
functionality, the dump aborts with the following message:

Aborting dump due to I/O error.
status == 0xb, scsi status == 0x0

** DUMP FAILED (ERROR 5) **
Automatic reboot in 5 seconds - press a key on the console to abort

Googling and searching freebsd.org have produced what appeared to be
some what relevant messages, but I found nothing pointing to a cause
and fix.  I'm hoping someone might be able to point me in a direction
to figuring this out.

-- 
Take care
Rick Miller
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Help with crash dump

2011-09-09 Thread Bernt Hansson

2011-09-08 22:11, Andrea Venturoli skrev:

Hello.

Anyone can give any hint on this?


Guessing!

You have run out of swapspace, based on these 2 lines

panic: ffs_write: dir write
current process = 0 (swapper)

Or you have a hardware error. Does the current process
change between panics or is it always the same?

I'm in no sense a kernel debugger, but it's a hint.


I really have no clue.

bye  Thanks
av.



# uname -a
FreeBSD x..it 7.3-RELEASE-p4 FreeBSD 7.3-RELEASE-p4 #1:
Wed Dec 15 11:53:13 CET 2010
r...@x..it:/usr/obj/usr/src/sys/x i386
# kgdb kernel.debug /var/crash/vmcore.17
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:
panic: ffs_write: dir write
cpuid = 3
Uptime: 26d9h4m27s
Physical memory: 2033 MB
Dumping 300 MB: 285 269 253 237 221 205 189 173 157 141 125 109 93
77kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address = 0x14
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc059accb
stack pointer = 0x28:0xc0c20ccc
frame pointer = 0x28:0xc0c20cec
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = resume, IOPL = 0
current process = 0 (swapper)
trap number = 12
panic: page fault
cpuid = 3
61 45 29 13

Reading symbols from /boot/kernel/splash_bmp.ko...Reading symbols from
/boot/kernel/splash_bmp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/splash_bmp.ko
Reading symbols from /boot/kernel/geom_stripe.ko...Reading symbols
from /boot/kernel/geom_stripe.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/geom_stripe.ko
Reading symbols from /boot/kernel/acpi.ko...Reading symbols from
/boot/kernel/acpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi.ko
#0 doadump () at pcpu.h:196
196 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) bt
#0 doadump () at pcpu.h:196
#1 0xc0563d48 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:418
#2 0xc0564025 in panic (fmt=Variable fmt is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3 0xc06cd16d in ffs_write (ap=0xe6912a44) at
/usr/src/sys/ufs/ffs/ffs_vnops.c:667
#4 0xc0740640 in VOP_WRITE_APV (vop=0xc07ba4e0, a=0xe6912a44) at
vnode_if.c:691
#5 0xc06fd8d6 in vnode_pager_generic_putpages (vp=0xc672f678,
m=0xe6912bb0, bytecount=Variable bytecount is not available.
) at vnode_if.h:373
#6 0xc05d4a5f in vop_stdputpages (ap=0xe6912ad4) at
/usr/src/sys/kern/vfs_default.c:540
#7 0xc073faf3 in VOP_PUTPAGES_APV (vop=0xc07ba4e0, a=0xe6912ad4) at
vnode_if.c:2189
#8 0xc06fda5f in vnode_pager_putpages (object=0xcb14ac80,
m=0xe6912bb0, count=1, sync=0, rtvals=0xe6912b20) at vnode_if.h:1164
#9 0xc06f730b in vm_pageout_flush (mc=0xe6912bb0, count=1, flags=0) at
vm_pager.h:148
#10 0xc06f7661 in vm_pageout_clean (m=Variable m is not available.
) at /usr/src/sys/vm/vm_pageout.c:403
#11 0xc06f92a2 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:1017
#12 0xc053e9a1 in fork_exit (callout=0xc06f82d6 vm_pageout, arg=0x0,
frame=0xe6912d38) at /usr/src/sys/kern/kern_fork.c:811
#13 0xc0718b30 in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:271
(kgdb)


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
freebsd-questions-unsubscr...@freebsd.org



___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Re: Help with crash dump

2011-09-09 Thread Andrea Venturoli

On 09/09/11 14:26, Bernt Hansson wrote:


You have run out of swapspace, based on these 2 lines

panic: ffs_write: dir write
current process = 0 (swapper)


Hmmm...
Cacti woldn't think so: the graph about swap space is plain flat (round 
0%, by the way); of course it could have risen so fast that it reached 
100% between two consecutive polls, but I doubt it.


Besides, why would the system crash for such a reason? I'd expect 
application failing, not the whole kernel. Am I wrong?





Or you have a hardware error.


SOB! I hope not. RAM is fine, HDs are SAS RAID with a good contoller 
which should have detected failures...

What else can I check?



 Does the current process

change between panics or is it always the same?


Right now I've only had this crash (and hope no other will follow). In 
the worst case, I'll take notice.





I'm in no sense a kernel debugger, but it's a hint.


I appreciate your interest anyway.



 bye  Thanks
av.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Help with crash dump

2011-09-08 Thread Andrea Venturoli

Hello.

Anyone can give any hint on this?
I really have no clue.

 bye  Thanks
av.



# uname -a
FreeBSD x..it 7.3-RELEASE-p4 FreeBSD 7.3-RELEASE-p4 #1: Wed Dec 15 
11:53:13 CET 2010 r...@x..it:/usr/obj/usr/src/sys/x  i386
# kgdb kernel.debug /var/crash/vmcore.17
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:
panic: ffs_write: dir write
cpuid = 3
Uptime: 26d9h4m27s
Physical memory: 2033 MB
Dumping 300 MB: 285 269 253 237 221 205 189 173 157 141 125 109 93 77kernel 
trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address   = 0x14
fault code  = supervisor read, page not present
instruction pointer = 0x20:0xc059accb
stack pointer   = 0x28:0xc0c20ccc
frame pointer   = 0x28:0xc0c20cec
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 0 (swapper)
trap number = 12
panic: page fault
cpuid = 3
 61 45 29 13

Reading symbols from /boot/kernel/splash_bmp.ko...Reading symbols from 
/boot/kernel/splash_bmp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/splash_bmp.ko
Reading symbols from /boot/kernel/geom_stripe.ko...Reading symbols from 
/boot/kernel/geom_stripe.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/geom_stripe.ko
Reading symbols from /boot/kernel/acpi.ko...Reading symbols from 
/boot/kernel/acpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi.ko
#0  doadump () at pcpu.h:196
196 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) bt
#0  doadump () at pcpu.h:196
#1  0xc0563d48 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2  0xc0564025 in panic (fmt=Variable fmt is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3  0xc06cd16d in ffs_write (ap=0xe6912a44) at 
/usr/src/sys/ufs/ffs/ffs_vnops.c:667
#4  0xc0740640 in VOP_WRITE_APV (vop=0xc07ba4e0, a=0xe6912a44) at vnode_if.c:691
#5  0xc06fd8d6 in vnode_pager_generic_putpages (vp=0xc672f678, m=0xe6912bb0, 
bytecount=Variable bytecount is not available.
) at vnode_if.h:373
#6  0xc05d4a5f in vop_stdputpages (ap=0xe6912ad4) at 
/usr/src/sys/kern/vfs_default.c:540
#7  0xc073faf3 in VOP_PUTPAGES_APV (vop=0xc07ba4e0, a=0xe6912ad4) at 
vnode_if.c:2189
#8  0xc06fda5f in vnode_pager_putpages (object=0xcb14ac80, m=0xe6912bb0, 
count=1, sync=0, rtvals=0xe6912b20) at vnode_if.h:1164
#9  0xc06f730b in vm_pageout_flush (mc=0xe6912bb0, count=1, flags=0) at 
vm_pager.h:148
#10 0xc06f7661 in vm_pageout_clean (m=Variable m is not available.
) at /usr/src/sys/vm/vm_pageout.c:403
#11 0xc06f92a2 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:1017
#12 0xc053e9a1 in fork_exit (callout=0xc06f82d6 vm_pageout, arg=0x0, 
frame=0xe6912d38) at /usr/src/sys/kern/kern_fork.c:811
#13 0xc0718b30 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:271
(kgdb)


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Crash dump freebsd 7.2

2009-08-22 Thread Zetinja Tresor
I have several jails running on my freebesd machine and lately it started to
crash when it gets a bit loaded. I followed the freebsd kernel debugging
manual, and got some output, but I have no idea what to do with it. The only
thing I think I understand of it that the bit that matters are just the two
last lines. Is there anyone that can help?


# kgdb kernel.debug /var/crash/vmcore.2
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:
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0x10
fault code  = supervisor read, page not present
instruction pointer = 0x20:0xc07d4a21
stack pointer   = 0x28:0xe9c879c4
frame pointer   = 0x28:0xe9c879d8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 18223 (libssl.so)
trap number = 12
panic: page fault
cpuid = 1


Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0x6e727598
fault code  = supervisor read, page not present
instruction pointer = 0x20:0xc08bf945
stack pointer   = 0x28:0xc72bfaa8
frame pointer   = 0x28:0xc72bfacc
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 30 (em1 taskq)
trap number = 12
panic: page fault
cpuid = 1
Uptime: 12h20m45s
Physical memory: 3827 MB
Dumping 295 MB: 280 264 248 232 216 200 184 168 152 136 120 104 88 72 56 40
24 8

Reading symbols from /boot/kernel/acpi.ko...Reading symbols from
/boot/kernel/acpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/linux.ko...Reading symbols from
/boot/kernel/linux.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from
/boot/kernel/nullfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/nullfs.ko
Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from
/boot/kernel/fdescfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/fdescfs.ko
#0  doadump () at pcpu.h:196
196 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb)
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org


Help with crash dump

2007-06-24 Thread Andrea Venturoli

Hello.
Any one can make anything out of this crash dump?
It's an SMP amd64 6.2 box with a RAID-5 SCSI controller and a couple GiB
of RAM. We are also using GELI.

 bye  Thanks
av.


--

# kgdb kernel.debug /var/crash/vmcore.1
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined 
symbol ps_pglobal_lookup]
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 amd64-marcel-freebsd.

Unread portion of the kernel message buffer:
0s1e

0xff004ecf5510: tag ufs, type VREG
usecount 1, writecount 0, refcount 9 mountedhere 0
flags ()
v_object 0xff002a70d000 ref 0 pages 515
 lock type ufs: EXCL (count 1) by thread 0xff007a85d720 (pid 31) with 1 
pending#0 0x802252b6 at lockmgr+0x5f6
#1 0x80302068 at ffs_lock+0x58
#2 0x80384fc1 at VOP_LOCK_APV+0x81
#3 0x802a78bb at vn_lock+0x6b
#4 0x8029ba00 at vget+0x90
#5 0x80329cb9 at vm_pageout+0x1309
#6 0x8021a30b at fork_exit+0xbb
#7 0x803358ee at fork_trampoline+0xe

ino 118134, on dev amrd0s1e

0xff000ba75510: tag ufs, type VREG
usecount 1, writecount 1, refcount 3 mountedhere 0
flags ()
v_object 0xff0043d80380 ref 0 pages 9
 lock type ufs: EXCL (count 1) by thread 0xff0079b9b980 (pid 447)#0 
0x802252b6 at lockmgr+0x5f6
#1 0x80302068 at ffs_lock+0x58
#2 0x80384fc1 at VOP_LOCK_APV+0x81
#3 0x802a78bb at vn_lock+0x6b
#4 0x802a3cfb at fsync+0xab
#5 0x8034a731 at syscall+0x4d1
#6 0x80335728 at Xfast_syscall+0xa8

ino 188422, on dev amrd0s1e

0xff0008358510: tag ufs, type VREG
usecount 1, writecount 1, refcount 3 mountedhere 0
flags ()
v_object 0xff0064290e00 ref 0 pages 3
 lock type ufs: EXCL (count 1) by thread 0xff001de6cbe0 (pid 3365)#0 
0x802252b6 at lockmgr+0x5f6
#1 0x80302068 at ffs_lock+0x58
#2 0x80384fc1 at VOP_LOCK_APV+0x81
#3 0x802a78bb at vn_lock+0x6b
#4 0x802a3cfb at fsync+0xab
#5 0x8034a731 at syscall+0x4d1
#6 0x80335728 at Xfast_syscall+0xa8

ino 117876, on dev amrd0s1e

0xff0011565a20: tag ufs, type VREG
usecount 1, writecount 1, refcount 3 mountedhere 0
flags ()
v_object 0xff002c970e00 ref 0 pages 3
 lock type ufs: EXCL (count 1) by thread 0xff00496e3000 (pid 3367)#0 
0x802252b6 at lockmgr+0x5f6
#1 0x80302068 at ffs_lock+0x58
#2 0x80384fc1 at VOP_LOCK_APV+0x81
#3 0x802a78bb at vn_lock+0x6b
#4 0x802a3cfb at fsync+0xab
#5 0x8034a731 at syscall+0x4d1
#6 0x80335728 at Xfast_syscall+0xa8

ino 118135, on dev amrd0s1e

0xff0036d66a20: tag ufs, type VREG
usecount 1, writecount 1, refcount 3 mountedhere 0
flags ()
v_object 0xff001d4a21c0 ref 0 pages 3
 lock type ufs: EXCL (count 1) by thread 0xff0046644980 (pid 3368)#0 
0x802252b6 at lockmgr+0x5f6
#1 0x80302068 at ffs_lock+0x58
#2 0x80384fc1 at VOP_LOCK_APV+0x81
#3 0x802a78bb at vn_lock+0x6b
#4 0x802a3cfb at fsync+0xab
#5 0x8034a731 at syscall+0x4d1
#6 0x80335728 at Xfast_syscall+0xa8

ino 118141, on dev amrd0s1e

0xff000419c288: tag ufs, type VREG
usecount 1, writecount 1, refcount 3 mountedhere 0
flags ()
v_object 0xff0049701000 ref 0 pages 3
 lock type ufs: EXCL (count 1) by thread 0xff003264c000 (pid 3369)#0 
0x802252b6 at lockmgr+0x5f6
#1 0x80302068 at ffs_lock+0x58
#2 0x80384fc1 at VOP_LOCK_APV+0x81
#3 0x802a78bb at vn_lock+0x6b
#4 0x802a3cfb at fsync+0xab
#5 0x8034a731 at syscall+0x4d1
#6 0x80335728 at Xfast_syscall+0xa8

ino 118305, on dev amrd0s1e

0xff0077dc1000: tag ufs, type VREG
usecount 1, writecount 1, refcount 2 mountedhere 0
flags ()
v_object 0xff004478f8c0 ref 0 pages 1
 lock type ufs: EXCL (count 1) by thread 0xff0079b9d980 (pid 593)#0 
0x802252b6 at lockmgr+0x5f6
#1 0x80302068 at ffs_lock+0x58
#2 0x80384fc1 at VOP_LOCK_APV+0x81
#3 0x802a78bb at vn_lock+0x6b
#4 0x802a8ab6 at vn_write+0x156
#5 0x8025f667 at dofilewrite+0x87
#6 0x8025f931 at kern_writev+0x51
#7 0x8025fa2a at write+0x4a
#8 0x8034a731 at syscall+0x4d1
#9 0x80335728 at Xfast_syscall+0xa8

ino 212070, on dev amrd0s1e

0xff00082c5798: tag ufs, type VREG
usecount 1, writecount 0, refcount 11258 mountedhere 0
flags ()
 lock type ufs: EXCL (count 1

kernel crash dump could not be obtained

2005-10-31 Thread kamal kc
dear all,

i have to make modifictions to the kernel and 
i have been encountering kernel crashes all the 
time.

the kernel panics with messages starting with
vm_fault: and then crashes and reboots.

i guess i have done incorrect memory operations and 
i want to know where i went wrong.

so i thought of obtaining the crash dump. i went
through the developers guide. 
and i added the following lines on the /etc/rc.conf

---
dumpdev=/dev/ad0s1b
dumpdir=/var/crash
savecore_flags=
--

the /etc/fstab file is

Device  Mountpoint  FStype  Options DumpPass#
/dev/ad0s1b noneswapsw  0   0
/dev/ad0s1a /   ufs rw  1   1
/dev/ad0s1e /tmpufs rw  2   2
/dev/ad0s1f /usrufs rw  2   2
/dev/ad0s1d /varufs rw  2   2
/dev/acd0   /cdrom  cd9660  ro,noauto   0   0


swap partition is /dev/ad0s1b

swapinfo gives the output:--
Device  1K-blocks UsedAvail Capacity
/dev/ad0s1b4950480   495048 0%

My memory size according to dmesg is --
real memory  = 266600448 (254 MB)
avail memory = 251232256 (239 MB)
--

Now when the kernel crashes it prints the message 
writing dump 240MB

but rebooting does not show any crash dump file 
on /var/crash.

please help
kamal










__ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: kernel crash dump could not be obtained

2005-10-31 Thread Kris Kennaway
On Mon, Oct 31, 2005 at 02:58:50AM -0800, kamal kc wrote:

 but rebooting does not show any crash dump file 
 on /var/crash.

What is displayed when savecore is run at boot time?  Alternatively,
what happens when you run savecore yourself?  You may not have enough
space on /var to save the dump.

Kris

P.S. Don't cross-post questions@ and [EMAIL PROTECTED]

pgpTjN9IVzhfR.pgp
Description: PGP signature


crash dump

2005-04-28 Thread Wei Chong
Hi,

I compiled my FreeBSD 5.3-STABLE kernel with 
options KDB, DDB
makeoptions DEBUG=-g

and wrote a kernel module that does nothing but call
panic() upon its loading, to try experimenting on
crash kernel debugger and crash dump.
Upon kldload the module, KDB was invoked and I was
dropped into a console debugger that let me see the
backtrace by typing where.
However, when I typed panic as suggested by the FAQ,
it doesn't dump anything to my swap device.  Only by
typing call doadump in the KDB that it does the job.

I wonder why?

Any help is appreciated.
Thanks.

Yours truly,
Tan, Wei Chong.

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


no crash dump generated

2005-02-16 Thread Roberto Nunnari
Hi.
A couple of days ago I upgrades the system and a few ports on
a 5.3 box and since then I'm often getting crashes.
-bash-2.05b# uname -a
FreeBSD jupiter.noonlights.net 5.3-RELEASE-p5 FreeBSD 5.3-RELEASE-p5 #0: 
Sun Feb 13 22:56:47 CET 2005 
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/JUPITER  i386

I'd like to get a crash dump and so
I added the following lines to /etc/rc.conf
dumpdev=/dev/ad0s1b
dumpdir=/usr/crash
-bash-2.05b# ls -ld /usr/crash/
drwx--  2 root  wheel  512 Feb 16 11:17 /usr/crash/
but I'm not getting any dump! /usr/crash is always empty.
..and the machine crashes quite often:
-bash-2.05b# last|grep reboot
reboot   ~ Wed Feb 16 20:04
reboot   ~ Wed Feb 16 19:17
reboot   ~ Wed Feb 16 18:40
reboot   ~ Wed Feb 16 17:26
reboot   ~ Wed Feb 16 14:07
reboot   ~ Wed Feb 16 12:39
reboot   ~ Wed Feb 16 11:30
reboot   ~ Wed Feb 16 10:27
reboot   ~ Wed Feb 16 09:31
reboot   ~ Wed Feb 16 09:16
What do I miss? Do I need some kernel option?
Best regards.
--
  Roberto Nunnari -software engineer-
   mailto:[EMAIL PROTECTED]
 Scuola Universitaria Professionale della Svizzera Italiana
 Dipartimento Tecnologie Innovative
  http://www.dti.supsi.ch
 SUPSI-DTI
 Via Cantonaletel: +41-91-6108561
 6928 Mannofax: +41-91-6108570
 Switzerland   (o o)
===oOO==(_)==OOo
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


finally a crash dump on 5.3

2005-01-06 Thread J.D. Bronson
I was up for 2wks and today saw this:
Fatal trap 12 - page fault while in kernel mode
CPUID 0 APIC ID 0
Fault write address = 0x418ad66c
Fault code = supervisor write, page not present
Inst Pointer = 0x8:0xc05109d9
Stack Pointer = 0x10:0xe5ea8978
Frame Pointer = 0x10:0xe5ea8994
Code Segment base 0x0 limit 0x type 0x1b
DPL 0, PRES 1 def 32 1, gran 1
current process= 7673 (telnetd)
-JEFF
..I had thought this was SCSI, but I dont have any scsi drives installed 
and was running on IDE.

What do I do with this information now that I finally have it ?
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: finally a crash dump on 5.3

2005-01-06 Thread Giorgos Keramidas
On 2005-01-06 08:56, J.D. Bronson [EMAIL PROTECTED] wrote:
 I was up for 2wks and today saw this:

 Fatal trap 12 - page fault while in kernel mode
 CPUID 0 APIC ID 0
 Fault write address = 0x418ad66c
 Fault code = supervisor write, page not present
 [...]

 What do I do with this information now that I finally have it ?

During the next boot, savecore should save a crash dump in /var/crash
(assuming one was successfully saved in swap when the crash happened).

Look at the Developers Handbook for details about obtaining a stack
trace of the kernel at the moment of the crash:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-gdb.html

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: finally a crash dump on 5.3

2005-01-06 Thread J.D. Bronson
At 09:32 AM 1/6/2005, Giorgos Keramidas wrote:
On 2005-01-06 08:56, J.D. Bronson [EMAIL PROTECTED] wrote:
 I was up for 2wks and today saw this:

 Fatal trap 12 - page fault while in kernel mode
 CPUID 0 APIC ID 0
 Fault write address = 0x418ad66c
 Fault code = supervisor write, page not present
 [...]

 What do I do with this information now that I finally have it ?
During the next boot, savecore should save a crash dump in /var/crash
(assuming one was successfully saved in swap when the crash happened).
Look at the Developers Handbook for details about obtaining a stack
trace of the kernel at the moment of the crash:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-gdb.html

Well so much for that idea :(
9:43:24am /var/crash ls -al
total 6
drwxr-x---   2 root  wheel  512 Dec 29 18:25 .
drwxr-xr-x  23 root  wheel  512 Jan  6 09:37 ..
-rw-r--r--   1 root  wheel5 Nov  4 19:27 minfree


--
J.D. Bronson
Aurora Health Care // Information Services // Milwaukee, WI USA
Office: 414.978.8282 // Email: [EMAIL PROTECTED] // Pager: 414.314.8282
This message should contain confidential and/or privileged information,
but it doesn't. If you are not the addressee or authorized to receive
this for the addressee, go ahead, copy, disclose, or take any action
based on this message or any information herein that you wish, what the heck!
If you have received this message in error, please ask the sender what the
heck they were thinking about.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: finally a crash dump on 5.3

2005-01-06 Thread Peter Risdon
On Thu, 2005-01-06 at 09:44 -0600, J.D. Bronson wrote:
 At 09:32 AM 1/6/2005, Giorgos Keramidas wrote:
 On 2005-01-06 08:56, J.D. Bronson [EMAIL PROTECTED] wrote:
   I was up for 2wks and today saw this:
  
   Fatal trap 12 - page fault while in kernel mode
   CPUID 0 APIC ID 0
   Fault write address = 0x418ad66c
   Fault code = supervisor write, page not present
   [...]
  
   What do I do with this information now that I finally have it ?
 
 During the next boot, savecore should save a crash dump in /var/crash
 (assuming one was successfully saved in swap when the crash happened).
 
 Look at the Developers Handbook for details about obtaining a stack
 trace of the kernel at the moment of the crash:
 http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-gdb.html
 
 
 Well so much for that idea :(
 
 9:43:24am /var/crash ls -al
 total 6
 drwxr-x---   2 root  wheel  512 Dec 29 18:25 .
 drwxr-xr-x  23 root  wheel  512 Jan  6 09:37 ..
 -rw-r--r--   1 root  wheel5 Nov  4 19:27 minfree

Call me old-fashioned, but I'd run memtest.

Peter.

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: finally a crash dump on 5.3

2005-01-06 Thread Giorgos Keramidas
On 2005-01-06 09:44, J.D. Bronson [EMAIL PROTECTED] wrote:
 At 09:32 AM 1/6/2005, Giorgos Keramidas wrote:
 On 2005-01-06 08:56, J.D. Bronson [EMAIL PROTECTED] wrote:
  I was up for 2wks and today saw this:
 
  Fatal trap 12 - page fault while in kernel mode
  CPUID 0 APIC ID 0
  Fault write address = 0x418ad66c
  Fault code = supervisor write, page not present
 
  What do I do with this information now that I finally have it ?
 
  During the next boot, savecore should save a crash dump in
  /var/crash (assuming one was successfully saved in swap when the
  crash happened).
 
  Look at the Developers Handbook for details about obtaining a stack
  trace of the kernel at the moment of the crash:
  http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-gdb.html

 Well so much for that idea :(

 9:43:24am /var/crash ls -al
 total 6
 drwxr-x---   2 root  wheel  512 Dec 29 18:25 .
 drwxr-xr-x  23 root  wheel  512 Jan  6 09:37 ..
 -rw-r--r--   1 root  wheel5 Nov  4 19:27 minfree

Then you are still seeing crashes without a dump :-(

- Giorgos

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: finally a crash dump on 5.3

2005-01-06 Thread Kris Kennaway
On Thu, Jan 06, 2005 at 08:56:45AM -0600, J.D. Bronson wrote:
 I was up for 2wks and today saw this:
 
 Fatal trap 12 - page fault while in kernel mode
 CPUID 0 APIC ID 0
 Fault write address = 0x418ad66c
 Fault code = supervisor write, page not present
 
 Inst Pointer = 0x8:0xc05109d9
 Stack Pointer = 0x10:0xe5ea8978
 Frame Pointer = 0x10:0xe5ea8994
 Code Segment base 0x0 limit 0x type 0x1b
 DPL 0, PRES 1 def 32 1, gran 1
 
 current process= 7673 (telnetd)
 
 -JEFF
 ..I had thought this was SCSI, but I dont have any scsi drives installed 
 and was running on IDE.
 
 What do I do with this information now that I finally have it ?

That's not a crashdump, that's a panic.  Check the handbook for the
steps required to enable crashdumping.

Kris


pgpmU1hJFZvjP.pgp
Description: PGP signature


FreeBSD 5.3BETA5: kernel panic and crash dump

2004-11-16 Thread Panagiotis Christias
Hello,

I have a FreeBSD 5.3-BETA5 server that panics more or less every week.
 I have compiled the kernel with makeoptions DEBUG=-g and got a
vmcore of the last crash. Next stop will be installing FreeBSD
5.3-RELEASE within the next days.

Here is the kgdb output:

# cd /usr/obj/usr/src/sys/GENERIC/
# kgdb /boot/kernel.debug/kernel.debug /var/crash/vmcore.1
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup]
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.
doadump () at pcpu.h:159
(kgdb) bt
#0  doadump () at pcpu.h:159
#1  0xc060b1fb in boot (howto=260) at ../../../kern/kern_shutdown.c:397
#2  0xc060b521 in panic (fmt=0xc07ec8c8 %s) at
../../../kern/kern_shutdown.c:553
#3  0xc07a5aa4 in trap_fatal (frame=0xe9979c30, eva=4) at
../../../i386/i386/trap.c:809
#4  0xc07a57e7 in trap_pfault (frame=0xe9979c30, usermode=0, eva=4) at
../../../i386/i386/trap.c:727
#5  0xc07a5421 in trap (frame=
  {tf_fs = 24, tf_es = 16, tf_ds = -937099248, tf_edi = 1, tf_esi
= -929937744, tf_ebp = -375939972, tf_isp = -375940004, tf_ebx =
-932514684, tf_edx = 0, tf_ecx = -928768836, tf_eax = 1, tf_trapno =
12, tf_err = 0, tf_eip = -1067512973, tf_cs = 8, tf_eflags = 66067,
tf_esp = -929937744, tf_ss = -929937836}) at
../../../i386/i386/trap.c:417
#6  0xc079390a in calltrap () at ../../../i386/i386/exception.s:140
#7  0x0018 in ?? ()
#8  0x0010 in ?? ()
#9  0xc8250010 in ?? ()
#10 0x0001 in ?? ()
#11 0xc89246b0 in ?? ()
#12 0xe9979c7c in ?? ()
#13 0xe9979c5c in ?? ()
#14 0xc86af484 in ?? ()
#15 0x in ?? ()
#16 0xc8a41cbc in ?? ()
#17 0x0001 in ?? ()
#18 0x000c in ?? ()
#19 0x in ?? ()
#20 0xc05f0b73 in knlist_remove_kq (knl=0xc89246b0, kn=0xc86af484,
knlislocked=1, kqislocked=0) at ../../../kern/kern_event.c:1510
#21 0xc05f0c53 in knlist_remove (knl=0xc89246b0, kn=0xc86af484,
islocked=1) at ../../../kern/kern_event.c:1528
#22 0xc06434f0 in filt_sordetach (kn=0xc89246b0) at
../../../kern/uipc_socket.c:2164
#23 0xc05f0f79 in knote_fdclose (td=0xc7d7baf0, fd=13) at
../../../kern/kern_event.c:1677
#24 0xc05ea4d8 in close (td=0xc7d7baf0, uap=0x0) at
../../../kern/kern_descrip.c:994
#25 0xc07a5daf in syscall (frame=
  {tf_fs = -1065811921, tf_es = 47, tf_ds = 47, tf_edi =
135872512, tf_esi = -1077966576, tf_ebp = -1077966696, tf_isp =
-375939724, tf_ebx = 672990700, tf_edx = 672983748, tf_ecx =
135872512, tf_eax = 6, tf_trapno = 22, tf_err = 2, tf_eip = 672503139,
tf_cs = 31, tf_eflags = 646, tf_esp = -1077966724, tf_ss = 47}) at
../../../i386/i386/trap.c:1001
#26 0xc079395f in Xint0x80_syscall () at ../../../i386/i386/exception.s:201
#27 0xc079002f in bsd_disklabel_le_dec (ptr=0x8194000 Address
0x8194000 out of bounds, d=Cannot access memory at address 0xbfbf88a4
) at endian.h:121
Previous frame inner to this frame (corrupt stack?)
(kgdb)


and also the dmesg output:

# dmesg
Copyright (c) 1992-2004 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.3-BETA5 #0: Sat Nov  6 19:38:50 EET 2004
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/GENERIC
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(TM) CPU 2.66GHz (2658.10-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf25  Stepping = 5
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Hyperthreading: 2 logical CPUs
real memory  = 2147418112 (2047 MB)
avail memory = 2095955968 (1998 MB)
ACPI APIC Table: INTEL  S7501HG0
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  6
 cpu3 (AP): APIC ID:  7
ACPI-0697: *** Warning: Type override - [DEB_] had invalid type
(Integer) for Scope operator, changed to (Scope)
ACPI-0697: *** Warning: Type override - [MLIB] had invalid type
(Integer) for Scope operator, changed to (Scope)
ACPI-0697: *** Warning: Type override - [DATA] had invalid type
(String) for Scope operator, changed to (Scope)
ACPI-0697: *** Warning: Type override - [SIO_] had invalid type
(String) for Scope operator, changed to (Scope)
ACPI-0697: *** Warning: Type override - [LEDP] had invalid type
(String) for Scope operator, changed to (Scope)
ACPI-0697: *** Warning: Type override - [GPEN] had invalid type
(String) for Scope operator, changed to (Scope)
ACPI-0697: *** Warning: Type override - [GPST] had invalid type
(String) for Scope operator, changed to (Scope)
ACPI-0697: *** Warning: Type override - [GP1N] had 

Crash Dump

2004-01-21 Thread Jack L. Stone

FreeBSD sage-american.com 4.8-RELEASE-p13

Hello again. Hope this the place for this question.

One of my mail servers has been crashing for several months about once
every 2 weeks at random times and after changing out all hardware,
including shifting the OS to 3 different machines, I finally concluded it
was the OS and setup to catch a crash dump. The dump is submitted below and
perhaps someone knows how to tranlate it for a recommended fix. If this
should be on another list, please let me know.

Thanks for any help!

CRASH DUMP:
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...(no debugging symbols found)...done.
(kgdb) exec-file /usr/crash/kernel.0
(kgdb) core-file /usr/crash/vmcore.0
IdlePTD at phsyical address 0x003e7000
initial pcb at physical address 0x003494a0
panicstr: lockmgr: locking against myself
panic messages:
---
panic: lockmgr: locking against myself

syncing disks... 24 3 
done
Uptime: 3h46m33s

dumping to dev #ad/0x20001, offset 3145856
dump ata0: resetting devices .. done
511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493
492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474
473 472 471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455
454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436
435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 420 419 418 417
416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398
397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 382 381 380 379
378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360
359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341
340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322
321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303
302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284
283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265
264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246
245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227
226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208
207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189
188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170
169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151
150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132
131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113
112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92
91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67
66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42
41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
---
#0  0xc018d12a in dumpsys ()
(kgdb) 
END CRASH DUMP

Best regards,
Jack L. Stone,
Administrator

Sage American
http://www.sage-american.com
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Trying to write a crash dump - Trying to debug a kernel panic

2002-10-18 Thread Joe Sotham
I am trying to debug a boot time kernel panic.  This is completely new 
territory for me and I need some help. I'm taking this one step at a 
time, the first step is to get a crash dump.

This is a repeateable panic which occurs when I boot from my windows 
partition to my FreeBSD partition.  Once the panic occurs, booting 
again clears the problem. 

Following the documentation in 
-http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html

has gotten me so far, but I am stuck.  I can trap and get dumped into 
the debugger (I think it's the debugger, the prompt is db).  However 
I am trying to  get a core dump written and that's where I am having no 
success.

1) I've added the kernel debugging options
 -- 
 options  DDB #Debug Support
 makeoptions DEBUG=-g
 options  KTRACE
 

2) made and installed the kernel,

3) added the following params to the rc.conf file
--
dumpdir=/var/crash
dumpdev=/dev/ad0s2b
-
where dumpdev corresponds to the swap device
the fstab entry corresponds below.
   
/dev/ad0s2b none  swapsw0   0
   

4)  executed the command  dumpon -v /dev/ad0s2b
5) rebooted to wwindows
6) rebooted to freeBSD - panic - db prompt

7) At this point I examined a few commands, (e.g. trace, show reg)
and finished with the panic command which according to the
documentation at

  http://www.freebsd.org/doc/en_US.ISO8859-1/  \
  books/developers-handbook/x9854.html
  
   This will cause your kernel to dump core and reboot, 
so you can later analyze the core on a higher level with gdb. 

8)  At which the system rebooted and came up, but with no core file


Joe Sotham

Christianity got over the difficulty of furious opposites
by keeping them both and keeping them furious.
  - G.K. Chesterton





To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message