Re: ucom console again [PATCH]

[Nick Hudson <nick.hudson%gmx.co.uk@localhost>]

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.