Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Martin Shepherd wrote:
>>> On Wed, 13 May 2009, Jan Kiszka wrote:
>>>> Martin, could you check if this helps you, too?
>>> It doesn't appear to help. To check, first I turned on the HPET and PM
>>> timer options, and recompiled the kernel without your patch, to verify
>>> that this reproduced the problem. I then manually applied your patch
>>> to include/asm-generic/xenomai/hal.h in the kernel source tree,
>>> recompiled the kernel, installed etc, and rebooted. However even with
>>> the patch in place, whenever I ran:
>>> dd if=/dev/zero of=/dev/null count=20000000
>>> then initially top showed that dd was getting very little CPU time
>>> (<10%), then after 30 seconds or so, the system became completely
>>> unresponsive until the dd ended. This is how it acts without the patch
>>> as well. So it doesn't appear that the patch has made any difference
>>> to this problem.
>> Hmm, so there is no Xenomai task running during this test, just Linux
>> load? Tried to reproduce with my kernel here (both HPET and PM enabled,
>> as usual), but no success. Strange.
> Just having HPET and PM_TIMER enabled is not enough: your CPU needs to
> actually have an HPET timer or PM timer.
That's the case for practically any modern system. So I bet the "trick"
is to make Linux _use_ one of them - in favor of the normally better
suited LAPIC. Need to check again what the reasons for this switch could
be. One that comes to my mind is problems of LAPIC vs. power management.
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
Xenomai-core mailing list