Re: [ge...@dts.su: Re[2]: fatal trap 12]
[Please, remove the questions@ on the reply, this is the topic for
f...@].
On Sat, Jun 06, 2009 at 08:16:00PM +0400, Chagin Dmitry wrote:
> - Forwarded message from ge...@dts.su -
>
> Date: Sat, 6 Jun 2009 10:58:11 +0400
> From: ge...@dts.su
> To: freebsd-questions@freebsd.org
> Subject: Re[2]: fatal trap 12
>
> Hello, Freebsd-questions.
>
> After one of new crash I have this:
>
> 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:
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 02
> fault virtual address = 0x0
> fault code = supervisor read data, page not present
> instruction pointer = 0x8:0x804c4eb8
> stack pointer = 0x10:0xff807a0478f0
> frame pointer = 0x10:0xff807a047930
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 32668 (perl5.10.0)
> Physical memory: 4082 MB
> Dumping 1647 MB: 1632 1616 1600 1584 1568 1552 1536 1520 1504 1488 1472 1456
> 1440 1424 1408 1392 1376 1360 1344 1328 1312 1296 1280 1264 1248 1232 1216
> 1200 1184 1168 1152 1136 1120 1104 1088 1072 1056 1040 1024 1008 992 976 960
> 944 928 912 896 880 864 848 832 816 800 784 768 752 736 720 704 688 672 656
> 640 624 608 592 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352
> 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16
>
> Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from
> /boot/kernel/accf_http.ko.symbols...done.
> done.
> Loaded symbols for /boot/kernel/accf_http.ko
> #0 doadump () at pcpu.h:195
> 195 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
> (kgdb) list *0x804c4eb8
> 0x804c4eb8 is in pfs_ioctl
> (/usr/src/sys/fs/pseudofs/pseudofs_vnops.c:265).
> 260 static int
> 261 pfs_ioctl(struct vop_ioctl_args *va)
> 262 {
> 263 struct vnode *vn = va->a_vp;
> 264 struct pfs_vdata *pvd = vn->v_data;
> 265 struct pfs_node *pn = pvd->pvd_pn;
> 266 struct proc *proc;
> 267 int error;
> 268
> 269 PFS_TRACE(("%s: %lx", pn->pn_name, va->a_command));
> (kgdb) backtrace
> #0 doadump () at pcpu.h:195
> #1 0x801c8dac in db_fncall (dummy1=Variable "dummy1" is not
> available.
> ) at /usr/src/sys/ddb/db_command.c:516
> #2 0x801c92df in db_command (last_cmdp=0x80b30c88,
> cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:413
> #3 0x801c94f0 in db_command_loop () at
> /usr/src/sys/ddb/db_command.c:466
> #4 0x801cb0d9 in db_trap (type=Variable "type" is not available.
> ) at /usr/src/sys/ddb/db_main.c:228
> #5 0x80554e55 in kdb_trap (type=12, code=0, tf=0xff807a047840)
> at /usr/src/sys/kern/subr_kdb.c:524
> #6 0x807fae80 in trap_fatal (frame=0xff807a047840, eva=Variable
> "eva" is not available.
> ) at /usr/src/sys/amd64/amd64/trap.c:752
> #7 0x807fb254 in trap_pfault (frame=0xff807a047840, usermode=0)
> at /usr/src/sys/amd64/amd64/trap.c:673
> #8 0x807fbc02 in trap (frame=0xff807a047840) at
> /usr/src/sys/amd64/amd64/trap.c:444
> #9 0x807df35e in calltrap () at
> /usr/src/sys/amd64/amd64/exception.S:209
> #10 0x804c4eb8 in pfs_ioctl (va=0xff807a047a10) at
> /usr/src/sys/fs/pseudofs/pseudofs_vnops.c:264
> #11 0x805bb1d3 in vn_ioctl (fp=Variable "fp" is not available.
> ) at vnode_if.h:437
> #12 0x80562d02 in kern_ioctl (td=0xff0006682000, fd=3,
> com=1076655123, data=0xff00ad2b7d40 "") at file.h:269
> #13 0x80563029 in ioctl (td=0xff0006682000,
> uap=0xff807a047bf0) at /usr/src/sys/kern/sys_generic.c:571
> #14 0x807fb4d6 in syscall (frame=0xff807a047c80) at
> /usr/src/sys/amd64/amd64/trap.c:900
> #15 0x807df56b in Xfast_syscall () at
> /usr/src/sys/amd64/amd64/exception.S:330
> #16 0x000800c9c0ec in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb)
>
>
> Can You help me? What can I do? Server crash periodicaly...
The issue is that VOP_IOCTL interface takes unlocked vnode, which
may be reclaimed at any moment. The right thing to do is to fix
this before 8.0 freezed KPI. Please, try the patch below.
diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
index a7f47b2..018e6bd 100644
--- a/sys/cddl/contrib/
Re: "sleeping without queue" ?
On Tue, Jul 22, 2008 at 01:09:28PM -0400, Mikhail Teterin wrote: > Kris Kennaway написав(ла): > >Mikhail Teterin wrote: > >>Kris Kennaway написав(ла): > >>>Well, I mean kernel backtrace. > >>Can I obtain that remotely and without restarting/panicking the box? > >>Thanks, > >kgdb on /dev/mem or procstat >[EMAIL PROTECTED]:~ (107) kgdb /boot/kernel/kernel /dev/mem >[...] >(kgdb) bt >#0 0x in ?? () >Error accessing memory address 0x0: Bad address. > > Even less luck with procstat: > >[EMAIL PROTECTED]:~ (108) locate procstat >[EMAIL PROTECTED]:~ (109) procstat >procstat: Нев?дома команда. >[EMAIL PROTECTED]:~ (110) man procstat >No manual entry for procstat > > I'm sorry, but you'll need to be more specific. What should I type? Thanks, Did you switched to the process before doing backtrace (using the proc command) ? What is the exact version of the system ? Note that procstat appeared in the late RELENG_7. Also, show the output of ps axl . pgps6aEl30pRA.pgp Description: PGP signature
Re: how sys_select, sys_fork, ... are defined for thread libraries?
On Thu, Aug 02, 2007 at 02:00:05PM -0700, Jin Guojun wrote: > I am trying to understand how these __sys_xxx functions are defined for > thread libraries. > Following string search tells that all thread libraries are using these > __sys_xxx functions, > for example, __sys_select(). However, the search also shows that these > functions are not defined anywhere in the entire source tree. > > /usr/src: findstring sys_select "*.[hcS]" > total files= 21687 : pattern= sys_select rootdir= /usr/src > regular mode: Thu Aug 2 13:31:40 PDT 2007 > ./lib/libc_r/uthread/uthread_fork.c > 91: * __sys_select: > > ./lib/libpthread/thread/thr_private.h > 1264:int __sys_select(int, fd_set *, fd_set *, fd_set *, struct > timeval *); > > ./lib/libpthread/thread/thr_select.c > 61: ret = __sys_select(numfds, readfds, writefds, exceptfds, > timeout); > > ./lib/libthr/thread/thr_private.h > 805:int __sys_select(int, fd_set *, fd_set *, fd_set *, struct > timeval *); > > ./lib/libthr/thread/thr_syscalls.c > 435:ret = __sys_select(numfds, readfds, writefds, exceptfds, timeout); > > > By searching the usr/lib objects, I found them in libc, but they are not > in libc source tree. > Can someone shed some light on how these system calls are built into > libc and what is the > different between standard syscall APIs and these __sys_syscall APIs, > e.g., __sys_read() vs. read(), etc. > > Thanks, > > -Jin > > > nm /usr/lib/libc.a | grep __sys_ > 0008 T __sys_sigreturn > 0008 T __sys_setlogin > 0008 T __sys_reboot > ... snapped > 0008 T __sys_kse_release > 0008 T __sys_kse_thr_interrupt > 0008 T __sys_kse_create > 0008 T __sys_kse_wakeup > ... skipped > 0008 T __sys_getdtablesize > 0008 T __sys_select > 0008 T __sys_ioctl > 0008 T __sys_close > 0008 T __sys_write > 0008 T __sys_read > 0008 T __sys___syscall The C standard specifies that namespace of identifiers starting with __ or _ is reserved for implementation. On the other hand, C standard allows for the programs to use any symbol not reserved by standard. The thread libraries (and libc) shall internally use the "right" implementation of syscalls, as opposed to some symbol supplied by user binary. To achieve this, for each syscall x, libc defines the normal symbol __sys_x, and two weak symbols _x and x. See, for instance, the file lib/libc/select.S from the obj directory, and lib/libc/i386/SYS.h for corresponding include file. Definition of weak symbols is provided by ELF specification. Simplyfing, weakness of the symbol mean that it is used only unless somebody provides the same normal symbol. Normal symbols from text segment are marked by "T" in nm output, and weak symbols has "t" mark. pgp6Dcyp1BXUr.pgp Description: PGP signature
