Re: [BUG] mysterious tty deadlock

[Andrew Morton <akpm@zip.com.au>]

William Lee Irwin III wrote:
> 
> One such stuck process had the following backtrace:
> 
> #0  schedule_timeout (timeout=-150765944) at timer.c:864

schedule_timeout is FASTCALL, which confuses gdb's stack crawler
somewhat.

> #1  0xc01a28a3 in uart_wait_until_sent (tty=0xf7669000, timeout=2147483647)
>     at core.c:1320

Might be a bit racy?

--- 2.5.32/drivers/serial/core.c~serial-race	Wed Aug 28 15:22:22 2002
+++ 2.5.32-akpm/drivers/serial/core.c	Wed Aug 28 15:22:26 2002
@@ -1315,13 +1315,14 @@ static void uart_wait_until_sent(struct 
 	 * 'timeout' / 'expire' give us the maximum amount of time
 	 * we wait.
 	 */
+	set_current_state(TASK_INTERRUPTIBLE);
 	while (!port->ops->tx_empty(port)) {
-		set_current_state(TASK_INTERRUPTIBLE);
 		schedule_timeout(char_time);
 		if (signal_pending(current))
 			break;
 		if (time_after(jiffies, expire))
 			break;
+		set_current_state(TASK_INTERRUPTIBLE);
 	}
 	set_current_state(TASK_RUNNING); /* might not be needed */
 }

.