Hi Peter,
I hit a panic in sys_sched_yield() because(for some unknown reason)
current->sched_class->yield_task is NULL.
It's an ARM embedded board with 3.4-rt kernel.
Could you share any hint for the possible causes?
Panic log attached.
Line 4551 "yield_task" is NULL.
4546 SYSCALL_DEFINE0(sched_yield)
4547 {
4548 struct rq *rq = this_rq_lock();
4549
4550 schedstat_inc(rq, yld_count);
4551 current->sched_class->yield_task(rq);
4552
4553 /*
4554 * Since we are going to call schedule() anyway, there's
4555 * no need to preempt or enable interrupts:
4556 */
4557 __release(rq->lock);
4558 spin_release(&rq->lock.dep_map, 1, _THIS_IP_);
4559 do_raw_spin_unlock(&rq->lock);
4560 sched_preempt_enable_no_resched();
4561
4562 schedule();
4563
4564 return 0;
4565 }
[12889.449746] r3 : 00000000 r2 : 00000001 r1 : 0000ddfc r0 : c0c1d2c0
r3 is NULL, so "blx r3" crashed.
c007a4e8: e12fff33 blx r3
c007a498 <sys_sched_yield>:
c007a498: e1a0c00d mov ip, sp
c007a49c: e92dd830 push {r4, r5, fp, ip, lr, pc}
c007a4a0: e24cb004 sub fp, ip, #4
c007a4a4: f10c0080 cpsid i
c007a4a8: e1a0300d mov r3, sp
c007a4ac: e3c34d7f bic r4, r3, #8128 ; 0x1fc0
c007a4b0: e3c4403f bic r4, r4, #63 ; 0x3f
c007a4b4: e3012df8 movw r2, #7672 ; 0x1df8
c007a4b8: e34c2073 movt r2, #49267 ; 0xc073
c007a4bc: e30232c0 movw r3, #8896 ; 0x22c0
c007a4c0: e5941014 ldr r1, [r4, #20]
c007a4c4: e34c3070 movt r3, #49264 ; 0xc070
c007a4c8: e7925101 ldr r5, [r2, r1, lsl #2]
c007a4cc: e0835005 add r5, r3, r5
c007a4d0: e1a00005 mov r0, r5
c007a4d4: eb0d472d bl c03cc190 <_raw_spin_lock>
c007a4d8: e594300c ldr r3, [r4, #12]
c007a4dc: e1a00005 mov r0, r5
c007a4e0: e5933030 ldr r3, [r3, #48] ; 0x30
c007a4e4: e593300c ldr r3, [r3, #12]
c007a4e8: e12fff33 blx r3
c007a4ec: f57ff05f dmb sy
c007a4f0: e3a03801 mov r3, #65536 ; 0x10000
c007a4f4: e1952f9f ldrex r2, [r5]
c007a4f8: e6522f13 uadd16 r2, r2, r3
c007a4fc: e1851f92 strex r1, r2, [r5]
c007a500: e3310000 teq r1, #0
c007a504: 1afffffa bne c007a4f4 <sys_sched_yield+0x5c>
c007a508: f57ff04f dsb sy
c007a50c: e320f004 sev
c007a510: e5943004 ldr r3, [r4, #4]
c007a514: e2433001 sub r3, r3, #1
c007a518: e5843004 str r3, [r4, #4]
c007a51c: eb0d44ae bl c03cb7dc <schedule>
c007a520: e3a00000 mov r0, #0
c007a524: e89da830 ldm sp, {r4, r5, fp, sp, pc}
Thanks,
Ming
On Wed, Apr 09, 2014 at 10:43:32AM -0700, Lin Ming wrote:
> Hi Peter,
>
> I hit a panic in sys_sched_yield() because(for some unknown reason)
> current->sched_class->yield_task is NULL.
> It's an ARM embedded board with 3.4-rt kernel.
>
> Could you share any hint for the possible causes?
What class does current->sched_class point to?
On Wed, Apr 9, 2014 at 11:25 AM, Peter Zijlstra <[email protected]> wrote:
> On Wed, Apr 09, 2014 at 10:43:32AM -0700, Lin Ming wrote:
>> Hi Peter,
>>
>> I hit a panic in sys_sched_yield() because(for some unknown reason)
>> current->sched_class->yield_task is NULL.
>> It's an ARM embedded board with 3.4-rt kernel.
>>
>> Could you share any hint for the possible causes?
>
> What class does current->sched_class point to?
[12890.088232] Process swapper/0 (pid: 0, stack limit = 0xc07042f0)
It's idle task. I think it should be idle_sched_class.
But let me double check it.
Thanks.
On Wed, Apr 9, 2014 at 11:32 AM, Lin Ming <[email protected]> wrote:
> On Wed, Apr 9, 2014 at 11:25 AM, Peter Zijlstra <[email protected]> wrote:
>> On Wed, Apr 09, 2014 at 10:43:32AM -0700, Lin Ming wrote:
>>> Hi Peter,
>>>
>>> I hit a panic in sys_sched_yield() because(for some unknown reason)
>>> current->sched_class->yield_task is NULL.
>>> It's an ARM embedded board with 3.4-rt kernel.
>>>
>>> Could you share any hint for the possible causes?
>>
>> What class does current->sched_class point to?
>
> [12890.088232] Process swapper/0 (pid: 0, stack limit = 0xc07042f0)
>
> It's idle task. I think it should be idle_sched_class.
> But let me double check it.
idle_sched_class has no "yield_task" defined.
Does it mean that idle task should not call yield() at all?
[12890.088232] Process swapper/0 (pid: 0, stack limit = 0xc07042f0)
[12890.094092] Stack: (0xc0705860 to 0xc0706000)
[12890.584616] Backtrace:
[12890.586996] [<c007a364>] (sys_sched_yield+0x0/0x90) from
[<c03cbf90>] (yield+0x2c/0x30)
[12890.598258] [<c03cbf64>] (yield+0x0/0x30) from [<c02eb650>]
(netlink_broadcast_filtered+0x3ec/0x400)
[12890.607170] [<c02eb264>] (netlink_broadcast_filtered+0x0/0x400)
from [<c02eb68c>] (netlink_broadcast+0x28/0x30)
[12890.616998] [<c02eb664>] (netlink_broadcast+0x0/0x30) from
[<c02ed420>] (msg_netlink_broadcast+0xa8/0xb4)
[12890.626337] [<c02ed378>] (msg_netlink_broadcast+0x0/0xb4) from
[<c039ad10>] (br_igmp_send_netlink_msg+0xb0/0xbc)
[12890.636256] [<c039ac60>] (br_igmp_send_netlink_msg+0x0/0xbc) from
[<c039b4a0>] (br_igmp_mc_fdb_add+0x424/0x6c0)
[12890.646084] [<c039b07c>] (br_igmp_mc_fdb_add+0x0/0x6c0) from
[<c039bd34>] (br_igmp_process_v3+0x4a8/0x518)
[12890.655515] [<c039b88c>] (br_igmp_process_v3+0x0/0x518) from
[<c039c110>] (br_igmp_snooping+0x36c/0x3e4)
[12890.664762] [<c039bda4>] (br_igmp_snooping+0x0/0x3e4) from
[<c039c204>] (br_igmp_mc_forward+0x7c/0x270)
[12890.673918] [<c039c188>] (br_igmp_mc_forward+0x0/0x270) from
[<c0393120>] (br_handle_frame_finish+0x160/0x358)
[12890.683654] [<c0392fc0>] (br_handle_frame_finish+0x0/0x358) from
[<c0398e7c>] (br_nf_pre_routing_finish+0x348/0x364)
[12890.693940] [<c0398b34>] (br_nf_pre_routing_finish+0x0/0x364) from
[<c03994c4>] (br_nf_pre_routing+0x5e0/0x630)
[12890.709291] [<c0398ee4>] (br_nf_pre_routing+0x0/0x630) from
[<c02eebf8>] (nf_iterate+0x68/0xa4)
[12890.717746] [<c02eeb90>] (nf_iterate+0x0/0xa4) from [<c02eec9c>]
(nf_hook_slow+0x68/0x124)
[12890.725803] [<c02eec34>] (nf_hook_slow+0x0/0x124) from [<c03935ac>]
(br_handle_frame+0x294/0x2e4)
[12890.734471] [<c0393318>] (br_handle_frame+0x0/0x2e4) from
[<c02c9eb0>] (__netif_receive_skb+0x3b0/0x514)
[12890.743718] [<c02c9b00>] (__netif_receive_skb+0x0/0x514) from
[<c02cabf0>] (netif_receive_skb+0xa8/0xbc)
[12890.752966] [<c02cab48>] (netif_receive_skb+0x0/0xbc) from
[<c02cd730>] (napi_skb_finish+0x34/0x50)
[12890.765235] [<c02cd6fc>] (napi_skb_finish+0x0/0x50) from
[<c02cd848>] (napi_gro_receive+0xfc/0x100)
[12890.777566] [<c02cd74c>] (napi_gro_receive+0x0/0x100) from
[<bf1a1618>] (nss_gmac_receive+0x48/0x4c [qca_nss_gmac])
[12890.787759] [<bf1a15d0>] (nss_gmac_receive+0x0/0x4c [qca_nss_gmac])
from [<bf186e40>] (nss_core_handle_napi+0x440/0xa78 [qca_nss_drv])
[12890.802989] [<bf186a00>] (nss_core_handle_napi+0x0/0xa78
[qca_nss_drv]) from [<c02cade4>] (net_rx_action+0x84/0x174)
[12890.813244] [<c02cad60>] (net_rx_action+0x0/0x174) from
[<c005ad80>] (__do_softirq+0xbc/0x160)
[12890.821637] [<c005acc4>] (__do_softirq+0x0/0x160) from [<c005b250>]
(irq_exit+0x58/0xa4)
[12890.829542] [<c005b1f8>] (irq_exit+0x0/0xa4) from [<c000ed60>]
(handle_IRQ+0x8c/0xb8)
[12890.840651] [<c000ecd4>] (handle_IRQ+0x0/0xb8) from [<c0008608>]
(gic_handle_irq+0x70/0xc4)
[12890.857681] [<c0008598>] (gic_handle_irq+0x0/0xc4) from
[<c000e080>] (__irq_svc+0x40/0x70)
>
> Thanks.
On Wed, Apr 09, 2014 at 11:49:17AM -0700, Lin Ming wrote:
> On Wed, Apr 9, 2014 at 11:32 AM, Lin Ming <[email protected]> wrote:
> > On Wed, Apr 9, 2014 at 11:25 AM, Peter Zijlstra <[email protected]> wrote:
> >> On Wed, Apr 09, 2014 at 10:43:32AM -0700, Lin Ming wrote:
> >>> Hi Peter,
> >>>
> >>> I hit a panic in sys_sched_yield() because(for some unknown reason)
> >>> current->sched_class->yield_task is NULL.
> >>> It's an ARM embedded board with 3.4-rt kernel.
> >>>
> >>> Could you share any hint for the possible causes?
> >>
> >> What class does current->sched_class point to?
> >
> > [12890.088232] Process swapper/0 (pid: 0, stack limit = 0xc07042f0)
> >
> > It's idle task. I think it should be idle_sched_class.
> > But let me double check it.
>
> idle_sched_class has no "yield_task" defined.
> Does it mean that idle task should not call yield() at all?
Indeed. The idle task should never call yield. In fact, it should only
ever run the idle loop code, and that had better bloody not include a
yield call.
On Wed, Apr 09, 2014 at 10:43:32AM -0700, Lin Ming wrote:
> [12890.586996] [<c007a364>] (sys_sched_yield+0x0/0x90) from [<c03cbf90>] (yield+0x2c/0x30)
> [12890.594779] r5:c18f4000 r4:00000000
> [12890.598258] [<c03cbf64>] (yield+0x0/0x30) from [<c02eb650>] (netlink_broadcast_filtered+0x3ec/0x400)
> [12890.607170] [<c02eb264>] (netlink_broadcast_filtered+0x0/0x400) from [<c02eb68c>] (netlink_broadcast+0x28/0x30)
> [12890.616998] [<c02eb664>] (netlink_broadcast+0x0/0x30) from [<c02ed420>] (msg_netlink_broadcast+0xa8/0xb4)
> [12890.626337] [<c02ed378>] (msg_netlink_broadcast+0x0/0xb4) from [<c039ad10>] (br_igmp_send_netlink_msg+0xb0/0xbc)
> [12890.636256] [<c039ac60>] (br_igmp_send_netlink_msg+0x0/0xbc) from [<c039b4a0>] (br_igmp_mc_fdb_add+0x424/0x6c0)
> [12890.646084] [<c039b07c>] (br_igmp_mc_fdb_add+0x0/0x6c0) from [<c039bd34>] (br_igmp_process_v3+0x4a8/0x518)
> [12890.655515] [<c039b88c>] (br_igmp_process_v3+0x0/0x518) from [<c039c110>] (br_igmp_snooping+0x36c/0x3e4)
> [12890.664762] [<c039bda4>] (br_igmp_snooping+0x0/0x3e4) from [<c039c204>] (br_igmp_mc_forward+0x7c/0x270)
> [12890.673918] [<c039c188>] (br_igmp_mc_forward+0x0/0x270) from [<c0393120>] (br_handle_frame_finish+0x160/0x358)
> [12890.683654] [<c0392fc0>] (br_handle_frame_finish+0x0/0x358) from [<c0398e7c>] (br_nf_pre_routing_finish+0x348/0x364)
> [12890.693940] [<c0398b34>] (br_nf_pre_routing_finish+0x0/0x364) from [<c03994c4>] (br_nf_pre_routing+0x5e0/0x630)
> [12890.703767] r7:c2e5c000 r6:00000000 r5:d71899c0 r4:da6ed0d0
> [12890.709291] [<c0398ee4>] (br_nf_pre_routing+0x0/0x630) from [<c02eebf8>] (nf_iterate+0x68/0xa4)
> [12890.717746] [<c02eeb90>] (nf_iterate+0x0/0xa4) from [<c02eec9c>] (nf_hook_slow+0x68/0x124)
> [12890.725803] [<c02eec34>] (nf_hook_slow+0x0/0x124) from [<c03935ac>] (br_handle_frame+0x294/0x2e4)
> [12890.734471] [<c0393318>] (br_handle_frame+0x0/0x2e4) from [<c02c9eb0>] (__netif_receive_skb+0x3b0/0x514)
> [12890.743718] [<c02c9b00>] (__netif_receive_skb+0x0/0x514) from [<c02cabf0>] (netif_receive_skb+0xa8/0xbc)
> [12890.752966] [<c02cab48>] (netif_receive_skb+0x0/0xbc) from [<c02cd730>] (napi_skb_finish+0x34/0x50)
> [12890.761756] r5:d71899c0 r4:00000003
> [12890.765235] [<c02cd6fc>] (napi_skb_finish+0x0/0x50) from [<c02cd848>] (napi_gro_receive+0xfc/0x100)
> [12890.774056] r4:00000000 r3:00000000
> [12890.777566] [<c02cd74c>] (napi_gro_receive+0x0/0x100) from [<bf1a1618>] (nss_gmac_receive+0x48/0x4c [qca_nss_gmac])
> [12890.787759] [<bf1a15d0>] (nss_gmac_receive+0x0/0x4c [qca_nss_gmac]) from [<bf186e40>] (nss_core_handle_napi+0x440/0xa78 [qca_nss_drv])
> [12890.799510] r5:d71899c0 r4:bf18e410
> [12890.802989] [<bf186a00>] (nss_core_handle_napi+0x0/0xa78 [qca_nss_drv]) from [<c02cade4>] (net_rx_action+0x84/0x174)
> [12890.813244] [<c02cad60>] (net_rx_action+0x0/0x174) from [<c005ad80>] (__do_softirq+0xbc/0x160)
> [12890.821637] [<c005acc4>] (__do_softirq+0x0/0x160) from [<c005b250>] (irq_exit+0x58/0xa4)
> [12890.829542] [<c005b1f8>] (irq_exit+0x0/0xa4) from [<c000ed60>] (handle_IRQ+0x8c/0xb8)
Look at that, its calling yield() from a non-preemptible context as
well.
That code is full of fail.
On Wed, Apr 09, 2014 at 09:47:42PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 09, 2014 at 10:43:32AM -0700, Lin Ming wrote:
> > [12890.586996] [<c007a364>] (sys_sched_yield+0x0/0x90) from [<c03cbf90>] (yield+0x2c/0x30)
> > [12890.594779] r5:c18f4000 r4:00000000
> > [12890.598258] [<c03cbf64>] (yield+0x0/0x30) from [<c02eb650>] (netlink_broadcast_filtered+0x3ec/0x400)
> > [12890.607170] [<c02eb264>] (netlink_broadcast_filtered+0x0/0x400) from [<c02eb68c>] (netlink_broadcast+0x28/0x30)
> > [12890.616998] [<c02eb664>] (netlink_broadcast+0x0/0x30) from [<c02ed420>] (msg_netlink_broadcast+0xa8/0xb4)
> > [12890.626337] [<c02ed378>] (msg_netlink_broadcast+0x0/0xb4) from [<c039ad10>] (br_igmp_send_netlink_msg+0xb0/0xbc)
> > [12890.636256] [<c039ac60>] (br_igmp_send_netlink_msg+0x0/0xbc) from [<c039b4a0>] (br_igmp_mc_fdb_add+0x424/0x6c0)
> > [12890.646084] [<c039b07c>] (br_igmp_mc_fdb_add+0x0/0x6c0) from [<c039bd34>] (br_igmp_process_v3+0x4a8/0x518)
> > [12890.655515] [<c039b88c>] (br_igmp_process_v3+0x0/0x518) from [<c039c110>] (br_igmp_snooping+0x36c/0x3e4)
> > [12890.664762] [<c039bda4>] (br_igmp_snooping+0x0/0x3e4) from [<c039c204>] (br_igmp_mc_forward+0x7c/0x270)
> > [12890.673918] [<c039c188>] (br_igmp_mc_forward+0x0/0x270) from [<c0393120>] (br_handle_frame_finish+0x160/0x358)
> > [12890.683654] [<c0392fc0>] (br_handle_frame_finish+0x0/0x358) from [<c0398e7c>] (br_nf_pre_routing_finish+0x348/0x364)
> > [12890.693940] [<c0398b34>] (br_nf_pre_routing_finish+0x0/0x364) from [<c03994c4>] (br_nf_pre_routing+0x5e0/0x630)
> > [12890.703767] r7:c2e5c000 r6:00000000 r5:d71899c0 r4:da6ed0d0
> > [12890.709291] [<c0398ee4>] (br_nf_pre_routing+0x0/0x630) from [<c02eebf8>] (nf_iterate+0x68/0xa4)
> > [12890.717746] [<c02eeb90>] (nf_iterate+0x0/0xa4) from [<c02eec9c>] (nf_hook_slow+0x68/0x124)
> > [12890.725803] [<c02eec34>] (nf_hook_slow+0x0/0x124) from [<c03935ac>] (br_handle_frame+0x294/0x2e4)
> > [12890.734471] [<c0393318>] (br_handle_frame+0x0/0x2e4) from [<c02c9eb0>] (__netif_receive_skb+0x3b0/0x514)
> > [12890.743718] [<c02c9b00>] (__netif_receive_skb+0x0/0x514) from [<c02cabf0>] (netif_receive_skb+0xa8/0xbc)
> > [12890.752966] [<c02cab48>] (netif_receive_skb+0x0/0xbc) from [<c02cd730>] (napi_skb_finish+0x34/0x50)
> > [12890.761756] r5:d71899c0 r4:00000003
> > [12890.765235] [<c02cd6fc>] (napi_skb_finish+0x0/0x50) from [<c02cd848>] (napi_gro_receive+0xfc/0x100)
> > [12890.774056] r4:00000000 r3:00000000
> > [12890.777566] [<c02cd74c>] (napi_gro_receive+0x0/0x100) from [<bf1a1618>] (nss_gmac_receive+0x48/0x4c [qca_nss_gmac])
> > [12890.787759] [<bf1a15d0>] (nss_gmac_receive+0x0/0x4c [qca_nss_gmac]) from [<bf186e40>] (nss_core_handle_napi+0x440/0xa78 [qca_nss_drv])
> > [12890.799510] r5:d71899c0 r4:bf18e410
> > [12890.802989] [<bf186a00>] (nss_core_handle_napi+0x0/0xa78 [qca_nss_drv]) from [<c02cade4>] (net_rx_action+0x84/0x174)
> > [12890.813244] [<c02cad60>] (net_rx_action+0x0/0x174) from [<c005ad80>] (__do_softirq+0xbc/0x160)
> > [12890.821637] [<c005acc4>] (__do_softirq+0x0/0x160) from [<c005b250>] (irq_exit+0x58/0xa4)
> > [12890.829542] [<c005b1f8>] (irq_exit+0x0/0xa4) from [<c000ed60>] (handle_IRQ+0x8c/0xb8)
>
> Look at that, its calling yield() from a non-preemptible context as
> well.
>
> That code is full of fail.
*phew* none of that br_igmp_* muck lives in any kernel tree near me so I
can stop worrying :-)
In any case, it wrongly passes a GFP_WAIT along to netlink_broadcast.
On Wed, Apr 9, 2014 at 1:08 PM, Peter Zijlstra <[email protected]> wrote:
> On Wed, Apr 09, 2014 at 09:47:42PM +0200, Peter Zijlstra wrote:
>> On Wed, Apr 09, 2014 at 10:43:32AM -0700, Lin Ming wrote:
>> > [12890.586996] [<c007a364>] (sys_sched_yield+0x0/0x90) from [<c03cbf90>] (yield+0x2c/0x30)
>> > [12890.594779] r5:c18f4000 r4:00000000
>> > [12890.598258] [<c03cbf64>] (yield+0x0/0x30) from [<c02eb650>] (netlink_broadcast_filtered+0x3ec/0x400)
>> > [12890.607170] [<c02eb264>] (netlink_broadcast_filtered+0x0/0x400) from [<c02eb68c>] (netlink_broadcast+0x28/0x30)
>> > [12890.616998] [<c02eb664>] (netlink_broadcast+0x0/0x30) from [<c02ed420>] (msg_netlink_broadcast+0xa8/0xb4)
>> > [12890.626337] [<c02ed378>] (msg_netlink_broadcast+0x0/0xb4) from [<c039ad10>] (br_igmp_send_netlink_msg+0xb0/0xbc)
>> > [12890.636256] [<c039ac60>] (br_igmp_send_netlink_msg+0x0/0xbc) from [<c039b4a0>] (br_igmp_mc_fdb_add+0x424/0x6c0)
>> > [12890.646084] [<c039b07c>] (br_igmp_mc_fdb_add+0x0/0x6c0) from [<c039bd34>] (br_igmp_process_v3+0x4a8/0x518)
>> > [12890.655515] [<c039b88c>] (br_igmp_process_v3+0x0/0x518) from [<c039c110>] (br_igmp_snooping+0x36c/0x3e4)
>> > [12890.664762] [<c039bda4>] (br_igmp_snooping+0x0/0x3e4) from [<c039c204>] (br_igmp_mc_forward+0x7c/0x270)
>> > [12890.673918] [<c039c188>] (br_igmp_mc_forward+0x0/0x270) from [<c0393120>] (br_handle_frame_finish+0x160/0x358)
>> > [12890.683654] [<c0392fc0>] (br_handle_frame_finish+0x0/0x358) from [<c0398e7c>] (br_nf_pre_routing_finish+0x348/0x364)
>> > [12890.693940] [<c0398b34>] (br_nf_pre_routing_finish+0x0/0x364) from [<c03994c4>] (br_nf_pre_routing+0x5e0/0x630)
>> > [12890.703767] r7:c2e5c000 r6:00000000 r5:d71899c0 r4:da6ed0d0
>> > [12890.709291] [<c0398ee4>] (br_nf_pre_routing+0x0/0x630) from [<c02eebf8>] (nf_iterate+0x68/0xa4)
>> > [12890.717746] [<c02eeb90>] (nf_iterate+0x0/0xa4) from [<c02eec9c>] (nf_hook_slow+0x68/0x124)
>> > [12890.725803] [<c02eec34>] (nf_hook_slow+0x0/0x124) from [<c03935ac>] (br_handle_frame+0x294/0x2e4)
>> > [12890.734471] [<c0393318>] (br_handle_frame+0x0/0x2e4) from [<c02c9eb0>] (__netif_receive_skb+0x3b0/0x514)
>> > [12890.743718] [<c02c9b00>] (__netif_receive_skb+0x0/0x514) from [<c02cabf0>] (netif_receive_skb+0xa8/0xbc)
>> > [12890.752966] [<c02cab48>] (netif_receive_skb+0x0/0xbc) from [<c02cd730>] (napi_skb_finish+0x34/0x50)
>> > [12890.761756] r5:d71899c0 r4:00000003
>> > [12890.765235] [<c02cd6fc>] (napi_skb_finish+0x0/0x50) from [<c02cd848>] (napi_gro_receive+0xfc/0x100)
>> > [12890.774056] r4:00000000 r3:00000000
>> > [12890.777566] [<c02cd74c>] (napi_gro_receive+0x0/0x100) from [<bf1a1618>] (nss_gmac_receive+0x48/0x4c [qca_nss_gmac])
>> > [12890.787759] [<bf1a15d0>] (nss_gmac_receive+0x0/0x4c [qca_nss_gmac]) from [<bf186e40>] (nss_core_handle_napi+0x440/0xa78 [qca_nss_drv])
>> > [12890.799510] r5:d71899c0 r4:bf18e410
>> > [12890.802989] [<bf186a00>] (nss_core_handle_napi+0x0/0xa78 [qca_nss_drv]) from [<c02cade4>] (net_rx_action+0x84/0x174)
>> > [12890.813244] [<c02cad60>] (net_rx_action+0x0/0x174) from [<c005ad80>] (__do_softirq+0xbc/0x160)
>> > [12890.821637] [<c005acc4>] (__do_softirq+0x0/0x160) from [<c005b250>] (irq_exit+0x58/0xa4)
>> > [12890.829542] [<c005b1f8>] (irq_exit+0x0/0xa4) from [<c000ed60>] (handle_IRQ+0x8c/0xb8)
>>
>> Look at that, its calling yield() from a non-preemptible context as
>> well.
>>
>> That code is full of fail.
>
> *phew* none of that br_igmp_* muck lives in any kernel tree near me so I
> can stop worrying :-)
It's our internal code.
>
> In any case, it wrongly passes a GFP_WAIT along to netlink_broadcast.
I'll fix it.
Thanks very much.
On Wed, Apr 9, 2014 at 5:39 PM, Lin Ming <[email protected]> wrote:
> On Wed, Apr 9, 2014 at 1:08 PM, Peter Zijlstra <[email protected]> wrote:
[...]
>>>
>>> Look at that, its calling yield() from a non-preemptible context as
>>> well.
>>>
>>> That code is full of fail.
>>
>> *phew* none of that br_igmp_* muck lives in any kernel tree near me so I
>> can stop worrying :-)
>
> It's our internal code.
In the future, please don't simply call it 3.4-rt when there are a bunch of
vendor/project/SDK patches also applied, as that can be very misleading
to the people you are asking for help from. If it is a hybrid franken-kernel
then please at least indicate that right at the very beginning.
Paul.
--
>
>>
>> In any case, it wrongly passes a GFP_WAIT along to netlink_broadcast.
>
> I'll fix it.
> Thanks very much.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Sat, Apr 19, 2014 at 9:21 AM, Paul Gortmaker
<[email protected]> wrote:
> On Wed, Apr 9, 2014 at 5:39 PM, Lin Ming <[email protected]> wrote:
>> On Wed, Apr 9, 2014 at 1:08 PM, Peter Zijlstra <[email protected]> wrote:
>
> [...]
>
>>>>
>>>> Look at that, its calling yield() from a non-preemptible context as
>>>> well.
>>>>
>>>> That code is full of fail.
>>>
>>> *phew* none of that br_igmp_* muck lives in any kernel tree near me so I
>>> can stop worrying :-)
>>
>> It's our internal code.
>
> In the future, please don't simply call it 3.4-rt when there are a bunch of
> vendor/project/SDK patches also applied, as that can be very misleading
> to the people you are asking for help from. If it is a hybrid franken-kernel
> then please at least indicate that right at the very beginning.
Sorry for the misleading.
I'll make it clear next time.
Thanks.
>
> Paul.
> --
>
>>
>>>
>>> In any case, it wrongly passes a GFP_WAIT along to netlink_broadcast.
>>
>> I'll fix it.
>> Thanks very much.