Florian Fainelli writes:
> On 11/14/2016 11:00 AM, Måns Rullgård wrote:
>> Florian Fainelli writes:
>>
>>> On 11/14/2016 10:20 AM, Florian Fainelli wrote:
On 11/14/2016 09:59 AM, Sebastian Frias wrote:
> On 11/14/2016 06:32 PM, Florian Fainelli wrote:
>> On 11/14/2016 07:33 AM, Mas
Hi Florian,
On 11/14/2016 10:00 PM, Florian Fainelli wrote:
> On 11/14/2016 12:27 PM, Mason wrote:
>> On 14/11/2016 19:20, Florian Fainelli wrote:
>>
>>> On 11/14/2016 09:59 AM, Sebastian Frias wrote:
>>>
Could you confirm that Mason's patch is correct and/or that it does not
has negativ
On 14/11/2016 22:00, Florian Fainelli wrote:
> No I missed that, way too many emails, really.
Sorry, I was trying to be thorough, but I went overboard.
I'll start a new thread tomorrow, with a smaller CC list
(only those who have participated so far) and I'll try to
remain concise.
Regards.
On 11/14/2016 12:27 PM, Mason wrote:
> On 14/11/2016 19:20, Florian Fainelli wrote:
>
>> On 11/14/2016 09:59 AM, Sebastian Frias wrote:
>>
>>> Could you confirm that Mason's patch is correct and/or that it does not
>>> has negative side-effects?
>>
>> The patch is not correct nor incorrect per-se,
On 14/11/2016 19:20, Florian Fainelli wrote:
> On 11/14/2016 09:59 AM, Sebastian Frias wrote:
>
>> Could you confirm that Mason's patch is correct and/or that it does not
>> has negative side-effects?
>
> The patch is not correct nor incorrect per-se, it changes the default
> policy of having pau
On 11/14/2016 11:00 AM, Måns Rullgård wrote:
> Florian Fainelli writes:
>
>> On 11/14/2016 10:20 AM, Florian Fainelli wrote:
>>> On 11/14/2016 09:59 AM, Sebastian Frias wrote:
On 11/14/2016 06:32 PM, Florian Fainelli wrote:
> On 11/14/2016 07:33 AM, Mason wrote:
>> On 14/11/2016 15:5
Florian Fainelli writes:
> On 11/14/2016 10:20 AM, Florian Fainelli wrote:
>> On 11/14/2016 09:59 AM, Sebastian Frias wrote:
>>> On 11/14/2016 06:32 PM, Florian Fainelli wrote:
On 11/14/2016 07:33 AM, Mason wrote:
> On 14/11/2016 15:58, Mason wrote:
>
>> nb8800 26000.ethernet eth
On 11/14/2016 10:20 AM, Florian Fainelli wrote:
> On 11/14/2016 09:59 AM, Sebastian Frias wrote:
>> On 11/14/2016 06:32 PM, Florian Fainelli wrote:
>>> On 11/14/2016 07:33 AM, Mason wrote:
On 14/11/2016 15:58, Mason wrote:
> nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow
On 11/14/2016 09:59 AM, Sebastian Frias wrote:
> On 11/14/2016 06:32 PM, Florian Fainelli wrote:
>> On 11/14/2016 07:33 AM, Mason wrote:
>>> On 14/11/2016 15:58, Mason wrote:
>>>
nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
vs
nb8800 26000.ethernet eth0:
On 11/14/2016 06:32 PM, Florian Fainelli wrote:
> On 11/14/2016 07:33 AM, Mason wrote:
>> On 14/11/2016 15:58, Mason wrote:
>>
>>> nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
>>> vs
>>> nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
>>>
>>> I
On 11/14/2016 07:33 AM, Mason wrote:
> On 14/11/2016 15:58, Mason wrote:
>
>> nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
>> vs
>> nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
>>
>> I'm not sure whether "flow control" is relevant...
>
> B
On 14/11/2016 15:58, Mason wrote:
> nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
> vs
> nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
>
> I'm not sure whether "flow control" is relevant...
Based on phy_print_status()
phydev->pause ? "rx/tx
On 14/11/2016 14:34, Andrew Lunn wrote:
> Mason wrote:
>
>> How exactly does one use the generic PHY driver?
>
> If there is no specific driver available for the PHY, linux will fall
> back to the generic driver. So just don't compile the specific driver.
> You can see under /sys/bus/mdio_bus/de
> How exactly does one use the generic PHY driver?
If there is no specific driver available for the PHY, linux will fall
back to the generic driver. So just don't compile the specific driver.
You can see under /sys/bus/mdio_bus/devices which driver is being
used.
Andrew
On 13/11/2016 20:55, 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
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 y
On 14/11/2016 13:13, Mason wrote:
> This is a different log which I got earlier, but can no longer reproduce:
>
> # tcpdump -n -i eth1-boards ether host 00:16:e8:4b:b0:7d
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1-boards, link-type EN10MB (Eth
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 i
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 fi
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
> 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
Hello everyone,
In a past thread ("Ethernet not working on a different SoC with
same eth HW") I was struggling getting Ethernet to work at all on
a new board using a recent 4.7 kernel.
After much hair-pulling, it turned out that *some* of the breakage
was caused by a local patch which should have
22 matches
Mail list logo
