Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

re: urndis panic

Patrick Welche writes:
> I just plugged someone's mobile phone into a 9.99.7/amd64 laptop, which
> made things freeze. I then unplugged it, and then the laptop rebooted.
> (Not sure if the unplugging part is relevant.) I have a nice core file
> though:
> (gdb) target kvm netbsd.12.core
> 0xffffffff8022137a in cpu_reboot (howto=howto@entry=260, 
>     bootstr=bootstr@entry=0x0) at ../../../../arch/amd64/amd64/machdep.c:728
> 728                     dumpsys();
> (gdb) bt
> #0  0xffffffff8022137a in cpu_reboot (howto=howto@entry=260, 
>     bootstr=bootstr@entry=0x0) at ../../../../arch/amd64/amd64/machdep.c:728
> #1  0xffffffff8064fa40 in vpanic (fmt=fmt@entry=0xffffffff80b2d7e0 "trap", 
>     ap=ap@entry=0xffffde80adba3868) at ../../../../kern/subr_prf.c:336
> #2  0xffffffff8064faf1 in panic (fmt=fmt@entry=0xffffffff80b2d7e0 "trap")
>     at ../../../../kern/subr_prf.c:255
> #3  0xffffffff80223021 in trap (frame=0xffffde80adba39b0)
>     at ../../../../arch/amd64/amd64/trap.c:332
> #4  0xffffffff8021c3e5 in alltraps ()
> #5  0xffffffff803670ec in urndis_ctrl_handle_init (hdr=0xffffd7f8286c8050, 
>     un=0x58) at ../../../../dev/usb/if_urndis.c:275
> #6  urndis_ctrl_handle (un=0x58, hdr=0xffffd7f8286c8050, buf=<optimized out>, 
>     bufsz=<optimized out>) at ../../../../dev/usb/if_urndis.c:199

there are at least 2 missing functions here i think!  frame #7 would
end up calling urndis_attach(), and then that would call something
else that calls frame #6's urndis_ctrl_handle().  i can imagine that
the caller of urndis_ctrl_handle was inlined into urndis_attach(),
but the attach function itself?  this confuses me.

> #7  0xffffffff8063ba99 in config_attach_loc (
>     parent=parent@entry=0xffffd7f8230fe0c0, cf=<optimized out>, 
>     locs=locs@entry=0xffffde80adba3be0, aux=aux@entry=0xffffde80adba3bf8, 
>     print=print@entry=0xffffffff80318ef2 <usbd_ifprint>)
>     at ../../../../kern/subr_autoconf.c:1602
[ ... ]
> #12 0xffffffff8031a6a5 in usbd_new_device (parent=<optimized out>, 
>     bus=0xffffd7f822f8d4f0, depth=<optimized out>, speed=3, port=port@entry=1, 
>     up=up@entry=0xffffd7f82300b7f0) at ../../../../dev/usb/usb_subr.c:1210
> #13 0xffffffff8031d371 in uhub_explore (dev=0xffffd7f822ca6818)
>     at ../../../../dev/usb/uhub.c:758
> #14 0xffffffff80316166 in usb_discover (sc=<optimized out>, sc=<optimized out>)
>     at ../../../../dev/usb/usb.c:1006
> #15 0xffffffff80316201 in usb_event_thread (arg=0xffffd7f962219f00)
>     at ../../../../dev/usb/usb.c:564
> #16 0xffffffff80208717 in lwp_trampoline ()
> #17 0x0000000000000000 in ?? ()

that thread was attempting to attach the device, and i suspect
when you yanked something Bad happened.

can you see if you can find another thread that is doing the
detach attempt perhaps?  maybe use crash vs gdb to get that.

looks like it's crashing when returning here:

271         if (le32toh(msg->rm_medium) != RNDIS_MEDIUM_802_3) {
272                 printf("%s: medium not 802.3 (current medium: 0x%x)\n",
273                     DEVNAME(un), le32toh(msg->rm_medium));
275                 return RNDIS_STATUS_FAILURE;

can you get the whole dmesg?  it may have that printf we can
confirm it was just there.

however, the crash line is L275, the return, so that implies
the stack has been smashed.

we have had recent successful urndis users, but it's a generic
driver like ahci for sata, so each device is its own problem..

perhaps we can identify the cause without having to ask you
to ask for that phone again :-)


Home | Main Index | Thread Index | Old Index