From: Greg KH <gregkh@linuxfoundation.org>
To: ariel marcovitch <arielmarcovitch@gmail.com>
Cc: johan@kernel.org, linux-usb@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Gaps in logs while using usb-serial as a console
Date: Mon, 30 Oct 2023 09:30:15 +0100 [thread overview]
Message-ID: <2023103003-defection-recess-cf49@gregkh> (raw)
In-Reply-To: <CAFGKuwp7JH8H9vjz8iJ24R9TRW0GDE-O96VBAG4L8X4DhTabXg@mail.gmail.com>
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).
> 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.
> > 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?
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
next prev parent reply other threads:[~2023-10-30 8:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-29 18:21 Gaps in logs while using usb-serial as a console ariel marcovitch
2023-10-30 6:22 ` Greg KH
2023-10-30 8:15 ` ariel marcovitch
2023-10-30 8:30 ` Greg KH [this message]
2023-10-30 14:19 ` Alan Stern
2023-10-31 3:51 ` Randy Dunlap
2023-11-09 18:55 ` ariel marcovitch
2023-11-10 8:38 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2023103003-defection-recess-cf49@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=arielmarcovitch@gmail.com \
--cc=johan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox