From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: rt_dev_send() stalls periodic task References: From: Jan Kiszka Message-ID: <2ade719a-84c7-c53d-9895-a5e6eea354a3@siemens.com> Date: Thu, 18 Apr 2019 10:36:29 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: C Smith Cc: Sumitabh Ghosh via Xenomai On 18.04.19 08:42, C Smith wrote: > > > On Tue, Apr 16, 2019 at 1:03 AM Jan Kiszka > wrote: > > > The serial device is set up this way: > > struct rtser_config serial_config = { > >          .config_mask       = 0xFFFF, > >          .baud_rate         = 115200, > >          .parity            = RTSER_NO_PARITY, > >          .data_bits         = RTSER_8_BITS, > >          .stop_bits         = RTSER_1_STOPB, > >          .handshake         = RTSER_NO_HAND, > >          .fifo_depth        = RTSER_DEF_FIFO_DEPTH, //RTSER_FIFO_DEPTH_8, > >      .reserved          = 0, > >          .rx_timeout        = 500000, > >          .tx_timeout        = RTSER_DEF_TIMEOUT, > >          .event_timeout     = 5000000, > >          .timestamp_history = RTSER_RX_TIMESTAMP_HISTORY, > >          .event_mask        = RTSER_EVENT_RXPEND, > > }; > > fd_tty[0] = rt_dev_open("rtser1", O_RDWR | O_NONBLOCK); > > sret = rt_dev_ioctl(fd_tty[0], RTSER_RTIOC_SET_CONFIG, &serial_config); > > > > The application transmits a packet of about 75 bytes repeatedly from a > > xenomai periodic task that wakes up at 125Hz repeatedly. Note that there is > > also a small RX serial packet arriving so there is some full-duplex > > overlap.  On rtser0 this works fine, on the other serial ports the stall > > happens after a few hours and my periodic xenomai task stops. There is no > > xenomai watchdog message in dmesg. The code is repeatedly checking the > > serial port status ioctl and there are no errors like framing errors etc. > > > > The periodic task is just a typical xenomai while() loop: > >    next += period_ns + adjust_ns; > >      rt_task_sleep_until(next); > > > > When my periodic task stops the kernel says the stack trace is: > > [root@oyx ~]# cd /proc/1066/task/1075/ > > [root@oyx 1075]# cat stack > > [] xnpod_suspend_thread+0x3d8/0x650 > > [] xnsynch_sleep_on+0x139/0x320 > > [] rtdm_event_timedwait+0x2e4/0x390 > > [] rt_16550_write+0x35b/0x540 [xeno_16550A] > > This means the driver is stuck while writing because there are no more free > entries in the hardware TX FIFO. Do you have hardware flow control enabled? Are > you sure the that the receiving side is playing nicely? > Jan > > > Well I'm not trying to use hardware flow control. Is hardware flow control the > xeno_16550A driver default? > I am using a 3-wire serial cable, no RTS/CTS wires at all, they are floating.z > > At present my app only ever calls the ioctl RTSER_RTIOC_SET_CONFIG as detailed > above. > Are you saying I need to do an ioctl RTSER_RTIOC_SET_CONTROL and clear control > bit *RTSER_MCR_RTS*   ? > > I have another Xenomai app which has been running fine as a 3-wire serial > connection for about 4 years, > and it does not do an ioctl RTSER_RTIOC_SET_CONFIG either. Doesn't that mean > setting flow control is unnecessary? The default handshake mode is #define RTSER_DEF_HAND RTSER_NO_HAND and your setting also does not change that. So that is not the reason. but we still see that the TX fifo does not get emptied at some point - or we miss the interrupt that informs us about this. You could confirm that missed-interrupt theory by checking the line status register (RTSER_RTIOC_GET_STATUS -> RTSER_LSR_TRANSM_EMPTY) when TX got stuck. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux