Here is the call that is being made to generate break sequence:

1. src/share/linux/native/com/oracle/dio/uart/uart.c

     if (-1 == tcsendbreak(data->uart->serial_descr.fd, data->duration)) {
        JAVACALL_REPORT_ERROR1(JC_DIO, "tcsendbreak error:%s", strerror(errno));

The problem is that third parameter in the call:

tcsendbreak(data->uart->serial_descr.fd, data->duration)

defines duration in DECISECONDS, while the values provided to

void jdk.dio.UART.generateBreak(int duration) is PLAINLY turned into it.

So, if duration is generated, it would take 100 times longer than expected.


2. Man tty_ioctl(4) states the following:
   Sending a break
       TCSBRK int arg
       Equivalent to tcsendbreak(fd, arg).
       ...
      If the terminal is using asynchronous serial data
              transmission, and arg is zero, then send a break (a stream of
              zero bits) for between 0.25 and 0.5 seconds. If the terminal
              is not using asynchronous serial data transmission, then
              either a break is sent, or the function returns without doing
              anything. When arg is nonzero, nobody knows what will happen.

              (SVr4, UnixWare, Solaris, Linux treat tcsendbreak(fd,arg) with
              nonzero arg like tcdrain(fd). SunOS treats arg as a
              multiplier, and sends a stream of bits arg times as long as
              done for zero arg. DG/UX and AIX treat arg (when nonzero) as
              a time interval measured in milliseconds. HP-UX ignores arg.)

=====================
It means that using positive argument value for second parameter to tcsendbreak()
is INVALID.

Instead, ioctl() with TCSBRKP (see same tty_ioctl man page) must be used:

"...
  TCSBRKP int arg
              So-called "POSIX version" of TCSBRK. It treats nonzero arg as
              a timeinterval measured in deciseconds, and does nothing when
              the driver does not support breaks.
...
"

3. It is not clear from the specification what to do if requested break' duration is less than one
    decisecond. Will clarify with spec author and file corresponding issue.