Hi Tony, Sometimes after reboot I am facing this message (not on poweroff + fresh boot). It repeats 4 times and then the kernel continues:
...
[ 0.087502] pinctrl core: initialized pinctrl subsystem [ 0.088814] driver_register 'reg-dummy' [ 0.092258] NET: Registered protocol family 16 [ 0.097064] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.098983] omap_hwmod: l3_main_3 using broken dt data from ocp [ 0.101014] omap_hwmod: l3_main_2 using broken dt data from ocp [ 1.504807] clock: dpll_abe_ck failed transition to 'locked' [ 2.804409] clock: dpll_abe_ck failed transition to 'locked' [ 4.104043] clock: dpll_abe_ck failed transition to 'locked' [ 5.403667] clock: dpll_abe_ck failed transition to 'locked' [ 5.406310] ------------[ cut here ]------------ [ 5.406331] WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:679 clk_disable+0x34/0x40 [ 5.406338] Modules linked in: [ 5.406354] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc4-letux+ #122 [ 5.406361] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 5.406384] [<c022789c>] (unwind_backtrace) from [<c022403c>] (show_stack+0x10/0x14) [ 5.406401] [<c022403c>] (show_stack) from [<c0517e44>] (dump_stack+0x88/0xc0) [ 5.406418] [<c0517e44>] (dump_stack) from [<c0249860>] (__warn+0xc0/0xec) [ 5.406434] [<c0249860>] (__warn) from [<c02498a8>] (warn_slowpath_null+0x1c/0x20) [ 5.406449] [<c02498a8>] (warn_slowpath_null) from [<c06e5854>] (clk_disable+0x34/0x40) [ 5.406467] [<c06e5854>] (clk_disable) from [<c0235f0c>] (_disable_clocks+0x18/0x70) [ 5.406481] [<c0235f0c>] (_disable_clocks) from [<c0237104>] (_enable.part.15+0x20c/0x248) [ 5.406494] [<c0237104>] (_enable.part.15) from [<c0e0ec94>] (_setup+0xc0/0x200) [ 5.406507] [<c0e0ec94>] (_setup) from [<c023769c>] (omap_hwmod_for_each+0x28/0x58) [ 5.406519] [<c023769c>] (omap_hwmod_for_each) from [<c0e0efc4>] (__omap_hwmod_setup_all+0x30/0x40) [ 5.406533] [<c0e0efc4>] (__omap_hwmod_setup_all) from [<c02018c0>] (do_one_initcall+0x100/0x1b8) [ 5.406549] [<c02018c0>] (do_one_initcall) from [<c0e00d28>] (do_basic_setup+0x98/0xd4) [ 5.406564] [<c0e00d28>] (do_basic_setup) from [<c0e00de8>] (kernel_init_freeable+0x84/0x124) [ 5.406581] [<c0e00de8>] (kernel_init_freeable) from [<c080381c>] (kernel_init+0x8/0x110) [ 5.406595] [<c080381c>] (kernel_init) from [<c02207c8>] (ret_from_fork+0x14/0x2c) [ 5.406657] ---[ end trace 35a58c46f27cd4a1 ]--- [ 5.406667] omap_hwmod: dmic: _wait_target_ready failed: -16 [ 5.406681] omap_hwmod: dmic: cannot be enabled for reset (3) [ 6.733460] clock: dpll_abe_ck failed transition to 'locked' [ 8.033089] clock: dpll_abe_ck failed transition to 'locked' [ 8.035732] ------------[ cut here ]------------
...
You had reported that:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/309047.h...
and there was a patch for OMAP4:
http://www.spinics.net/lists/linux-omap/msg95381.html
So what is the state for OMAP5?
Could this be the reason for all our spurious kernel hangs and problems?
BR and thanks, Nikolaus
Hi,
* H. Nikolaus Schaller hns@goldelico.com [160423 09:48]:
Hi Tony, Sometimes after reboot I am facing this message (not on poweroff + fresh boot). It repeats 4 times and then the kernel continues:
...
[ 0.087502] pinctrl core: initialized pinctrl subsystem [ 0.088814] driver_register 'reg-dummy' [ 0.092258] NET: Registered protocol family 16 [ 0.097064] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.098983] omap_hwmod: l3_main_3 using broken dt data from ocp [ 0.101014] omap_hwmod: l3_main_2 using broken dt data from ocp [ 1.504807] clock: dpll_abe_ck failed transition to 'locked' [ 2.804409] clock: dpll_abe_ck failed transition to 'locked' [ 4.104043] clock: dpll_abe_ck failed transition to 'locked' [ 5.403667] clock: dpll_abe_ck failed transition to 'locked' [ 5.406310] ------------[ cut here ]------------ [ 5.406331] WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:679 clk_disable+0x34/0x40 [ 5.406338] Modules linked in: [ 5.406354] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc4-letux+ #122 [ 5.406361] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 5.406384] [<c022789c>] (unwind_backtrace) from [<c022403c>] (show_stack+0x10/0x14) [ 5.406401] [<c022403c>] (show_stack) from [<c0517e44>] (dump_stack+0x88/0xc0) [ 5.406418] [<c0517e44>] (dump_stack) from [<c0249860>] (__warn+0xc0/0xec) [ 5.406434] [<c0249860>] (__warn) from [<c02498a8>] (warn_slowpath_null+0x1c/0x20) [ 5.406449] [<c02498a8>] (warn_slowpath_null) from [<c06e5854>] (clk_disable+0x34/0x40) [ 5.406467] [<c06e5854>] (clk_disable) from [<c0235f0c>] (_disable_clocks+0x18/0x70) [ 5.406481] [<c0235f0c>] (_disable_clocks) from [<c0237104>] (_enable.part.15+0x20c/0x248) [ 5.406494] [<c0237104>] (_enable.part.15) from [<c0e0ec94>] (_setup+0xc0/0x200) [ 5.406507] [<c0e0ec94>] (_setup) from [<c023769c>] (omap_hwmod_for_each+0x28/0x58) [ 5.406519] [<c023769c>] (omap_hwmod_for_each) from [<c0e0efc4>] (__omap_hwmod_setup_all+0x30/0x40) [ 5.406533] [<c0e0efc4>] (__omap_hwmod_setup_all) from [<c02018c0>] (do_one_initcall+0x100/0x1b8) [ 5.406549] [<c02018c0>] (do_one_initcall) from [<c0e00d28>] (do_basic_setup+0x98/0xd4) [ 5.406564] [<c0e00d28>] (do_basic_setup) from [<c0e00de8>] (kernel_init_freeable+0x84/0x124) [ 5.406581] [<c0e00de8>] (kernel_init_freeable) from [<c080381c>] (kernel_init+0x8/0x110) [ 5.406595] [<c080381c>] (kernel_init) from [<c02207c8>] (ret_from_fork+0x14/0x2c) [ 5.406657] ---[ end trace 35a58c46f27cd4a1 ]--- [ 5.406667] omap_hwmod: dmic: _wait_target_ready failed: -16 [ 5.406681] omap_hwmod: dmic: cannot be enabled for reset (3) [ 6.733460] clock: dpll_abe_ck failed transition to 'locked' [ 8.033089] clock: dpll_abe_ck failed transition to 'locked' [ 8.035732] ------------[ cut here ]------------
...
You had reported that:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/309047.h...
and there was a patch for OMAP4:
http://www.spinics.net/lists/linux-omap/msg95381.html
So what is the state for OMAP5?
I think I'm only seeing this with igepv5 on every warm reset. I don't think it happens on omap5-uevm. Most likely it depends on the u-boot revision somehow? Should be fixed for the kernel though.
Could this be the reason for all our spurious kernel hangs and problems?
For reboots at least :) For me it eventually boots with tons of errors.
Regards,
Tony
Hi,
Am 25.04.2016 um 18:20 schrieb Tony Lindgren tony@atomide.com:
Hi,
- H. Nikolaus Schaller hns@goldelico.com [160423 09:48]:
Hi Tony, Sometimes after reboot I am facing this message (not on poweroff + fresh boot). It repeats 4 times and then the kernel continues:
...
[ 0.087502] pinctrl core: initialized pinctrl subsystem [ 0.088814] driver_register 'reg-dummy' [ 0.092258] NET: Registered protocol family 16 [ 0.097064] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.098983] omap_hwmod: l3_main_3 using broken dt data from ocp [ 0.101014] omap_hwmod: l3_main_2 using broken dt data from ocp [ 1.504807] clock: dpll_abe_ck failed transition to 'locked' [ 2.804409] clock: dpll_abe_ck failed transition to 'locked' [ 4.104043] clock: dpll_abe_ck failed transition to 'locked' [ 5.403667] clock: dpll_abe_ck failed transition to 'locked' [ 5.406310] ------------[ cut here ]------------ [ 5.406331] WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:679 clk_disable+0x34/0x40 [ 5.406338] Modules linked in: [ 5.406354] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc4-letux+ #122 [ 5.406361] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 5.406384] [<c022789c>] (unwind_backtrace) from [<c022403c>] (show_stack+0x10/0x14) [ 5.406401] [<c022403c>] (show_stack) from [<c0517e44>] (dump_stack+0x88/0xc0) [ 5.406418] [<c0517e44>] (dump_stack) from [<c0249860>] (__warn+0xc0/0xec) [ 5.406434] [<c0249860>] (__warn) from [<c02498a8>] (warn_slowpath_null+0x1c/0x20) [ 5.406449] [<c02498a8>] (warn_slowpath_null) from [<c06e5854>] (clk_disable+0x34/0x40) [ 5.406467] [<c06e5854>] (clk_disable) from [<c0235f0c>] (_disable_clocks+0x18/0x70) [ 5.406481] [<c0235f0c>] (_disable_clocks) from [<c0237104>] (_enable.part.15+0x20c/0x248) [ 5.406494] [<c0237104>] (_enable.part.15) from [<c0e0ec94>] (_setup+0xc0/0x200) [ 5.406507] [<c0e0ec94>] (_setup) from [<c023769c>] (omap_hwmod_for_each+0x28/0x58) [ 5.406519] [<c023769c>] (omap_hwmod_for_each) from [<c0e0efc4>] (__omap_hwmod_setup_all+0x30/0x40) [ 5.406533] [<c0e0efc4>] (__omap_hwmod_setup_all) from [<c02018c0>] (do_one_initcall+0x100/0x1b8) [ 5.406549] [<c02018c0>] (do_one_initcall) from [<c0e00d28>] (do_basic_setup+0x98/0xd4) [ 5.406564] [<c0e00d28>] (do_basic_setup) from [<c0e00de8>] (kernel_init_freeable+0x84/0x124) [ 5.406581] [<c0e00de8>] (kernel_init_freeable) from [<c080381c>] (kernel_init+0x8/0x110) [ 5.406595] [<c080381c>] (kernel_init) from [<c02207c8>] (ret_from_fork+0x14/0x2c) [ 5.406657] ---[ end trace 35a58c46f27cd4a1 ]--- [ 5.406667] omap_hwmod: dmic: _wait_target_ready failed: -16 [ 5.406681] omap_hwmod: dmic: cannot be enabled for reset (3) [ 6.733460] clock: dpll_abe_ck failed transition to 'locked' [ 8.033089] clock: dpll_abe_ck failed transition to 'locked' [ 8.035732] ------------[ cut here ]------------
...
You had reported that:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/309047.h...
and there was a patch for OMAP4:
http://www.spinics.net/lists/linux-omap/msg95381.html
So what is the state for OMAP5?
I think I'm only seeing this with igepv5 on every warm reset. I don't think it happens on omap5-uevm. Most likely it depends on the u-boot revision somehow?
I use U-Boot 2015.10 to boot the Pyra.
And U-Boot 2013.01-gdc6238c on the uevm, where I do not see this issue.
So it looks as if newer U-Boot has a problem with newer kernel.
If I find time I could cross-check with the same 2015.10 on the UEVM.
I hope we soon have many more omap5 developers so that I have not to queue this up on my too long to-do list...
Should be fixed for the kernel though.
Could this be the reason for all our spurious kernel hangs and problems?
For reboots at least :) For me it eventually boots with tons of errors.
Well, we should simply avoid "rebooots" :)
BR, NIkolaus
* H. Nikolaus Schaller hns@goldelico.com [160425 10:43]:
Am 25.04.2016 um 18:20 schrieb Tony Lindgren tony@atomide.com: For reboots at least :) For me it eventually boots with tons of errors.
Well, we should simply avoid "rebooots" :)
FYI, looks like reboots are now working reliably with current Linux next for igepv5 with no changes to u-boot here.
Regards,
Tony
* H. Nikolaus Schaller hns@goldelico.com [160425 10:43]:
Am 25.04.2016 um 18:20 schrieb Tony Lindgren tony@atomide.com: For reboots at least :) For me it eventually boots with tons of errors.
Well, we should simply avoid "rebooots" :)
FYI, looks like current Linux next reboots OK on igepv5.
Tony
Am 17.05.2016 um 19:05 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [160425 10:43]:
Am 25.04.2016 um 18:20 schrieb Tony Lindgren tony@atomide.com: For reboots at least :) For me it eventually boots with tons of errors.
Well, we should simply avoid "rebooots" :)
FYI, looks like current Linux next reboots OK on igepv5.
Just tested on Pyra with 4.6.0
Kernel is stuck at
Starting kernel...
for a while and then starts.
But:
[ 0.170790] pinctrl core: initialized pinctrl subsystem [ 0.172154] driver_register 'reg-dummy' [ 0.175351] NET: Registered protocol family 16 [ 0.179862] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.181942] omap_hwmod: l3_main_3 using broken dt data from ocp [ 0.183672] omap_hwmod: l3_main_2 using broken dt data from ocp [ 1.557607] clock: dpll_abe_ck failed transition to 'locked' [ 2.831819] clock: dpll_abe_ck failed transition to 'locked' [ 4.108770] clock: dpll_abe_ck failed transition to 'locked' [ 5.407895] clock: dpll_abe_ck failed transition to 'locked' [ 5.410480] ------------[ cut here ]------------ [ 5.410501] WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:679 clk_disable+0x28/0x34 [ 5.410508] Modules linked in: [ 5.410523] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-letux+ #332 [ 5.410531] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 5.410548] [<c010f198>] (unwind_backtrace) from [<c010b6d4>] (show_stack+0x10/0x14) [ 5.410564] [<c010b6d4>] (show_stack) from [<c03e6990>] (dump_stack+0x98/0xd0) [ 5.410579] [<c03e6990>] (dump_stack) from [<c012f7bc>] (__warn+0xd0/0x100) [ 5.410590] [<c012f7bc>] (__warn) from [<c012f890>] (warn_slowpath_null+0x1c/0x24) [ 5.410603] [<c012f890>] (warn_slowpath_null) from [<c05aaa94>] (clk_disable+0x28/0x34) [ 5.410618] [<c05aaa94>] (clk_disable) from [<c011cbf0>] (_disable_clocks+0x18/0x70) [ 5.410631] [<c011cbf0>] (_disable_clocks) from [<c011d2d8>] (_enable+0x270/0x2b4) [ 5.410644] [<c011d2d8>] (_enable) from [<c0a0d5f4>] (_setup+0xc4/0x3ec) [ 5.410657] [<c0a0d5f4>] (_setup) from [<c011d7c0>] (omap_hwmod_for_each+0x3c/0x64) [ 5.410670] [<c011d7c0>] (omap_hwmod_for_each) from [<c0a0dc50>] (__omap_hwmod_setup_all+0x30/0x40) [ 5.410683] [<c0a0dc50>] (__omap_hwmod_setup_all) from [<c01018e0>] (do_one_initcall+0x100/0x1b8) [ 5.410696] [<c01018e0>] (do_one_initcall) from [<c0a00d74>] (kernel_init_freeable+0x120/0x1ec) [ 5.410711] [<c0a00d74>] (kernel_init_freeable) from [<c06c2bcc>] (kernel_init+0x8/0x110) [ 5.410725] [<c06c2bcc>] (kernel_init) from [<c01070b0>] (ret_from_fork+0x14/0x24) [ 5.410782] ---[ end trace 8d6b9260cd66cb9a ]--- [ 5.410792] omap_hwmod: dmic: _wait_target_ready failed: -16 [ 5.410805] omap_hwmod: dmic: cannot be enabled for reset (3) [ 6.718804] clock: dpll_abe_ck failed transition to 'locked' [ 8.017926] clock: dpll_abe_ck failed transition to 'locked' [ 8.020498] ------------[ cut here ]------------ [ 8.020512] WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:679 clk_disable+0x28/0x34 [ 8.020519] Modules linked in: [ 8.020532] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.6.0-letux+ #332 [ 8.020539] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 8.020554] [<c010f198>] (unwind_backtrace) from [<c010b6d4>] (show_stack+0x10/0x14) [ 8.020567] [<c010b6d4>] (show_stack) from [<c03e6990>] (dump_stack+0x98/0xd0) [ 8.020579] [<c03e6990>] (dump_stack) from [<c012f7bc>] (__warn+0xd0/0x100) [ 8.020591] [<c012f7bc>] (__warn) from [<c012f890>] (warn_slowpath_null+0x1c/0x24) [ 8.020604] [<c012f890>] (warn_slowpath_null) from [<c05aaa94>] (clk_disable+0x28/0x34) [ 8.020618] [<c05aaa94>] (clk_disable) from [<c011cbf0>] (_disable_clocks+0x18/0x70) [ 8.020631] [<c011cbf0>] (_disable_clocks) from [<c011d2d8>] (_enable+0x270/0x2b4) [ 8.020643] [<c011d2d8>] (_enable) from [<c0a0d5f4>] (_setup+0xc4/0x3ec) [ 8.020656] [<c0a0d5f4>] (_setup) from [<c011d7c0>] (omap_hwmod_for_each+0x3c/0x64) [ 8.020669] [<c011d7c0>] (omap_hwmod_for_each) from [<c0a0dc50>] (__omap_hwmod_setup_all+0x30/0x40) [ 8.020681] [<c0a0dc50>] (__omap_hwmod_setup_all) from [<c01018e0>] (do_one_initcall+0x100/0x1b8) [ 8.020694] [<c01018e0>] (do_one_initcall) from [<c0a00d74>] (kernel_init_freeable+0x120/0x1ec) [ 8.020706] [<c0a00d74>] (kernel_init_freeable) from [<c06c2bcc>] (kernel_init+0x8/0x110) [ 8.020719] [<c06c2bcc>] (kernel_init) from [<c01070b0>] (ret_from_fork+0x14/0x24) [ 8.020728] ---[ end trace 8d6b9260cd66cb9b ]--- [ 8.020736] omap_hwmod: mcbsp1: _wait_target_ready failed: -16 [ 8.020748] omap_hwmod: mcbsp1: cannot be enabled for reset (3) [ 9.302177] clock: dpll_abe_ck failed transition to 'locked' [ 10.601353] clock: dpll_abe_ck failed transition to 'locked' [ 10.603939] ------------[ cut here ]------------
And after ~20 seconds it is finally stuck.
So it is better, but not yet 100% solved. Someone with more spare time than me can finally fix it (as soon as we have more devices to test on).
BR, Nikolaus
Am 26.05.2016 um 16:55 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 17.05.2016 um 19:05 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [160425 10:43]:
Am 25.04.2016 um 18:20 schrieb Tony Lindgren tony@atomide.com: For reboots at least :) For me it eventually boots with tons of errors.
Well, we should simply avoid "rebooots" :)
FYI, looks like current Linux next reboots OK on igepv5.
Just tested on Pyra with 4.6.0
Kernel is stuck at
Starting kernel...
for a while and then starts.
means ~15 seconds until [ 0.000000] begins. Usually it takes <2 seconds.
But:
[ 0.170790] pinctrl core: initialized pinctrl subsystem [ 0.172154] driver_register 'reg-dummy' [ 0.175351] NET: Registered protocol family 16 [ 0.179862] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.181942] omap_hwmod: l3_main_3 using broken dt data from ocp [ 0.183672] omap_hwmod: l3_main_2 using broken dt data from ocp [ 1.557607] clock: dpll_abe_ck failed transition to 'locked' [ 2.831819] clock: dpll_abe_ck failed transition to 'locked' [ 4.108770] clock: dpll_abe_ck failed transition to 'locked' [ 5.407895] clock: dpll_abe_ck failed transition to 'locked' [ 5.410480] ------------[ cut here ]------------ [ 5.410501] WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:679 clk_disable+0x28/0x34 [ 5.410508] Modules linked in: [ 5.410523] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-letux+ #332 [ 5.410531] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 5.410548] [<c010f198>] (unwind_backtrace) from [<c010b6d4>] (show_stack+0x10/0x14) [ 5.410564] [<c010b6d4>] (show_stack) from [<c03e6990>] (dump_stack+0x98/0xd0) [ 5.410579] [<c03e6990>] (dump_stack) from [<c012f7bc>] (__warn+0xd0/0x100) [ 5.410590] [<c012f7bc>] (__warn) from [<c012f890>] (warn_slowpath_null+0x1c/0x24) [ 5.410603] [<c012f890>] (warn_slowpath_null) from [<c05aaa94>] (clk_disable+0x28/0x34) [ 5.410618] [<c05aaa94>] (clk_disable) from [<c011cbf0>] (_disable_clocks+0x18/0x70) [ 5.410631] [<c011cbf0>] (_disable_clocks) from [<c011d2d8>] (_enable+0x270/0x2b4) [ 5.410644] [<c011d2d8>] (_enable) from [<c0a0d5f4>] (_setup+0xc4/0x3ec) [ 5.410657] [<c0a0d5f4>] (_setup) from [<c011d7c0>] (omap_hwmod_for_each+0x3c/0x64) [ 5.410670] [<c011d7c0>] (omap_hwmod_for_each) from [<c0a0dc50>] (__omap_hwmod_setup_all+0x30/0x40) [ 5.410683] [<c0a0dc50>] (__omap_hwmod_setup_all) from [<c01018e0>] (do_one_initcall+0x100/0x1b8) [ 5.410696] [<c01018e0>] (do_one_initcall) from [<c0a00d74>] (kernel_init_freeable+0x120/0x1ec) [ 5.410711] [<c0a00d74>] (kernel_init_freeable) from [<c06c2bcc>] (kernel_init+0x8/0x110) [ 5.410725] [<c06c2bcc>] (kernel_init) from [<c01070b0>] (ret_from_fork+0x14/0x24) [ 5.410782] ---[ end trace 8d6b9260cd66cb9a ]--- [ 5.410792] omap_hwmod: dmic: _wait_target_ready failed: -16 [ 5.410805] omap_hwmod: dmic: cannot be enabled for reset (3) [ 6.718804] clock: dpll_abe_ck failed transition to 'locked' [ 8.017926] clock: dpll_abe_ck failed transition to 'locked' [ 8.020498] ------------[ cut here ]------------ [ 8.020512] WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:679 clk_disable+0x28/0x34 [ 8.020519] Modules linked in: [ 8.020532] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.6.0-letux+ #332 [ 8.020539] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 8.020554] [<c010f198>] (unwind_backtrace) from [<c010b6d4>] (show_stack+0x10/0x14) [ 8.020567] [<c010b6d4>] (show_stack) from [<c03e6990>] (dump_stack+0x98/0xd0) [ 8.020579] [<c03e6990>] (dump_stack) from [<c012f7bc>] (__warn+0xd0/0x100) [ 8.020591] [<c012f7bc>] (__warn) from [<c012f890>] (warn_slowpath_null+0x1c/0x24) [ 8.020604] [<c012f890>] (warn_slowpath_null) from [<c05aaa94>] (clk_disable+0x28/0x34) [ 8.020618] [<c05aaa94>] (clk_disable) from [<c011cbf0>] (_disable_clocks+0x18/0x70) [ 8.020631] [<c011cbf0>] (_disable_clocks) from [<c011d2d8>] (_enable+0x270/0x2b4) [ 8.020643] [<c011d2d8>] (_enable) from [<c0a0d5f4>] (_setup+0xc4/0x3ec) [ 8.020656] [<c0a0d5f4>] (_setup) from [<c011d7c0>] (omap_hwmod_for_each+0x3c/0x64) [ 8.020669] [<c011d7c0>] (omap_hwmod_for_each) from [<c0a0dc50>] (__omap_hwmod_setup_all+0x30/0x40) [ 8.020681] [<c0a0dc50>] (__omap_hwmod_setup_all) from [<c01018e0>] (do_one_initcall+0x100/0x1b8) [ 8.020694] [<c01018e0>] (do_one_initcall) from [<c0a00d74>] (kernel_init_freeable+0x120/0x1ec) [ 8.020706] [<c0a00d74>] (kernel_init_freeable) from [<c06c2bcc>] (kernel_init+0x8/0x110) [ 8.020719] [<c06c2bcc>] (kernel_init) from [<c01070b0>] (ret_from_fork+0x14/0x24) [ 8.020728] ---[ end trace 8d6b9260cd66cb9b ]--- [ 8.020736] omap_hwmod: mcbsp1: _wait_target_ready failed: -16 [ 8.020748] omap_hwmod: mcbsp1: cannot be enabled for reset (3) [ 9.302177] clock: dpll_abe_ck failed transition to 'locked' [ 10.601353] clock: dpll_abe_ck failed transition to 'locked' [ 10.603939] ------------[ cut here ]------------
And after ~20 seconds it is finally stuck.
So it is better, but not yet 100% solved. Someone with more spare time than me can finally fix it (as soon as we have more devices to test on).
BR, Nikolaus
BTW: this state survives a board reset. I have to poweroff by pressing the Palmas connected power button for 10 seconds and then power on.
BR, Nikolaus
* H. Nikolaus Schaller hns@goldelico.com [160526 08:00]:
Am 26.05.2016 um 16:55 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 17.05.2016 um 19:05 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [160425 10:43]:
Am 25.04.2016 um 18:20 schrieb Tony Lindgren tony@atomide.com: For reboots at least :) For me it eventually boots with tons of errors.
Well, we should simply avoid "rebooots" :)
FYI, looks like current Linux next reboots OK on igepv5.
Just tested on Pyra with 4.6.0
Kernel is stuck at
Starting kernel...
for a while and then starts.
means ~15 seconds until [ 0.000000] begins. Usually it takes <2 seconds.
Yeah strange, I'm only seeing this now if I reboot to the old kernel from new kernel or the other way around I forgot.
Regards,
Tony
Hi,
Am 27.05.2016 um 18:38 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [160526 08:00]:
Am 26.05.2016 um 16:55 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 17.05.2016 um 19:05 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [160425 10:43]:
Am 25.04.2016 um 18:20 schrieb Tony Lindgren tony@atomide.com: For reboots at least :) For me it eventually boots with tons of errors.
Well, we should simply avoid "rebooots" :)
FYI, looks like current Linux next reboots OK on igepv5.
Just tested on Pyra with 4.6.0
Kernel is stuck at
Starting kernel...
for a while and then starts.
means ~15 seconds until [ 0.000000] begins. Usually it takes <2 seconds.
Yeah strange, I'm only seeing this now if I reboot to the old kernel from new kernel or the other way around I forgot.
I do not see it on the EVM, but on our Pyra hardware. This is strange since I use the same U-Boot (except for minor patches and nothing clock related) and the same uImage. Well, DT differs, but both are based on omap5-common.dtsi.
So there is something in the Pyra hardware which "remembers" the previous state.
Maybe we have a slightly different Palmas variant? I don't know such details.
BR, Nikolaus
* H. Nikolaus Schaller hns@goldelico.com [160530 06:31]:
I do not see it on the EVM, but on our Pyra hardware. This is strange since I use the same U-Boot (except for minor patches and nothing clock related) and the same uImage. Well, DT differs, but both are based on omap5-common.dtsi.
So there is something in the Pyra hardware which "remembers" the previous state.
Maybe we have a slightly different Palmas variant? I don't know such details.
No idea.. With omapconf you can diff the registers between two different states quite easily though.
Regards,
Tony
Hi Tony,
Am 31.05.2016 um 18:21 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [160530 06:31]:
I do not see it on the EVM, but on our Pyra hardware. This is strange since I use the same U-Boot (except for minor patches and nothing clock related) and the same uImage. Well, DT differs, but both are based on omap5-common.dtsi.
So there is something in the Pyra hardware which "remembers" the previous state.
Maybe we have a slightly different Palmas variant? I don't know such details.
No idea.. With omapconf you can diff the registers between two different states quite easily though.
Wow, that sounds cool!
I will try to install the Ubuntu package on Debian. But compiling from source doesn't look problematic either.
BR, Nikolaus
* H. Nikolaus Schaller hns@goldelico.com [160531 09:32]:
Hi Tony,
Am 31.05.2016 um 18:21 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [160530 06:31]:
I do not see it on the EVM, but on our Pyra hardware. This is strange since I use the same U-Boot (except for minor patches and nothing clock related) and the same uImage. Well, DT differs, but both are based on omap5-common.dtsi.
So there is something in the Pyra hardware which "remembers" the previous state.
Maybe we have a slightly different Palmas variant? I don't know such details.
Hmm I think this reboot issue might be only happening when booting from MMC? Or eMMC only? I'm not seeing it with tftp + NFSroot I think..
Tony
Am 02.06.2016 um 02:00 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [160531 09:32]:
Hi Tony,
Am 31.05.2016 um 18:21 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [160530 06:31]:
I do not see it on the EVM, but on our Pyra hardware. This is strange since I use the same U-Boot (except for minor patches and nothing clock related) and the same uImage. Well, DT differs, but both are based on omap5-common.dtsi.
So there is something in the Pyra hardware which "remembers" the previous state.
Maybe we have a slightly different Palmas variant? I don't know such details.
Hmm I think this reboot issue might be only happening when booting from MMC? Or eMMC only? I'm not seeing it with tftp + NFSroot I think..
We currently boot my MMC only (eMMC works but needs some setup nobody has done so far).
Could that mean that some MMC clock isn't "rebooted" properly? But U-Boot starts each time and does its own MMC drivers.
BR, Nikolaus
Am 31.05.2016 um 18:21 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [160530 06:31]:
I do not see it on the EVM, but on our Pyra hardware. This is strange since I use the same U-Boot (except for minor patches and nothing clock related) and the same uImage. Well, DT differs, but both are based on omap5-common.dtsi.
So there is something in the Pyra hardware which "remembers" the previous state.
Maybe we have a slightly different Palmas variant? I don't know such details.
No idea.. With omapconf you can diff the registers between two different states quite easily though.
It was easy to git clone + make on some board (because I just had it connected I did on a BeagleBoard XM).
But all I can get is:
!!! OUPS... MEMORY ERROR @ 0x00000000 !!! Are you sure that: MEMORY ADDRESS IS VALID? TARGETED MODULE IS CLOCKED?
And I was not able to get some --help from it. Is it possible that omapconf is not compatible with a 4.7-rc1 kernel?
BR, Nikolaus
Am 02.06.2016 um 09:51 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 31.05.2016 um 18:21 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [160530 06:31]:
I do not see it on the EVM, but on our Pyra hardware. This is strange since I use the same U-Boot (except for minor patches and nothing clock related) and the same uImage. Well, DT differs, but both are based on omap5-common.dtsi.
So there is something in the Pyra hardware which "remembers" the previous state.
Maybe we have a slightly different Palmas variant? I don't know such details.
No idea.. With omapconf you can diff the registers between two different states quite easily though.
It was easy to git clone + make on some board (because I just had it connected, I did experiment on a BeagleBoard XM).
But all I can get is:
!!! OUPS... MEMORY ERROR @ 0x00000000 !!! Are you sure that: MEMORY ADDRESS IS VALID? TARGETED MODULE IS CLOCKED?
And I was not able to get some --help from it. Is it possible that omapconf is not compatible with a 4.7-rc1 kernel?
Here is real console log:
root@gta04:~/omapconf# ./omapconf --help [ 7917.198059] Unhandled fault: external abort on non-linefetch (0x1018) at 0xb6e64204 [ 7917.206176] pgd = d4a4c000 [ 7917.209075] [b6e64204] *pgd=9c359831, *pte=4a002303, *ppte=4a002a33 [ 7917.215850] Address Hole seen by MPU at address 4a002200 [ 7917.221557] ------------[ cut here ]------------ [ 7917.226470] WARNING: CPU: 0 PID: 13300 at drivers/bus/omap_l3_smx.c:166 omap3_l3_app_irq+0xe0/0x124 [ 7917.235992] Modules linked in: ipv6 bluetooth autofs4 usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs smsc95xx usbnet omapdrm drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea drm panel_tpo_td028ttec1 connector_analog_tv bq27xxx_battery snd_soc_omap_twl4030 w2sg0004 twl4030_madc_hwmon omap3_isp leds_gpio extcon_gpio pwm_bl videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_core v4l2_common snd_soc_omap_mcbsp snd_soc_omap w1_bq27000 snd_pcm_dmaengine videodev media omap_hdq omap2430 leds_tca6507 tsc2007 phy_twl4030_usb musb_hdrc gpio_twl4030 rtc_twl snd_soc_twl4030 twl4030_pwrbutton twl4030_madc twl4030_keypad twl4030_charger ehci_omap omapdss [ 7917.303558] CPU: 0 PID: 13300 Comm: omapconf Tainted: G W 4.7.0-rc1-letux+ #353 [ 7917.312469] Hardware name: Generic OMAP36xx (Flattened Device Tree) [ 7917.319122] [<c010f180>] (unwind_backtrace) from [<c010b6d8>] (show_stack+0x10/0x14) [ 7917.327331] [<c010b6d8>] (show_stack) from [<c03ec930>] (dump_stack+0x98/0xd0) [ 7917.334991] [<c03ec930>] (dump_stack) from [<c012f9f0>] (__warn+0xd0/0x100) [ 7917.342376] [<c012f9f0>] (__warn) from [<c012fac4>] (warn_slowpath_null+0x1c/0x24) [ 7917.350372] [<c012fac4>] (warn_slowpath_null) from [<c04158c0>] (omap3_l3_app_irq+0xe0/0x124) [ 7917.359405] [<c04158c0>] (omap3_l3_app_irq) from [<c018dd40>] (handle_irq_event_percpu+0x180/0x4c4) [ 7917.368957] [<c018dd40>] (handle_irq_event_percpu) from [<c018e0bc>] (handle_irq_event+0x38/0x5c) [ 7917.378356] [<c018e0bc>] (handle_irq_event) from [<c0191168>] (handle_level_irq+0xe4/0x124) [ 7917.387176] [<c0191168>] (handle_level_irq) from [<c018d2dc>] (generic_handle_irq+0x18/0x28) [ 7917.396118] [<c018d2dc>] (generic_handle_irq) from [<c018d600>] (__handle_domain_irq+0xa0/0xe0) [ 7917.405303] [<c018d600>] (__handle_domain_irq) from [<c06d5e78>] (__irq_svc+0x58/0x98) [ 7917.413696] [<c06d5e78>] (__irq_svc) from [<c010b098>] (do_work_pending+0x50/0xb4) [ 7917.421722] [<c010b098>] (do_work_pending) from [<c0107068>] (slow_work_pending+0xc/0x20) [ 7917.430358] ---[ end trace a1044efbf7733748 ]---
!!! OUPS... MEMORY ERROR @ 0x00000000 !!! Are you sure that: MEMORY ADDRESS IS VALID? TARGETED MODULE IS CLOCKED?
root@gta04:~/omapconf#
* H. Nikolaus Schaller hns@goldelico.com [160602 00:54]:
!!! OUPS... MEMORY ERROR @ 0x00000000 !!! Are you sure that: MEMORY ADDRESS IS VALID? TARGETED MODULE IS CLOCKED?
And I was not able to get some --help from it. Is it possible that omapconf is not compatible with a 4.7-rc1 kernel?
It just uses /dev/mem.. Hmm you're trying to read physical address 0 :) Doing omapconf --help on my omap5-uevm produces tons of help options.
Also check out Tomi Valkeinen's rwmem on github, that's handy for checking a single register.
Tony
Hi Tony,
Am 02.06.2016 um 18:22 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [160602 00:54]:
!!! OUPS... MEMORY ERROR @ 0x00000000 !!! Are you sure that: MEMORY ADDRESS IS VALID? TARGETED MODULE IS CLOCKED?
And I was not able to get some --help from it. Is it possible that omapconf is not compatible with a 4.7-rc1 kernel?
It just uses /dev/mem.. Hmm you're trying to read physical address 0 :) Doing omapconf --help on my omap5-uevm produces tons of help options.
No idea why it fails. I just compiled from latest git sources.
If I find spare time (what is that?) I can try it on the 5432EVM (I tested on BB XM) and with strace.
Also check out Tomi Valkeinen's rwmem on github, that's handy for checking a single register.
We have devmem2 [1] which is quite similar.
BR, NIkolaus
[1]: https://github.com/hackndev/tools/blob/master/devmem2.c
On 02/06/16 19:54, H. Nikolaus Schaller wrote:
Also check out Tomi Valkeinen's rwmem on github, that's handy for checking a single register.
We have devmem2 [1] which is quite similar.
It's similar the same way as a paper knife is similar to a Leatherman multi-tool ;).
Tomi
On Thu, May 26, 2016 at 04:55:24PM +0200, H. Nikolaus Schaller wrote:
Just tested on Pyra with 4.6.0
Are you referring to vanilla mainline kernel?
I'd like to follow the kernel development for Pyra. I have checked git://git.openpandora.org/pyra-kernel.git , but all branches here seem to be abandoned. Is there a git repo accumulating changes before they are accepted into mainline? Or everything just gets posted to LKML and accumulates in linux-next?
Also feel free to ask me for some "janitor" work for Pyra kernel. I have some experience with kernel development (https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?qt=aut...)
Hi Andrey,
Am 26.05.2016 um 21:26 schrieb Andrey Utkin andrey_utkin@fastmail.com:
On Thu, May 26, 2016 at 04:55:24PM +0200, H. Nikolaus Schaller wrote:
Just tested on Pyra with 4.6.0
Are you referring to vanilla mainline kernel?
I'd like to follow the kernel development for Pyra. I have checked git://git.openpandora.org/pyra-kernel.git , but all branches here seem to be abandoned.
There is no pyra-only kernel project any more and I can't even find a pyra-kernel.git on http://git.openpandora.org
But the ssh access seems to still work so I have fixed my git mirror script. So if you git clone git://git.openpandora.org/pyra-kernel.git it should be more up to date now.
Is there a git repo accumulating changes before they are accepted into mainline?
Yes, the letux-kernel is the key development project and also supports the Pyra (as well as OpenPandora, Pandaboard, BeagleBoard, BeagleBone, GTA04, OMAP5EVM):
http://projects.goldelico.com/p/gta04-kernel/
Or everything just gets posted to LKML and accumulates in linux-next?
Well, not everything is already mature enough for LKML and some of our ideas have even been heavily rejected. So this unfortunately requires to keep our own fork to have a useable kernel for debugging and operation.
This project was already initiated some years ago for the Letux/GTA04 and it was easier to add support for the Pyra hardware to the Letux kernel project than running an independent kernel tree focussing on Pyra only since they share a lot of device drivers.
The development model is that the letux-base branch is updated almost every week to follow linus/master:
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/letux-b...
It already includes some basic diffs to linus/master mainly for historic reasons.
On top of that are approx. 25 feature branches (work/xxx) where the work piles up:
http://git.goldelico.com/?p=gta04-kernel.git;a=heads
This is rebased every week on top of letux-base. And all features are finally merged on top of letux-base so that a new letux-4.x appears.
So the idea is to get rid of this in the long run, but follow linus/master until we have achieved that.
Also feel free to ask me for some "janitor" work for Pyra kernel. I have some experience with kernel development (https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?qt=aut...)
Oh nice! We definitively need help to get the patches in the feature branches into kernel.org
We also have an issue tracker so that you can see what we know as missing or buggy:
http://projects.goldelico.com/p/gta04-kernel/issues/
BR, Nikolaus
On Thu, May 26, 2016 at 10:16:00PM +0200, H. Nikolaus Schaller wrote:
Oh nice! We definitively need help to get the patches in the feature branches into kernel.org
Will do my best to be helpful. Thanks for great introduction, I have fetched the correct git repo and will review what is where. I am andrey_utkin at Freenode IRC. I look at #dragonbox-pyra from time to time, but if there's dedicated development room, I'd like to know about it.
We also have an issue tracker so that you can see what we know as missing or buggy:
My account registration fails when I submit my password:
The server encountered an unexpected condition which prevented it from fulfilling your request.
An email has been sent to the administrators, we will correct this error as soon as possible. Thank you for your comprehension.
500 - Internal Server Error
I'd like at last to have notifications from this issue tracker.
Hi Andrey,
Am 26.05.2016 um 22:58 schrieb Andrey Utkin andrey_utkin@fastmail.com:
On Thu, May 26, 2016 at 10:16:00PM +0200, H. Nikolaus Schaller wrote:
Oh nice! We definitively need help to get the patches in the feature branches into kernel.org
Will do my best to be helpful. Thanks for great introduction, I have fetched the correct git repo and will review what is where. I am andrey_utkin at Freenode IRC. I look at #dragonbox-pyra from time to time, but if there's dedicated development room, I'd like to know about it.
I don't think that the kernel team currently uses IRC. Mainly there is this mailing list for pyra specific discussions and there is also
http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
We also have an issue tracker so that you can see what we know as missing or buggy:
My account registration fails when I submit my password:
The server encountered an unexpected condition which prevented it from fulfilling your request.
An email has been sent to the administrators,
I have received a stack trace... And it tells me that some "pear" package (File_Passwd) is missing. But it is installed. So it must be something else I have to dig into (search path most likely).
we will correct this error as soon as possible. Thank you for your comprehension.
500 - Internal Server Error
I'd like at last to have notifications from this issue tracker.
Yes, that would be helpful of course.
BR, Nikolaus
Yeah that was suppose to be the dedicated development IRC channel, it tends to go off topic a lot.
On Thu, May 26, 2016 at 4:58 PM, Andrey Utkin andrey_utkin@fastmail.com wrote:
On Thu, May 26, 2016 at 10:16:00PM +0200, H. Nikolaus Schaller wrote:
Oh nice! We definitively need help to get the patches in the feature
branches into kernel.org
Will do my best to be helpful. Thanks for great introduction, I have fetched the correct git repo and will review what is where. I am andrey_utkin at Freenode IRC. I look at #dragonbox-pyra from time to time, but if there's dedicated development room, I'd like to know about it.
We also have an issue tracker so that you can see what we know as
missing or buggy:
My account registration fails when I submit my password:
The server encountered an unexpected condition which prevented it from fulfilling your request.
An email has been sent to the administrators, we will correct this error as soon as possible. Thank you for your comprehension.
500 - Internal Server Error
I'd like at last to have notifications from this issue tracker. _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Am 27.05.2016 um 00:31 schrieb aTc atc@k-n-p.org:
On 05/26/2016 11:16 PM, Roy Gillotti wrote:
Yeah that was suppose to be the dedicated development IRC channel, it tends to go off topic a lot.
There now is #dragonbox-dev on freenode, that should be a bit less noisy.
Just FYI: I am on no IRC channel.
The reason is that I run multiple projects in parallel so that I can't hang around and wait for pings or "interesting topics" to comment on.
I am easily reached by e-mail or mailing lists.
BR, Nikolaus
Am Thu, 26 May 2016 23:58:30 +0300 hat Andrey Utkin andrey_utkin@fastmail.com geschrieben:
Hi Andrey,
thanks for your offer for help and welcome :D
As Nikolaus is not on IRC, it's great having someone else working on the kernel who is on IRC.
So we can discuss there and work on patches and send the final results to Nikolaus.
If you really want to work more on that, I should also be able to send you a prototype unit at some time.
On Thu, May 26, 2016 at 10:16:00PM +0200, H. Nikolaus Schaller wrote:
Oh nice! We definitively need help to get the patches in the feature branches into kernel.org
Will do my best to be helpful. Thanks for great introduction, I have fetched the correct git repo and will review what is where. I am andrey_utkin at Freenode IRC. I look at #dragonbox-pyra from time to time, but if there's dedicated development room, I'd like to know about it.
We also have an issue tracker so that you can see what we know as missing or buggy:
My account registration fails when I submit my password:
The server encountered an unexpected condition which prevented it from fulfilling your request.
An email has been sent to the administrators, we will correct this error as soon as possible. Thank you for your comprehension.
500 - Internal Server Error
I'd like at last to have notifications from this issue tracker. _______________________________________________ Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Hi,
Am 27.05.2016 um 11:09 schrieb Michael Mrozek EvilDragon@openpandora.org:
Am Thu, 26 May 2016 23:58:30 +0300 hat Andrey Utkin andrey_utkin@fastmail.com geschrieben:
Hi Andrey,
thanks for your offer for help and welcome :D
As Nikolaus is not on IRC, it's great having someone else working on the kernel who is on IRC.
Well, I would say the most important thing is to have someone more working on the kernel :)
The second important factor is to communicate and exchange ideas (by whatever means).
IRC is IMHO not a prerequisite to be successful. It is just another choice for a tool amongst others for communication.
In fact I have never been missing IRC for kernel work or any other project... And as mentioned earlier, I have no spare time to hang on several IRC channels.
Just send me an e-mail and I will respond within minutes if I am available (20 min this time).
So we can discuss there and work on patches and send the final results to Nikolaus.
There are never final results :) Only if they arrive at kernel.org in linux/next...
Also important will be to provide write access to the git repo (but that does not work for the strange server error).
If you really want to work more on that, I should also be able to send you a prototype unit at some time.
Or it could be useful to start with an OMAP5432EVM or IGEP5 board so that kernel work is not blocked by hardware availability.
On Thu, May 26, 2016 at 10:16:00PM +0200, H. Nikolaus Schaller wrote:
Oh nice! We definitively need help to get the patches in the feature branches into kernel.org
Will do my best to be helpful. Thanks for great introduction, I have fetched the correct git repo and will review what is where. I am andrey_utkin at Freenode IRC. I look at #dragonbox-pyra from time to time, but if there's dedicated development room, I'd like to know about it.
We also have an issue tracker so that you can see what we know as missing or buggy:
My account registration fails when I submit my password:
The server encountered an unexpected condition which prevented it from fulfilling your request.
An email has been sent to the administrators, we will correct this error as soon as possible. Thank you for your comprehension.
500 - Internal Server Error
I am still searching for that issue but with no success. PEAR is installed (and used in other locations of Indefero, e.g. sending out notification mails).
Indefero search path also includes the right directory. Even cleaning the caches and restarting the server didn't help yet.
BR, Nikolaus
Hi Andrey,
Am 26.05.2016 um 22:58 schrieb Andrey Utkin andrey_utkin@fastmail.com:
My account registration fails when I submit my password:
The server encountered an unexpected condition which prevented it from fulfilling your request.
An email has been sent to the administrators, we will correct this error as soon as possible. Thank you for your comprehension.
500 - Internal Server Error
I think I have found the server bug and it seems to work now! Please try.
The reason is that the server has (for unknown reasons) two different subdirectories where Pear packages are installed to (/usr/local/lib/php and /usr/local/pear/share/pear). And it depends on the default search path and Indefero search path extensions which one is used.
So my installation attempts did install to the new packages to the unused directory.
Now back to Pyra-HW and kernel...
BR, Nikolaus