Re: Page faults from bento cluster (Re: Problems reading vmcores)
On 31 Aug, Kris Kennaway wrote:
> Another one. I have the cores if anyone needs to look at
> them..otherwise I'll stop posting these for now.
>
> Kris
>
> panic: page fault
> panic messages:
> ---
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x4
> fault code = supervisor read, page not present
> #6 0xc0399a48 in calltrap () at {standard input}:98
> #7 0xc021d91f in exec_elf32_imgact (imgp=0xda326bb4) at imgact_elf.c:607
> #8 0xc022a9a2 in execve (td=0xc484c240, uap=0xda326d10)
> at /usr/src/sys/kern/kern_exec.c:280
> #9 0xc03a8a31 in syscall (frame=
> {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135022716, tf_esi = 0, tf_ebp =
>-1077940704, tf_isp = -634229388, tf_ebx = 135022736, tf_edx = 135022736, tf_ecx =
>135022895, tf_eax = 59, tf_trapno = 12, tf_err = 2, tf_eip = 134697908, tf_cs = 31,
>tf_eflags = 659, tf_esp = -1077940748, tf_ss = 47})
> at /usr/src/sys/i386/i386/trap.c:1050
> #10 0xc0399a9d in Xint0x80_syscall () at {standard input}:140
> ---Can't read userspace from dump, or kernel process---
Line 607 is the inner if statement in the loop below:
/* If the executable has a brand, search for it in the brand list. */
if (brand_info == NULL) {
for (i = 0; i < MAX_BRANDS; i++) {
Elf_Brandinfo *bi = elf_brand_list[i];
if (bi != NULL &&
(hdr->e_ident[EI_OSABI] == bi->brand
|| 0 ==
strncmp((const char *)&hdr->e_ident[OLD_EI_BRAND],
bi->compat_3_brand, strlen(bi->compat_3_brand {
brand_info = bi;
break;
}
}
}
Structure member compat_3_brand is at offset 4, but I don't see how we
could be getting that far because of the 'bi != NULL' check.
Can you point gdb at the core file and print the values of bi and hdr?
BTW, this code has changed a lot since your kernel was generated.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Page faults from bento cluster (Re: Problems reading vmcores)
On Sat, Aug 31, 2002 at 11:30:32PM -0700, Don Lewis wrote: > I've seen other reports of similar crashes on the list. What version of > imgact_elf.c is this? $FreeBSD: src/sys/kern/imgact_elf.c,v 1.111 2002/06/02 20:05:54 schweikh Exp $ Kris msg42383/pgp0.pgp Description: PGP signature
Re: Page faults from bento cluster (Re: Problems reading vmcores)
On Sun, 1 Sep 2002, Don Lewis wrote:
> This code in vflush() bothers me:
>
> mtx_lock(&mntvnode_mtx);
> loop:
> for (vp = TAILQ_FIRST(&mp->mnt_nvnodelist); vp; vp = nvp) {
> /*
> * Make sure this vnode wasn't reclaimed in getnewvnode().
> * Start over if it has (it won't be on the list anymore).
> */
> if (vp->v_mount != mp)
> goto loop;
> nvp = TAILQ_NEXT(vp, v_nmntvnodes);
>
> mtx_unlock(&mntvnode_mtx);
> vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
> /*
> * Skip over a vnodes marked VV_SYSTEM.
> */
> if ((flags & SKIPSYSTEM) && (vp->v_vflag & VV_SYSTEM)) {
> VOP_UNLOCK(vp, 0, td);
> mtx_lock(&mntvnode_mtx);
> continue;
> }
> /*
> * If WRITECLOSE is set, flush out unlinked but still open
> * files (even if open only for reading) and regular file
> * vnodes open for writing.
> */
> error = VOP_GETATTR(vp, &vattr, td->td_ucred, td);
> VI_LOCK(vp);
>
> As near as I can tell the panic is happening in VOP_GETATTR(). It looks
> to me like it would be possible for the vnode to be recycled between the
> time when it passes the vp->v_mount test at the top of the loop and the
> time when vn_lock() succeeds. Shouldn't we bump the vnode reference
> count by calling vref() at the top of the loop and add the appropriate
> calls to vrele()?
Rev.1.395 made some changes that I didn't like much here. The
VOP_GETATTR() is now done unconditionally. This pessimizes vflush()
and enlarges any race windows. I think WRITECLOSE is only used for
mount -u from rw to ro, so the pessimization exercises code that was
rarely used before.
Rev.1.394 called VOP_GETATTR() with the interlock held. This was wrong
but probably reduced race windows. The window seems to have been
opened before rev.1.394 by releasing mntvnode_slock before aquiring
the interlock. RELENG_4 doesn't release mntvnode_slock at that point
(it holds both locks across the VOP_GETATTR()).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Page faults from bento cluster (Re: Problems reading vmcores)
On 31 Aug, Kris Kennaway wrote:
> Another page fault in umount
I haven't seen any reports of this one before.
> #6 0xc0399a48 in calltrap () at {standard input}:98
> #7 0xc029198d in vflush (mp=0xc5e6, rootrefs=0, flags=2) at vnode_if.h:309
> #8 0xc0200eaa in devfs_unmount (mp=0xc5e6, mntflags=524288, td=0xc5855000)
> at /usr/src/sys/fs/devfs/devfs_vfsops.c:130
> #9 0xc028d9b4 in dounmount (mp=0xc5e6, flags=-974782464, td=0xc5855000)
> at /usr/src/sys/kern/vfs_mount.c:1296
> #10 0xc028d79c in unmount (td=0xc5855000, uap=0xda021d10)
> at /usr/src/sys/kern/vfs_mount.c:1239
> #11 0xc03a8a31 in syscall (frame=
> {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134845070, tf_esi = 134950973,
>tf_ebp = -1077938936, tf_isp = -637395596, tf_ebx = 0, tf_edx = 1, tf_ecx = 3, tf_eax
>= 22, tf_trapno = 12, tf_err = 2, tf_eip = 134524579, tf_cs = 31, tf_eflags = 514,
>tf_esp = -1077939060, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1050
> #12 0xc0399a9d in Xint0x80_syscall () at {standard input}:140
> ---Can't read userspace from dump, or kernel process---
This code in vflush() bothers me:
mtx_lock(&mntvnode_mtx);
loop:
for (vp = TAILQ_FIRST(&mp->mnt_nvnodelist); vp; vp = nvp) {
/*
* Make sure this vnode wasn't reclaimed in getnewvnode().
* Start over if it has (it won't be on the list anymore).
*/
if (vp->v_mount != mp)
goto loop;
nvp = TAILQ_NEXT(vp, v_nmntvnodes);
mtx_unlock(&mntvnode_mtx);
vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
/*
* Skip over a vnodes marked VV_SYSTEM.
*/
if ((flags & SKIPSYSTEM) && (vp->v_vflag & VV_SYSTEM)) {
VOP_UNLOCK(vp, 0, td);
mtx_lock(&mntvnode_mtx);
continue;
}
/*
* If WRITECLOSE is set, flush out unlinked but still open
* files (even if open only for reading) and regular file
* vnodes open for writing.
*/
error = VOP_GETATTR(vp, &vattr, td->td_ucred, td);
VI_LOCK(vp);
As near as I can tell the panic is happening in VOP_GETATTR(). It looks
to me like it would be possible for the vnode to be recycled between the
time when it passes the vp->v_mount test at the top of the loop and the
time when vn_lock() succeeds. Shouldn't we bump the vnode reference
count by calling vref() at the top of the loop and add the appropriate
calls to vrele()?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Page faults from bento cluster (Re: Problems reading vmcores)
On 31 Aug, Kris Kennaway wrote:
> panic: page fault
> panic messages:
> ---
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x4
Looks like a NULL structure pointer dereference. It looks like the
access is four bytes into the structure.
> #7 0xc021d91f in exec_elf32_imgact (imgp=0xda326bb4) at imgact_elf.c:607
> #8 0xc022a9a2 in execve (td=0xc484c240, uap=0xda326d10)
> at /usr/src/sys/kern/kern_exec.c:280
> #9 0xc03a8a31 in syscall (frame=
> {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135022716, tf_esi = 0, tf_ebp =
>-1077940704, tf_isp = -634229388, tf_ebx = 135022736, tf_edx = 135022736, tf_ecx =
>135022895, tf_eax = 59, tf_trapno = 12, tf_err = 2, tf_eip = 134697908, tf_cs = 31,
>tf_eflags = 659, tf_esp = -1077940748, tf_ss = 47})
> at /usr/src/sys/i386/i386/trap.c:1050
> #10 0xc0399a9d in Xint0x80_syscall () at {standard input}:140
> ---Can't read userspace from dump, or kernel process---
I've seen other reports of similar crashes on the list. What version of
imgact_elf.c is this?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Page faults from bento cluster (Re: Problems reading vmcores)
Another one. I have the cores if anyone needs to look at
them..otherwise I'll stop posting these for now.
Kris
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x4
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc021cd13
stack pointer = 0x10:0xda326a50
frame pointer = 0x10:0xda326a58
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 = 9298 (sh)
trap number = 12
panic: page fault
Uptime: 4h36m51s
Dumping 510 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
213 /usr/src/sys/kern/kern_shutdown.c: No such file or directory.
in /usr/src/sys/kern/kern_shutdown.c
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
#1 0xc0242ed4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:345
#2 0xc024310b in panic () at /usr/src/sys/kern/kern_shutdown.c:493
#3 0xc03a86f3 in trap_fatal (frame=0x104, eva=0)
at /usr/src/sys/i386/i386/trap.c:846
#4 0xc03a83d2 in trap_pfault (frame=0xda326a10, usermode=0, eva=4)
at /usr/src/sys/i386/i386/trap.c:760
#5 0xc03a7efd in trap (frame=
{tf_fs = 24, tf_es = -634257392, tf_ds = -1069219824, tf_edi = -634229836,
tf_esi = -1069110816, tf_ebp = -634230184, tf_isp = -634230212, tf_ebx = 40, tf_edx =
3, tf_ecx = -725475328, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071526637,
tf_cs = 8, tf_eflags = 66199, tf_esp = -725475328, tf_ss = 1})
at /usr/src/sys/i386/i386/trap.c:446
#6 0xc0399a48 in calltrap () at {standard input}:98
#7 0xc021d91f in exec_elf32_imgact (imgp=0xda326bb4) at imgact_elf.c:607
#8 0xc022a9a2 in execve (td=0xc484c240, uap=0xda326d10)
at /usr/src/sys/kern/kern_exec.c:280
#9 0xc03a8a31 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135022716, tf_esi = 0, tf_ebp =
-1077940704, tf_isp = -634229388, tf_ebx = 135022736, tf_edx = 135022736, tf_ecx =
135022895, tf_eax = 59, tf_trapno = 12, tf_err = 2, tf_eip = 134697908, tf_cs = 31,
tf_eflags = 659, tf_esp = -1077940748, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1050
#10 0xc0399a9d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
msg42364/pgp0.pgp
Description: PGP signature
Re: Page faults from bento cluster (Re: Problems reading vmcores)
Another page fault in umount
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x28
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc02012ed
stack pointer = 0x10:0xda021b1c
frame pointer = 0x10:0xda021b30
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 = 40889 (umount)
trap number = 12
panic: page fault
Uptime: 1h54m17s
Dumping 510 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
213 /usr/src/sys/kern/kern_shutdown.c: No such file or directory.
in /usr/src/sys/kern/kern_shutdown.c
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
#1 0xc0242ed4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:345
#2 0xc024310b in panic () at /usr/src/sys/kern/kern_shutdown.c:493
#3 0xc03a86f3 in trap_fatal (frame=0x104, eva=0)
at /usr/src/sys/i386/i386/trap.c:846
#4 0xc03a83d2 in trap_pfault (frame=0xda021adc, usermode=0, eva=40)
at /usr/src/sys/i386/i386/trap.c:760
#5 0xc03a7efd in trap (frame=
{tf_fs = -637403112, tf_es = -1071120368, tf_ds = -989069296, tf_edi = 0, tf_esi
= -989006984, tf_ebp = -637396176, tf_isp = -637396216, tf_ebx = -637396056, tf_edx =
-1006065664, tf_ecx = 0, tf_eax = -637396056, tf_trapno = 12, tf_err = 0, tf_eip =
-1071639827, tf_cs = 8, tf_eflags = 66118, tf_esp = -637396056, tf_ss = 104})
at /usr/src/sys/i386/i386/trap.c:446
#6 0xc0399a48 in calltrap () at {standard input}:98
#7 0xc029198d in vflush (mp=0xc5e6, rootrefs=0, flags=2) at vnode_if.h:309
#8 0xc0200eaa in devfs_unmount (mp=0xc5e6, mntflags=524288, td=0xc5855000)
at /usr/src/sys/fs/devfs/devfs_vfsops.c:130
#9 0xc028d9b4 in dounmount (mp=0xc5e6, flags=-974782464, td=0xc5855000)
at /usr/src/sys/kern/vfs_mount.c:1296
#10 0xc028d79c in unmount (td=0xc5855000, uap=0xda021d10)
at /usr/src/sys/kern/vfs_mount.c:1239
#11 0xc03a8a31 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134845070, tf_esi = 134950973,
tf_ebp = -1077938936, tf_isp = -637395596, tf_ebx = 0, tf_edx = 1, tf_ecx = 3, tf_eax
= 22, tf_trapno = 12, tf_err = 2, tf_eip = 134524579, tf_cs = 31, tf_eflags = 514,
tf_esp = -1077939060, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1050
#12 0xc0399a9d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
msg42363/pgp0.pgp
Description: PGP signature
Page faults from bento cluster (Re: Problems reading vmcores)
I worked out what was wrong: some of them were very old vmcores that
had never been saved. There's another problem though, because those
machines have all panicked in the past 24 hours, so I don't know where
the remaining dumps went.
Kris
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x28
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc02012ed
stack pointer = 0x10:0xd7b24b1c
frame pointer = 0x10:0xd7b24b30
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 = 88342 (umount)
trap number = 12
panic: page fault
Uptime: 10h9m31s
Dumping 510 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
213 /usr/src/sys/kern/kern_shutdown.c: No such file or directory.
in /usr/src/sys/kern/kern_shutdown.c
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
#1 0xc0242ed4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:345
#2 0xc024310b in panic () at /usr/src/sys/kern/kern_shutdown.c:493
#3 0xc03a86f3 in trap_fatal (frame=0x104, eva=0)
at /usr/src/sys/i386/i386/trap.c:846
#4 0xc03a83d2 in trap_pfault (frame=0xd7b24adc, usermode=0, eva=40)
at /usr/src/sys/i386/i386/trap.c:760
#5 0xc03a7efd in trap (frame=
{tf_fs = -676200424, tf_es = -1071120368, tf_ds = -977731568, tf_edi = 0, tf_esi
= -977701728, tf_ebp = -676181200, tf_isp = -676181240, tf_ebx = -676181080, tf_edx =
-1006065664, tf_ecx = 0, tf_eax = -676181080, tf_trapno = 12, tf_err = 0, tf_eip =
-1071639827, tf_cs = 8, tf_eflags = 66118, tf_esp = -676181080, tf_ss = 104})
at /usr/src/sys/i386/i386/trap.c:446
#6 0xc0399a48 in calltrap () at {standard input}:98
#7 0xc029198d in vflush (mp=0xc4a75400, rootrefs=0, flags=2) at vnode_if.h:309
#8 0xc0200eaa in devfs_unmount (mp=0xc4a75400, mntflags=524288, td=0xc41b29c0)
at /usr/src/sys/fs/devfs/devfs_vfsops.c:130
#9 0xc028d9b4 in dounmount (mp=0xc4a75400, flags=-995666944, td=0xc41b29c0)
at /usr/src/sys/kern/vfs_mount.c:1296
#10 0xc028d79c in unmount (td=0xc41b29c0, uap=0xd7b24d10)
at /usr/src/sys/kern/vfs_mount.c:1239
#11 0xc03a8a31 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134845070, tf_esi = 134951997,
tf_ebp = -1077938952, tf_isp = -676180620, tf_ebx = 0, tf_edx = 1, tf_ecx = 3, tf_eax
= 22, tf_trapno = 12, tf_err = 2, tf_eip = 134524579, tf_cs = 31, tf_eflags = 514,
tf_esp = -1077939076, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1050
#12 0xc0399a9d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x28
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc02012ed
stack pointer = 0x10:0xd7b27b1c
frame pointer = 0x10:0xd7b27b30
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 = 50685 (umount)
trap number = 12
panic: page fault
Uptime: 10h24m57s
Dumping 510 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
213 /usr/src/sys/kern/kern_shutdown.c: No such file or directory.
in /usr/src/sys/kern/kern_shutdown.c
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
#1 0xc0242ed4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:345
#2 0xc024310b in panic () at /usr/src/sys/kern/kern_shutdown.c:493
#3 0xc03a86f3 in trap_fatal (frame=0x104, eva=0)
at /usr/src/sys/i386/i386/trap.c:846
#4 0xc03a83d2 in trap_pfault (frame=0xd7b27adc, usermode=0, eva=40)
at /usr/src/sys/i386/i386/trap.c:760
#5 0xc03a7efd in trap (frame=
{tf_fs = -676200424, tf_es = -1071120368, tf_ds = -977862640, tf_edi = 0, tf_esi
= -977815232, tf_ebp = -676168912, tf_isp = -676168952, tf_ebx = -676168792, tf_edx =
-1005847040, tf_ecx = 0, tf_eax = -676168792, tf_trapno = 12, tf_err = 0, tf_eip =
-1071639827, tf_cs = 8, tf_eflags = 66118, tf_esp = -676168792, tf_ss = 104})
at /usr/src/sys/i386/i386/trap.c:446
#6 0xc0399a48 in calltrap () at {standard input}:98
#7 0xc029198d in vflush (mp=0xc58d6c00, rootrefs=0, flags=2) at vnode_if.h:309
#8 0xc0200eaa in devfs_unmount (mp=0xc58d6c00, mntflags=524288, td=0xc41b2a80)
at /usr/src/sys/fs/devfs/devfs_vfsops.c:130
#9 0xc028d9b4 in dounmount (mp=0xc58
Re: Problems reading vmcores
On Sat, 31 Aug 2002, Kris Kennaway wrote: > On Sat, Aug 31, 2002 at 03:00:43PM -0700, Kris Kennaway wrote: > > On Sat, Aug 31, 2002 at 11:42:01PM +0200, Yann Berthier wrote: > > > On Sat, 31 Aug 2002, Kris Kennaway wrote: > > > > > > > I'm having difficulty reading vmcore images with gdb (either the > > > > system version or the port). > > > > > > > > (gdb) gohan10# gdb /a/kernel.debug /a/vmcore.0 > > > > > >But you need to specify the -k flag to gdb to use it against kernel > > >dumps, I'm sure it will give much better results :) > > > > Oops, pasted the wrong thing: > > > > gohan10# gdb -k kernel.debug vmcore.0 > > GNU gdb 5.2.0 (FreeBSD) 20020627 > > 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-undermydesk-freebsd"... > > /a/vmcore.0: Undefined error: 0. > > Also > > gohan10# bin/gdb52 -k kernel.debug vmcore.0 > GNU gdb 5.2 (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-portbld-freebsd5.0"... > /a/vmcore.0: Bad file descriptor. Sorry, I can't help you: I never uncountered this behavior, and certainly not on the recent kernel dumps I have under the hood. PS: I must admit I was a bit surprised by your initial post, I have classified it in the 'he must be aspleep / under caffeined ' category :) - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems reading vmcores
On Sat, Aug 31, 2002 at 03:00:43PM -0700, Kris Kennaway wrote: > On Sat, Aug 31, 2002 at 11:42:01PM +0200, Yann Berthier wrote: > > On Sat, 31 Aug 2002, Kris Kennaway wrote: > > > > > I'm having difficulty reading vmcore images with gdb (either the > > > system version or the port). > > > > > > (gdb) gohan10# gdb /a/kernel.debug /a/vmcore.0 > > > >But you need to specify the -k flag to gdb to use it against kernel > >dumps, I'm sure it will give much better results :) > > Oops, pasted the wrong thing: > > gohan10# gdb -k kernel.debug vmcore.0 > GNU gdb 5.2.0 (FreeBSD) 20020627 > 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-undermydesk-freebsd"... > /a/vmcore.0: Undefined error: 0. Also gohan10# bin/gdb52 -k kernel.debug vmcore.0 GNU gdb 5.2 (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-portbld-freebsd5.0"... /a/vmcore.0: Bad file descriptor. Kris msg42357/pgp0.pgp Description: PGP signature
Re: Problems reading vmcores
On Sat, Aug 31, 2002 at 11:42:01PM +0200, Yann Berthier wrote: > On Sat, 31 Aug 2002, Kris Kennaway wrote: > > > I'm having difficulty reading vmcore images with gdb (either the > > system version or the port). > > > > (gdb) gohan10# gdb /a/kernel.debug /a/vmcore.0 > >But you need to specify the -k flag to gdb to use it against kernel >dumps, I'm sure it will give much better results :) Oops, pasted the wrong thing: gohan10# gdb -k kernel.debug vmcore.0 GNU gdb 5.2.0 (FreeBSD) 20020627 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-undermydesk-freebsd"... /a/vmcore.0: Undefined error: 0. Kris msg42356/pgp0.pgp Description: PGP signature
Re: Problems reading vmcores
On Sat, 31 Aug 2002, Kris Kennaway wrote: > I'm having difficulty reading vmcore images with gdb (either the > system version or the port). > > (gdb) gohan10# gdb /a/kernel.debug /a/vmcore.0 But you need to specify the -k flag to gdb to use it against kernel dumps, I'm sure it will give much better results :) regards, - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problems reading vmcores
I'm having difficulty reading vmcore images with gdb (either the system version or the port). (gdb) gohan10# gdb /a/kernel.debug /a/vmcore.0 GNU gdb 5.2.0 (FreeBSD) 20020627 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-undermydesk-freebsd"... "/a/vmcore.0" is not a core dump: File format not recognized I have a lovely collection of panics from the bento cluster over the last 12 hours, but no way to get tracebacks. savecore: reboot after panic: ufs_dirbad: bad dir savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 savecore: reboot after panic: page fault savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 savecore: reboot after panic: sleeping thread owns a mutex savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 savecore: reboot after panic: page fault savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 savecore: reboot after panic: page fault savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 savecore: reboot after panic: pipe buffer gone savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 savecore: reboot after panic: Most recently used by AD driver savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 Kris msg42353/pgp0.pgp Description: PGP signature
