Date: Thu, 29 Sep 2011 12:11:47 +0530 From: "Jayachandran C." <c.jayachandran@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-mips@freebsd.org Subject: Re: eventtimer issue on mips: temporary workaround Message-ID: <CA%2B7sy7DpEEhZ7WGoT-p9FCgvGBAeBHnyGVXmcUtHs%2BTt6tsTng@mail.gmail.com> In-Reply-To: <CAJ-Vmo=i6-3PNTPbP5xCftNU0w1OmMhZSysgaSRzDqgwLU6prQ@mail.gmail.com> References: <CAJ-Vmo=qONOffCTgusWtbwuo43zKYyXDqqu5YEaL-MDQSbt-mQ@mail.gmail.com> <CAJ-Vmo=i6-3PNTPbP5xCftNU0w1OmMhZSysgaSRzDqgwLU6prQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 28, 2011 at 10:06 PM, Adrian Chadd <adrian@freebsd.org> wrote: > .. so, the patch is totallyw rong. > > intr_disable() needs to be moved before critical_enter() or it doesn't > achieve anything. I'm not able to figure out why... > But the race is still there, between intr_enable() and "wait". > The only way to eliminate this race is to completely eliminate all the > code in cpu_idle(). the amd implementation seems to be using the STI instruction to enable interrupts - but I'm not able to see how to avoid this race condition on platforms which does not have a similar instruction. > Would someone clued in the implementation of wait please step up and help? :) What if go back to the earlier version of cpu_idle which does not have critical_enter() and cpu_idleclock() for now, or does this also have issues? I had also seen issues on XLR which went away when I took out 'ET_FLAGS_ONESHOT' from the mips clock event timer . That is another possible workaround. JC.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2B7sy7DpEEhZ7WGoT-p9FCgvGBAeBHnyGVXmcUtHs%2BTt6tsTng>