Messages in this thread | | | Date | Fri, 29 Oct 2010 19:26:31 +0200 | From | Markus Trippelsdorf <> | Subject | Re: [bisected] Clocksource tsc unstable git |
| |
On Fri, Oct 29, 2010 at 07:00:40PM +0200, Borislav Petkov wrote: > On Fri, Oct 29, 2010 at 08:14:12AM -0400, Thomas Gleixner wrote: > > On Fri, 29 Oct 2010, Borislav Petkov wrote: > > > On Fri, Oct 29, 2010 at 04:30:13AM -0400, Markus Trippelsdorf wrote: > > > That's strange, when we tested this one everything seemed fine so I > > > guess this is one of those bugs which appear later, just as if out of > > > nowhere. > > > > > > Thomas, could it be that SMI fires in between the HPET write and > > > subsequent read: > > > > > > hpet_writel(cnt, HPET_Tn_CMP(timer)); > > > > > > ... > > > > > > res = (s32)(cnt - hpet_readl(HPET_COUNTER)); > > > > > > causing the -ETIME and thus a wait for HPET wraparound? My machine at > > > least does SMI-initiated C1E so it could very well be the problem. > > > > Well, even if a SMI fires, then the counter will be ahead of cnt and > > we get -ETIME. The upper layer of clockevents/timers will then > > reprogram HPET. So that's not an issue. > > Ah, I missed the upper layer, good. > > > The only problem which might hit us is when our assumption of 8 HPET > > cycles being enough to transfer the new match value into the real > > match register is wrong. > > So Markus, can you try with 995bd3bb5c78, but by increasing the value > to, say 16 (I don't know what's a good value here, let's double the old > one). Simply change the line > > return res < 8 ? -ETIME : 0; > > to > > return res < 16 ? -ETIME : 0; > > > in <arch/x86/kernel/hpet.c:hpet_next_event()>. I'll do that too on the > machine here when I get around to it.
Yes, I already did this, although I'm running return res < 12 ? -ETIME : 0; at the moment.
-- Markus
| |