Messages in this thread | | | Date | Tue, 23 Jun 2009 12:29:01 -0600 | From | Paul Fulghum <> | 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
| |