From owner-freebsd-net@FreeBSD.ORG Mon Sep 27 19:46:47 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C62CB106564A for ; Mon, 27 Sep 2010 19:46:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-21.mx.aerioconnect.net [216.240.47.81]) by mx1.freebsd.org (Postfix) with ESMTP id AB73B8FC18 for ; Mon, 27 Sep 2010 19:46:47 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o8RJkkmL007766 for ; Mon, 27 Sep 2010 12:46:46 -0700 X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 513322D6013 for ; Mon, 27 Sep 2010 12:46:45 -0700 (PDT) Message-ID: <4CA0F4CE.7020905@freebsd.org> Date: Mon, 27 Sep 2010 12:47:26 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Subject: Fwd: Re: VIMAGE + NDIS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 19:46:47 -0000 anyone here have NDIS experience? On 9/27/10 10:51 AM, Nikos Vassiliadis wrote: > Julian Elischer wrote: >>> #10 0xc0978200 in rt_dispatch (m=0xc764ad00, sa=0x0) at >>> /usr/src/sys/net/rtsock.c:1374 >>> 1374 if (V_loif) >>> (kgdb) list >>> 1369 } >>> 1370 *(unsigned short *)(tag + 1) = sa->sa_family; >>> 1371 m_tag_prepend(m, tag); >>> 1372 } >>> 1373 #ifdef VIMAGE >>> 1374 if (V_loif) >>> 1375 m->m_pkthdr.rcvif = V_loif; >>> 1376 else { >>> 1377 m_freem(m); >>> 1378 return; >>> (kgdb) >>> >> >> ok so probably there is a code-path to this point that does not first >> set up the current-vnet pointer before doing this. >> what you need to do is to produce a stack-trace so we can see how >> it got here, >> and then we can figure out where on that path we should set the >> pointer. > > Here it is: > (kgdb) #0 doadump () at pcpu.h:231 > #1 0xc04d48b9 in db_fncall (dummy1=1, dummy2=0, dummy3=-1058443808, > dummy4=0xeef1d720 "") at /usr/src/sys/ddb/db_command.c:548 > #2 0xc04d4cb1 in db_command (last_cmdp=0xc0df4bdc, cmd_table=0x0, > dopager=1) > at /usr/src/sys/ddb/db_command.c:445 > #3 0xc04d4e0a in db_command_loop () at > /usr/src/sys/ddb/db_command.c:498 > #4 0xc04d6d0d in db_trap (type=12, code=0) at > /usr/src/sys/ddb/db_main.c:229 > #5 0xc08e17ce in kdb_trap (type=12, code=0, tf=0xeef1d948) > at /usr/src/sys/kern/subr_kdb.c:535 > #6 0xc0c0ae7f in trap_fatal (frame=0xeef1d948, eva=24) > at /usr/src/sys/i386/i386/trap.c:929 > #7 0xc0c0b140 in trap_pfault (frame=0xeef1d948, usermode=0, eva=24) > at /usr/src/sys/i386/i386/trap.c:851 > #8 0xc0c0bad5 in trap (frame=0xeef1d948) at > /usr/src/sys/i386/i386/trap.c:533 > #9 0xc0bec9ac in calltrap () at /usr/src/sys/i386/i386/exception.s:166 > #10 0xc0978200 in rt_dispatch (m=0xc764ad00, sa=0x0) > at /usr/src/sys/net/rtsock.c:1374 > #11 0xc0978864 in rt_ifmsg (ifp=0xc6c3d400) at > /usr/src/sys/net/rtsock.c:1168 > #12 0xc76704a1 in ?? () > #13 0xc6c3d400 in ?? () > #14 0xeef1daa8 in ?? () > #15 0xeef1daf4 in ?? () > #16 0xc769ecb3 in NdisMIndicateStatusComplete (adapter=0xc76b9200) > at /usr/src/sys/modules/ndis/../../compat/ndis/subr_ndis.c:3105 > #17 0xc766d8a1 in ?? () > #18 0xc76b9200 in ?? () > #19 0xc76c0000 in ?? () > #20 0xc76f1000 in ?? () > #21 0xeef1dacc in ?? () > #22 0xc79d2afd in ndis_bcmwl5_sys_drv_data_start () > from /boot/modules/bcmwl5_sys.ko > #23 0x006c0000 in ?? () > #24 0xeef1dbb4 in ?? () > #25 0xc79dcdac in ndis_bcmwl5_sys_drv_data_start () > from /boot/modules/bcmwl5_sys.ko > #26 0xc76c0000 in ?? () > #27 0xc76c0000 in ?? () > #28 0xc7340800 in ?? () > #29 0xc086adcc in hardclock_cpu (usermode=7077888) > at /usr/src/sys/kern/kern_clock.c:447 whoa! hardclock interrupted itself? > #30 0xc79d2afd in ndis_bcmwl5_sys_drv_data_start () > from /boot/modules/bcmwl5_sys.ko > #31 0x006c0000 in ?? () > #32 0xeef1dbb4 in ?? () > #33 0xc79dcdac in ndis_bcmwl5_sys_drv_data_start () > from /boot/modules/bcmwl5_sys.ko > #34 0xc76c0000 in ?? () > #35 0xc76c0000 in ?? () > #36 0xc7340800 in ?? () hmmm maybe we need to get ndis to put in a wrapper at this point that is called form hardclock and sets the value before going further I'd have to look at the code to see what happens here.. *wonders who has their fingers in this code*.. > #37 0xc086adcc in hardclock_cpu (usermode=-949223424) > at /usr/src/sys/kern/kern_clock.c:447 > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > > and the panic, in case it helps: > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x18 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0978200 > stack pointer = 0x28:0xeef1d988 > frame pointer = 0x28:0xeef1d9a0 > 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 = 1404 (Windows Workitem 3) > panic: from debugger > cpuid = 1 > KDB: stack backtrace: > Physical memory: 2916 MB > Dumping 113 MB: 98 82 66 50 34 18 2 > > Thanks, Nikos > _______________________________________________ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org"