Wiki Recent Changes

Poky migration from rocko to warrior

Thu, 08/08/2019 - 15:55

‎- Note 4: PHP causing 'unsupported FP instruction in kernel mode'

← Older revision Revision as of 21:55, 8 August 2019 (8 intermediate revisions by the same user not shown)Line 69: Line 69: =='''[SOLVED]''' Note 1: Bring back fpga char device== =='''[SOLVED]''' Note 1: Bring back fpga char device== −* /dev/xdevfg got obsolete - there's fpga manager instead which cannot load *.bit (only *.bin or *.bit.bin)+* /dev/xdevfg got retired by Xilinx - instead there's the FPGA 'Manager' which is unable to load a simple *.bit (only *.bin or *.bit.bin). * '''Solution:''' * '''Solution:''' Brought back the old driver (drivers/char/xilinx_devcfg.c and edited Kconfig and Makefile)- it works as it used to Brought back the old driver (drivers/char/xilinx_devcfg.c and edited Kconfig and Makefile)- it works as it used to Line 92: Line 92: ** Haven't found if Xilinx uses any driver for /dev/hwrng ** Haven't found if Xilinx uses any driver for /dev/hwrng ** TODO: Find out if the order of entropy sources can be changed ** TODO: Find out if the order of entropy sources can be changed +** That lag at boot is really annoying - 5-10 seconds?!! =='''-''' Note 4: PHP causing 'unsupported FP instruction in kernel mode'== =='''-''' Note 4: PHP causing 'unsupported FP instruction in kernel mode'== − +* Kernel Oops: −* '''autocampars.php''' runs at boot and sometimes causes Kernel Oops: − [ 35.872118] BUG: unsupported FP instruction in kernel mode [ 35.872118] BUG: unsupported FP instruction in kernel mode [ 35.877621] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [ 35.877621] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM Line 121: Line 120: [ 35.999422] note: php[1756] exited with preempt_count 2 [ 35.999422] note: php[1756] exited with preempt_count 2 −Unsupported floating point instruction in kernel?+* Unsupported floating point instruction in kernel? + +* Details: + - single sensor (MT9P006) on port 0 + - at boot + - after the Oops the camera seems to be operating normal + - the appearance is random (but <50%) - easier reproduced with ''reboot -f'' than power cycle + - '''autocampars.php''' runs at boot and sometimes causes this - it happens after 0 is written to initiate sensors' driver + - fpga is already programmed + - after mt9x001_pgm_initsensor() exit + - autocampars.php log seems to be ok and full + - tested with 2 boards −* Is it hardware (some faulty board? temperature based?) or kernel or php?+* Causes? + - hardware + - power board? + - system board? (probably not cause reproduced on 2 boards) + - temperature? + - kernel? + - some racing conditions? + - php? + - too old? the version 5.6.40 is EOL + - got built with some package that is too new for it? Like it won't build with newer mysql −* solution?:+* Solution?: − Took arch/vfp/vfpmodule.c from kernel 4.19+ - Took arch/vfp/vfpmodule.c from kernel 4.19. The current was 4.14. It didn't work. Roll back and check which php call caused it? Also might be a linux driver. − The current was 4.14+ - Try php 7.x.x - need to update the extension − It didn't work. Roll back and check which php call caused it?+ - Try php 5.6.31 (the one that used to work) - Opps persists + - On the bright side, at least it's not a kernel panic * TODO: keep an eye on this, because the real reason is not investigated * TODO: keep an eye on this, because the real reason is not investigated Oleg

Poky migration from rocko to warrior

Thu, 08/08/2019 - 15:55

‎- Note 4: PHP causing 'unsupported FP instruction in kernel mode'

← Older revision Revision as of 21:55, 8 August 2019 (13 intermediate revisions by the same user not shown)Line 30: Line 30: │ │ ├── jpeghead.c │ │ ├── jpeghead.c │ │ ├── klogger_393.c │ │ ├── klogger_393.c − │ │ ├── lepton.c+ │ │ ├── lepton.c − │ │ ├── mt9f002.c+ │ │ ├── mt9f002.c │ │ ├── mt9x001.c # sensor is programmed correctly │ │ ├── mt9x001.c # sensor is programmed correctly │ │ ├── multi10359.c │ │ ├── multi10359.c Line 69: Line 69: =='''[SOLVED]''' Note 1: Bring back fpga char device== =='''[SOLVED]''' Note 1: Bring back fpga char device== −* /dev/xdevfg got obsolete - there's fpga manager instead which cannot load *.bit (only *.bin or *.bit.bin)+* /dev/xdevfg got retired by Xilinx - instead there's the FPGA 'Manager' which is unable to load a simple *.bit (only *.bin or *.bit.bin). * '''Solution:''' * '''Solution:''' Brought back the old driver (drivers/char/xilinx_devcfg.c and edited Kconfig and Makefile)- it works as it used to Brought back the old driver (drivers/char/xilinx_devcfg.c and edited Kconfig and Makefile)- it works as it used to Line 92: Line 92: ** Haven't found if Xilinx uses any driver for /dev/hwrng ** Haven't found if Xilinx uses any driver for /dev/hwrng ** TODO: Find out if the order of entropy sources can be changed ** TODO: Find out if the order of entropy sources can be changed +** That lag at boot is really annoying - 5-10 seconds?!! =='''-''' Note 4: PHP causing 'unsupported FP instruction in kernel mode'== =='''-''' Note 4: PHP causing 'unsupported FP instruction in kernel mode'== − +* Kernel Oops: −* '''autocampars.php''' runs at boot and sometimes causes Kernel Oops: − [ 35.872118] BUG: unsupported FP instruction in kernel mode [ 35.872118] BUG: unsupported FP instruction in kernel mode [ 35.877621] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [ 35.877621] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM Line 121: Line 120: [ 35.999422] note: php[1756] exited with preempt_count 2 [ 35.999422] note: php[1756] exited with preempt_count 2 −Unsupported floating point instruction in kernel?+* Unsupported floating point instruction in kernel? + +* Details: + - single sensor (MT9P006) on port 0 + - at boot + - after the Oops the camera seems to be operating normal + - the appearance is random (but <50%) - easier reproduced with ''reboot -f'' than power cycle + - '''autocampars.php''' runs at boot and sometimes causes this - it happens after 0 is written to initiate sensors' driver + - fpga is already programmed + - after mt9x001_pgm_initsensor() exit + - autocampars.php log seems to be ok and full + - tested with 2 boards −* Is it hardware (some faulty board? temperature based?) or kernel or php?+* Causes? + - hardware + - power board? + - system board? (probably not cause reproduced on 2 boards) + - temperature? + - kernel? + - some racing conditions? + - php? + - too old? the version 5.6.40 is EOL + - got built with some package that is too new for it? Like it won't build with newer mysql −* solution?:+* Solution?: − Took arch/vfp/vfpmodule.c from kernel 4.19+ - Took arch/vfp/vfpmodule.c from kernel 4.19. The current was 4.14. It didn't work. Roll back and check which php call caused it? Also might be a linux driver. − The current was 4.14+ - Try php 7.x.x - need to update the extension − It didn't work. Roll back and check which php call caused it?+ - Try php 5.6.31 (the one that used to work) - Opps persists + - On the bright side, at least it's not a kernel panic * TODO: keep an eye on this, because the real reason is not investigated * TODO: keep an eye on this, because the real reason is not investigated Line 197: Line 217: - write/read works - write/read works −=='''-''' Note 12: test raw recording==+=='''[SOLVED]''' Note 12: test raw recording== * test recording on a raw partition * test recording on a raw partition +* comments: + There was a typo in camogm_align.c - it was not aligning when it should have. + CHUNK_LEADER changed to CHUNK_HEADER in line 339: + ... + if (chunks[CHUNK_HEADER].iov_len != 0){ // only if it is not TIFF + ... + +=='''[SOLVED]''' Note 13: FLIR Lepton 3.5 sensor: NULL pointer dereference== +* Solution: + Forgot to pull the latest device tree with lepton description + Old device tree didn't have i2c configuration for lepton hence something returned NULL + +* Original log: + framepars_operations elphel393-framepars@0: Configuring compressor DMA channels + circbuf elphel393-circbuf@0: Setting i2c drive mode for port 0 + circbuf elphel393-circbuf@0: register_i2c_sensor() + detect_sensors elphel393-detect_sensors@0: detect_sensors_par2addr_init(): sensorPortConfig[0].sensor[0] = 0x44 + Unable to handle kernel NULL pointer dereference at virtual address 00000000 + pgd = ecdb4000 + [00000000] *pgd=00000000 + Internal error: Oops - BUG: 5 [#1] PREEMPT SMP ARM + Modules linked in: + CPU: 1 PID: 1755 Comm: php Not tainted 4.14.0-xilinx-v2018.3 #1 + Hardware name: Xilinx Zynq Platform + task: ee80cd80 task.stack: ecda0000 + PC is at register_i2c_sensor+0x244/0x2ac + LR is at 0x0 + pc : [<c05a19e8>] lr : [<00000000>] psr: 60030013 + sp : ecda1480 ip : ecda14a8 fp : 00000000 + r10: c0ee625c r9 : 000000fc r8 : 00000000 + r7 : 00000028 r6 : ecda14a8 r5 : c0c3ca58 r4 : 00000000 + r3 : 00000000 r2 : c09b093a r1 : ee973c91 r0 : 00000000 + Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none + Control: 18c5387d Table: 2cdb404a DAC: 00000051 + Process php (pid: 1755, stack limit = 0xecda0210) + Stack: (0xecda1480 to 0xecda2000) + ... + ---[ end Kernel panic - not syncing: Fatal exception in interrupt Oleg