> 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. -Tony - 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
