>-----Original Message----- >From: Daniel Walker <danie...@cisco.com> >Sent: Thursday, October 18, 2018 5:05 PM >To: Claudiu Manoil <claudiu.man...@nxp.com> >Cc: Hemant Ramdasi <hramd...@cisco.com>; netdev@vger.kernel.org >Subject: Re: [danie...@cisco.com: Re: gianfar: Implement MAC reset and >reconfig procedure] > [...] > >Here's some parts of the logs. I added a dump_stack() into adjust_link(). It >does appear to be running, but it seems it's not working or not doing what you >think it should be doing. The signature of the issue is below, you bring up the >interface the first time and it works, then bring it down/up and no traffic. >You can see in the second ping there is %100 packet loss. > >Seems the "Link is Up" lines indicate what adjust_link() changes. > >IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready >CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 3.14.0-rc3 #174 >Workqueue: events_power_efficient phy_state_machine >Call Trace: >[e81ffdb0] [c0008718] show_stack+0xfc/0x1bc (unreliable) >[e81ffe00] [c0602168] dump_stack+0x78/0xa0 >[e81ffe10] [c0437b20] adjust_link+0x30/0x2b0 >[e81ffe50] [c0430f1c] phy_state_machine+0x428/0x47c >[e81ffe70] [c0060a84] process_one_work+0x158/0x3c4 >[e81ffea0] [c0061120] worker_thread+0x138/0x384 >[e81ffed0] [c0068714] kthread+0xd0/0xe4 >[e81fff40] [c0011bc8] ret_from_kernel_thread+0x5c/0x64 >CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 3.14.0-rc3 #174 >Workqueue: events_power_efficient phy_state_machine >Call Trace: >[e81ffdb0] [c0008718] show_stack+0xfc/0x1bc (unreliable) >[e81ffe00] [c0602168] dump_stack+0x78/0xa0 >[e81ffe10] [c0437b20] adjust_link+0x30/0x2b0 >[e81ffe50] [c0430e60] phy_state_machine+0x36c/0x47c >[e81ffe70] [c0060a84] process_one_work+0x158/0x3c4 >[e81ffea0] [c0061120] worker_thread+0x138/0x384 >[e81ffed0] [c0068714] kthread+0xd0/0xe4 >[e81fff40] [c0011bc8] ret_from_kernel_thread+0x5c/0x64 >fsl-gianfar ff725000.ethernet eth1: Link is Up - 100Mbps/Full - flow control >off >IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready >PING 10.126.154.1 (10.126.154.1): 56 data bytes >64 bytes from 10.126.154.1: seq=0 ttl=255 time=5.606 ms > >--- 10.126.154.1 ping statistics --- >1 packets transmitted, 1 packets received, 0% packet loss >round-trip min/avg/max = 5.606/5.606/5.606 ms >CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 3.14.0-rc3 #174 >Workqueue: events_power_efficient phy_state_machine >Call Trace: >[e81ffdb0] [c0008718] show_stack+0xfc/0x1bc (unreliable) >[e81ffe00] [c0602168] dump_stack+0x78/0xa0 >[e81ffe10] [c0437b20] adjust_link+0x30/0x2b0 >[e81ffe50] [c0430f1c] phy_state_machine+0x428/0x47c >[e81ffe70] [c0060a84] process_one_work+0x158/0x3c4 >[e81ffea0] [c0061120] worker_thread+0x138/0x384 >[e81ffed0] [c0068714] kthread+0xd0/0xe4 >[e81fff40] [c0011bc8] ret_from_kernel_thread+0x5c/0x64 >CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 3.14.0-rc3 #174 >Workqueue: events_power_efficient phy_state_machine >Call Trace: >[e81ffdb0] [c0008718] show_stack+0xfc/0x1bc (unreliable) >[e81ffe00] [c0602168] dump_stack+0x78/0xa0 >[e81ffe10] [c0437b20] adjust_link+0x30/0x2b0 >[e81ffe50] [c0430e60] phy_state_machine+0x36c/0x47c >[e81ffe70] [c0060a84] process_one_work+0x158/0x3c4 >[e81ffea0] [c0061120] worker_thread+0x138/0x384 >[e81ffed0] [c0068714] kthread+0xd0/0xe4 >[e81fff40] [c0011bc8] ret_from_kernel_thread+0x5c/0x64 >fsl-gianfar ff725000.ethernet eth1: Link is Up - 100Mbps/Full - flow control >off >PING 10.126.154.1 (10.126.154.1): 56 data bytes > >--- 10.126.154.1 ping statistics --- >1 packets transmitted, 0 packets received, 100% packet loss
I can only advise you to check whether the MACCFG2 register settings are consistent at this point, when ping fails. You should check the I/F Mode bits (22-23) and the Full Duplex bit (31), in big-endian format. If these do not match the 100Mbps full duplex link mode, then it might be that another thread (probably doing reset_gfar) changes MACCFG2 concurrently. I think MACCFG2 may be dumped with ethtool -d. I can get my hands on a board no sooner than maybe next week. -Claudiu
