Re: Gaps in logs while using usb-serial as a console

[ariel marcovitch]

Hello and sorry for the delay

On Mon, 30 Oct 2023 at 10:30, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Oct 30, 2023 at 10:15:30AM +0200, ariel marcovitch wrote:
> > > Please realize that usb-serial console was the result of me loosing a
> > > drunken bet.  It's amazing it works at all.  For "fake" devices like
> > LOL your drunken bet was quite helpful to some people
> > Because modern PCs come without a serial port, I wanted to use it to
> > see early logs on my crashing kernel without having to use printk
> > delay and things like that.
> > I'm curious as to how kernel people debug PCs in general...
>
> We use a usb debug port connection (it's a special cable).
Interesting
What makes it work well as opposed to usb-serial? Is it a less
complicated format?
What code is responsible for this feature?
>
> > In any case, the usb-serial setup was quite weird as it required two
> > usb-serial and a gender changer
>
> Yes, that's normal.
>
> > > this, that use the generic usb-serial code, yes, you will have overruns
> > > and other problems, that's just part of how it works (i.e. not well.)
> > >
> > > For something like qemu, please use a real console, like the serial port
> > > (i.e. a fake serial port), not the fake usb-serial port.
> > Yeah I was just using it to demonstrate the problem (I agree it is
> > quite weird to use usb-serial as a console for qemu)
> > I experienced the same problem with a real usb-serial device, then I
> > tried to use emulation so I can debug it more easily
>
> Which real usb-serial device?  That matters as it's up to the individual
> driver to handle the flow control properly.
Oh sorry I really thought I mentioned but it seems I missed it: pl2302
Isn't the problem generic, though? (The speed of the device may make some
difference probably)
>
> > > So this is "working as designed" in that it wasn't designed at all and
> > > again, it is a miracle any data is flowing there at all :)
> > I see...
> > However it may be possible to fix it without much effort, so why not?
> > Something like checking the return value for the console's write
> > function seems reasonable to me anyway...
>
> But overflows for buffers can not be handled by consoles like this
>
> > Besides, don't other types of consoles have the same problem (being
> > initialized late, getting a lot of data, losing some of it)?
>
> Yes, they do have that problem, this is not unique.  You can just see it
> very easily when using the generic usb-serial driver as there is almost
> no buffering at all in it other than what the tty layer provides.
>
> Adding larger buffers can help with this, but where do you stop?  What
> is the proper buffer size to always use?
Specifically, since we are talking about data coming from the console,
and it saves the full log anyway (or at least buffers a lot of it, in
a configurable manner),
why can't it make the per-console seq track the actual data that was
able to be sent?
It sound reasonable for me, is it really that bad?
>
> Overall, if you are going to be doing lots of debugging of early-boot
> and console logs, I recommend getting a usb debug cable instead, sorry.
> usb-serial console is just "best effort" and we're happy that any data
> flows out of the thing at all :)
>
> thanks,
>
> greg k-h
Thanks,
Ariel Marcovitch