From owner-freebsd-current@FreeBSD.ORG Tue Jan 20 04:42:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87D1816A4CE for ; Tue, 20 Jan 2004 04:42:05 -0800 (PST) Received: from s1.vhost.cz (s1.vhost.cz [195.39.16.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 349EC43D55 for ; Tue, 20 Jan 2004 04:42:03 -0800 (PST) (envelope-from konfer@mikulas.com) Received: (qmail 42696 invoked by uid 89); 20 Jan 2004 13:42:01 +0100 Received: from unknown (HELO mikulas.com) (jiri@mikulas.com@195.122.204.153) by s1.vhost.cz with AES256-SHA encrypted SMTP; 20 Jan 2004 13:42:01 +0100 Message-ID: <400D2239.9050009@mikulas.com> Date: Tue, 20 Jan 2004 13:42:33 +0100 From: Jiri Mikulas User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6b) Gecko/20040116 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: PANIC: sent too much X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2004 12:42:05 -0000 hello sometimes i got this panic with high load on network interfaces map02# cat info.0 Good dump found on device /dev/ad2s1b Architecture: i386 Architecture version: 1 Dump length: 268369920B (255 MB) Blocksize: 512 Dumptime: Sat Jan 17 10:21:26 2004 Hostname: map02.modrany.czf Versionstring: FreeBSD 5.2-CURRENT #3: Mon Jan 12 18:17:30 CET 2004 mik@map02.modrany.czf:/usr/obj/usr/src/sys/ROUTER-IPFW Panicstring: sent too much Bounds: 0 (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc0634eec in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc0635277 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc065a77b in propagate_priority (td=0xc14df000) at /usr/src/sys/kern/subr_turnstile.c:176 #4 0xc065b1ed in turnstile_wait (ts=0xc14d7100, lock=0xc096546c, owner=0xc14df000) at /usr/src/sys/kern/subr_turnstile.c:510 #5 0xc062b895 in _mtx_lock_sleep (m=0xc096546c, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:482 #6 0xc062b3b7 in _mtx_lock_flags (m=0xc096546c, opts=0, file=0xc0887efa "/usr/src/sys/netinet/tcp_timer.c", line=488) at /usr/src/sys/kern/kern_mutex.c:218 #7 0xc06dffe0 in tcp_timer_rexmt (xtp=0xc302b170) at /usr/src/sys/netinet/tcp_timer.c:488 #8 0xc06458c8 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:226 #9 0xc06213f2 in ithread_loop (arg=0xc14dc500) at /usr/src/sys/kern/kern_intr.c:544 #10 0xc06203e4 in fork_exit (callout=0xc0621260 , arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:797 (kgdb) up 3 #3 0xc065a77b in propagate_priority (td=0xc14df000) at /usr/src/sys/kern/subr_turnstile.c:176 176 KASSERT(!TD_IS_SLEEPING(td), (kgdb) list 171 * first thread to grab a slock of a sx lock. In that case 172 * it is possible for us to be at SSLEEP or some other 173 * weird state. We should probably just return if the state 174 * isn't SRUN or SLOCK. 175 */ 176 KASSERT(!TD_IS_SLEEPING(td), 177 ("sleeping thread (pid %d) owns a non-sleepable lock", 178 td->td_proc->p_pid)); 179 180 /* my interfaces are: wi0: mem 0xe6000000-0xe6000fff irq 11 at device 9.0 on pci0 wi0: Intersil Firmware: Primary (1.1.1), Station (1.7.4) wi1: mem 0xe6001000-0xe6001fff irq 10 at device 10.0 on pci0 wi1: Intersil Firmware: Primary (1.1.1), Station (1.7.4) wi2: mem 0xe6002000-0xe6002fff irq 12 at device 11.0 on pci0 wi2: Intersil Firmware: Primary (1.1.1), Station (1.7.4) wi3: mem 0xe6003000-0xe6003fff irq 5 at device 12.0 on pci0 wi3: Intersil Firmware: Primary (1.1.1), Station (1.7.4) rl0: port 0xd000-0xd0ff mem 0xe6004000-0xe60040ff irq 10 at device 14.0 on pci0 Jiri