Re: On softints, softnet_lock and sleeping (aka ipv6 vs USB network interfaces)

2016-01-01 Thread Frank Kardel
Hi ! Is there any progress on this? I see also PR/49065 being still existent on an RPI2. Also running named with 4 threads on an RPI2 together with vtund doing "ifconfig tunX ..." is a sure killer. Runinng named with only one thread gets you over it (maybe just most of the time).

Re: On softints, softnet_lock and sleeping (aka ipv6 vs USB network interfaces)

2016-01-01 Thread Nick Hudson
On 01/01/16 15:21, Frank Kardel wrote: Hi ! Is there any progress on this? I see also PR/49065 being still existent on an RPI2. Also running named with 4 threads on an RPI2 together with vtund doing "ifconfig tunX ..." is a sure killer. Runinng named with only one thread gets you over it

Re: On softints, softnet_lock and sleeping (aka ipv6 vs USB network interfaces)

2015-12-07 Thread Nick Hudson
On 12/06/15 16:01, Taylor R Campbell wrote: Date: Sun, 6 Dec 2015 09:22:05 + From: Nick Hudson It seems to me that nd6_timer is either expecting too much of the USB stack by expecting a synchronous interface to changing multicast filters that doesn't

Re: On softints, softnet_lock and sleeping (aka ipv6 vs USB network interfaces)

2015-12-07 Thread Mouse
>>> That aside, can softints even interrupt softints, or are the >>> priorities only about who goes first if two softints are scheduled >>> `simultaneously' (as far as softint_dispatch can discern)? >> The latter, iiuc. > I checked on arm, and it looks like higher-priority softints can > interrupt

Re: On softints, softnet_lock and sleeping (aka ipv6 vs USB network interfaces)

2015-12-06 Thread Taylor R Campbell
Date: Sun, 6 Dec 2015 09:22:05 + From: Nick Hudson It seems to me that nd6_timer is either expecting too much of the USB stack by expecting a synchronous interface to changing multicast filters that doesn't sleep; or the USB stack should provide an

Re: On softints, softnet_lock and sleeping (aka ipv6 vs USB network interfaces)

2015-12-06 Thread Thor Lancelot Simon
On Sun, Dec 06, 2015 at 04:01:22PM +, Taylor R Campbell wrote: > > Aside: This is probably because ipintr gets scheduled on a specified > target CPU, not on the local CPU, in pktq_enqueue...and apparently > every caller, except for bridges, specifies CPU 0. Huh. This is either a

pktq_enqueue CPU distribution [was Re: On softints, softnet_lock and sleeping (aka ipv6 vs USB network] interfaces)

2015-12-06 Thread Taylor R Campbell
Date: Sun, 6 Dec 2015 12:07:22 -0500 From: Thor Lancelot Simon On Sun, Dec 06, 2015 at 04:01:22PM +, Taylor R Campbell wrote: > > Aside: This is probably because ipintr gets scheduled on a specified > target CPU, not on the local CPU, in pktq_enqueue...and

On softints, softnet_lock and sleeping (aka ipv6 vs USB network interfaces)

2015-12-06 Thread Nick Hudson
Hi, PR/50491 raises some questions that I need some guidance on. Take this stack trace... Setting date via ntp. panic: assert_sleepable: softint caller=0x802e2014 cpu2: Begin traceback... 0xbada3c3c: netbsd:db_panic+0xc 0xbada3c6c: netbsd:vpanic+0x1b0 0xbada3c84: netbsd:snprintf

re: On softints, softnet_lock and sleeping (aka ipv6 vs USB network interfaces)

2015-12-06 Thread matthew green
Manuel Bouyer writes: > On Sun, Dec 06, 2015 at 04:01:22PM +, Taylor R Campbell wrote: > > [...] > >2) CPU 0 takes clock interrupt and nd6_timer expires. nd6_timer starts > > and > >tries to take softnet lock and blocks > > a callout shout never sleep. When it does, this delays all

Re: On softints, softnet_lock and sleeping (aka ipv6 vs USB network interfaces)

2015-12-06 Thread Manuel Bouyer
On Sun, Dec 06, 2015 at 04:01:22PM +, Taylor R Campbell wrote: > [...] >2) CPU 0 takes clock interrupt and nd6_timer expires. nd6_timer starts and >tries to take softnet lock and blocks a callout shout never sleep. When it does, this delays all other callouts. I've already fixed