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
