Translations:Sub-projects/Embedding and PLC/79/en

Assembling and testing process:

1. Patches CONFIG_PREEMPT_RT and AUFS of days of 2.6.29 are conflicted on the function "debug_mutex_set_owner()", in CONFIG_PREEMPT_RT it was removed — replaced to "mutex_set_owner()".
2. On the assembling here detected series of problems for "# typedef void irqreturn_t;" — replaced to "#include <linux/irqreturn.h>".
3. The first start with CONFIG_PREEMPT_RT, but without AUFS, was successful — the results above.
4. The starting with AUFS was revealed a problem in memory allocation by AUFS in "aufs_mmap()" — the working code of AUFS was taken from the preliminary assembling "rt-up-2.6.29.alt2".
5. Starting with AUFS was revealed a problem of hanging on the FS root in AUFS, like to the possibility of cycling/blocking a RT-task — setup CONFIG_PREEMPT_NONE, on LP-8781 and "AMD Turion" any problem does not observed (possible the problem due the HPET missing on PLX8).
6. At the first look the kernel works fine, but jumps to continuous growing the measured value of the delay time observed.
7. There finished adapting of the kernel to a binary compatibility for the modules "slot" and "icp" from ICP_DAS. The module "8250_linpac" crashes at its loading, and "icpdas_8250" has more unresolved symbols — the modules need to reassemble or to try the interfaces > COM2 initiate through setserial — the modules was reassembled by the help of Golden Wang (technical support of ICPDAS).
8. The new kernel set to high loading by the project configuration ACS ball drum mills:

• network with the driver "via_rhine" halted, after 4 days of successful working — the halt expected, assembled the driver "rhinefet", testing continued.
• on the driver "rhinefet" the system on loading had work three weeks. But here observed the interrupt 11, on what hangs mostly all standard hardware (USB, Ethernet and may be something), had disabled and the network continued to work in the "Polling" mode, which is slower. Possible that interruption disabling occurs also with "via_rhine", and it can not work in the mode "Polling", why packages in the network do not go. The problem reason linked to halt and generation the unhandled interruptions from one of hardware on the interruption 11.
• The problem fixed by preventing the interruption disabling at help the Linux kernel parameter "noirqdebug".
• The adapting successful finished and the firmwares based on the kernel ready to the production implementation!
• 01.03.2015: Instead function EnableWDT() used EnableSysWDT(), by limit to 30 seconds and cyclic reloading if the system was not loaded in 30 seconds (up to three reloadings).
• 17.03.2015: With assist of the ICP_DAS support service there was fixed a problem in the serial interfaces driver for more to COM2 which causes to Linux kernel "freeze" (like to interruptions block) after closing one port and activity on some other.
• 29.07.2015: Detected one more problem looks like by the symptoms to the interruption 11 disabling, but: the interruption 11 is not disabled and all other devices on it works. It reproduced only on configurations with using that both network interfaces, at that possible "braking" for one of its. The problem resolved only by reloading "the braked" network interface, by the command: ifdown eth0; ifup eth0. To detect it and the reloading performs we recommend on the OpenSCADA level append the traffic control and same reloading of the interface on the traffic lack.
• 21.11.2016: Driver "rhinefet" has been adapted to prevent the interrupts lock and the interrupt vector disable but SHARE mode using. For now it works but 19.12.2016 also there was observer the two adapters network slowing after about two week working.

Then the hardware is broken for two adapters work and for the PLC you can use only one for stable work!

• 06.09.2017: Not complete fixing in the serial driver of ICP-DAS, caused to malfunction on using more then two serial ports, seems already completely fixed in the last versions, which observed on LX-8x31.