[ale] UART Debugging headache w/ embedded Linux SBC

[John Mills]

Christopher -

Thanks for the note.

On Mon, 16 Jan 2006, Christopher Fowler wrote:

> My concern would be why the line is not getting reset.  Possibly the
> kernel has locked up while servicing the interrupt?  When the board
> locks up do you know what the kernel is actually doing at that point?

I guess the kernel could be doing almost anything at that point. There's 
quite a bit going on in normal activity. I suspect this scenario:

1. UART receives some input or detects something that sets its IRQ while a 
normal character interrupt is being handled.

2. The condition reflected by the IRQ is not tested nor reset at exit by 
the driver.

3. The persistent IRQ results in a tight loop of exit-renter-re-exit-... 
at the ISR level.

Naturally that's just guesswork at this point, and carries a number of 
assumptions.

> Is this UART on a separate PC/104 module is it part of the SBC?  Is the
> SBC the TS-7200?

The UART is on a separate, specially built PC/104 board that also carries 
a modem (which may be signalling something to the UART). The SBC is 
actually a TS-7250 (lighter-weight sibling of TS-7200).

Next step is a look at the modem's signals with a 'scope. Other approaches
and/or leads are naturally welcome.

Cheers.
 - Mills

> On Mon, 2006-01-16 at 14:03 -0500, John Mills wrote:
> > ALErs (particularly embedded-processor wonks) -
 
> > I have an ARM/linux single-board computer that experiences irregular
> > but fairly frequent (~1s. to 3:45hr.) lockups. It appears that an
> > off-board 16550A UART has requested an interrupt that was not
> > successfully reset by the (generic) kernel driver. It may send 200
> > packets fine, then lock - effectively freezing the board.