[LEDE-DEV] WRT300N v2 AR5416 (was:MV88E6060 switch)

[Nerijus Baliunas via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Sat, 14 Oct 2017 17:48:12 +0300 Nerijus Baliunas 
 wrote:

> Thank you. Another question about wifi - there is no /etc/config/wireless
> file, and even if I create it and reboot the device, wifi is not working
> and there is no wlan0 interface. ath5k module is loaded.

WRT300N v2 has AR5416 card, so the driver should be ath9k. I enabled
kmod-ath9k, but did not check "Support chips used in PC OEM cards" and
"Enable TX99 support (WARNING: testing only, breaks normal operation!)".
The module is loaded when booting, but:

[   14.686040] ath9k :00:01.0: enabling device (0340 -> 0342)
[   15.372420] kmodloader: page allocation failure: order:6, mode:0x240c0c0
[   15.379319] CPU: 0 PID: 1331 Comm: kmodloader Not tainted 4.4.91 #0
[   15.385595] Hardware name: Linksys WRT300N v2
[   15.389993] Backtrace: 
[   15.392516] [] (dump_backtrace) from [] 
(show_stack+0x18/0x1c)
[   15.400134]  r7: r6:0006 r5:0240c0c0 r4:0001
[   15.405870] [] (show_stack) from [] 
(dump_stack+0x20/0x28)
[   15.413187] [] (dump_stack) from [] 
(warn_alloc_failed+0xf0/0x118)
[   15.421176] [] (warn_alloc_failed) from [] 
(__alloc_pages_nodemask+0x6c4/0x718)
[   15.430258]  r3:2001 r2:
[   15.433848]  r7: r6:0240c0c0 r5:0006 r4:0240c0c0
[   15.439603] [] (__alloc_pages_nodemask) from [] 
(alloc_kmem_pages+0x18/0x20)
[   15.448421]  r10:0002 r9:0004 r8: r7: r6:024080c0 
r5:c0a34c10
[   15.456290]  r4:c0a34b80
[   15.458925] [] (alloc_kmem_pages) from [] 
(kmalloc_order+0x18/0x4c)
[   15.466991] [] (kmalloc_order) from [] 
(__kmalloc+0x2c/0x120)
[   15.474897] [] (__kmalloc) from [] 
(ieee80211_txq_setup_flows+0x90/0x1f8 [mac80211])
[   15.484453]  r7: r6:002f r5:c0a34c10 r4:c0a34b80
[   15.490864] [] (ieee80211_txq_setup_flows [mac80211]) from 
[] (ieee80211_register_hw+0x898/0x948 )
[   15.502505]  r7: r6:002f r5: r4:c0a34b80
[   15.508685] [] (ieee80211_register_hw [mac80211]) from 
[] (ath9k_init_device+0x8e0/0xa04 [ath9k])
[   15.519371]  r10:c0e800fc r9:c0e80010 r8:c0e80010 r7: r6: 
r5:c0a34b80
[   15.527246]  r4:c0a354a0
[   15.529948] [] (ath9k_init_device [ath9k]) from [] 
(ath_pci_probe+0x240/0x2fc [ath9k])
[   15.539632]  r10: r9:bf1db968 r8:c0a34b80 r7: r6:c084bc68 
r5:c0a354a0
[   15.547501]  r4:c084bc00
[   15.550170] [] (ath_pci_probe [ath9k]) from [] 
(pci_device_probe+0x70/0xbc)
[   15.558911]  r10:c005bec8 r9:0001 r8:bf1de4c0 r7: r6:c084bc68 
r5:c084bc00
[   15.566785]  r4:bf1de4f4
[   15.569385] [] (pci_device_probe) from [] 
(driver_probe_device+0xf4/0x258)
[   15.578027]  r9:0001 r8:bf1de4f4 r7:c03ba818 r6:c03ba81c r5:c084bc9c 
r4:c084bc68
[   15.585842] [] (driver_probe_device) from [] 
(__driver_attach+0x70/0x94)
[   15.594315]  r9: r8:c0372008 r7:c0388b28 r6:bf1de4f4 r5:c084bc9c 
r4:c084bc68
[   15.602179] [] (__driver_attach) from [] 
(bus_for_each_dev+0x74/0x98)
[   15.610389]  r7:c0388b28 r6:c018681c r5:bf1de4f4 r4:
[   15.616117] [] (bus_for_each_dev) from [] 
(driver_attach+0x20/0x28)
[   15.624153]  r6:c055a900 r5: r4:bf1de4f4
[   15.628850] [] (driver_attach) from [] 
(bus_add_driver+0xd4/0x1e8)
[   15.636803] [] (bus_add_driver) from [] 
(driver_register+0xa4/0xe8)
[   15.644843]  r7:c0376008 r6:c0376008 r5:bf1e1000 r4:bf1de4f4
[   15.650595] [] (driver_register) from [] 
(__pci_register_driver+0x38/0x40)
[   15.659240]  r5:bf1e1000 r4:c0428ee0
[   15.662919] [] (__pci_register_driver) from [] 
(ath_pci_init+0x1c/0x2c [ath9k])
[   15.672150] [] (ath_pci_init [ath9k]) from [] 
(init_module+0x14/0x38 [ath9k])
[   15.681153] [] (init_module [ath9k]) from [] 
(do_one_initcall+0x1bc/0x200)
[   15.689863] [] (do_one_initcall) from [] 
(do_init_module+0x60/0x1a0)
[   15.697985]  r9:c0d83f34 r8:001a r7: r6:c0428420 r5:c06bc800 
r4:bf1de540
[   15.705803] [] (do_init_module) from [] 
(load_module+0x1444/0x188c)
[   15.713848]  r6:c06bca10 r5:c06bc800 r4:bf1de540
[   15.718540] [] (load_module) from [] 
(SyS_init_module+0x114/0x134)
[   15.726460]  r10:0051 r9:c0d82000 r8:0001276a r7:c1b0417c r6: 
r5:b6f2518c
[   15.734358]  r4:c17c
[   15.736932] [] (SyS_init_module) from [] 
(ret_fast_syscall+0x0/0x38)
[   15.745060]  r10: r9:c0d82000 r8:c0009564 r7:0080 r6:0003 
r5:
[   15.752956]  r4:1f02
[   15.755496] Mem-Info:
[   15.757853] active_anon:135 inactive_anon:2 isolated_anon:0
[   15.757853]  active_file:204 inactive_file:193 isolated_file:0
[   15.757853]  unevictable:0 dirty:0 writeback:0 unstable:0
[   15.757853]  slab_reclaimable:181 slab_unreclaimable:1094
[   15.757853]  mapped:246 shmem:3 

Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch

[Nerijus Baliunas via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Thu, 12 Oct 2017 03:11:21 +0300 Sergey Ryazanov  
wrote:

> > I assume the new board type should be added to the config file,
> > for which this patch should be enabled?
> 
> I do not think so. These two patches are just a quick hacks to fix
> common underlying issues.
> 
> The first patch completes the work of adding phy(s) without the
> standard MDIO interface, so it should be merged to existing patches.
> 
> The second patch fixes the issue, which was introduced by
> 304-ixp4xx_eth_jumboframe.patch, which adds JumboFrames support. So we
> either should completely remove jumboframe support patch. Or, if
> someone really use jumboframe feature, then we should to rework this
> patch to avoid memory issues when using a regular MTU.
> 
> I can try to make normal (and formal) fixes in a couple of days. It
> would be nice if you could test them when they will be ready.

Thank you. Another question about wifi - there is no /etc/config/wireless
file, and even if I create it and reboot the device, wifi is not working
and there is no wlan0 interface. ath5k module is loaded.

Regards,
Nerijus

--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch

[Nerijus Baliunas via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Thu, 12 Oct 2017 01:30:35 +0300 Sergey Ryazanov  
wrote:

> Try this patch, it should reduce the memory demand of the ethernet
> driver, so it will have the change to get started on your router.
> 
> Just put it to target/linux/ixp4xx/patches-4.4 along with the previous
> one and rebuild your firmware.

I rebuilt the image with ppp and ipv6 excluded, but it did not help,
after boot only 624 kB MemFree. But with your patch it works.
Thanks a lot!
I assume the new board type should be added to the config file,
for which this patch should be enabled?

Regards,
Nerijus

--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch

[Nerijus Baliunas via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Thu, 12 Oct 2017 00:15:15 +0300 Sergey Ryazanov  
wrote:

> >> As a quick test, can you unload all kernel modules and try to set eth0 UP 
> >> again?
> >
> > Unfortunately rmmod with a list of modules does not work:
> > # rmmod ip_tables ip6_tables ip6t_REJECT ...
> > Usage:
> > rmmod module
> > so I had to unload one by one. I unloaded until there was
> > # cat /proc/meminfo
> > MemTotal:  12232 kB
> > MemFree:1304 kB
> >
> > but still does not work:
> > # ifconfig eth0 up
> > ifconfig: SIOCSIFFLAGS: Out of memory
> 
> Can you boot in failsafe mode again, check free memory while the
> interface is Up, then bring it Down and check free memory again? That
> will show which amount of memory it needs.

# cat /proc/meminfo 
MemTotal:  12232 kB
MemFree:1108 kB
# ifconfig eth0 down
# cat /proc/meminfo 
MemTotal:  12232 kB
MemFree:2136 kB


--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch

[Nerijus Baliunas via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Wed, 11 Oct 2017 23:28:00 +0300 Sergey Ryazanov  
wrote:

> > root@LEDE:/# cat /proc/meminfo
> > MemTotal:  12232 kB
> > MemFree: 996 kB
> 
> Looks like this ^^^ is the cause of the "ifconfig up" failure. Your
> board really have not free RAM.
> 
> As a quick test, can you unload all kernel modules and try to set eth0 UP 
> again?

Unfortunately rmmod with a list of modules does not work:
# rmmod ip_tables ip6_tables ip6t_REJECT ...
Usage:
rmmod module
so I had to unload one by one. I unloaded until there was
# cat /proc/meminfo 
MemTotal:  12232 kB
MemFree:1304 kB

but still does not work:
# ifconfig eth0 up
ifconfig: SIOCSIFFLAGS: Out of memory

Regards,
Nerijus

--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch

[Nerijus Baliunas via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Wed, 11 Oct 2017 22:50:40 +0300 Sergey Ryazanov  
wrote:

> Khm, according to wikidevi your router is equipped with 16MB of RAM,
> the ethernet driver for xscale SoCs attempts to allocate almost a 1 MB
> of memory for buffers, so may be there are really no free memory for
> them.

Yes, RAM is 16 MB.

> Check, please, memory information and list of loaded kernel modules:
> # cat /proc/meminfo
> # lsmod

root@LEDE:/# free
 total   used   free sharedbuffers cached
Mem: 12232  11352880 40632   2420
-/+ buffers/cache:   8300   3932
Swap:0  0  0
root@LEDE:/# cat /proc/meminfo
MemTotal:  12232 kB
MemFree: 996 kB
MemAvailable:   3316 kB
Buffers: 648 kB
Cached: 2384 kB
SwapCached:0 kB
Active: 3012 kB
Inactive:796 kB
Active(anon):804 kB
Inactive(anon):   20 kB
Active(file):   2208 kB
Inactive(file):  776 kB
Unevictable:   0 kB
Mlocked:   0 kB
SwapTotal: 0 kB
SwapFree:  0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages:   792 kB
Mapped: 1680 kB
Shmem:48 kB
Slab:   4436 kB
SReclaimable:848 kB
SUnreclaim: 3588 kB
KernelStack: 280 kB
PageTables:  136 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit:6116 kB
Committed_AS:   2456 kB
VmallocTotal:1015808 kB
VmallocUsed:   0 kB
VmallocChunk:  0 kB
root@LEDE:/# lsmod
ath16602  1 ath5k
ath5k 177618  0 
cfg80211  231978  3 ath5k,ath,mac80211
cmac2157  0 
compat 11563  3 ath5k,mac80211,cfg80211
crc_ccitt   1035  1 ppp_async
crypto_hash10802  2 mac80211,cmac
ip_tables   9079  3 iptable_nat,iptable_mangle,iptable_filter
ip6_tables  8885  2 ip6table_mangle,ip6table_filter
ip6t_REJECT  972  2 
ip6table_filter  734  1 
ip6table_mangle 1054  1 
ipt_MASQUERADE   754  1 
ipt_REJECT   938  2 
iptable_filter   796  1 
iptable_mangle   924  1 
iptable_nat 1073  1 
mac80211  405550  1 ath5k
nf_conntrack   46856  8 
nf_conntrack_ipv6,xt_state,xt_conntrack,nf_nat_masquerade_ipv4,nf_conntrack_ipv4,nf_e
nf_conntrack_ipv4   5251 10 
nf_conntrack_ipv6   5500  5 
nf_conntrack_rtcache2482  0 
nf_defrag_ipv4   924  1 nf_conntrack_ipv4
nf_defrag_ipv6  9209  1 nf_conntrack_ipv6
nf_log_common   2191  2 nf_log_ipv4,nf_log_ipv6
nf_log_ipv4 2998  0 
nf_log_ipv6 3223  0 
nf_nat  8675  4 
xt_nat,nf_nat_redirect,nf_nat_masquerade_ipv4,nf_nat_ipv4
nf_nat_ipv4 3367  1 iptable_nat
nf_nat_masquerade_ipv41517  1 ipt_MASQUERADE
nf_nat_redirect  955  1 xt_REDIRECT
nf_reject_ipv4  1795  1 ipt_REJECT
nf_reject_ipv6  2088  1 ip6t_REJECT
ppp_async   6445  0 
ppp_generic20137  3 pppoe,ppp_async,pppox
pppoe   7959  0 
pppox   1319  1 pppoe
slhc3922  1 ppp_generic
x_tables   10587 22 
ipt_REJECT,ipt_MASQUERADE,xt_time,xt_tcpudp,xt_state,xt_nat,xt_multiport,xt_mark,xt_s
xt_LOG   899  0 
xt_REDIRECT  885  0 
xt_TCPMSS   2664  2 
xt_comment   555125 
xt_conntrack2424 14 
xt_limit1129 20 
xt_mac   711  0 
xt_mark  768  0 
xt_multiport1332  0 
xt_nat  1405  0 
xt_state 841  0 
xt_tcpudp   1816 10 
xt_time 1702  0 


--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch

[Nerijus Baliunas via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Wed, 11 Oct 2017 18:53:40 +0300 Sergey Ryazanov  
wrote:

> A-ha! The interface survives the down/up circle but does not survive
> the init procedure.
> 
> Try to completely avoid bridge usage, e.g.:
> 1. boot in normal mode
> 2. disable bridge usage on "lan":
> # uci delete network.lan.type
> # uci commit
> 3. reboot
> 4. after reboot is completed, check whether IP address has been
> assigned to eth0.
> 5. ping

Yes, after reboot eth0 has 192.168.1.1, but it does not ping.
dmesg:
[4.970623] init: - preinit -
[6.462015] random: jshn: uninitialized urandom read (4 bytes read, 10 bits 
of entropy available)
[6.532512] random: jshn: uninitialized urandom read (4 bytes read, 10 bits 
of entropy available)
[6.748641] NPE-B: firmware's license can be found in 
/usr/share/doc/LICENSE.IPL
[6.756083] NPE-B: firmware functionality 0x2, revision 0x2:1
[6.764113] eth0: link up, speed 100 Mb/s, full duplex
[   10.330454] jffs2: notice: (733) jffs2_build_xattr_subsystem: complete 
building xattr subsystem, 0 of xdatum (0 u.
[   10.348884] mount_root: switching to jffs2 overlay
[   10.401588] urandom-seed: Seeding with /etc/urandom.seed
[   10.553168] eth0: link down


--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch

[Nerijus Baliunas via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Wed, 11 Oct 2017 14:53:16 +0300 Sergey Ryazanov  
wrote:

> Ok. At least we know now that the switch functioning (even without a
> dedicated driver). One question left: what happens to the Ethernet
> driver?
> 
> Can you boot your router in failsafe mode again, and try to toggle
> eth0 down/up? E.g.:
> # ifconfig eth0 down
> # ifconfig eth0 up

root@(none):/# ifconfig eth0 down
[   42.063281] eth0: link down
root@(none):/# ifconfig eth0 up
[   49.665365] eth0: link up, speed 100 Mb/s, full duplex
root@(none):/# ifconfig eth0 down
[   62.063281] eth0: link down
root@(none):/# ifconfig eth0 up
[   68.295374] eth0: link up, speed 100 Mb/s, full duplex

ping stops replying after down and replies after up.

> To figure out, is taking down the interface enough to break it, or
> something else happened during the initialization, what prevent us to
> bring it up again.

Regards,
Nerijus

--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch

[Nerijus Baliunas via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Wed, 11 Oct 2017 02:07:00 +0300 Sergey Ryazanov  
wrote:

> Ok. I am starting to run out of ideas. Let's start guessing.
> 
> eth0 works at least during preinit. You could check your switch
> functioning in the failsafe mode:
> 1. Power on router
> 2. When the "Press the [f] key and hit [enter]" line will be printed
> on serial console then press the "f" and hit [enter] :)
> 3. You could check which IP address configured on eth0 with ifconfig
> and if there are not address, then configure it manually
> 4. Try to pinging in order to check switch functioning

This works:
= FAILSAFE MODE active 
# ifconfig -a
eth0  Link encap:Ethernet  HWaddr 00:18:39:21:0D:AE  
  inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
  inet6 addr: fe80::218:39ff:fe21:dae/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:8 errors:0 dropped:0 overruns:0 carrier:0

Ping to 192.168.1.1 answers, after pinging:
  RX packets:5 errors:0 dropped:0 overruns:0 frame:0
  TX packets:14 errors:0 dropped:0 overruns:0 carrier:0

> Another guess is to try to disable bridge before bringing eth0 up:
> 1. Boot your router in normal mode
> 2. Check whether eth0 is added to the bridge or not:
>   # brctl show
> 3. Disable the bridge and configure eth0 for standalone working:
>  # brctl delif br-lan eth0
>  # ifconfig br-lan down
>  # ifconfig eth0 192.168.0.10 up
> 4. Try to pinging

This does not:
# brctl show
bridge name bridge id   STP enabled interfaces
br-lan  7fff.001839210dae   no  eth0
# brctl delif br-lan eth0
# ifconfig br-lan down
# ifconfig eth0 192.168.0.10 up
ifconfig: SIOCSIFFLAGS: Out of memory
# brctl show
bridge name bridge id   STP enabled interfaces
br-lan  7fff.001839210dae   no
# ifconfig -a
br-lanLink encap:Ethernet  HWaddr 00:18:39:21:0D:AE  
  inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
  BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0  Link encap:Ethernet  HWaddr 00:18:39:21:0D:AE  
  inet addr:192.168.0.10  Bcast:192.168.0.255  Mask:255.255.255.0
  BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:100 
  RX bytes:0 (0.0 B)  TX bytes:1551 (1.5 KiB)

Ping to neither 192.168.1.1 nor 192.168.0.10 does not answer.

Regards,
Nerijus

--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch

[Nerijus Baliunas via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Mon, 9 Oct 2017 01:31:29 +0300 Sergey Ryazanov  
wrote:

> > Just tried:
> > # ifconfig eth0 192.168.0.10 up
> > ifconfig: SIOCSIFFLAGS: Out of memory
> > # dmesg|grep eth
> > [0.998445] eth0: MII PHY 32 on NPE-B
> > [1.005134] eth1: MII PHY 1 on NPE-C
> > [6.540687] eth0: link up, speed 100 Mb/s, full duplex
> > [9.323993] eth0: link down
> > [   36.266247] device eth0 entered promiscuous mode
> 
> Check please, is there any new kernel messages after 'ifconfig ... up'
> failure (may be not directly related to eth0). Just run dmesg without
> grep.

I don't see anything suspicious. The full serial console log (dmesg included) 
is here -
https://paste.fedoraproject.org/paste/P5sDjdpJr1hFZ-hp~Prwcw

> It is also stranger that something bring eth0 up and then putting it
> back to down. Is these strings (eth0: link up/eth0: link down) appear
> in the kernel log during preinit procedure?

Seems so:
[4.981198] init: - preinit -
[6.473760] random: jshn: uninitialized urandom read (4 bytes read, 10 bits 
of entropy available)
[6.544511] random: jshn: uninitialized urandom read (4 bytes read, 10 bits 
of entropy available)
[6.761251] NPE-B: firmware's license can be found in 
/usr/share/doc/LICENSE.IPL
[6.768796] NPE-B: firmware functionality 0x2, revision 0x2:1
[6.776745] eth0: link up, speed 100 Mb/s, full duplex
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[   10.310754] mount_root: jffs2 not ready yet, using temporary tmpfs overlay
[   10.359891] urandom-seed: Seed file not found (/etc/urandom.seed)
[   10.492841] eth0: link down

Regards,
Nerijus

--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch

[Nerijus Baliunas via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Sun, 8 Oct 2017 23:44:58 +0300 Sergey Ryazanov  
wrote:

> > I assigned IP with a command
> > ip a a 192.168.0.10/24 dev eth0
> >
> > but ping from PC does not answer.
>
> Have you bring eth0 UP? I mean, could you do "ifconfig eth0
> 192.168.0.10 up" and try pinging again?

Just tried:
# ifconfig eth0 192.168.0.10 up
ifconfig: SIOCSIFFLAGS: Out of memory
# dmesg|grep eth
[0.998445] eth0: MII PHY 32 on NPE-B
[1.005134] eth1: MII PHY 1 on NPE-C
[6.540687] eth0: link up, speed 100 Mb/s, full duplex
[9.323993] eth0: link down
[   36.266247] device eth0 entered promiscuous mode
# ifconfig eth0 192.168.0.10 up
ifconfig: SIOCSIFFLAGS: Out of memory
# ifconfig -a
br-lanLink encap:Ethernet  HWaddr 00:18:39:21:0D:AE  
  inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
  inet6 addr: fde1:e263:bcc::1/60 Scope:Global
  UP BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0  Link encap:Ethernet  HWaddr 00:18:39:21:0D:AE  
  inet addr:192.168.0.10  Bcast:192.168.0.255  Mask:255.255.255.0
  BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:2 errors:0 dropped:0 overruns:0 frame:0
  TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:100 
  RX bytes:92 (92.0 B)  TX bytes:1551 (1.5 KiB)

Ping still does not answer.

Regards,
Nerijus

--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch

[Nerijus Baliunas via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Tue, 3 Oct 2017 03:27:21 +0300 Sergey Ryazanov  
wrote:

> After these lines, I carefully examine available data about WRT300Nv2
> and related code and found several interesting things.
> 
> Usually SoC in the router have only one ethernet interface and vendors
> pair it with manageable switch IC. This swith IC accepts packets from
> LAN and WAN ports, then it tags them and forward to the SoC. Thus,
> using VLAN tags, SoC can distinguish from which port the packet was
> received and handle it appropriately. So the firmware should contains
> a driver for switch IC to be able to properly configure ports and
> VLANs inside the switch.
> 
> In case of WRT300Nv2 the SoC contains two ethernet adapters: NPE-C
> (eth1), which has own phy and acted as a WAN port and NPE-B (eth0),
> which is connected to switch IC, each port of which is acting as LAN
> port. So since all ports of switch are equal then the switch themself
> requires a minimal (if any) configuration. And this router can
> possibly act without any special driver for switch IC.
> 
> Also I found why the switch is properly detected on the MDIO bus but
> not used as phy-device. This happened because PHY ID for eth0 is
> hardcoded inside WRT300Nv2 setup code.
> 
> To check whether your board can act without dedicated driver for 88E6060:
> * revert any earlier modifications to LEDE if you do any
> * disable any drivers for 88E6060 (e.g. disable both
> CONFIG_NET_DSA_MV88E6060 and CONFIG_MVSWITCH_PHY)
> * place attached patch to the target/linux/ixp4xx/patches-4.4
> * rebuild and boot new firmware
> * check dmesg for "eth0: link up" message
> * check eth0 functioning: check packets receiving with tcpdump or
> manually assign IP address to the eth0 interface (without any VLAN's
> and so on) and try to ping.

I did this, and now when booting I see
[0.999140] eth0: MII PHY 32 on NPE-B
[1.005714] eth1: MII PHY 1 on NPE-C
...
[6.531972] NPE-B: firmware functionality 0x2, revision 0x2:1
[6.540066] eth0: link up, speed 100 Mb/s, full duplex
[9.070970] mount_root: jffs2 not ready yet, using temporary tmpfs overlay
[9.118732] urandom-seed: Seed file not found (/etc/urandom.seed)
[9.250596] eth0: link down

I assigned IP with a command
ip a a 192.168.0.10/24 dev eth0
but ping from PC does not answer.
ifconfig -a shows a few RX and TX packets:
eth0  Link encap:Ethernet  HWaddr 00:18:39:21:0D:AE  
  inet addr:192.168.0.10  Bcast:0.0.0.0  Mask:255.255.255.0
  BROADCAST MULTICAST  MTU:1500  Metric:1
  RX packets:5 errors:0 dropped:0 overruns:0 frame:0
  TX packets:7 errors:0 dropped:0 overruns:0 carrier:0

but the packet count does not increase after pinging.

Regards,
Nerijus

--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch

[Nerijus Baliunas via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Fri, 8 Sep 2017 22:50:13 +0300 Sergey Ryazanov  
wrote:

> >> >> Did  you  see  the  "Marvell  88E6060  PHY  driver attached" in kernel
> >> >> messages   log?  If  not then the mwswitch driver did not attached and
> >> >> you  should  fix  this  first.  And  only  then  go  to  the interface
> >> >> configuration.
> >> >
> >> > No, dmesg|grep 6060 does not show anything. How do I fix it?
> >>
> >> Try   to check, which MDIO addresses PHY core (or Ethernet MAC driver)
> >> scans to detect connected PHYs.
> >
> > I enabled #define DEBUG_MDIO 1 in ixp4xx_eth.c and got this:
> > # dmesg|grep -i MII|grep -v took
> > ...
> > [0.976646] IXP4xx MII Bus #16: MII read [2] -> 0x141
> > [0.976747] IXP4xx MII Bus #16: MII read [3] -> 0xC87
> > [0.978682] IXP4xx MII Bus #24: MII read [3] -> 0x602
> 
> Looks like mvswitch driver tries to check chip here and got an
> expected value 0x060X from register 3. So on the one hand the driver
> is functioning, but on the other hand it can not detect switch IC.
> 
> Can you go to the /sys/class/mdio_bus/ and for each bus check driver
> and ID of the each detected device. E.g.:
> # cd /sys/class/mdio_bus
> # ls -l */*/driver

lrwxrwxrwx1 root root 0 Jul 22 21:31 
ixp4xx-eth-0/ixp4xx-eth-0:01/driver -> 
../../../../../bus/mdio_bus/drivers/Generic PHY
lrwxrwxrwx1 root root 0 Jul 22 21:31 
ixp4xx-eth-0/ixp4xx-eth-0:10/driver -> 
../../../../../bus/mdio_bus/drivers/Marvell 88E6060

> # ls -l */*/phy_id

-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:01/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:10/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:11/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:12/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:13/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:14/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:15/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:16/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:17/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:18/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:19/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:1a/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:1b/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:1c/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:1d/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:1e/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:1f/phy_id

> # cat */*/phy_id

0x8201
0x088e6060
0x01410c87
0x01410c87
0x01410c87
0x01410c87
0x
0x
0x
0x0602
0x0602
0x0602
0x0602
0x0602
0x0602
0x
0x

Regards,
Nerijus

--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch

[Nerijus Baliunas via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Thu, 27 Jul 2017 23:43:19 +0300 Sergey Ryazanov  
wrote:

> >> Did  you  see  the  "Marvell  88E6060  PHY  driver attached" in kernel
> >> messages   log?  If  not then the mwswitch driver did not attached and
> >> you  should  fix  this  first.  And  only  then  go  to  the interface
> >> configuration.
> >
> > No, dmesg|grep 6060 does not show anything. How do I fix it?
> 
> Try   to check, which MDIO addresses PHY core (or Ethernet MAC driver)
> scans to detect connected PHYs.

I enabled #define DEBUG_MDIO 1 in ixp4xx_eth.c and got this:
# dmesg|grep -i MII|grep -v took
[0.971141] IXP4xx MII Bus #0: MII read failed
[0.971173] IXP4xx MII Bus #0: MII read [2] -> 0x
[0.971268] IXP4xx MII Bus #0: MII read failed
[0.971299] IXP4xx MII Bus #0: MII read [3] -> 0x
[0.971400] IXP4xx MII Bus #1: MII read [2] -> 0x0
[0.971500] IXP4xx MII Bus #1: MII read [3] -> 0x8201
[0.973099] IXP4xx MII Bus #2: MII read failed
[0.973132] IXP4xx MII Bus #2: MII read [2] -> 0x
[0.973227] IXP4xx MII Bus #2: MII read failed
[0.973258] IXP4xx MII Bus #2: MII read [3] -> 0x
[0.973354] IXP4xx MII Bus #3: MII read failed
[0.973385] IXP4xx MII Bus #3: MII read [2] -> 0x
[0.973479] IXP4xx MII Bus #3: MII read failed
[0.973511] IXP4xx MII Bus #3: MII read [3] -> 0x
[0.973606] IXP4xx MII Bus #4: MII read failed
[0.973637] IXP4xx MII Bus #4: MII read [2] -> 0x
[0.973731] IXP4xx MII Bus #4: MII read failed
[0.973762] IXP4xx MII Bus #4: MII read [3] -> 0x
[0.973857] IXP4xx MII Bus #5: MII read failed
[0.973888] IXP4xx MII Bus #5: MII read [2] -> 0x
[0.973982] IXP4xx MII Bus #5: MII read failed
[0.974014] IXP4xx MII Bus #5: MII read [3] -> 0x
[0.974109] IXP4xx MII Bus #6: MII read failed
[0.974140] IXP4xx MII Bus #6: MII read [2] -> 0x
[0.974235] IXP4xx MII Bus #6: MII read failed
[0.974266] IXP4xx MII Bus #6: MII read [3] -> 0x
[0.974361] IXP4xx MII Bus #7: MII read failed
[0.974392] IXP4xx MII Bus #7: MII read [2] -> 0x
[0.974486] IXP4xx MII Bus #7: MII read failed
[0.974517] IXP4xx MII Bus #7: MII read [3] -> 0x
[0.974613] IXP4xx MII Bus #8: MII read failed
[0.974644] IXP4xx MII Bus #8: MII read [2] -> 0x
[0.974739] IXP4xx MII Bus #8: MII read failed
[0.974770] IXP4xx MII Bus #8: MII read [3] -> 0x
[0.974865] IXP4xx MII Bus #9: MII read failed
[0.974896] IXP4xx MII Bus #9: MII read [2] -> 0x
[0.974990] IXP4xx MII Bus #9: MII read failed
[0.975021] IXP4xx MII Bus #9: MII read [3] -> 0x
[0.975118] IXP4xx MII Bus #10: MII read failed
[0.975149] IXP4xx MII Bus #10: MII read [2] -> 0x
[0.975245] IXP4xx MII Bus #10: MII read failed
[0.975276] IXP4xx MII Bus #10: MII read [3] -> 0x
[0.975372] IXP4xx MII Bus #11: MII read failed
[0.975403] IXP4xx MII Bus #11: MII read [2] -> 0x
[0.975498] IXP4xx MII Bus #11: MII read failed
[0.975530] IXP4xx MII Bus #11: MII read [3] -> 0x
[0.975626] IXP4xx MII Bus #12: MII read failed
[0.975657] IXP4xx MII Bus #12: MII read [2] -> 0x
[0.975752] IXP4xx MII Bus #12: MII read failed
[0.975784] IXP4xx MII Bus #12: MII read [3] -> 0x
[0.975879] IXP4xx MII Bus #13: MII read failed
[0.975911] IXP4xx MII Bus #13: MII read [2] -> 0x
[0.976006] IXP4xx MII Bus #13: MII read failed
[0.976037] IXP4xx MII Bus #13: MII read [3] -> 0x
[0.976133] IXP4xx MII Bus #14: MII read failed
[0.976165] IXP4xx MII Bus #14: MII read [2] -> 0x
[0.976261] IXP4xx MII Bus #14: MII read failed
[0.976292] IXP4xx MII Bus #14: MII read [3] -> 0x
[0.976388] IXP4xx MII Bus #15: MII read failed
[0.976419] IXP4xx MII Bus #15: MII read [2] -> 0x
[0.976514] IXP4xx MII Bus #15: MII read failed
[0.976545] IXP4xx MII Bus #15: MII read [3] -> 0x
[0.976646] IXP4xx MII Bus #16: MII read [2] -> 0x141
[0.976747] IXP4xx MII Bus #16: MII read [3] -> 0xC87
[0.978682] IXP4xx MII Bus #24: MII read [3] -> 0x602
[0.979235] IXP4xx MII Bus #17: MII read [2] -> 0x141
[0.979336] IXP4xx MII Bus #17: MII read [3] -> 0xC87
[0.981110] IXP4xx MII Bus #18: MII read [2] -> 0x141
[0.981211] IXP4xx MII Bus #18: MII read [3] -> 0xC87
[0.982664] IXP4xx MII Bus #19: MII read [2] -> 0x141
[0.982765] IXP4xx MII Bus #19: MII read [3] -> 0xC87
[0.984184] IXP4xx MII Bus #20: MII read [2] -> 0x141
[0.984285] IXP4xx MII Bus #20: MII read [3] -> 0xC87
[0.985770] IXP4xx MII Bus #21: MII read [2] -> 0x0
[0.985870] IXP4xx MII Bus #21: MII read [3] -> 0x0
[0.987322] IXP4xx MII Bus #22: MII read