Re: kern/50491: unkillable wait in usbd_transfer while using usmsc0 on raspberry pi 2

[Nick Hudson <nick.hudson%gmx.co.uk@localhost>]

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

From: Nick Hudson <nick.hudson%gmx.co.uk@localhost>
To: gnats-bugs%NetBSD.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
 mfpnb%plass-family.net@localhost
Cc: 
Subject: Re: kern/50491: unkillable wait in usbd_transfer while using usmsc0
 on raspberry pi 2
Date: Thu, 3 Dec 2015 07:32:03 +0000

 On 12/3/2015 5:30 AM, Michael Plass wrote:
 > The following reply was made to PR kern/50491; it has been noted by GNATS.
 >
 > From: Michael Plass <mfpnb%plass-family.net@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc: Michael Plass <mfpnb%plass-family.net@localhost>
 > Subject: Re: kern/50491: unkillable wait in usbd_transfer while using usmsc0 on raspberry pi 2
 > Date: Wed, 2 Dec 2015 21:26:11 -0800
 >
 >   Nick,
 >   
 >   I saw one of the 'usbd_do_request: not in process context' messages go by
 >   (actually while still coming up to multiuser mode), but apparently DEBUG was
 >   not defined, so the ASSERT_SLEEPABLE() was a NOP. I've rebuilt with a call to
 >   assert_sleepable() instead, and I'll run with that.
 Oops. Any reason to not define DEBUG? assert_sleepable should do, but 
 they more checks the better.
 
 
 
 
 >   PID    LID S CPU     FLAGS       STRUCT LWP *               NAME WAIT
 >   230      1 3   0         0           bacfab60            cleanup tstile
 
 
 >   2583     1 3   3         0           ba46a0c0               sshd tstile
 
 >   0       31 3   3       200           bada4880          softclk/3 tstile
 
 
 >   0        5 3   0       200           baf05340          softclk/0 tstile
 
 >   0        3 3   0       200           baf058c0          softnet/0 tstile
 
 
 Backtraces from these might help, but see below...
 
 >   db{0}> bt/t 0t230
 >   trace: pid 230 lid 1 at 0xbaccdd4c
 >   0xbaccdd4c: netbsd:mi_switch+0x10
 >   0xbaccdd7c: netbsd:sleepq_block+0xb4
 >   0xbaccddbc: netbsd:turnstile_block+0x3e8
 >   0xbaccde1c: netbsd:mutex_enter+0x220
 >   0xbaccde3c: netbsd:sosetlock+0x58
 >   0xbaccde6c: netbsd:tcp_attach_wrapper+0x30
 >   0xbaccde9c: netbsd:socreate+0x158
 >   0xbaccdee4: netbsd:fsocreate+0xac
 >   0xbaccdf0c: netbsd:sys___socket30+0x30
 >   0xbaccdf7c: netbsd:syscall+0x88
 >   0xbaccdfac: netbsd:swi_handler+0x98
 
 Blocked on softnet_lock in sosetlock
 
 x/x softnet_lock should tell us who owns it. Get a backtrace from the 
 offending lwp.
 
 Nick