* Frans Klaver | 2014-09-17 12:28:12 [+0200]: >- Bone Black: Yocto poky, core-image-minimal > Login, "less file" locks up, doesn't show anything. I can exit using > Ctrl-C. So I have the same with my and the serial-omap driver. No difference here. The trace looks like this: | <idle>-0 [000] d.h. 444.393585: serial8250_handle_irq: iir cc lsr 61 | <idle>-0 [000] d.h. 444.393605: serial8250_rx_chars: get 0d received the enter key | <idle>-0 [000] d.h. 444.393609: serial8250_rx_chars: insert d lsr 61 | <idle>-0 [000] d.h. 444.393614: uart_insert_char: 1 | <idle>-0 [000] d.h. 444.393617: uart_insert_char: 2 | <idle>-0 [000] dnh. 444.393636: serial8250_tx_chars: empty | kworker/0:2-753 [000] d... 444.393686: serial8250_start_tx: empty?1 | kworker/0:2-753 [000] d.h. 444.393699: serial8250_handle_irq: iir c2 lsr 60 | kworker/0:2-753 [000] d.h. 444.393705: serial8250_tx_chars: empty | sh-1042 [000] d... 444.393822: serial8250_start_tx: empty?1 | sh-1042 [000] d.h. 444.393836: serial8250_handle_irq: iir c2 lsr 60 | sh-1042 [000] d.h. 444.393842: serial8250_tx_chars: empty | sh-1042 [000] d... 444.393855: serial8250_start_tx: empty?0 | sh-1042 [000] d.h. 444.393863: serial8250_handle_irq: iir c2 lsr 60 | sh-1042 [000] d.h. 444.393867: serial8250_tx_chars: put 0d | sh-1042 [000] d.h. 444.393871: serial8250_tx_chars: put 0a shell responded with "\r\n" which I see and then | sh-1042 [000] d.h. 444.394057: serial8250_handle_irq: iir c2 lsr 60 | sh-1042 [000] d.h. 444.394065: serial8250_tx_chars: empty nothing more. less isn't sending data for some reason. Exactly the same thing happens in a Debian environment except that it continues: … | bash-2468 [000] d.h. 99.657899: serial8250_tx_chars: put 0a | bash-2468 [000] d.h. 99.658089: serial8250_handle_irq: iir c2 lsr 60 | bash-2468 [000] d.h. 99.658095: serial8250_tx_chars: empty => | less-2474 [000] d... 99.696038: serial8250_start_tx: empty?0 | less-2474 [000] d.h. 99.696069: serial8250_handle_irq: iir c2 lsr 60 | less-2474 [000] d.h. 99.696078: serial8250_tx_chars: put 1b | less-2474 [000] d.h. 99.696082: serial8250_tx_chars: put 5b | less-2474 [000] d.h. 99.696085: serial8250_tx_chars: put 3f | less-2474 [000] d.h. 99.696087: serial8250_tx_chars: put 31 It has to be something about the environment. Booting Debian and chroot into this RFS and less works perfectly. But since it behaves like that with both drivers, I guess the problem is somewhere else… > vi runs normally, only occupies part of the total screen estate in > minicom. After quitting, a weird character shows up (typically I see > ÿ there), but minicom can use the rest of the screen estate again. > If we disregard the odd character, this is much like the behavior we > have on the omap-serial driver. >- Custom board: Yocto poky, custom image > Login, "less file" locks up, showing only "ÿ" in the top left corner > of the screen. Can get out of there by having something dumped through > /dev/kmsg. I managed to run into something like that with vi on dra7 and with little more patience on am335x as well by "vi *" and then ":n". This gets fixed indeed by writing. Hours of debugging and a lot of hair less later: the yocto RFS calls set_termios quite a lot. This includes changing the baudrate (not by yocto but the driver sets it to 0 and then to the requested one) and this seems to be responsible for the "bad bytes". I haven't figured out yet I don't see this with omap-serial. Even worse: If this (set_termios()) happens while the DMA is still active then it might stall it. A write into the FIFO seems to fix it and this is where your "echo >/dev/kmsg" fixes things. If I delay the restore_registers part of set_termios() until TX-DMA is complete then it seems that the TX-DMA stall does not tall anymore. >Having it summed up like this, I think we're back at ncurses and its >interaction with the serial driver. > >Hope this helps. Thanks for your effort so far, >Frans Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
