On 4/29/22 16:43, Fabiano Rosas wrote: > Rob Landley <r...@landley.net> writes: >> Then paste something longer than 16 characters at the eventual command prompt >> once the kernel finishes booting. > > I suspect this is due to how the tty driver (n_tty.c) interacts with > the console (hvc_console.c) driver's buffer size. > > This is the stack: > > #0 hvc_push <-- calls into KVM/QEMU to write up to 16 bytes > #1 hvc_write > #2 tty_put_char > #3 do_output_char > #4 __process_echoes <-- writes up to tty_write_room() chars > #5 flush_echoes <-- returns early if ~ECHO && ~ECHONL > #6 n_tty_receive_buf_common <-- buffers more than 16 bytes > #7 tty_ldisc_receive_buf > #8 tty_port_default_receive_buf > #9 receive_buf > #10 process_one_work > > In my busybox instance which does not have this issue I can see that > termios.c_lflag = 0x447, so in the stack above #4 is not called (ECHO > is 0x8, ECHONL is 0x10). > > In the bug scenario: termios.c_lflag = 0x5cf, so we go into #4 which > is supposed to write (say) 17 bytes, but ends up writing only 16 > because that is what tty_write_room() returns.
I think my init script left the terminal wherever the hardware defaults initialized it to? (I note that sh4 also has a variant of this problem, but instead of the stutter-and-flush behavior it just hard discards everything after the first 16 characters of a paste. Large pastes seemsto work without issue on all the other targets I've tried so far, I.E. x86, arm, mips, powerpc -M g3beige, s390x, and m68k. And by "large" I mean I've fed half a megabyte of uuencode output into uudecode as a single paste.) > What I think is causing this issue is that the hvc_vio.c driver is > configured with hp->outbuf_size = 16. That number comes from the > H_PUT_TERM_CHAR hypercall spec which reads two registers at a > time. However, the hvc_write function supports writes larger than 16 > bytes so it seems we're needlessly propagating the 16 byte limitation > to the upper layer. Looks like the call is: hp = hvc_alloc(termno, vdev->irq, ops, MAX_VIO_PUT_CHARS); MAX_VIO_PUT_CHARS implies it's the maximum allowed write size. Understandable if writes bigger than that didn't get a lot of testing. (There's an identical call in hvc_opal.c, by the way.) > The driver is also not buffering the write, so if it gets called to > write one char at a time (like __process_echoes does) there should be no > limit to how much it can write. > > I think if we increase hp->outbuf_size to a value that is larger than > N_TTY_BUF_SIZE=4096 the echo buffer would drain before reaching this new > hvc driver limit. How is this handled on any of the architectures where it works? (Or do their tty flags just start at different defaults so I don't see it there?) > I tested that and it seems to work, but I'm not sure if it's the right > fix, there are some things I couldn't figure out: Let me know if I can help, although this sounds like it's moved a bit beyond areas I'm familiar with. Thanks, Rob