Messages in this thread |  | | Date | Thu, 29 Aug 2002 00:21:03 +0100 | From | Russell King <> | Subject | Re: [BUG] mysterious tty deadlock |
| |
On Wed, Aug 28, 2002 at 03:25:20PM -0700, Andrew Morton wrote: > 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 */ > }
Patch looks good, as far as correctness goes. However, since char_time will be the amount of time for one character, we should never sleep long enough for the user to notice this slip-up.
If people are seeing deadlocks, I agree with wli that there's something very wrong elsewhere.
-- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
- 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/
|  |