Thread (26 messages) 26 messages, 6 authors, 1999-10-12

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)

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/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help