From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: rt_dev_send() stalls periodic task References: <2ade719a-84c7-c53d-9895-a5e6eea354a3@siemens.com> <5CBCCE3F.5090000@freyder.net> <5CBE1B46.3050804@freyder.net> <5CBE2AFC.2050105@freyder.net> From: Steve Freyder Message-ID: <5CBE51D1.80801@freyder.net> Date: Mon, 22 Apr 2019 18:44:17 -0500 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: C Smith Cc: "xenomai@xenomai.org" On 4/22/2019 5:56 PM, C Smith wrote: > Please don't think the cross-link.c app config has the magic answer. > Changing RX timeouts to prevent TX stalls would be an open loop hack > that might fail the serial traffic jitters differently. The most > suspicious difference between the two apps is that : cross-link.c > behaves very regularly in terms of timing, because it receives its own > transmissions. My app receives packets from another computer > asynchronously (full duplex). So there is likely a random timing > anomaly causing the problem. Any properly working UART and driver > should be able to handle this, National Semiconductor would say. But I > have a strange serial port, and it is tricking the xeno_16550A driver. > > Jan alluded to a buffer-filling race condition in his comment. > I also fear that Receive interrupt handlers are somehow clearing > Transmit interrupts? > > I didn't look at the stack trace when my app hung at startup due to > that infinite RX config. BTW there was no serial traffic whatsover > during this hang. I could try it again and look at the stack... > Also, it would be too hard to rewrite my apps to send single bytes. > Its two computers, rigid packet protocols & CRCs etc. Lots and lots of > code. Thats why I did that test app. > > -C Smith Anything that can prove that there's no hardware problem causing lost TX interrupts is good. I remember you said that you had three serial ports, and one never failed like this, the other two *do* fail like this. Isn't that true? That seems important.