I already had occasional random failures rebooting my bbb, but it happened rarely and I hadn't investigated yet. While debugging another issue I turned off the "quiet" option and as a side-effect I discovered the cause of the failures: random: nonblocking pool is initialized irq 187: nobody cared (try booting with the "irqpoll" option) CPU: 0 PID: $varies Comm: $varies Not tainted 4.6.0-bone3-dd1 #2 Hardware name: Generic AM33XX (Flattened Device Tree) [<c010b059>] (unwind_backtrace) from [<c0109945>] (show_stack+0x11/0x14) [<c0109945>] (show_stack) from [<c014802f>] (__report_bad_irq+0x23/0x84) [<c014802f>] (__report_bad_irq) from [<c01482a1>] (note_interrupt+0x1c5/0x200) [<c01482a1>] (note_interrupt) from [<c0146a13>] (handle_irq_event_percpu+0xfb/0x154) [<c0146a13>] (handle_irq_event_percpu) from [<c0146a8d>] (handle_irq_event+0x21/0x2c) [<c0146a8d>] (handle_irq_event) from [<c01486d1>] (handle_level_irq+0x61/0xac) [<c01486d1>] (handle_level_irq) from [<c014633d>] (generic_handle_irq+0x1d/0x28) [<c014633d>] (generic_handle_irq) from [<c01464ff>] (__handle_domain_irq+0x3b/0x80) [<c01464ff>] (__handle_domain_irq) from [<c044284d>] (__irq_svc+0x4d/0x74) [<c044284d>] (__irq_svc) from [<c0121d52>] (__do_softirq+0x66/0x1c8) [<c0121d52>] (__do_softirq) from [<c0122229>] (irq_exit+0x95/0xbc) [<c0122229>] (irq_exit) from [<c0146503>] (__handle_domain_irq+0x3f/0x80) [<c0146503>] (__handle_domain_irq) from [<c044284d>] (__irq_svc+0x4d/0x74) [<c044284d>] (__irq_svc) from [<c0145656>] (console_unlock+0x26e/0x410) [<c0145656>] (console_unlock) from [<c01459b5>] (vprintk_emit+0x1bd/0x310) (rest of traceback varies) handlers: [<c02c5e6d>] dma_ccerr_handler Disabling IRQ #187 To be honest, I can't even begin to speculate what's going on here. I checked dma_ccerr_handler but I don't see how it could fail to clear the error irq. And I didn't include the "random: nonblocking pool is initialized" message right before the traceback by accident. So far it's been there every single time. The exact moment this happens varies, I just made it easier to trigger by increasing the volume of console output. Probably. Repeatedly dumping a large pile of output to /dev/console failed to trigger it though. It does however on rare occasion also happen on shutdown. Whenever it occurs during boot, often things eventually get stuck resulting in hung task tracebacks in out_of_line_wait_on_bit() in ext4 code. But not always. I haven't seen it block shutdown. I've confirmed I can also reproduce it using mainline v4.6. My config file can be found here: https://github.com/dutchanddutch/bb-kernel/blob/am33x-v4.6/patches/defconfig The only change needed to build with mainline is clearing EXTRA_FIRMWARE Matthijs van Duin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
