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 */
}
.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Aug 31 2002 - 22:00:25 EST