Quoting Stelian Pop <[EMAIL PROTECTED]>:
Le jeudi 01 septembre 2005 à 16:09 +0300, Heikki Lindholm a écrit :
Stelian Pop kirjoitti:
> Le jeudi 01 septembre 2005 à 14:20 +0200, Stelian Pop a écrit :
>
>
>>I'll try testing the 2.6.10 patch, maybe this will tell if the problem
>>is in the adeos core or in the newer kernel changes...
>
>
> Okay, it also hangs with the 2.6.10 patch (even with the fix for
> activate_mm()). It took two invocations of 'rtai-test' but it ended up
> hanging just like before.
Are you sure this is not the same I was experiencing, eg. missed
decrementer interrupt that stalls the machine (looks like hard lock-up)
for two minutes.
I tried waiting (at least 5 minutes) and nothing happened.
Here is a revisited version of Heikki's patch applicable against an
Adeos-patched kernel, and which is expected to solve the lagging
interrupt sync
issue; tested on a mpc8541 board. I'd be interested to know if this
still fixes
the issue discovered on ppc64, and maybe on the G4.
--- linuxppc-mpc52xx-adeos/kernel/adeos.c 2005-08-21 11:44:52.000000000
+0200
+++ linux-2.6.10-ppc-adeos/kernel/adeos.c 2005-09-01 00:19:58.000000000
+0200
@@ -173,6 +173,13 @@
break;
}
}
+ else if (next_domain != this_domain &&
+ next_domain->cpudata[cpuid].irq_pending_hi != 0 &&
+
!test_bit(IPIPE_STALL_FLAG,&next_domain->cpudata[cpuid].status))
+ {
+ __adeos_switch_to(this_domain,next_domain,cpuid);
+ adeos_load_cpuid(); /* Processor might have changed. */
+ }
if (next_domain == this_domain)
break;
@@ -223,6 +230,13 @@
propagate = evinfo.propagate;
}
+ else if (next_domain != this_domain &&
+ next_domain->cpudata[cpuid].irq_pending_hi != 0 &&
+
!test_bit(IPIPE_STALL_FLAG,&next_domain->cpudata[cpuid].status))
+ {
+ __adeos_switch_to(this_domain,next_domain,cpuid);
+ adeos_load_cpuid(); /* Processor might have changed. */
+ }
if (next_domain == this_domain || !propagate)
break;
