On Tuesday 07 February 2006 19:20, Luck, Tony wrote: > > The fix is to include a __delay(1) call in the loop, to correctly > > approximate > > the intended delay timeout of 1 second. The code assumes that every > > architecture implements __delay(1) to last around 1/(loops_per_jiffy*HZ) > > seconds. > > But we calculate loops_per_jiffy based on somewhat larger vales passed > to __delay() ... where the function call overhead is amortized away. > > I'd expect that __delay(1) would last quite a bit longer than > 1/(loops_per_jiffy * HZ) ... so we'll wait a lot more than a > second.
For this case that would be ok, as long as it isn't a hour or so, but let's say < 1 minute. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
