Created attachment 149349 [details] Setup uart_intr() as both filter and hander Broken by: https://svnweb.freebsd.org/base?view=revision&revision=253161 With this, uart_intr() can return FILTER_SCHEDULE_THREAD, but we don't setup a threaded handler, which leads to the panic. Since the handling in uart_intr() looks MP-safe now, the attached patch should do the trick.
A commit references this bug: Author: marius Date: Fri Jul 24 17:01:18 UTC 2015 New revision: 285843 URL: https://svnweb.freebsd.org/changeset/base/285843 Log: - Since r253161, uart_intr() abuses FILTER_SCHEDULE_THREAD for signaling uart_bus_attach() during its test that 20 iterations weren't sufficient for clearing all pending interrupts, assuming this means that hardware is broken and doesn't deassert interrupts. However, under pressure, 20 iterations also can be insufficient for clearing all pending interrupts, leading to a panic as intr_event_handle() tries to schedule an interrupt handler not registered. Solve this by introducing a flag that is set in test mode and otherwise restores pre-r253161 behavior of uart_intr(). The approach of additionally registering uart_intr() as handler as suggested in PR 194979 is not taken as that in turn would abuse special pccard and pccbb handling code of intr_event_handle(). [1] - Const'ify uart_driver_name. - Fix some minor style bugs. PR: 194979 [1] Reviewed by: marcel (earlier version) MFC after: 3 days Changes: head/sys/dev/uart/uart_bus.h head/sys/dev/uart/uart_core.c
A commit references this bug: Author: marius Date: Thu Jul 30 02:23:11 UTC 2015 New revision: 286059 URL: https://svnweb.freebsd.org/changeset/base/286059 Log: MFC: r285843 - Since r253161, uart_intr() abuses FILTER_SCHEDULE_THREAD for signaling uart_bus_attach() during its test that 20 iterations weren't sufficient for clearing all pending interrupts, assuming this means that hardware is broken and doesn't deassert interrupts. However, under pressure, 20 iterations also can be insufficient for clearing all pending interrupts, leading to a panic as intr_event_handle() tries to schedule an interrupt handler not registered. Solve this by introducing a flag that is set in test mode and otherwise restores pre-r253161 behavior of uart_intr(). The approach of additionally registering uart_intr() as handler as suggested in PR 194979 is not taken as that in turn would abuse special pccard and pccbb handling code of intr_event_handle(). [1] - Const'ify uart_driver_name. - Fix some minor style bugs. PR: 194979 [1] Reviewed by: marcel (earlier version) Changes: _U stable/10/ stable/10/sys/dev/uart/uart_bus.h stable/10/sys/dev/uart/uart_core.c
A commit references this bug: Author: marius Date: Thu Jul 30 03:06:13 UTC 2015 New revision: 286061 URL: https://svnweb.freebsd.org/changeset/base/286061 Log: MFC: r285843 (r286059 in stable/10) - Since r253161, uart_intr() abuses FILTER_SCHEDULE_THREAD for signaling uart_bus_attach() during its test that 20 iterations weren't sufficient for clearing all pending interrupts, assuming this means that hardware is broken and doesn't deassert interrupts. However, under pressure, 20 iterations also can be insufficient for clearing all pending interrupts, leading to a panic as intr_event_handle() tries to schedule an interrupt handler not registered. Solve this by introducing a flag that is set in test mode and otherwise restores pre-r253161 behavior of uart_intr(). The approach of additionally registering uart_intr() as handler as suggested in PR 194979 is not taken as that in turn would abuse special pccard and pccbb handling code of intr_event_handle(). [1] - Const'ify uart_driver_name. - Fix some minor style bugs. PR: 194979 [1] Reviewed by: marcel (earlier version) Approved by: re (gjb) Changes: _U releng/10.2/ releng/10.2/sys/dev/uart/uart_bus.h releng/10.2/sys/dev/uart/uart_core.c