On Tuesday 27 June 2006 22:06, Larry Finger wrote: > John, > > I would like to find a diplomatic solution to this impasse between Michael > and Jeff, which is why > I'm writing to you privately. Michael is correct in that the loop in question > will not usually delay
private? > long; however, on some hardware it takes longer than on his. On mine, I have > seen delays as long as > 550 usec. What's the chip? > In any case, I think that the following code fragment would work and pass > Jeff's criticism: > > for (i=5000; i; i--) { > .......... > usleep(1); usleep? Can't find that in my kernel tree. In fact, I think the lowest possible sleep time depends on HZ and is 1msec on 1000HZ. Additionally, we are holding a spinlock at this time, so it is not as easy as simply replacing udelay() by some sleeping function. > This would make the worst-case delay be 5 msec, but would provide a cushion > of 10X the longest I > have seen and should be safe. > > Do you have any suggestions on what should be done next? Leave it as is and find out why it takes so long for your strange card. ;) -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html