The following reply was made to PR kern/34674; it has been noted by GNATS.

From: Christian Biere <christianbiere@gmx.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/34674: Panic in tcp_input() by integer division fault
Date: Sun, 1 Oct 2006 01:21:26 +0200

 Christian Biere wrote:
 >  > This is strange. Why is savecore broken for you ? Can you provide a  
 >  > backtrace ?
 
 I recompiled savecore manually since "build.sh build" keeps failing, the
 trace looks somewhat bogus and shows no details albeit the kernel is
 not stripped. This is the GENERIC kernel:
 
 (no debugging symbols found)...(gdb) target kcore /var/crash/netbsd.2.core
 panic: trap
 #0  0x0092d000 in ?? ()
 (gdb) bt
 #0  0x0092d000 in ?? ()
 #1  0xc04a9951 in cpu_reboot ()
 #2  0xc0424a9d in panic ()
 #3  0xc04b4b6a in trap ()
 #4  0xc0102eb7 in calltrap ()
 #5  0xc01b73a9 in db_get_value ()
 #6  0xc04a6aa6 in db_stack_trace_print ()
 #7  0xc0424a6f in panic ()
 #8  0xc04b4b6a in trap ()
 #9  0xc0102eb7 in calltrap ()
 #10 0xc014189d in ip_input ()
 #11 0xc0141a95 in ipintr ()
 #12 0xc0102b59 in Xsoftnet ()
 
 >  I can show you the raw message from dmesg after the panic and
 >  the assembler code.
 
 fatal integer divide fault in supervisor mode
 trap type 8 code 0 eip c014a98d cs 8 eflags 10246 cr2 bb672000 ilevel 5
 panic: trap
 Begin traceback...
 
 eip points into tcp_input(). I've dumped the assembler code of tcp_input()
 and uploaded it here:
 
 http://ghostwhitecrab.de/trash/gdb.log.bz2
 
 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006
     The NetBSD Foundation, Inc.  All rights reserved.
 Copyright (c) 1982, 1986, 1989, 1991, 1993
     The Regents of the University of California.  All rights reserved.
 
 NetBSD 4.99.3 (GENERIC) #1: Sun Oct  1 00:17:10 CEST 2006
 	src@cyclonus:/o/NetBSD/obj/sys/arch/i386/compile/GENERIC
 total memory = 255 MiB
 avail memory = 241 MiB
 timecounter: Timecounters tick every 10.000 msec
 timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
 timecounter: selected timecounter "i8254" frequency 1193182 Hz quality 100
 BIOS32 rev. 0 found at 0xfdae0
 mainbus0 (root)
 cpu0 at mainbus0: (uniprocessor)
 cpu0: AMD Duron (686-class), 1394.12 MHz, id 0x681
 cpu0: features c1c3fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR>
 cpu0: features c1c3fbff<PGE,MCA,CMOV,PAT,PSE36,MMXX,MMX>
 cpu0: features c1c3fbff<FXSR,3DNOW2,3DNOW>
 cpu0: "AMD Duron(tm) Processor"
 cpu0: I-cache 64 KiB 64B/line 2-way, D-cache 64 KiB 64B/line 2-way
 cpu0: L2 cache 64 KiB 64B/line 16-way
 cpu0: ITLB 16 4 KiB entries fully associative, 8 4 MiB entries fully associative
 cpu0: DTLB 32 4 KiB entries fully associative, 8 4 MiB entries 4-way
 cpu0: 8 page colors
 [...]
 
   
 >  > >>How-To-Repeat:
 >  > >Any TCP-heavy application with many connections should trigger this  
 >  > >panic.
 
 >  > Did you tried with anything else but gnutella ?
   
 >  No, not yet. Email and web browsing didn't trigger anything. I can
 >  try with raw TCP connections. gtk-gnutella uses IPv6 TCP sockets
 >  but so far I don't think it's IPv6 related.
 
 I tried hammering a web server in parallel with curl for a moment
 and used rtorrent for some minutes. None of those trigger the
 panic. gtk-gnutella triggers it reliably after startup.
 
 The "culprit" is definitely /sys/netinet/tcp_output.c rev. 1.144.
 With the previous revision and no other modification, I cannot
 trigger the panic.
 
 -- 
 Christian