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
