Le jeudi 01 septembre 2005 à 10:47 +0200, Philippe Gerum a écrit : > >> Ok. Looks like time has come to upgrade the combined Adeos/PREEMPT_RT patch > >> to > >> -rt1 in order to fix the issues brought since 0.7.44, I guess. > > > > How does this relate to the above ? I worked on the _plain_ adeos > > patch, not the combo rt one. That being said, the plain adeos patch > > does contain some PREEMPT_RT bits - and those are the ones causing the > > problems. > > > > This is exactely how this relates to the above: The PREEMPT_RT-aware bits are > out of date.
I was under the impression that the PREEMPT_RT bits were not supposed to be at all in the plain (non rt combo) patch. But I suppose the current plan is to fold those bits into the regular patch. > >> >The ppc patch was a bit more tricky, but I think I got all of it right. > >> >It works ok most of the time (RTAI fusion testsuite passes for example - > >> >on a G4 Powerbook), but it hangs the machine hard sometimes. I am not > >> >sure if the problem is due to the port or if it is present in the 2.6.10 > >> >version as well. > >> > > >> > >> I had a report about issues involving insufficiently protected > >> get_mmu_context/destroy_context calls on the RTAI mailing list with > >> 2.6.10-r8c1; I'm currently checking the proposed fix that has been sent to > >> me > >> on a mpc8541. If this works, then maybe this would solve the issue you > >> mention > >> too; hopefully. > > > > I suppose you're talking about: > > https://mail.rtai.org/pipermail/rtai/2005-August/012841.html > > > > Yes; Looking at the code a bit more, I think the issue was more > generally lying > in the unprotected use of activate_mm(), as called from the fs/exec stuff. I saw the patch you posted on the rtai list and tried it, but unfortunately it does not solve my problems. The bug (hard lockup without any message at all) is 100% reproductible when running fusion's rtai-test application. It does not always hang at the same point in execution, but it does often hang at the end of the 'latency' binary invocation. I am also unable to reproduce this bug when running manually the 'latency' test, even when simulating some load like 'rtai-test' does. I suppose I could end up reproducing the bug if I tried hard enough... 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... Stelian. -- Stelian Pop <[EMAIL PROTECTED]>
