From owner-freebsd-net@FreeBSD.ORG Sat Oct 9 16:55:29 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 A2F02106567A; Sat, 9 Oct 2010 16:55:29 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3C5C48FC12; Sat, 9 Oct 2010 16:55:28 +0000 (UTC) Received: by vws1 with SMTP id 1so514520vws.13 for ; Sat, 09 Oct 2010 09:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=LJb94KJnkgYvd6MGOn9BQfiJhFmHUghtzPQSBdaZFqs=; b=bi1ghff5mbm++0eJWY0Hd5neXE9svfisK3IUbJvPZlXsWwMsoBFWnNrO5JXVwsEGGS 4aQBKsntm4yZ2HDGBXrqHtNpKzwzIYY0kuyh8BpTnVFK52cw0Za+0ppMnxZ6+x6Ubouy tOPMx2gIDqFC0tpWSXH0kfO6xr8SO8tvZccHU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SsPXMxwYTe9gmRQRJH4W89PBFgZNT3sjUuMIcIPGhazAeH6Dw80R4L35xagIbMoZie /J7FFLQA5/lpQsxmjNppQm4v05uEX4LT//xfFLffFKBlgJUMmLFG5wZJ96+P3427/ES+ hhPNfzfuII+qEldRCAg64BS+2VFN4F35aW3YM= MIME-Version: 1.0 Received: by 10.220.179.11 with SMTP id bo11mr323159vcb.87.1286643328238; Sat, 09 Oct 2010 09:55:28 -0700 (PDT) Received: by 10.220.180.135 with HTTP; Sat, 9 Oct 2010 09:55:28 -0700 (PDT) In-Reply-To: <4CB0944D.7060806@gmx.com> References: <4CA0F4CE.7020905@freebsd.org> <4CB0944D.7060806@gmx.com> Date: Sat, 9 Oct 2010 16:55:28 +0000 Message-ID: From: Paul B Mahol To: Nikos Vassiliadis Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net Subject: 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: Sat, 09 Oct 2010 16:55:29 -0000 On 10/9/10, Nikos Vassiliadis wrote: > Paul B Mahol wrote: >> On 9/27/10, Julian Elischer wrote: >>> 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 >>>> >> >> Please give more background information of this case. >> Personally I never tested VIMAGE. > > Sorry for the delayed response, > > It is easily producible. Build a kernel with VIMAGE, associate > with an AP, run dhclient and then change the SSID to something > random. > > If there is something I can do to help you debug this problem, > please don't hesitate to ask. First remove rt_ifmsg() call from if_ndis.c rebuild & load if_ndis module and tell me if it still happens.