Date: Mon, 19 May 2025 04:46:33 +0000 From: bugzilla-noreply@freebsd.org To: sysinstall@FreeBSD.org Subject: [Bug 286703] During bsdinstall, pkg hangs outputting to serial console Message-ID: <bug-286703-8135-EqwUDxw1ME@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-286703-8135@https.bugs.freebsd.org/bugzilla/> References: <bug-286703-8135@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286703 --- Comment #4 from Ravi Pokala <rpokala@panasas.com> --- Some additional observations: 1. Apart from `bsdinstall', I found that one of our internal utilities would consistently cause the serial console to go non-responsive. The same utility run via the KVM works without issue. Interestingly, redirecting the output of the utility to a file and then `cat'ing it on the serial console, does *not* cause the console to go non-responsive. 2. If running that utility on the serial console causes it to go non-responsive, breaking into the debugger (NMI or video console) causes it to emit the output from the utility to the console, before it brings up the debugger. This means that characters directed to the serial console were continuing to be buffered, but the buffer was not actually being flushed to the console. My colleagues and I agree that (2) in particular has the feel of a missed interrupt. And then, serendipity! While we were debugging this problem, @cpercival committed: https://cgit.freebsd.org/src/commit/?id=9a685c09f06a which disabled a workaround from a dozen years ago: https://cgit.freebsd.org/src/commit/?id=1c60b24baa50 and a more recent related change https://cgit.freebsd.org/src/commit/?id=7e7f7beee732 That is talking about an emulated UART from QEMU and Xen and EC2, but it seems to describe our issue with the physical hardware: TX FIFO didn't interrupt while emptying, stopping further flushing. And when something force the flush to happen -- NMI via BMC, or video console debugger sequence -- the buffer finishes flushing. We added 'hw.broken_txfifo="1"' to /boot/loader.conf to enable the workaround, and that solved the problem. We completed several dozen successful installations with `bsdinstall', and as many runs of the utility which previously triggered the hang. We need to do some testing to see if the fix causes latency spikes on real hardware the way it did on EC2, which is why @cpercival disabled it there. -- 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-286703-8135-EqwUDxw1ME>