From owner-freebsd-bugs Fri May 12 19:46:46 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA21526 for bugs-outgoing; Fri, 12 May 1995 19:46:46 -0700 Received: from mpp.com (dialup-4-55.gw.umn.edu [128.101.96.55]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id TAA21498 for ; Fri, 12 May 1995 19:46:34 -0700 Received: (from mpp@localhost) by mpp.com (8.6.11/8.6.9) id VAA00225 for bugs@freebsd.org; Fri, 12 May 1995 21:45:44 -0500 From: Mike Pritchard Message-Id: <199505130245.VAA00225@mpp.com> Subject: -current kernel panics in rtfree To: bugs@FreeBSD.org Date: Fri, 12 May 1995 21:45:44 -0500 (CDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2308 Sender: bugs-owner@FreeBSD.org Precedence: bulk I don't have time to examine the crash dump I've got now, but I've seen a couple of crashes with a -current kernel from about 2 hours ago. The chain of events seems to be: 1) I make a slip connection (delete some routes, start the connection, setup my routing for my dynamic IP number from my provider), 2) do some stuff over the slip link (get mail, etc) 3) terminate the slip link (delete some of the previous routes I just setup, and reset them to route the way they were originally) The default route is involved above, which makes me suspect some code that went in recently in this area. I've never seen a problem with a kernel from a couple of weeks ago. Shortly after terminating the slip link the machine panics with: panic: rtfree During one of the panics I also saw: May 12 21:23:22 mpp /kernel.mpp: rtfree: 0xf06b2d00 not freed (neg refs) shortly before the actual panic. The stack trace from both crashes shows that we are in the softclock() routine processing the callout table. Here is the stack from the dump I have right now: Reading symbol data from /usr/var/crash/kernel.0... (no debugging symbols found)...done. IdlePTD 202000 panic: rtfree current pcb at 1d63b0 (kgdb) bt #0 0xf0199394 in boot () #1 0xf0117dc5 in panic () #2 0xf010125d in db_panic () #3 0xf0101146 in db_command (-266589452, -266589868, -267382174) #4 0xf01012c5 in db_command_loop () #5 0xf0103c48 in db_trap () #6 0xf01965ea in kdb_trap (3, 0, -272630676) #7 0xf019d9e4 in trap () #8 0xf0196e91 in exception:calltrap () #9 0xf0117dbf in panic () #10 0xf013f39f in rtfree (-261400576) #11 0xf013f434 in rtfree (-261365248) #12 0xf01441f5 in in_pcbdetach () #13 0xf014e16e in tcp_close () #14 0xf014e49e in tcp_timers (-261365504, 3) #15 0xf014ea35 in tcp_usrreq (-261372416, 19, 0, 3, 0) #16 0xf014e3cd in tcp_slowtimo () #17 0xf011fb0f in pfslowtimo (0) #18 0xf010bbf0 in softclock () #19 0xf01981e7 in exception:doreti_swi () #20 0xf012d9e0 in chmod () #21 0xf019e3c5 in syscall () (kgdb) quit Another disturbing thing that happened during the above crash was that my clock was also reset to be exactly 4 months in the past from May 12 to Jan 12, the time was correct. -- Mike Pritchard pritc003@maroon.tc.umn.edu "Go that way. Really fast. If something gets in your way, turn"