lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181018140505.6q6bzx6uboqbimq6@zorba>
Date:   Thu, 18 Oct 2018 07:05:05 -0700
From:   Daniel Walker <danielwa@...co.com>
To:     Claudiu Manoil <claudiu.manoil@....com>
Cc:     Hemant Ramdasi <hramdasi@...co.com>, netdev@...r.kernel.org
Subject: Re: [danielwa@...co.com: Re: gianfar: Implement MAC reset and
 reconfig procedure]

On Thu, Oct 18, 2018 at 12:16:06PM +0000, Claudiu Manoil wrote:
> Hi,
> 
> Sorry but I never heard about the phy you're quoting, this m88e1101, what is it?
> Link mode? (SGMII, RGMII, ?)
> Our boards (the ones I know) have Vitesse or Atheros phys.
> If the maccfg2 setting you're mentioning really makes the difference, then it looks
> like your phy enters in 10/100 Mbit or half duplex operation mode after MAC reset,
> aka lower speed MII mode, whereas the INIT_SETTINGS set up the MAC to operate
> in 1000 full duplex mode (GMII mode) by default.
> Link speed settings for the MACCFG2 register should be later adjusted via adjust_link() callback,
> so that if the initial maccfg2 settings don't match with the phy settings they will be adjusted
> by phylib's adjust_link().  For some reason this doesn't seem to happen on your setup either.
> So, could you please confirm whether after MAC reset your phy enters lower speed mode (MII),
> and whether the adjust_link() callback is getting invoked after ifconfig up?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ