netdev - Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2b1e69ed-7c95-d99c-5efc-bd5b23767d1e@gmail.com>
Date:   Sat, 29 Jul 2017 13:15:32 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Mason <slash.tmp@...e.fr>, Mans Rullgard <mans@...sr.com>
Cc:     Marc Gonzalez <marc_gonzalez@...madesigns.com>,
        "David S. Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open

On 07/29/2017 05:44 AM, Mason wrote:
> On 29/07/2017 14:05, Måns Rullgård wrote:
> 
>> Mason writes:
>>
>>> I'll take this opportunity to change flow control to
>>> off by default (it breaks several 100 Mbps switches).
>>
>> I was told to have it on by default.  This is what most other drivers
>> do too.  If you have faulty switches, that's your problem.
> 
> Or maybe the fault is in the HW implementation, and
> it is the board's fault that the connection is hosed.

If there really is a linkage with pause frames then it's a pretty binary
thing at the electrical interface level, either the (RG)MII connection
works, or or it does not, but pause frames are normal frames as far as
the electrical interface is concerned. Their special handling is at the
MAC level, see below.

> 
> How many switches did you test the driver on?
> 
> We tested 4 switches, and DHCP failed on 3 of them.
> Disabling pause frames "fixed" that.

OK, so it is this problem that you reported about before? Pause frames
are tricky in that receiving pause frames means you should backpressure
your transmitter and sending pause frames happens when your receiver
cannot keep up. It is somewhat conceivable that your HW implementation
is bogus and that you can get the HW in a state where it gets
permanently backpressured for instance? And then only a full re-init
would get you out of this stuck state presumably? Are there significant
differences at the DMA/Ethernet controller level between Tango 3 (is
that the one Mans worked on?) and Tango 4 for instance that could
explain a behavioral difference?

Some Ethernet NICs allow you to actually observe pause frames (AFAIR a
few Intel ones do) so you could conceivably set up a bridge with such a
NIC and snoop traffic between your tango4 board and your switch and see
what happens.

> 
> I could spend weeks testing dozens of switches, but
> I have to prioritize. Ethernet flow control is simply
> not an important feature in the market the SoC is
> intended for.

-- 
Florian