i.MX28 Application UART driver mxs-auart locks up if application is killed

[CraigMcQueen]

E.g.:

1) Run picocom (or some other serial program) on the target hardware:

  picocom /dev/ttySP0

  Verify that communications to the connected device can occur normally.

2) In another console (e.g. SSH), do command:

  kill -s SIGKILL <picocom-PID>

  (where picocom-PID is obtained from ps command)

3) Restart picocom with the same command as before.

Observe that communications no longer work as expected in picocom. The AUART ttySP0 basically doesn't function properly until the system is restarted.

This situation shouldn't happen in "nominal" operation, but it might happen in various error scenarios, and it indicates that the mxs-auart driver is not very robustly written.

I haven't debugged this yet. Looking at the code I haven't figured out which ops in struct uart_ops would normally run in the "nominal" case, and fail in the "application killed" case.

Any advice on this?

[jimmychan]

have you try the latest BSP for i.MX28EVK?  L2.6.35_1.1.0_ER_SOURCE

[CraigMcQueen]

I now have the latest BSP. I tried the steps above. Strangely, after killing picocom in step (2), I found that input on the debug console on the debug UART locked up -- no input characters could be entered. However debug console output (various occasional kernel messages) was still functional.

Via my SSH session, I was still able to do things as normal. I ran picocom on /dev/ttySP0 in the SSH session, and was able to communicate on it.

So after the patches, it looks as though it's fixed AUART lock-up, but still causing a DUART lock-up. Which is strange, since it's a different UART.