ENVIRONMENT: Fish River Island 2 (FRI2) STEPS TO REPRODUCE: 1. Launch connman-properties after system booting 2. choose "offline mode" and check the connection of all network interfaces EXPECTED OUTCOME: All connection should be off after clicking "offline mode" . ACTUAL OUTCOME: eth0 is is still active and up after setting Offline mode in connman. Ping is working, ssh connections also. Cheers, Ionut C
Cristian, can you dig a bit more here and help identify where and how this is failing? For example, is connman issuing an "ifdown eth0" and that doesn't work? Does it work from the command line? Does connman use another mechanism entirely? This doesn't sound BSP specific, but apparently it was only on the FRI2 that it occurred, so we need to find something more FRI2 specific than just connman.
Hello Darren, all, I have tested a similar scenario on qemux86-64, without any issues. So this seems to be a HW specific issue. Investigation continues.
Beside the original issue, during tests, linux on fri2 froze twice, while changing settings in connman-gnome.
I have built my own core-image-sato with: poky head: commit db80f796e78746014a0f9497638e5c6fd2953ef0 Refs: master, <origin/HEAD>, <origin/master>, 1.6_M4-595-gdb80f79 Author: Denys Dmytriyenko <denys@ti.com> AuthorDate: Thu Apr 10 04:02:13 2014 -0400 Commit: Richard Purdie <richard.purdie@linuxfoundation.org> CommitDate: Thu Apr 10 10:13:55 2014 +0100 README.hardware: update with Texas Instruments Beaglebone instructions Replaces outdated Beagleboard instructions with Beaglebone Black (and White). (From meta-yocto rev: 283b51b0149f7e5838bd1c8465451897baf0bf44) Signed-off-by: Denys Dmytriyenko <denys@ti.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> meta-intel head: commit db84acfc8d9ed8dccd4a79de39fee337bc729662 Refs: master, <origin/HEAD>, <origin/master>, 1.6_M2-92-gdb84acf Author: Darren Hart <dvhart@linux.intel.com> AuthorDate: Tue Apr 1 15:34:57 2014 -0700 Commit: Darren Hart <dvhart@linux.intel.com> CommitDate: Wed Apr 9 09:51:19 2014 -0700 intel-common: Set common PACKAGE_ARCH for linux-yocto-rt The linux-yocto/meta support is now available for the intel-core* machines and the preempt-rt kernel. Enable the common PACKAGE_ARCH in intel-common-pkgarch.inc. Signed-off-by: Darren Hart <dvhart@linux.intel.com> target: fri2-noemgd image: core-image-sato We couldn't not make that image install on two different FRI2.
Created attachment 1904 [details] connmanctl enable offline on qemux86-64 execution trace
Created attachment 1905 [details] connmanctl enable offline on FRI2 execution trace
Created attachment 1906 [details] running connmanctl and other info log Running connmanctl and other info log on FRI2.
Trace execution paths for: connnmanctl enable offline command looks pretty different on qemux86-64 and FRI2. Can someone provide some insights into what is happening?
@Alex.Palalau: Can you please test this issue on FRI2 with MACHINE=fri2-noemgd? It seems that in that case the linux kernel would be 3.14, offering a more similar environment with qemux86-64.
Plase note that issuing: ifconfig eth0 down works correctly on FRI2.
Investigation ongoing. I'm going to narrow down the scenarios for the mentioned behavior.
This seems to be a regression of bug 4237. Also present on crownbay with poky & meta-intel 1.6 M5 RC4.
And there is also this bug 3804 which has a fix.
Hi Corneliu, I am not sure that bug 4237 and bug 3804 are related to this bug.
Investigation continues.
Cristina will retest.
(In reply to comment #16) > Cristina will retest. It reproduces with genericx86 on Lenovo S10-3. on 1.8_M4.rc1. The network is set to DHCP and when setting to OfflineMode in System Configuration: - ping works from another host to the tested device - ssh doesn't work from another host to the tested device - ifconfig on the tested device shows eth0 Didn't reproduce on qemux86-64 though
Hi Alex, Cristina, Is this issue reproducible on any other real hardware (except for genericx86)? We need to clearly define this issue, in order to define the root cause. Thanks, Cristian
The issue cannot be reproduced on NUC for 1.8_M4.rc1, building a core-image-sato-sdk for an intel-core-i7-64 BSP. On the other hand for both Lenovo S10-3 and Dell Inspiron 5520 the issue was reproduced, having the same premises as upwards (image type and BSP). Thanks, Cristina
As a correction to my latest comment, Lenovo S10-3 had a core-image-sato-sdk for genericx86. BR, Cristina
Created attachment 2469 [details] Lenovo S10-3 system log Output of system log for Lenovo S10-3 with genericx86.
Cristina, please recheck with latest master.
Tested with genericx86 and core2-32 images on Lenovo S10-3 and also with corei7-64 image on Dell Inspiron 5520 and the issue cannot be reproduced. Set this as resolved.
Verified as per above comments.