From owner-freebsd-current@FreeBSD.ORG Fri Sep 15 19:10:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org 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 D42DA16A407 for ; Fri, 15 Sep 2006 19:10:27 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 447CE43D5D for ; Fri, 15 Sep 2006 19:10:26 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.6/8.13.6) with ESMTP id k8FJAPBc008627 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 15 Sep 2006 15:10:25 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k8FJAKf8020933; Fri, 15 Sep 2006 15:10:20 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17674.64156.166629.417557@grasshopper.cs.duke.edu> Date: Fri, 15 Sep 2006 15:10:20 -0400 (EDT) To: freebsd-current@freebsd.org X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Subject: multicast panic in -current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 15 Sep 2006 19:10:27 -0000 When running sources cvsupped on Monday on amd64, I hit the following panic when attempting to add a multicast address. I don't have a stack trace, but I do have a ddb trace. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x68 fault code = supervisor read, page not present instruction pointer = 0x8:0xffffffff80343402 stack pointer = 0x10:0xffffffff9399b830 frame pointer = 0x10:0xffffffff9399b8e0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1615 (multicast) [thread pid 1615 tid 100073 ] Stopped at ip_output+0x352: testb $0x5,0x68(%rdx) db> tr Tracing pid 1615 tid 100073 td 0xffffff0013d09000 ip_output() at ip_output+0x352 igmp_sendpkt() at igmp_sendpkt+0x123 igmp_joingroup() at igmp_joingroup+0xa1 in_addmulti() at in_addmulti+0x19f ip_ctloutput() at ip_ctloutput+0xfc6 sosetopt() at sosetopt+0x178 kern_setsockopt() at kern_setsockopt+0x111 setsockopt() at setsockopt+0x22 syscall() at syscall+0x272 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (105, FreeBSD ELF64, setsockopt), rip = 0x8006c0e8c, rsp = 0x7fffffffe668, rbp = 0x3 --- db> >From gdb after the reboot: (gdb) l *ip_output+0x352 0xffffffff80343402 is in ip_output (../../../netinet/ip_output.c:249). 244 } 245 /* 246 * Calculate MTU. If we have a route that is up, use that, 247 * otherwise use the interface's MTU. 248 */ 249 if (ro->ro_rt->rt_flags & (RTF_UP | RTF_HOST)) { 250 /* 251 * This case can happen if the user changed the MTU 252 * of an interface after enabling IP on it. Because 253 * most netifs don't keep track of routes pointing to 0xffffffff80337613 is in igmp_sendpkt (../../../netinet/igmp.c:510). 505 * XXX 506 * Do we have to worry about reentrancy here? Don't think so. 507 */ 508 ip_output(m, router_alert, &igmprt, 0, &imo, NULL); 509 510 ++igmpstat.igps_snd_reports; 511 } Drew