Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
From: Lou Langholtz <hidden>
Date: 1999-09-29 18:46:54
Possibly related (same subject, not in this thread)
- 1999-09-29 · Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity] · Geert Uytterhoeven <hidden>
- 1999-09-29 · Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity] · Geert Uytterhoeven <hidden>
- 1999-09-10 · [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity] · Lou Langholtz <hidden>
Takashi Oe wrote:
On Wed, 29 Sep 1999, Lou Langholtz wrote:quoted
What might happen if a driver does: save_flags(old_flags); cli(); restore_flags(old_flags); save_flags(new_flags); cli(); restore_flags(new_flags); /* can't we be interupted here? Assume yes, if so */ restore_flags(old_flags); . . .
quoted hunk ↗ jump to hunk
I'm fairly certain it's a bug. Good spotting. The last restore_flags() shouldn't be there.--- macserial.c.ORIG Wed Sep 29 02:05:14 1999 +++ macserial.c Wed Sep 29 02:05:31 1999@@ -1381,7 +1381,6 @@ if (info->xmit_cnt && !tty->stopped && !info->tx_stopped && !info->tx_active) transmit_chars(info); - restore_flags(flags); return ret; }Takashi Oe
If this is true, then what about wherever else transmit_chars() is called. There's numerous instances where because transmit_chars() itself goes into a save_flags(); cli(); ...; restore_flags() where we have these nested cli()... restore_flags(). For instance in rs_throttle() transmit_chars() is called while cli()'s already in effect. If the real problem is the nesting of the locks introduced by transmit_chars() then this would also seem to explain the TCP die-off phenomena. Opinions? ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/