Strange Kernel lockup with 16550 uarts

[Altera_Forum]

We have a custom design that we've been using for a while and is stable. It is based on a NO MMU kernel. It uses 2 16550 uarts (open cores). We have one of the ports connected to a linux work station, the configuration is 115200, no parity, 8 data bits, 1stop, 1start and no flow control. In normal usage, the port would be connected to another one of our instruments, so the PC simulates our status query packet which is 6 bytes long. If we send this packet in a loop with a 250 mSec delay between each packet all is well. We have an app running on the NIOS side that simply reads the packets and throws them away. But if we also add a small delay of 270 microseconds (about 31 bit times) between the third and fourth bytes in the packet, it will lock-up the entire kernel within a few hundred packets. This second delay is time critical. 240uSec, no problem 300uS, no problem. We found this, of course, because there just happens to be a 270 uSec delay sometimes in our system. 

 The question is, how do I go about trouble shooting this??? Since the kernel is using the other uart for its console, and they both use the 8250 driver, printk is useless.   One final bit of information. The 16550 uart interrupts on the 14th byte. if there is a 4 character time delay before it gets a byte it interrupts so that data less than 14 bytes long will not be stale in the 16550 buffer. Looking with an analyzer, we see a short interrupt coming from the uart during this delay period. The period of this interrupt is variable and it is when it gets really short that the system crashes (we can't measure that time with our analyzer, too short). It is also a little odd that our delay (measured) is about 3 char times not 4.   Any help or ideas would be greatly appreciated. Thanks in advance!

[Altera_Forum]

I forgot to mention, if we configure the uart to interrupt after every character, the problem goes away!