Date: Wed, 07 Oct 2020 13:59:32 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 240122] ddb: cont doesn't give a working terminal back Message-ID: <bug-240122-227-2nPTnt8V5a@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-240122-227@https.bugs.freebsd.org/bugzilla/> References: <bug-240122-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240122 Mark Johnston <markj@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |markj@FreeBSD.org Status|New |Open --- Comment #4 from Mark Johnston <markj@FreeBSD.org> --- I see it on an amd64 system. With debug.kdb.alt_break_to_debugger=1, I can enter ddb using the alt break sequence and resuming works fine. When I enter with sysctl debug.kdb.enter=1, I get the same hang. Happily, I can re-enter ddb in this state using the alt break sequence, so it's possible to debug a bit. In this state, the shell is stuck: db> bt Tracing pid 1447 tid 100097 td 0xfffffe000b532c00 sched_switch() at sched_switch+0x5b2/frame 0xfffffe003bac74c0 mi_switch() at mi_switch+0x155/frame 0xfffffe003bac74e0 sleepq_switch() at sleepq_switch+0x11a/frame 0xfffffe003bac7520 sleepq_catch_signals() at sleepq_catch_signals+0x262/frame 0xfffffe003bac7570 sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12/frame 0xfffffe003bac75b0 _cv_timedwait_sig_sbt() at _cv_timedwait_sig_sbt+0x184/frame 0xfffffe003bac7620 tty_drain() at tty_drain+0x1cc/frame 0xfffffe003bac7680 tty_ioctl() at tty_ioctl+0x26d/frame 0xfffffe003bac76d0 ttydev_ioctl() at ttydev_ioctl+0x247/frame 0xfffffe003bac7720 devfs_ioctl() at devfs_ioctl+0xcc/frame 0xfffffe003bac7770 vn_ioctl() at vn_ioctl+0x132/frame 0xfffffe003bac7880 devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfffffe003bac78a0 kern_ioctl() at kern_ioctl+0x276/frame 0xfffffe003bac7900 sys_ioctl() at sys_ioctl+0x127/frame 0xfffffe003bac79d0 amd64_syscall() at amd64_syscall+0x135/frame 0xfffffe003bac7af0 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe003bac7af0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8005e016a, rsp = 0x7fffffffd8e8, rbp = 0x7fffffffd930 --- Indeed, there are some bytes "stuck" in the tty queues: db> show tty 0xfffff80004075000 0xfffff80004075000: ttyu0 mtx: 0xfffff80004075008 flags: 0xe<INITLOCK,CALLOUT,OPENED_IN> revokecnt: 2 inq: 0xfffff80004075048 begin 0 linestart 2 reprint 2 end 2 nblocks 180 quota 180 outq: 0xfffff80004075088 begin 16 end 29 nblocks 93 quota 93 inlow: 20736 outlow: 20757 termios: iflag 0x2b02 oflag 0x7 cflag 0xcb00 lflag 0x5cb ispeed 115200 ospeed 115200 winsize: row 87 col 319 xpixel 0 ypixel 0 column: 0 writepos: 0 compatflags: 0x0 termios_init_in: iflag 0x2b02 oflag 0x3 cflag 0xcb00 lflag 0x5cb ispeed 115200 ospeed 115200 termios_init_out: iflag 0x2b02 oflag 0x3 cflag 0xcb00 lflag 0x5cb ispeed 115200 ospeed 115200 termios_lock_in: iflag 0x0 oflag 0x0 cflag 0x0 lflag 0x0 ispeed 0 ospeed 0 termios_lock_out: iflag 0x0 oflag 0x0 cflag 0x0 lflag 0x0 ispeed 0 ospeed 0 devsw: uart_tty_class (0xffffffff818d0a08) open: uart_tty_open close: uart_tty_close outwakeup: uart_tty_outwakeup inwakeup: uart_tty_inwakeup ioctl: uart_tty_ioctl param: uart_tty_param modem: uart_tty_modem mmap: ttydevsw_defmmap pktnotify: ttydevsw_defpktnotify free: uart_tty_free hook: 0 (0) pgrp: 0xfffff800036f6080 gid 1447 jobc 1 session: 0xfffff80004587b80 count 2 leader 0xfffff80006b43000 tty 0xfffff80004075000 sid 1443 login root sessioncnt: 1 devswsoftc: 0xfffff80004075800 hooksoftc: 0 dev: 0xfffff8000407a000 So I guess there is some race that results in uart(4) not handling an interrupt, so ttydisc_getc() isn't getting called to drain the outq. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-240122-227-2nPTnt8V5a>