On Fri, Dec 22, 2017 at 4:30 PM, David Daney wrote:
> On 12/22/2017 04:22 PM, Tim Harvey wrote:
>>
>> BGXX_GMP_GMI_TXX_INT[UNDFLW] is getting set when the issue is
>> triggered. From CN80XX-HM-1.2P this is caused by:
>>
>> "In the unlikely event that P2X data cannot keep the GMP TX FIFO full,
>>
On 12/22/2017 04:22 PM, Tim Harvey wrote:
On Fri, Dec 22, 2017 at 3:00 PM, David Daney wrote:
On 12/22/2017 02:19 PM, Tim Harvey wrote:
On Tue, Dec 19, 2017 at 12:52 PM, Andrew Lunn wrote:
On Mon, Dec 18, 2017 at 01:53:47PM -0800, Tim Harvey wrote:
On Wed, Dec 13, 2017 at 11:43 AM, Andre
On Fri, Dec 22, 2017 at 3:00 PM, David Daney wrote:
> On 12/22/2017 02:19 PM, Tim Harvey wrote:
>>
>> On Tue, Dec 19, 2017 at 12:52 PM, Andrew Lunn wrote:
>>>
>>> On Mon, Dec 18, 2017 at 01:53:47PM -0800, Tim Harvey wrote:
On Wed, Dec 13, 2017 at 11:43 AM, Andrew Lunn wrote:
>>
>>>
On Fri, Dec 22, 2017 at 2:45 PM, Andrew Lunn wrote:
>> Currently I'm not using the DP83867_PHY driver (after verifying the
>> issue occurs with or without that driver).
>>
>> It does not occur if I limit UDP (ie 950mbps). I disabled all offloads
>> and the issue still occurs.
>
>> I'm told that th
On 12/22/2017 02:19 PM, Tim Harvey wrote:
On Tue, Dec 19, 2017 at 12:52 PM, Andrew Lunn wrote:
On Mon, Dec 18, 2017 at 01:53:47PM -0800, Tim Harvey wrote:
On Wed, Dec 13, 2017 at 11:43 AM, Andrew Lunn wrote:
The nic appears to work fine (pings, TCP etc) up until a performance
test is attempt
> Currently I'm not using the DP83867_PHY driver (after verifying the
> issue occurs with or without that driver).
>
> It does not occur if I limit UDP (ie 950mbps). I disabled all offloads
> and the issue still occurs.
> I'm told that the particular Cavium reference board with an SGMII phy
> doe
On Tue, Dec 19, 2017 at 12:52 PM, Andrew Lunn wrote:
> On Mon, Dec 18, 2017 at 01:53:47PM -0800, Tim Harvey wrote:
>> On Wed, Dec 13, 2017 at 11:43 AM, Andrew Lunn wrote:
>> >> The nic appears to work fine (pings, TCP etc) up until a performance
>> >> test is attempted.
>> >> When an iperf bandwi
On Mon, Dec 18, 2017 at 01:53:47PM -0800, Tim Harvey wrote:
> On Wed, Dec 13, 2017 at 11:43 AM, Andrew Lunn wrote:
> >> The nic appears to work fine (pings, TCP etc) up until a performance
> >> test is attempted.
> >> When an iperf bandwidth test is attempted the nic ends up in a state
> >> where
On Tue, Dec 19, 2017 at 3:23 AM, Tim Harvey wrote:
> On Wed, Dec 13, 2017 at 11:43 AM, Andrew Lunn wrote:
>>> The nic appears to work fine (pings, TCP etc) up until a performance
>>> test is attempted.
>>> When an iperf bandwidth test is attempted the nic ends up in a state
>>> where truncated-ip
On Wed, Dec 13, 2017 at 11:43 AM, Andrew Lunn wrote:
>> The nic appears to work fine (pings, TCP etc) up until a performance
>> test is attempted.
>> When an iperf bandwidth test is attempted the nic ends up in a state
>> where truncated-ip packets are being sent out (per a tcpdump from
>> another
> The nic appears to work fine (pings, TCP etc) up until a performance
> test is attempted.
> When an iperf bandwidth test is attempted the nic ends up in a state
> where truncated-ip packets are being sent out (per a tcpdump from
> another board):
Hi Tim
Are pause frames supported? Have you trie
Greetings,
We are experiencing an issue on a CN80XX with an SGMII interface
coupled to a TI DP83867IS phy. We have the same PHY connected to the
RGMII interface on the same board design and everything is working as
expected on that nic both before and after triggering the hang.
The nic appears to
12 matches
Mail list logo
