FreeBSD amd64, recent stable/10: When running some task on a graphical console window and that task writes lots of output to a console, the console gets stuck after some time (like 20 minutes), output stops, keyboard appears unresponsive, alt-ctrl-Fn is unable to switch consoles - but the machine seems otherwise sane: I can log in over ssh, file system and processes are healthy, CPU not busy. This was first noticed trying to rebuild kde from ports in a console window. Same happened when bulk updating packages from a remote site and the pkg update was busily writing its output to a console. The same heavy tasks (e.g. ports rebuild) can run just fine in an ssh session, or in a konsole / xterm. As a final proof, I tried a perl one-liner which writes a line (a count and some text) ten times per second: it manages to screw up the console window in about 6 minutes. Interestingly, while the console output is stuck and I blindly type a command on a keyboard (no echo), then run a shutdown from another (ssh) session, the console output gets unstuck during shutdown, rapidly displays the missing lines, including the echo of a command typed blindly previously, along with its output. Btw, this never happened on this machine while it was running 9.2 or older versions. Anybody seen this or can reproduce it? Mark
I see this when the kernel is outputting debugging .. the console can quickly lock up exactly how you describe. I've never figured out why though. :( -a On 22 December 2013 16:47, Mark Martinec <Mark.Martinec+freebsd at ijs.si> wrote:> FreeBSD amd64, recent stable/10: > > When running some task on a graphical console window > and that task writes lots of output to a console, the > console gets stuck after some time (like 20 minutes), > output stops, keyboard appears unresponsive, alt-ctrl-Fn > is unable to switch consoles - but the machine seems > otherwise sane: I can log in over ssh, file system and > processes are healthy, CPU not busy. > > This was first noticed trying to rebuild kde from > ports in a console window. Same happened when bulk > updating packages from a remote site and the pkg update > was busily writing its output to a console. > > The same heavy tasks (e.g. ports rebuild) can run > just fine in an ssh session, or in a konsole / xterm. > > As a final proof, I tried a perl one-liner which > writes a line (a count and some text) ten times per > second: it manages to screw up the console window > in about 6 minutes. > > Interestingly, while the console output is stuck > and I blindly type a command on a keyboard (no echo), > then run a shutdown from another (ssh) session, > the console output gets unstuck during shutdown, > rapidly displays the missing lines, including the > echo of a command typed blindly previously, along > with its output. > > Btw, this never happened on this machine while it was > running 9.2 or older versions. > > Anybody seen this or can reproduce it? > > Mark > _______________________________________________ > freebsd-stable at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
On 2013/12/23 08:47, Mark Martinec wrote:> FreeBSD amd64, recent stable/10: > > When running some task on a graphical console window > and that task writes lots of output to a console, the > console gets stuck after some time (like 20 minutes), > output stops, keyboard appears unresponsive, alt-ctrl-Fn > is unable to switch consoles - but the machine seems > otherwise sane: I can log in over ssh, file system and > processes are healthy, CPU not busy. > > This was first noticed trying to rebuild kde from > ports in a console window. Same happened when bulk > updating packages from a remote site and the pkg update > was busily writing its output to a console. > > The same heavy tasks (e.g. ports rebuild) can run > just fine in an ssh session, or in a konsole / xterm. > > As a final proof, I tried a perl one-liner which > writes a line (a count and some text) ten times per > second: it manages to screw up the console window > in about 6 minutes. > > Interestingly, while the console output is stuck > and I blindly type a command on a keyboard (no echo), > then run a shutdown from another (ssh) session, > the console output gets unstuck during shutdown, > rapidly displays the missing lines, including the > echo of a command typed blindly previously, along > with its output. > > Btw, this never happened on this machine while it was > running 9.2 or older versions. > > Anybody seen this or can reproduce it? > > MarkThis is a longstanding bug. Years ago I found this, it seems there is a race between kernel tty code and select syscall, although I had read some code and do not know where it is. I can reproduce it by running command "find /" in gnome terminal, and switch between some windows and when I come back to the terminal window, the find process gets stuck at "ttyout" state. davidxu at demo:~%ps xaHl | grep find 1001 1247 1195 0 -8 0 10276 1952 piperd S+ 0 0:00.00 grep find 1001 1239 1225 0 21 0 14100 6740 ttyout S+ 1 0:02.05 find / davidxu at demo:~%procstat -h -k 1239 1239 100187 find - mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _cv_wait_sig tty_wait ttydisc_write ttydev_write devfs_write_f dofilewrite kern_writev sys_write syscall Xint0x80_syscall davidxu at demo:~%ps xaHl | grep gnome-terminal 1001 1193 1 0 21 0 99852 23232 select S v0 0:15.97 gnome-terminal 1001 1193 1 0 21 0 99852 23232 select S v0 0:01.79 gnome-terminal 1001 1193 1 0 21 0 99852 23232 select I v0 0:00.00 gnome-terminal 1001 1256 1195 0 21 0 344 236 - R+ 0 0:00.00 grep gnome-terminal davidxu at demo:~%ps xaHl | davidxu at demo:~%procstat -k 1193 PID TID COMM TDNAME KSTACK 1193 100202 gnome-terminal - mi_switch sleepq_switch sleepq_catch_signals sleepq_timedwait_sig _cv_timedwait_sig_sbt seltdwait sys_poll syscall Xint0x80_syscall 1193 100206 gnome-terminal - mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait sys_poll syscall Xint0x80_syscall 1193 100209 gnome-terminal - mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait sys_poll syscall Xint0x80_syscall