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