On Mon, Jan 08, 2007 at 02:45:00PM -0700, Eric W. Biederman wrote: > Adrian Bunk <[EMAIL PROTECTED]> writes: > > > On Mon, Jan 08, 2007 at 09:11:24AM -0700, Eric W. Biederman wrote: > >> > >> To a large extent this reverts b026872601976f666bae77b609dc490d1834bf77 > >> while still keeping to the spirits of it's goal, the ability to > >> make smart guesses about how the timer irq is routed when the BIOS > >> gets it wrong. > >>... > > > > That's code where every changed line has a great potential of causing a > > different kind of breakage on someone else's computer. > > Why does this piece of code give every one the screaming hebie jebies? > I read it I understand it, it is code. > > This code is not a terribly sensitive delicate heuristic, and Andi has > already broken it as much as it can possibly be broken. It's not like > the code is on a SMP fastpath full of carefully orchestrated races > that are safe because within certain limits even stale values are ok. > > This is code is straight forward logic, you tell the computer what to > do and it does it. Of those things we can do only very few of > them are correct, and we are seeking to enhance our ability to find > correct solutions by adding intelligent guesses. As long as the first > guess is trust the BIOS the rest of this code is largely a don't > care. As Andi proved by breaking all the rest of this. Or why > don't I have more testers just crawling out of the wood work, > screaming for this code to be fixed? > > Plus this code can only cause one type of breakage. A failure to > work around a broken BIOS and make the IRQs work.
We just got a completely different bug reported that was confirmed to be caused by Andi's patch: AMD64/ATI : timer is running twice as fast as it should [1] > > Your comment therefore translates to "rexvert commit > > b026872601976f666bae77b609dc490d1834bf77 for 2.6.20 and try to find a > > better solution for 2.6.21". > > If that is the practical translation I am fine with it. >... > I really don't care how we do it, or in what timeframe. But what I have > posted is the only way I can see of making it better, than what we had > in 2.6.19. >... My whole point is that for 2.6.20, we can live with simply reverting Andi's commit. What to do for 2.6.21 is a completely different story. > Eric cu Adrian [1] http://bugzilla.kernel.org/show_bug.cgi?id=7789 -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
