On Sun, 2009-11-01 at 19:58 +, Bernhard Walle wrote:
> In some conditions, while testing Xenomai in VirtualBox, I had the error that
> xnarch_init_timeconv() is called from init_32.h with a frequency of 0. That
> leads to a division by zero, followed by a system oops.
>
> Of course that is a bug in the virtualisation and Linux reports a CPU
> frequency
> of 0 in /proc/cpuinfo. However, there's no harm if Xenomai checks that instead
> of crashing the whole system.
>
>
I agree with the conclusion, not with the fix.
- the userland part reuses the frequency value returned by the nucleus,
so testing the issue up front when the nucleus initializes would be
enough. No need to propagate error detection to userland.
- the kernel side should rather test RTHAL_CPU_FREQ for consistency in
the generic hal init code, and bail out with an error if 0 is detected,
since there is no way for the nucleus to operate properly with such
setting anyway.
It turns out that no change have to be done in xnarch_init_timeconv()
which should remain a void routine, but its argument - RTHAL_CPU_FREQ -
should rather be tested as early as possible for consistency, directly
from kernel space.
> Signed-off-by: Bernhard Walle
>
>
> include/asm-arm/bits/init.h | 4 +++-
> include/asm-blackfin/bits/init.h| 4 +++-
> include/asm-generic/bits/timeconv.h | 18 +-
> include/asm-nios2/bits/init.h | 4 +++-
> include/asm-powerpc/bits/init.h | 4 +++-
> include/asm-x86/bits/init_32.h | 4 +++-
> include/asm-x86/bits/init_64.h | 4 +++-
> src/skins/native/timer.c| 7 ++-
> src/skins/posix/clock.c | 8 +++-
> 9 files changed, 48 insertions(+), 9 deletions(-)
>
>
> ___
> Xenomai-core mailing list
> Xenomai-core@gna.org
> https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
