Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 01 Sep 1997 20:51:55 +0900
From:      Akira Watanabe <akira@myaw.ei.meisei-u.ac.jp>
To:        smp@freebsd.org
Subject:   Fatal trap 18: integer divide fault while in kernel mode
Message-ID:  <199709011151.UAA10588@silvia.myaw.ei.meisei-u.ac.jp>

next in thread | raw e-mail | index | archive | help
Hi.

The kernel (suped yesterday) causes a panic.

Fatal trap 18: integer divide fault while in kernel mode
cpuid = 0
lapic.id = 16777216
instruction pointer     = 0x8:0xf01bc794
stack pointer           = 0x10:0xf4cabc84
frame pointer           = 0x10:0xf4cabcd0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 236 (ftpd)
mp_lock                 = 00000003
interrupt mask          =  <- SMP: XXX
trap number             = 18
panic: integer divide fault
 cpuid 0
boot() called on cpu#0

syncing disks... 11 11 8 2 done

Here is a stack trace.

# gdb -k kernel /var/crash/vmcore.0
GDB is free software and you are welcome to 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.
GDB 4.16 (i386-unknown-freebsd), 
Copyright 1996 Free Software Foundation, Inc...
IdlePTD 24d000
current pcb at 1f9608
panic: integer divide fault
#0  boot (howto=256) at ../../kern/kern_shutdown.c:289
289                                     dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0  boot (howto=256) at ../../kern/kern_shutdown.c:289
#1  0xf0118e36 in panic (fmt=0xf01ccbea "integer divide fault")
    at ../../kern/kern_shutdown.c:416
#2  0xf01cd86f in trap_fatal (frame=0xf4cabc48) at ../../i386/i386/trap.c:806
#3  0xf01cd072 in trap (frame={tf_es = -256049136, tf_ds = 131088, 
      tf_edi = -256677376, tf_esi = 0, tf_ebp = -188039984, 
      tf_isp = -188040080, tf_ebx = 0, tf_edx = 0, tf_ecx = 4096, 
      tf_eax = 4096, tf_trapno = 18, tf_err = 0, tf_eip = -266614892, 
      tf_cs = 8, tf_eflags = 66118, tf_esp = 0, tf_ss = 3})
    at ../../i386/i386/trap.c:487
#4  0xf01bc794 in vnode_pager_haspage (object=0xf0bdb800, pindex=0, 
    before=0xf4cabd34, after=0xf4cabd30) at ../../vm/vnode_pager.c:231
#5  0xf01bbcff in vm_pager_has_page (object=0xf0bdb800, offset=0, 
    before=0xf4cabd34, after=0xf4cabd30) at ../../vm/vm_pager.c:205
#6  0xf01b2e05 in vm_fault_additional_pages (m=0xf04ef7c4, rbehind=3, 
    rahead=4, marray=0xf4cabdd0, reqpage=0xf4cabda4)
    at ../../vm/vm_fault.c:1100
#7  0xf01b21c0 in vm_fault (map=0xf0bd9300, vaddr=134385664, 
    fault_type=1 '\001', fault_flags=0) at ../../vm/vm_fault.c:414
#8  0xf01cd23a in trap_pfault (frame=0xf4cabe50, usermode=0)
    at ../../i386/i386/trap.c:681
#9  0xf01ccf47 in trap (frame={tf_es = 134348816, tf_ds = 134348816, 
      tf_edi = -259133440, tf_esi = 134385664, tf_ebp = -188039496, 
      tf_isp = -188039560, tf_ebx = 2048, tf_edx = 134387712, tf_ecx = 512, 
      tf_eax = -188047360, tf_trapno = 12, tf_err = 0, tf_eip = -266551371, 
      tf_cs = 8, tf_eflags = 66054, tf_esp = -188039368, tf_ss = -188039376})
    at ../../i386/i386/trap.c:339
#10 0xf01cbfb5 in generic_copyin ()
#11 0xf012cf6f in sosend (so=0xf0bddc00, addr=0x0, uio=0xf4cabf38, top=0x0, 
    control=0x0, flags=0, p=0xf0bb9600) at ../../kern/uipc_socket.c:449
#12 0xf0122ec8 in soo_write (fp=0xf0bdcd40, uio=0xf4cabf38, cred=0xf0bd8b00)
    at ../../kern/sys_socket.c:78
#13 0xf0120884 in write (p=0xf0bb9600, uap=0xf4cabf94, retval=0xf4cabf84)
    at ../../kern/sys_generic.c:268
#14 0xf01cdacb in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 134385664, 
      tf_esi = 2256, tf_ebp = -272642012, tf_isp = -188039196, tf_ebx = 6, 
      tf_edx = 5, tf_ecx = 1, tf_eax = 4, tf_trapno = 22, tf_err = 7, 
      tf_eip = 135028641, tf_cs = 31, tf_eflags = 531, tf_esp = -272642064, 
      tf_ss = 39}) at ../../i386/i386/trap.c:953
#15 0x80c5fa1 in ?? ()
#16 0x3658 in ?? ()
#17 0x86fb in ?? ()
#18 0x2045 in ?? ()
#19 0x1096 in ?? ()
(kgdb) 

Another problem is that sometimes the kernel reports like 

	 de0: abnormal interrupt: transmit underflow (raising TX threshold to 8|512)

Is this related to a change of the locking scheme under SMP ?

-------
Akira Watanabe, Meisei University.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709011151.UAA10588>