On 9/27/10, Julian Elischer <jul...@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.
Note that, for unknown reason (must be bug from old days) if_ndis.c calls
rt_ifmsg() on its own via NdisMIndicateStatusComplete(), and I see no
point to do that.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
