Re: serial hang in qemu-system-ppc64 -M pseries

[Rob Landley <rob@landley.net>]

On 4/29/22 16:43, Fabiano Rosas wrote:
> Rob Landley <rob@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