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?
Thiemo
--- a/vl.c
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, this one touches vl.c
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_ENVS];
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 is
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 (!env)
