On 02/12/2007, Thiemo Seufer <[EMAIL PROTECTED]> wrote:
> andrzej zaborowski wrote:
> > On 24/11/2007, Paul Brook <[EMAIL PROTECTED]> wrote:
> > > > There is a chance that when using "unix" or "dynticks" clock, the
> > > > signal arrives when no cpu is executing.
> >
> > How about this version, thi
andrzej zaborowski wrote:
> On 24/11/2007, Paul Brook <[EMAIL PROTECTED]> wrote:
> > > There is a chance that when using "unix" or "dynticks" clock, the
> > > signal arrives when no cpu is executing.
>
> How about this version, this one touches vl.c only:
Any reason why this isn't in CVS?
Thiem
On 24/11/2007, Paul Brook <[EMAIL PROTECTED]> wrote:
> > There is a chance that when using "unix" or "dynticks" clock, the
> > signal arrives when no cpu is executing.
How about this version, this one touches vl.c only:
--- a/vl.c
+++ b/vl.c
@@ -236,6 +236,10 @@ const char *prom_envs[MAX_PROM_ENV
> There is a chance that when using "unix" or "dynticks" clock, the
> signal arrives when no cpu is executing.
I've seen similar stalls, but not managed to track down the source. Your
analysis seems correct.
> + /* cause an interrupt in the first cpu that tries to start running */
> + if
Hi,
There is a chance that when using "unix" or "dynticks" clock, the
signal arrives when no cpu is executing. The probability is high when
using dynticks and a timer is scheduled to expire very soon so that a
signal is delivered very soon after a previous signal. When that
happens cpu_single_env
