On 8/2/17 6:15 PM, David Miller wrote:
So you don't want to run a proper watchdog on your systems?
You want them to just hang there and wait for someone to
notice instead?
This is for internal development. We noticed the problem first during
debugging, when we would halt a core for more than
From: Timur Tabi
Date: Wed, 2 Aug 2017 13:39:34 -0500
> On 08/02/2017 01:35 PM, David Miller wrote:
>> Again, any serious installation will have a system watchdog enabled
>> which will break the pause frame bomb.
>
> Oh well. I guess I'll have to carry this patch internally.
So you don't want
On 08/02/2017 01:35 PM, David Miller wrote:
Again, any serious installation will have a system watchdog enabled
which will break the pause frame bomb.
Oh well. I guess I'll have to carry this patch internally.
What about patch #2?
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of
From: Timur Tabi
Date: Wed, 2 Aug 2017 13:23:18 -0500
> It's practically impossible to overload the chip such that it can't
> process the incoming packets fast enough. I don't know of any
> real-world situation where the EMAC needs to transmit pause frames.
Slow cpus or very expensive stack ope
From: Timur Tabi
Date: Wed, 2 Aug 2017 13:23:18 -0500
> On 08/02/2017 12:54 PM, David Miller wrote:
>> And if this kind of thing matters to the user, they will have a
>> software or hardware watchdog driver enabled to break out of this
>> situation.
>
> The problem is that the user is not going
On 08/02/2017 12:54 PM, David Miller wrote:
And if this kind of thing matters to the user, they will have a
software or hardware watchdog driver enabled to break out of this
situation.
The problem is that the user is not going to expect that the EMAC can
disable the nearby switch(es) when the
From: Timur Tabi
Date: Tue, 1 Aug 2017 16:37:39 -0500
> The EMAC has a curious qwirk when RX flow control is enabled and the
> kernel hangs. With the kernel hung, the EMAC's RX queue soon fills.
> If RX flow control is enabled, the EMAC will then send a non-stop
> stream of pause frames until t
From: Timur Tabi
> Sent: 02 August 2017 16:09
> On 08/02/2017 09:51 AM, David Laight wrote:
> > Sending pause frames just tells the adjacent switch not to send you packets
> > (because you'll discard them).
> > Since the idea is to avoid the discards, the switch will buffer the
> > packets it would
On 08/02/2017 09:51 AM, David Laight wrote:
Sending pause frames just tells the adjacent switch not to send you packets
(because you'll discard them).
Since the idea is to avoid the discards, the switch will buffer the
packets it would have sent.
The buffers in the switch then fill up with packet
From: Timur Tabi
> Sent: 02 August 2017 15:22
> On 8/2/17 8:48 AM, David Laight wrote:
> > If the nearby switches cannot handle pause frames, then the MAC shouldn't
> > be sending them at all.
>
> There's no way for me to know whether the switches can handle the pause
> frames or not. You would t
On 8/2/17 8:48 AM, David Laight wrote:
If the nearby switches cannot handle pause frames, then the MAC shouldn't
be sending them at all.
There's no way for me to know whether the switches can handle the pause
frames or not. You would think that sending one multicast pause frame
ever 33ms wou
From: Timur Tabi
> Sent: 01 August 2017 22:38
> The EMAC has a curious qwirk when RX flow control is enabled and the
> kernel hangs. With the kernel hung, the EMAC's RX queue soon fills.
> If RX flow control is enabled, the EMAC will then send a non-stop
> stream of pause frames until the system i
On 8/1/17 9:58 PM, Andrew Lunn wrote:
The PHY does not participate directly in flow control/pause frames except by
making sure that the SUPPORTED_Pause and SUPPORTED_AsymPause bits are set in
MII_ADVERTISE to indicate towards the link partner that the Ethernet MAC
controller supports such
On Tue, Aug 01, 2017 at 07:56:31PM -0500, Timur Tabi wrote:
> On 8/1/17 6:15 PM, Andrew Lunn wrote:
> >Pause frames are something you can auto-negotiate at the PHY
> >level. Should you also be clearing some bits in the phydev, so the
> >peer knows pause frames are not supported?
>
> When pause fra
On 8/1/17 6:15 PM, Andrew Lunn wrote:
Pause frames are something you can auto-negotiate at the PHY
level. Should you also be clearing some bits in the phydev, so the
peer knows pause frames are not supported?
When pause frame autonegotiation is enabled in the driver, that only
means that the d
On Tue, Aug 01, 2017 at 04:37:39PM -0500, Timur Tabi wrote:
> The EMAC has a curious qwirk when RX flow control is enabled and the
> kernel hangs. With the kernel hung, the EMAC's RX queue soon fills.
> If RX flow control is enabled, the EMAC will then send a non-stop
> stream of pause frames unti
On 08/01/2017 03:02 PM, Timur Tabi wrote:
> On 08/01/2017 04:55 PM, Florian Fainelli wrote:
>> This is not specific to your EMAC, a lot of adapters have this problem
>> actually.
>>
>> I wonder if it would make sense to reach for a broader solution where we
>> could have a networking stack panic/oo
On 08/01/2017 04:55 PM, Florian Fainelli wrote:
This is not specific to your EMAC, a lot of adapters have this problem
actually.
I wonder if it would make sense to reach for a broader solution where we
could have a networking stack panic/oops notifier which will actively
clean up the active netw
On 08/01/2017 02:37 PM, Timur Tabi wrote:
> The EMAC has a curious qwirk when RX flow control is enabled and the
> kernel hangs. With the kernel hung, the EMAC's RX queue soon fills.
> If RX flow control is enabled, the EMAC will then send a non-stop
> stream of pause frames until the system is re
The EMAC has a curious qwirk when RX flow control is enabled and the
kernel hangs. With the kernel hung, the EMAC's RX queue soon fills.
If RX flow control is enabled, the EMAC will then send a non-stop
stream of pause frames until the system is reset. The EMAC does not
have a built-in watchdog.
20 matches
Mail list logo
