Re: ucom console again [PATCH]
Nick Hudson <[email protected]>
| Newsgroups | gmane.os.netbsd.devel.kernel |
|---|---|
| Message-ID | <[email protected]> |
On 20/12/2025 16:37, Emmanuel Dreyfus wrote: > On Wed, Nov 19, 2025 at 02:54:30AM +0000, Emmanuel Dreyfus wrote: >> On Qemu: >> - boot -a sometime hang on a prompt. There is a race somewhere, >> I suspect it does not happen on real hardware because Qemu >> serial emulation is much faster than a real serial port. > I finally got a console hang on real hardware. Not surprised. > Only the output > was concerned, I have been able to crash the machine by blindly > typing the cnmagic sequence. I don't understand what you're trying to say here. > So there is a real race, something rare enough to be tough > to debug. The only hope is that it is the same bug as I observed > with boot -a in Qemu, where it can be easily reproduced. I've already told you where the problem is "cn_sending is racey and it's my fault." Something like making ucom_cnput_bytes loop and right after it does atomic_store_relaxed(&cn->cn_sending, 0); it should re-check the ring for entries and try to set it again, etc... > Nick, you never explained me what was wrong with my initial > version with an lwp in charge of deferred console output. It did > not hang on boot -a, that seems to be an attractive feature. It's unnecessary. You thought it was necessary as you thought you needed synchronous transfers which you don't.