From: Sebastian Frias <sf84@laposte•net>
To: Florian Fainelli <f.fainelli@gmail•com>,
Mason <slash.tmp@free•fr>, Andrew Lunn <andrew@lunn•ch>
Cc: netdev <netdev@vger•kernel.org>, Mans Rullgard <mans@mansr•com>,
Sergei Shtylyov <sergei.shtylyov@cogentembedded•com>,
Tom Lendacky <thomas.lendacky@amd•com>,
Zach Brown <zach.brown@ni•com>, Shaohui Xie <shaohui.xie@nxp•com>,
Tim Beale <tim.beale@alliedtelesis•co.nz>,
Brian Hill <brian@houston-radar•com>,
Vince Bridgers <vbridgers2013@gmail•com>,
Balakumaran Kannan <kumaran.4353@gmail•com>,
"David S. Miller" <davem@davemloft•net>,
Kirill Kapranov <kapranoff@inbox•ru>
Subject: Re: Debugging Ethernet issues
Date: Mon, 14 Nov 2016 14:03:59 +0100 [thread overview]
Message-ID: <5829B63F.9050306@laposte.net> (raw)
In-Reply-To: <9d1f28a7-959b-fdde-3403-f6da5f521125@gmail.com>
On 11/13/2016 08:55 PM, Florian Fainelli wrote:
> Le 13/11/2016 à 11:51, Mason a écrit :
>> On 13/11/2016 04:09, Andrew Lunn wrote:
>>
>>> Mason wrote:
>>>
>>>> When connected to a Gigabit switch
>>>> 3.4 negotiates a LAN DHCP setup instantly
>>>> 4.7 requires over 5 seconds to do so
>>>
>>> When you run tcpdump on the DHCP server, are you noticing the first
>>> request is missing?
>>>
>>> What can happen is the dhclient gets started immediately and sends out
>>> its first request before auto-negotiation has finished. So this first packet
>>> gets lost. The retransmit after a few seconds is then successful.
>>
>> I will run tcpdump on the server as I run udhcpc on the client
>> for Linux 3.4 vs 4.7
>>
>> Do you know what would make auto-negotiation fail at 100 Mbps
>> on 4.7? (whereas it succeeds on 3.4)
>>
>> (Thinking out loud) If the problem were in auto-negotiation,
>> then if should work if I hard-code speed and duplex using
>> ethtool, right? (IIRC, hard-coding doesn't help.)
>
> I would start with checking basic things:
>
> - does your Ethernet driver get a link UP being reported correctly
> (netif_carrier_ok returns 1)?
> - if you let the bootloader configure the PHY and utilize the Generic
> PHY driver instead of the Atheros PHY driver, does the problem appear as
> well?
Would using a "fixed-link" serve the same?
It appears that using a fixed-link
ð0 {
#address-cells = <1>;
#size-cells = <0>;
#ifdef WITH_FIXED_LINK
phy-connection-type = "rgmii";
fixed-link {
speed = <100>;
full-duplex;
};
#else
phy-connection-type = "rgmii";
phy-handle = <ð0_phy>;
/* Atheros AR8035 */
eth0_phy: ethernet-phy@4 {
interrupt-parent = <&irq0>;
compatible = "ethernet-phy-id004d.d072",
"ethernet-phy-ieee802.3-c22";
interrupts = <37 IRQ_TYPE_EDGE_RISING>;
reg = <4>;
};
#endif
};
works.
----
For what is worth, the patch that Mason was talking about earlier
in the thread:
"...After much hair-pulling, it turned out that *some* of the breakage
was caused by a local patch..."
was setting changing the following delay in 'drivers/net/phy/phy.c:phy_state_machine()'
/* Only re-schedule a PHY state machine change if we are polling the
* PHY, if PHY_IGNORE_INTERRUPT is set, then we will be moving
* between states from phy_mac_interrupt()
*/
if (phydev->irq == PHY_POLL)
queue_delayed_work(system_power_efficient_wq, &phydev->state_queue,
PHY_STATE_TIME * HZ);
from "PHY_STATE_TIME * HZ" to "0".
That caused 2 of 3 types of boards to fail, while one of them always worked
regardless of the delay.
In a nutshell:
- Board A, chip X: works with delay "PHY_STATE_TIME * HZ" or "0".
- Board B, chip X: does not work with delay "0"
- Board C, chip Y: does not work with delay "0"
Does board A works by "luck" when this delay is "0"?
(this delay has always been there, but it is not clear why)
> - what do transmit/receive counters on the Ethernet driver/MAC return?
>
next prev parent reply other threads:[~2016-11-14 13:04 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-13 0:01 Debugging Ethernet issues Mason
2016-11-13 3:09 ` Andrew Lunn
2016-11-13 19:51 ` Mason
2016-11-13 19:55 ` Florian Fainelli
2016-11-14 13:03 ` Sebastian Frias [this message]
2016-11-14 13:28 ` Mason
2016-11-14 13:34 ` Andrew Lunn
2016-11-14 14:58 ` Mason
2016-11-14 15:33 ` Mason
2016-11-14 17:32 ` Florian Fainelli
2016-11-14 17:59 ` Sebastian Frias
2016-11-14 18:20 ` Florian Fainelli
2016-11-14 18:42 ` Florian Fainelli
2016-11-14 19:00 ` Måns Rullgård
2016-11-14 19:19 ` Florian Fainelli
2016-11-17 22:17 ` Måns Rullgård
2016-11-14 20:27 ` Mason
2016-11-14 21:00 ` Florian Fainelli
2016-11-14 22:48 ` Mason
2016-11-16 11:10 ` Sebastian Frias
2016-11-14 12:13 ` Mason
2016-11-14 12:45 ` Mason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5829B63F.9050306@laposte.net \
--to=sf84@laposte$(echo .)net \
--cc=andrew@lunn$(echo .)ch \
--cc=brian@houston-radar$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=f.fainelli@gmail$(echo .)com \
--cc=kapranoff@inbox$(echo .)ru \
--cc=kumaran.4353@gmail$(echo .)com \
--cc=mans@mansr$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=sergei.shtylyov@cogentembedded$(echo .)com \
--cc=shaohui.xie@nxp$(echo .)com \
--cc=slash.tmp@free$(echo .)fr \
--cc=thomas.lendacky@amd$(echo .)com \
--cc=tim.beale@alliedtelesis$(echo .)co.nz \
--cc=vbridgers2013@gmail$(echo .)com \
--cc=zach.brown@ni$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox