sECuRE
October 19, 2016, 7:03am
21
I tried all three different possible settings:
root@turris:~# echo -n phy-def> /sys/devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth1/phy_select
root@turris:~# echo -n phy-sgmii-sfp> /sys/devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth1/phy_select
root@turris:~# echo -n phy-sfp> /sys/devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth1/phy_select
With none of them do I see any incoming packets in tcpdump.
I guess we’ll need to wait for brill’s test version.
emeidi
November 1, 2016, 2:08pm
22
Did it arrive? Is it working?
emeidi
November 1, 2016, 2:10pm
23
I’m wondering whether the following patch might bring Fiber7 compatibility?
sECuRE
November 1, 2016, 7:07pm
24
I canceled my order with FlexOptics, as they explained that I’d run into precisely the same issue with their turris-specific optic.
sECuRE
November 3, 2016, 9:52pm
25
brill, any news on your updated firmware?
brill
November 4, 2016, 1:12pm
26
Yes. The new Kernel for the OpenWRT is in images generated in dev-tms branch https://api.turris.cz/openwrt-repo/omnia-dev-tms/ . However, you still need to manually replace sfpswitch.py - you may use this one: https://github.com/tmshlvck/omnia-debian/blob/master/files/sfpswitch.py
The testing OpenWRT image is building now. And it will take some time to pass through review process to the release and automatic update.
In the meantime you may also have a look at Debian image with this patch (http://aule.elfove.cz/~brill/omnia-debian/ ).
sECuRE
November 5, 2016, 9:38am
27
Can you please outline what the timeline is for this process, so that interested users can decide whether they prefer to wait or prefer to install the test images?
brill
November 6, 2016, 12:26pm
28
A week or so. But the question is whether I will be able to test it and prove that it really fixes the problem.
Anyway I will finish the testing image and write down debugging guide tomorrow and post it here.
1 Like
emeidi
November 8, 2016, 6:07pm
29
Just spotted this in my GitHub RSS feed:
brill
November 10, 2016, 2:20pm
30
The compiled image is here: https://api.turris.cz/openwrt-repo/omnia-dev-tms/medkit/omnia-medkit-201611101407-minimal.tar.gz
Flashing a new image is perfectly safe, procedure is here: https://www.turris.cz/doc/en/howto/omnia_factory_reset in part “Re-flash”.
Once the new image is installed you might want to try to simply force proper MII mode in force_mode variable, which is declared on the top of /usr/sbin/sfpswitch.py .
sECuRE
November 11, 2016, 9:17am
31
Thanks for the updated image. However, when flashing it and restoring my configuration, the router goes into a crashloop with the following kernel panic:
[ 13.294552] ieee80211 phy1: Atheros AR9287 Rev:2 mem=0xf0ee0000, irq=108
[ 25.469982] Unable to handle kernel NULL pointer dereference at virtual address 0000000e
[ 25.478117] pgd = edec0000
[ 25.480843] [0000000e] *pgd=2e543831, *pte=00000000, *ppte=00000000
[ 25.487156] Internal error: Oops: 17 [#1] SMP ARM
[ 25.491869] Modules linked in: pppoe ppp_async iptable_nat ath9k pppox ppp_generic nf_nat_ipv4 nf_conn
track_netlink nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE ebtable_nat ebtable_filter eb
table_broute ath9k_common xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_id xt
_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc nfnetlink nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat_ftp nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack_ftp nf_conntrack mvsdio iptable_raw iptable_mangle iptable_filter ip_tables ebtables ebt_vlan ebt_stp ebt_redirect ebt_pkttype ebt_mark_m ebt_mark ebt_limit ebt_among ebt_802_3 crc_ccitt ath9k_hw armada_thermal ledtrig_usbdev ledtrig_oneshot xt_LED ledtrig_morse ledtrig_heartbeat ledtrig_gpio ath10k_pci ath10k_core thermal_sys hwmon ath mac80211 cfg80211 compat ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables tun usb_storage xhci_plat_hcd xhci_pci xhci_hcd orion_wdt ledtrig_transient sd_mod scsi_mod usbcore nls_base usb_common
[ 25.591934] CPU: 0 PID: 1387 Comm: hotplug-call Not tainted 4.4.30-ab2542ed8b0135746db27dadc0a9818d-12 #1
[ 25.601522] Hardware name: Marvell Armada 380/385 (Device Tree)
[ 25.607453] task: ef279280 ti: ed854000 task.ti: ed854000
[ 25.612903] PC is at ieee80211_scan_completed+0x24/0x5a0 [mac80211]
[ 25.619200] LR is at ieee80211_scan_completed+0x24/0x5a0 [mac80211]
[ 25.625480] pc : [<bf120640>] lr : [<bf120640>] psr: 60000113
[ 25.625480] sp : ed855a70 ip : 00000000 fp : ed855a8c
[ 25.636982] r10: 00000000 r9 : ee4115e0 r8 : 00001450
[ 25.642218] r7 : 00000002 r6 : ee411280 r5 : ee410ba0 r4 : 00000000
[ 25.648758] r3 : 00000008 r2 : 0000000a r1 : ee411280 r0 : 00000000
[ 25.655299] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 25.662449] Control: 10c5387d Table: 2dec004a DAC: 00000051
[ 25.668207] Process hotplug-call (pid: 1387, stack limit = 0xed854210)
[ 25.674747] Stack: (0xed855a70 to 0xed856000)
[ 25.679114] 5a60: 00000000 ee4115e0 ee412308 00000000
[ 25.687311] 5a80: ed855aa4 ed855a90 bf1b3778 bf120628 00000002 ee4115e0 ed855ae4 ed855aa8
[ 25.695507] 5aa0: bf1c5920 bf1b373c 00000002 00000000 00001450 0000a001 0000a000 00000000
[ 25.703703] 5ac0: ef2b3c40 00009000 ee09f040 ee4115e0 00000000 ee41508c ed855b04 ed855ae8
[ 25.711899] 5ae0: bf1c8368 bf1c57d4 bf1c8288 ee4115e0 bf1b8cf0 ed855b88 ed855b1c ed855b08
[ 25.720096] 5b00: bf1c0a5c bf1c8294 ed2c4140 bf1b8cf0 ed855b6c ed855b20 bf1b9028 bf1c0a44
[ 25.728292] 5b20: 00000002 00000000 ee415040 fffffffb ed855b4c 00000002 0000001c c002c4b0
[ 25.736488] 5b40: ed855b6c 00000000 bf1b8cf0 ed855b88 ee4115e0 ee41508c c0697fc8 00000000
[ 25.744684] 5b60: ed855bc4 ed855b70 bf1ec170 bf1b8cfc 0000003c ef021940 bf1b8cf0 00000002
[ 25.752880] 5b80: ee09f040 00000024 ed855b88 ed855b88 00000000 ed855ba0 bf1ecf88 ee41508c
[ 25.761077] 5ba0: ee415040 ee4115e0 00057c30 c06ba7c0 ed855c30 ed854000 ed855bd4 ed855bc8
[ 25.769272] 5bc0: bf1ec1f4 bf1ec024 ed855bf4 ed855bd8 bf1efab4 bf1ec1e8 00000002 00000000
[ 25.777469] 5be0: ee4115e0 00000001 ed855c14 ed855bf8 bf1efb74 bf1efa5c ee4115e0 ee414f20
[ 25.785665] 5c00: 00000000 c068c154 ed855c2c ed855c18 bf1edb00 bf1efaf8 ee414f38 ee414f3c
[ 25.793861] 5c20: ed855c5c ed855c30 c002c08c bf1edad4 c002c008 c0692098 c0692080 40000006
[ 25.802057] 5c40: ed854000 00000100 00000006 00000000 ed855cbc ed855c60 c002c290 c002c014
[ 25.810254] 5c60: c0315d80 c0065118 00400040 c05a9d08 ffff94c4 c0692100 c06ba7c0 00000009
[ 25.818451] 5c80: c068c1c8 c0692080 ed854020 edion stack(0xef065f48 to 0xef065f90)
[ 26.563726] 5f40: 00000001 00000000 ef065fa8 c000b460 ef064000 c0692498
[ 26.571922] 5f60: c05a9cfc 00000000 00000000 c068e150 ef065fb8 ef065fa4 ef065fa8 ef065f98
[ 26.580118] 5f80: c001923c c0019240 60000013 ffffffff
[ 26.585178] r9:c068e150 r8:00000000 r7:ef065f7c r6:ffffffff r5:60000013 r4:c0019240
[ 26.592995] [<c0019200>] (arch_cpu_idle) from [<c005cf50>] (default_idle_call+0x28/0x34)
[ 26.601106] [<c005cf28>] (default_idle_call) from [<c005d0a8>] (cpu_startup_entry+0x14c/0x22c)
[ 26.609738] [<c005cf5c>] (cpu_startup_entry) from [<c001e8e8>] (secondary_start_kernel+0x138/0x140)
[ 26.618801] r7:c06ba060
[ 26.621350] [<c001e7b0>] (secondary_start_kernel) from [<0000962c>] (0x962c)
[ 26.628413] r5:00000051 r4:2f04c06a
[ 26.632015] Rebooting in 3 seconds..
brill
November 11, 2016, 10:23am
32
I failed to reproduce it here… Anyway, it looks like a problem with the WiFi card. Can you try to remove both WiFi cards from the board to verify that?
sECuRE
November 11, 2016, 7:02pm
33
I changed my configuration to disable all wireless interfaces (by changing “disabled” from 0 to 1 in all lines in /etc/config/wireless), which stops the crashing.
Now, unfortunately the SFP still doesn’t work.
I’ve tried forcing each of the available modes (phy-sfp, phy-sfp-sgmii, phy-sfp-noneg) by setting force_mode
in /usr/sbin/sfpswitch.py
, followed by /etc/init.d/sfpswitch restart
. With phy-sfp-noneg, the interface stays up (as expected), but it still does not receive a single byte of traffic:
eth1 Link encap:Ethernet HWaddr D8:58:D7:00:4E:DF
inet6 addr: fe80::da58:d7ff:fe00:4edf/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:58 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:532
RX bytes:0 (0.0 B) TX bytes:16280 (15.8 KiB)
Interrupt:38
In dmesg, the last entries are:
[ 212.290650] mvneta f1034000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[ 212.290668] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Also, a ping6 ff02::1%eth1
yields no results, whereas, when connected to the media converter, I get duplicate replies from the router.
sECuRE
November 11, 2016, 10:03pm
34
One more thing: in your image, the web interface doesn’t come up right away, and sometimes not ever. Not sure what’s up with that, but without a serial console handy, I would recommend against testing it.
emeidi
November 14, 2016, 4:11pm
35
More activity here … Does anyone know whether Fiber7 requires noneg?
committed 05:57PM - 31 Oct 16 UTC
Do major DTS cleanup.
Make PHY modes of eth1 (dual-PHY NIC) consistent. The PHY names are:
* phy-def - matalic build-in ethernet, SGMII...
sECuRE
November 14, 2016, 6:44pm
36
I’m actually not sure. I do remember that I needed to configure my tp-link MC220L media converter like this:
Pay attention to configure the media converter to “auto”, not “force”. In both cases you’ll get a link, but with “force”, you will not get any replies to your packets.
My guess is that “force” corresponds to noneg? @brill , could you confirm please?
brill
November 15, 2016, 12:07pm
37
The web interface issue might be caused by the procd/neifd. My image is based on testing branch of OpenWRT, which is more susceptible to problems like that.
Anyway, we definitely need to test it in our lab with the flexOptix 1000BASE-BX.
brill
November 15, 2016, 3:38pm
38
And yes, I would say so - force is perhaps translated to the same behavior of L2 as phy-sfp-noneg mode in our case.
I would expect that you need either phy-sfp (which is default) or phy-sfp-sgmii.
Can you, please, try the new image https://api.turris.cz/openwrt-repo/omnia-dev-tms/medkit/omnia-medkit-201611151300-minimal.tar.gz (which might solve some problems)? And can you please restart the router after setting force_mode in sfpswitch.py ? (It might sound silly, but there is still a possibility of having a problem in SFP support code in kernel mvneta driver.)
sECuRE
November 15, 2016, 6:18pm
39
Flashed and tested; still not able to get a link.
I tried the following settings (each with a complete power off / power on after changing the setting):
force_mode=None: https://p.nnev.de/8359
force_mode=phy-sfp-sgmii: https://p.nnev.de/8360
force_mode=phy-sfp-noneg: https://p.nnev.de/8361
force_mode=phy-sfp: https://p.nnev.de/8362
force_mode=phy-def: https://p.nnev.de/8363
In none of the modes would I ever receive a single byte.
sECuRE
November 25, 2016, 10:48am
40
@brill Any update? Will there be a new test image soon? Otherwise I’ll disconnect my serial port and close my router for the time being. Thanks!