Date: Sat, 9 Oct 2010 16:55:28 +0000 From: Paul B Mahol <onemda@gmail.com> To: Nikos Vassiliadis <nvass9573@gmx.com> Cc: FreeBSD Net <net@freebsd.org> Subject: Re: VIMAGE + NDIS Message-ID: <AANLkTin47WKZ=Hh9ys1eB2AJz3wB0g-edzBv_S6CspX%2B@mail.gmail.com> In-Reply-To: <4CB0944D.7060806@gmx.com> References: <4CA0F4CE.7020905@freebsd.org> <AANLkTinG=TtS-h6VO6D50cY79c22rSKvYj3_bVH3p8te@mail.gmail.com> <4CB0944D.7060806@gmx.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/9/10, Nikos Vassiliadis <nvass9573@gmx.com> wrote:
> Paul B Mahol wrote:
>> On 9/27/10, Julian Elischer <julian@freebsd.org> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTin47WKZ=Hh9ys1eB2AJz3wB0g-edzBv_S6CspX%2B>