Summary: | arm64: serial console unresponsive after debug.kdb.enter=1 then ddb 'c'ontinue | ||
---|---|---|---|
Product: | Base System | Reporter: | Ed Maste <emaste> |
Component: | arm | Assignee: | Mitchell Horne <mhorne> |
Status: | Closed FIXED | ||
Severity: | Affects Only Me | CC: | manu, markj, mhorne |
Priority: | --- | ||
Version: | CURRENT | ||
Hardware: | Any | ||
OS: | Any | ||
URL: | https://reviews.freebsd.org/D29130 | ||
See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240122 | ||
Bug Depends on: | |||
Bug Blocks: | 231027, 203349, 228911 |
Description
Ed Maste
2017-11-27 18:32:42 UTC
A commit references this bug: Author: andrew Date: Tue Nov 28 11:04:47 UTC 2017 New revision: 326312 URL: https://svnweb.freebsd.org/changeset/base/326312 Log: When we exit the kernel debugger having entered because of a breakpoint instruction we need to jump over the instruction. Without this we will execute the same instruction again and enter into the debugger again. PR: 223917 Reported by: emaste MFC after: 1 week Sponsored by: DARPA, AFRL Changes: head/sys/arm64/arm64/trap.c The original problem seems to be solved, but at r331355 with probably-unrelated WIP on a Pine64 the console is unresponsive after 'c': root@:~ # sysctl debug.kdb.enter=1 debug.kdb.enter:KDB: enter: sysctl debug.kdb.enter [ thread pid 561 tid 100111 ] Stopped at 0x402319b4: undefined 54000042 db> c [ nothing ] Running GENERIC + BREAK_TO_DEBUGGER on pine64 here Sending break and hitting c in kdb does works. Using sysctl debug.kdb.enter=1 is when I have problems : # sysctl debug.kdb.enter=1 debug.kdb.enter:KDB: enter: sysctl debug.kdb.enter [ thread pid 30 tid 100098 ] Stopped at 0x40232974: undefined 54000042 db> show thread 100098 Thread 100098 at 0xfffffd000788ea80: proc (pid 31): 0xfffffd0007880a50 name: sysctl stack: 0xffff0000402da000-0xffff0000402ddfff flags: 0x4 pflags: 0 state: RUNNING (CPU 1) priority: 120 container lock: sched lock 1 (0xffff000000af1100) last voluntary switch: 11 ms ago db> show thread 0xfffffd000788ea80 Thread 100098 at 0xfffffd000788ea80: proc (pid 31): 0xfffffd0007880a50 name: sysctl stack: 0xffff0000402da000-0xffff0000402ddfff flags: 0x4 pflags: 0 state: RUNNING (CPU 1) priority: 120 container lock: sched lock 1 (0xffff000000af1100) last voluntary switch: 11 ms ago db> c (HANG but not really) Sending BREAK : ~KDB: enter: Break to debugger [ thread pid 11 tid 100004 ] Stopped at 0x4 db> show thread 0xfffffd000788ea80 Thread 100098 at 0xfffffd000788ea80: proc (pid 31): 0xfffffd0007880a50 name: sysctl stack: 0xffff0000402da000-0xffff0000402ddfff flags: 0x4 pflags: 0 state: INACTIVE priority: 203 container lock: sched lock 0 (0xffff000000af0400) last voluntary switch: 1005 ms ago last involuntary switch: 1003 ms ago db> kill 2 31 Can't find process with pid 31 Adding some printfs almost everywhere along the path I've found that we do go back to userland but it seems that sysctl is block in sys_ioctl Side note: I have no problem on my overdrive 1000 It seems only related to the uart console as ssh session are still up after 'c' (In reply to Emmanuel Vadot from comment #3) Behaviour confirmed on my pine64: I can 'c'ontinue after breaking via CR ~ ^B, not after sysctl debug.kdb.enter=1. Also another CR ~ ^B will re-enter ddb while the console appears hung. Seems to work for me on a packet.net ThunderX: login: KDB: enter: sysctl debug.kdb.enter [ thread pid 1123 tid 100976 ] Stopped at 0x40427bf4: undefined 54000042 db> c login: KDB: enter: sysctl debug.kdb.enter [ thread pid 1125 tid 100976 ] Stopped at 0x40427bf4: undefined 54000042 db> c vnic1: Interface stopped DISTRIBUTING, possible flapping login: (In reply to Mark Johnston from comment #7) Interesting - I just tried the same thing on my pine64, and sysctl debug.kdb.enter=1 from the ssh session works fine (i.e., breaks to the debugger and 'c' works as expected). (In reply to Ed Maste from comment #8) I don't see any problems with sysctl debug.kdb.enter=1 from the serial console either. Looks like a race; this works on the serial console: # (sleep 0.1; sysctl debug.kdb.enter=1 >/dev/null) & A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=7e7f7beee732810d3afcc83828341ac3e139b5bd commit 7e7f7beee732810d3afcc83828341ac3e139b5bd Author: Mitchell Horne <mhorne@FreeBSD.org> AuthorDate: 2021-03-10 14:57:12 +0000 Commit: Mitchell Horne <mhorne@FreeBSD.org> CommitDate: 2021-03-10 15:04:42 +0000 ns8250: don't drop IER_TXRDY on bus_grab/ungrab It has been observed that some systems are often unable to resume from ddb after entering with debug.kdb.enter=1. Checking the status further shows the terminal is blocked waiting in tty_drain(), but it never makes progress in clearing the output queue, because sc->sc_txbusy is high. I noticed that when entering polling mode for the debugger, IER_TXRDY is set in the failure case. Since this bit is never tracked by the softc, it will not be restored by ns8250_bus_ungrab(). This creates a race in which a TX interrupt can be lost, creating the hang described above. Ensuring that this bit is restored is enough to prevent this, and resume from ddb as expected. The solution is to track this bit in the sc->ier field, for the same lifetime that TX interrupts are enabled. PR: 223917, 240122 Reviewed by: imp, manu Tested by: bz MFC after: 5 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D29130 sys/dev/uart/uart_dev_ns8250.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=17d301f7b59f49c52983fe0957208dddf40b1232 commit 17d301f7b59f49c52983fe0957208dddf40b1232 Author: Mitchell Horne <mhorne@FreeBSD.org> AuthorDate: 2021-03-10 14:57:12 +0000 Commit: Mitchell Horne <mhorne@FreeBSD.org> CommitDate: 2021-03-15 14:22:17 +0000 ns8250: don't drop IER_TXRDY on bus_grab/ungrab It has been observed that some systems are often unable to resume from ddb after entering with debug.kdb.enter=1. Checking the status further shows the terminal is blocked waiting in tty_drain(), but it never makes progress in clearing the output queue, because sc->sc_txbusy is high. I noticed that when entering polling mode for the debugger, IER_TXRDY is set in the failure case. Since this bit is never tracked by the softc, it will not be restored by ns8250_bus_ungrab(). This creates a race in which a TX interrupt can be lost, creating the hang described above. Ensuring that this bit is restored is enough to prevent this, and resume from ddb as expected. The solution is to track this bit in the sc->ier field, for the same lifetime that TX interrupts are enabled. PR: 223917, 240122 Sponsored by: The FreeBSD Foundation (cherry picked from commit 7e7f7beee732810d3afcc83828341ac3e139b5bd) sys/dev/uart/uart_dev_ns8250.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=a54c346ff3e80ff8f2f3d0ec56b5374a7dc34429 commit a54c346ff3e80ff8f2f3d0ec56b5374a7dc34429 Author: Mitchell Horne <mhorne@FreeBSD.org> AuthorDate: 2021-03-10 14:57:12 +0000 Commit: Mitchell Horne <mhorne@FreeBSD.org> CommitDate: 2021-03-16 17:56:03 +0000 ns8250: don't drop IER_TXRDY on bus_grab/ungrab It has been observed that some systems are often unable to resume from ddb after entering with debug.kdb.enter=1. Checking the status further shows the terminal is blocked waiting in tty_drain(), but it never makes progress in clearing the output queue, because sc->sc_txbusy is high. I noticed that when entering polling mode for the debugger, IER_TXRDY is set in the failure case. Since this bit is never tracked by the softc, it will not be restored by ns8250_bus_ungrab(). This creates a race in which a TX interrupt can be lost, creating the hang described above. Ensuring that this bit is restored is enough to prevent this, and resume from ddb as expected. The solution is to track this bit in the sc->ier field, for the same lifetime that TX interrupts are enabled. PR: 223917, 240122 Sponsored by: The FreeBSD Foundation (cherry picked from commit 7e7f7beee732810d3afcc83828341ac3e139b5bd) sys/dev/uart/uart_dev_ns8250.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) |