Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 25 Feb 2022 08:17:19 -0500
From:   Steven Rostedt <rostedt@goodmis.org>
To:     Willy Tarreau <w@1wt.eu>
Cc:     David Laight <David.Laight@aculab.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Petr Mladek <pmladek@suse.com>,
        Sergey Senozhatsky <senozhatsky@chromium.org>,
        John Ogness <john.ogness@linutronix.de>
Subject: Re: Strange output on the console
Message-ID: <20220225081719.7710f62e@gandalf.local.home>
In-Reply-To: <20220225122546.GB18720@1wt.eu>
References: <20220224230035.36547137@gandalf.local.home>
        <61226fc12ff9459d8daed8e346d6ab94@AcuMS.aculab.com>
        <20220225063637.GA18039@1wt.eu>
        <1dcb185901f04a5ea2476a449e371167@AcuMS.aculab.com>
        <20220225103239.GA18720@1wt.eu>
        <32a7af26f4494f47a03a6d965ac7c99a@AcuMS.aculab.com>
        <20220225122546.GB18720@1wt.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Fri, 25 Feb 2022 13:25:46 +0100
Willy Tarreau <w@1wt.eu> wrote:

> > TnsTesOT s T sKTesOT sKTvsOTtsTtsKTtsT sKTesTesKT sKTesOT siT stTnsaTvsaTesKTnsOT s
> > TesKTnsT s TvsKTeslT sOTesT sKTtseTnseTvs_Tts_T sOTes TnsOT s T spTespTesdTesdTeseTtseTeseTt_rTe_rTv_oTes:T s:Tes:TnfwOTvfrKT fwT frTefpuTefpKTefpTvf:TnsOTvsOTnsoTvs Tvs TvsTtssTnsT sKTesTnsTvsTtsoTesmTnsgTesiTeslTtsTvsKTnsTvsOTtsT s_Tnsu
> > 
> > which really doesn't have enough different characters in it to be a fifo problem.
> > That looks like a UART struggling to find valid start and stop bits
> > on a continuous data stream that doesn't match the baud rate.
> > 
> > It may also be that whatever 'terminal' is being used is masking off the 0x80 bit.  
> 
> That could be one option I thought about but still, that sounds quite
> suspicious. You don't even get any #!:$/ etc. Or maybe the UART is
> configured in 6-bit mode (most 16550 support 5-8 bits), and maybe even
> the stop bit and/or parity participates.

One thing that's not easy to demonstrate here (I could try to video it), is
that this output is the final result. It shows a bunch of other characters
as it is displayed but then the cursor goes backwards and writes over it.

But the characters that are deleted still do not make sense. When watching
it, it reminds me of the Matrix characters, but running horizontal and not
vertical.

> 
> > Another possibility is that the count of characters is about right.
> > But the receiver is misaligned on the 10 bit async characters.
> > Because these is no line idle, it never synchronises properly.
> > ISTR a real async terminal behaving that way.
> > But I think that gives a much wider range of characters - just the wrong ones.
> >
> > There is also a third error pattern:
> > ^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[
> > which might be an 'even more wrong' baud rate.  
> 
> This one just looks like the Up arrow, that Steven might have pressed at
> some point during the capture.

Yeah, sorry about that. That was the mouse wheel over my console window and
I didn't quite hit "shift" in time. "shift-mouse-up" scrolls up the
terminal window, but just "mouse-up" is the same as "up arrow", and caused
that huge string of ^[[A to appear.

> 
> > So maybe we are both right - for different bits of the error.  
> 
> :-)
> ... and Steven having fun reading our proposals after having made this
> up entirely in preparation of the next April's fool :-)


I was thinking the same thing, but this output being the joke. Someone
planning on slipping in Matrix characters for printk?

-- Steve