Re: kern/49065: ifconfig tun0 ... sequence locks up system

[Frank Kardel <kardel%netbsd.org@localhost>]

The following reply was made to PR kern/49065; it has been noted by GNATS.

From: Frank Kardel <kardel%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/49065: ifconfig tun0 ... sequence locks up system
Date: Sun, 03 Aug 2014 22:53:57 +0200

 On 08/03/14 21:45, Nick Hudson wrote:
 > The following reply was made to PR kern/49065; it has been noted by GNATS.
 >
 >   [...snip..]
 >   trace: pid 0 lid 3 at 0xcbf3fe7c
 >   0xcbf3fe7c: netbsd:mi_switch+0xc
 >   0xcbf3feac: netbsd:sleepq_block+0xa4
 >   0xcbf3feec: netbsd:turnstile_block+0x2f8
 >   0xcbf3ff34: netbsd:mutex_enter+0x1c4
 >   0xcbf3ff64: netbsd:route_intr+0x30
 >   0xcbf3ffac: netbsd:softint_dispatch+0xec
 >   Bad frame pointer: 0xcac89a74
 >   db> bt/a cbf45340
 >   trace: pid 0 lid 5 at 0xcbf3be4c
 >   0xcbf3be4c: netbsd:mi_switch+0xc
 >   0xcbf3be7c: netbsd:sleepq_block+0xa4
 >   0xcbf3bebc: netbsd:turnstile_block+0x2f8
 >   0xcbf3bf04: netbsd:mutex_enter+0x1c4
 >   0xcbf3bf1c: netbsd:frag6_fasttimo+0x1c
 >   0xcbf3bf34: netbsd:pffasttimo+0x50
 >   0xcbf3bf64: netbsd:callout_softclock+0x18c
 >   0xcbf3bfac: netbsd:softint_dispatch+0xec
 >   Bad frame pointer: 0xcb2abd1c
 >   db> bt/a cad333c0
 >   trace: pid 790 lid 1 at 0xcac89cec
 >   0xcac89cec: netbsd:mi_switch+0xc
 >   0xcac89d1c: netbsd:sleepq_block+0xa4
 >   0xcac89d5c: netbsd:turnstile_block+0x2f8
 >   0xcac89da4: netbsd:mutex_enter+0x1c4
 >   0xcac89dcc: netbsd:soclose+0x20
 >   0xcac89de4: netbsd:soo_close+0x20
 >   0xcac89e24: netbsd:closef+0x6c
 >   0xcac89e6c: netbsd:fd_free+0x174
 >   0xcac89eec: netbsd:exit1+0x100
 >   0xcac89f0c: netbsd:sys_exit+0x3c
 >   0xcac89f7c: netbsd:syscall+0x8c
 >   0xcac89fac: netbsd:swi_handler+0x98
 >     -- tf 0xbfffca44
 >   db>
 >   db> x/x softnet_lock
 >   netbsd:softnet_lock:    cbfc5fc0
 >   
 >   
 >   They're all waiting on softnet_lock
 >   
 >   Nick
 >   
 >   
 Yes and mdnsd owns the lock. mdnsd (looking at my system) is sleeping here:
 db> bt/a dac5fc20
 trace: pid 3659 lid 1 at 0xdac61bb4
 0xdac61bb4: netbsd:mi_switch+0xc
 0xdac61be4: netbsd:sleepq_block+0xa4
 0xdac61c1c: netbsd:cv_wait+0x114
 0xdac61c44: netbsd:usbd_transfer+0x1e8
 0xdac61c7c: netbsd:usbd_do_request_flags_pipe+0xd0
 0xdac61ca4: netbsd:usbd_do_request+0x38
 0xdac61cd4: netbsd:smsc_write_reg+0x60
 0xdac61d04: netbsd:smsc_ioctl+0x110
 0xdac61dac: netbsd:if_mcast_op+0x50
 0xdac61dd4: netbsd:in_delmulti+0x70
 0xdac61df4: netbsd:ip_freemoptions+0x30
 0xdac61e14: netbsd:in_pcbdetach+0x58
 0xdac61e3c: netbsd:soclose+0xf4
 0xdac61e54: netbsd:soo_close+0x20
 0xdac61e94: netbsd:closef+0x6c
 0xdac61ef4: netbsd:fd_close+0x234
 0xdac61f0c: netbsd:sys_close+0x2c
 0xdac61f7c: netbsd:syscall+0x8c
 0xdac61fac: netbsd:swi_handler+0x98
 
 I cannot see yet why the usb transfer is not terminating, though.