Just to sumarize the bug after poking before the patch: systemd calls open/close on /dev/ttyS0 per line atmel_shutdown executes on close uart_timer_callback may fire during shutdown before timer is killed tasklet gets scheduled after tasklet_kill atmel_shutdown returns back to uart_close dice roll: if the tasklet executes before uart_close kills the tty references, the kernel is fine <--- I saw this happening more often than panics, around once every 3 resets if the tasklet executes after uart_close kills the tty references, it panics I tested the patch by old fashion way of manual board resets with a total of 70 resets each on two individual SAMA5D34-EK boards I have in my possession programmed with the same patched kernel image and rootfs. They did not panic once with the patch applied. Typically before the patch the panic would occur around once every 10 resets if not more often to the point it occured for 4 resets straight. I have been trying to automate the testing, even If I make sure nothing is using ttyS0 and then run a program that spams open() writev() and close() (systemd uses the syscalls) to print messages, it will never panic so I'm possibly misunderstanding how the driver startup/shutdown ops get triggered(which should just be open/close respectively) or variable length of messages from systemd and timing between messages contributes to being unlucky and having the timer fire at the wrong time. But from manual testing I'm pretty confident the bug is fixed. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html