From: John K L. <jk...@lu...> - 2005-02-05 22:13:25
|
On Wed, Feb 02, 2005 at 12:15:49AM -0800, Stephen Hemminger wrote: > > Doesn't do >1 sec case properly, if it matters? There is no >1 second case, the mtt is encoded with a u16 meaning that it'll never be greater than 65.5ms. Other drivers assume this so if it were ever changed (unlikely, I think) one would have to audit each driver anyway. > Also not sure whether my original code using gettimeofday is really that great an idea, > is it worth the effort to do turnaround times < 1ms? The 10us special case is probably not very useful. I mean, either the last packet was just received and you're going to end up sleeping a jiffie or more, or it's been a long time since everything has come in. The probability of the 10us case is really low I'd assume. On a 10ms/jiffie arch, the turnaround time probably hurts. Not really sure what the ideal solution is. > > @@ -787,7 +788,7 @@ static int stir_transmit_thread(void *ar > > stir_send(stir, skb); > > dev_kfree_skb(skb); > > > > - if (stir->speed != new_speed) { > > + if ((new_speed != -1) && (stir->speed != new_speed)) { > > if (fifo_txwait(stir, -1) || > > change_speed(stir, new_speed)) > > break; > > > > How is new_speed of -1 getting in anyway? why did it get this far... > should it just be checked when speed change is detected? > I don't think it got very far, the new_speed value is coming right out of the skb. Look at the definition of irda_get_next_speed and you will see this is totally sane behavior. BTW, I have been using an application which uses a packet socket to send only, and that is how both problems were uncovered :). -jkl |