Re: [Xenomai-help] Kernel panic: not syncing

["Petr Cervenka" <grugh@domain.hid>]

Jan Kiszka wrote:
>We likely see some race that causes weird memory corruptions. Its
>probability often increases when the code execution frequency raises.
>
>However, reducing the test case is very important now to reduce the
>search domain for this issue. E.g. try to fake peripheral access as far
>as possible, unloading the unused driver and only leaving the test
>program behind that is executable on arbitrary Xenomai installation
>(maybe finally on one of my boxes...).
>
I'm not sure if I will be able to reduce the software. It's dependent on hardware and it's controlled from another windows computer with GUI and control application. And to check if the error is still there usually takes couple of days.
I ran a test during last weekend (and nothing wrong happened). But the /proc/xenomai/stat output is strange. Probably some type cast error, because 18446744071739514846 = 0xFFFFFFFF8A939FDE and the appropriate value perhaps should be 0x000000008A939FDE = 2324930526.

CPU  PID    MSW        CSW        PF    STAT       %CPU  NAME
  0  0      0          18446744071739514846 0     00500088   69.8  ROOT/0
  1  0      0          18446744071675175740 0     00500080   23.2  ROOT/1
  0  5299   0          351459     0     00300182    0.0  LOGGER_TASK_1804289383
  0  5100   8          283613     0     00300186    0.0
  0  5317   0          40591      0     00300182    0.0
  0  5034   2          2330696    0     00300184    0.0  MAIN_TASK_2056
  0  5318   5          18446744071736105613 3     00300180   29.5  REG_TASK_2056
  0  5319   28         36         0     00300182    0.0  WORK_TASK_2056
  0  5321   38926      39159      0     00300380    0.0  CERECV_2056
  0  5323   1159385    2438330    0     00300181    0.0  CESEND_2056
  1  5710   0          18446744071675175740 0     00300184   76.8  HARDWARE_KERNEL
  0  0      0          18446744071964064315 0     00000000    0.7  IRQ520: [timer]
  1  0      0          232145209  0     00000000    0.0  IRQ520: [timer] 

My theory is, that a occasional "longer" work or system call usage in the real-time task corrupts the rest of the system (under some special circumstances).

Petr