[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4A411EED.8030201@microgate.com>
Date: Tue, 23 Jun 2009 12:29:01 -0600
From: Paul Fulghum <paulkf@...rogate.com>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: Alan Cox <alan@...rguk.ukuu.org.uk>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] synclink_gt fix transmit race and timeout
Andrew Morton wrote:
> I'm referring to
>
> Where did the "7" come from?
Oops, I did not scroll down far enough.
+ /*
+ * use worst case speed of 1200bps to calculate transmit timeout
+ * based on data in buffers (tbuf_bytes) and FIFO (128 bytes)
+ */
+ if (info->params.mode == MGSL_MODE_HDLC) {
+ int timeout = (tbuf_bytes(info) * 7) + 1000;
+ mod_timer(&info->tx_timer, jiffies + msecs_to_jiffies(timeout));
+ }
7 is roughly the number of milliseconds to send a byte at 1200bps.
The problem with externally provided data clocks is that you
don't necessarily know the data rate before hand, so a somewhat
arbitrary worst case assumption is used.
> and
>
> I have a suspicion that tx_stop() should use del_timer_sync(), not
> del_timer(). What happens if the timer handler is concurrently
> running?
Everything is synchronized with info->lock spin_lock,
so nothing critical runs concurrently. tx_stop() is sometimes
called in interrupt context so it can't call del_timer_sync().
If the timer has already fired but has not
run yet it does nothing more than call tx_stop() itself and wake
any transmit waiters so there are no ill effects.
--
Paul Fulghum
MicroGate Systems, Ltd.
=Customer Driven, by Design=
(800)444-1982
(512)345-7791 (Direct)
(512)343-9046 (Fax)
Central Time Zone (GMT -5h)
www.microgate.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists