VIMAGE + NDIS

[Nikos Vassiliadis]

Paul B Mahol wrote:
> On 9/27/10, Julian Elischer <julian at 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.

Thanks, Nikos