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

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Nov 09, 2023 at 08:55:49PM +0200, ariel marcovitch wrote:
> Hello and sorry for the delay
> 
> On Mon, 30 Oct 2023 at 10:30, Greg KH <gregkh@linuxfoundation.org> 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?

Yes, it looks like a serial console you just write the characters to and
they come out the other end.  No messing around with USB stuff.

> What code is responsible for this feature?

drivers/usb/host/xhci-dbgtty.c

> > > 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)

The type of device and the speed it is sending out the characters makes
all the difference here.  A pl2303 device is a very tiny and dumb uart
with almost no buffer in it at all.  Overruns will happen if you try to
use a console to get boot messages.

> > > > 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?

Try changing it and see!  :)

It's complex stuff, there is buffering already, but for slow devices
with no additional buffers in them, you will have overruns.

But hey, I could be totally wrong here, patches are always gladly
reviewed for this stuff if you find some places that could be improved.

thanks,

greg k-h