On Nov11 22:13, Rustad, Mark D wrote:
> Just so you know, there are patches in queue that will improve this situation
> in two ways:
> 1) When the I2C probe times out, the code assumes that the cage is empty and
> does not retry the access until the next probe.
> 2) The driver will use its own pr
William,
Emil S wrote:
>> It also fixes my issue: even if eth{2,3} are still up with no carrier, I
>> don't have any kworker in D state.
>
> It appears that you have 2 ports with empty cages. If that is the case there
> is no reason to keep the interfaces up. If you bring them down, or plug the
On 11/11/2015 01:34 PM, William Dauchy wrote:
On Nov11 20:33, Tantilov, Emil S wrote:
If the diff above is the patch you are referring to then you will break the
SFP+ detection in the case where the driver was loaded while there were no
SFP+ modules present in the cages.
understood, I was surpr
On Nov11 20:33, Tantilov, Emil S wrote:
> If the diff above is the patch you are referring to then you will break the
> SFP+ detection in the case where the driver was loaded while there were no
> SFP+ modules present in the cages.
understood, I was surprised of the modification of behavior.
--
>-Original Message-
>From: William Dauchy [mailto:will...@gandi.net]
>Sent: Wednesday, November 11, 2015 9:35 AM
>To: Kirsher, Jeffrey T; Tantilov, Emil S
>Cc: da...@davemloft.net; netdev@vger.kernel.org; Schmitt, Phillip J; intel-
>wired-...@lists.osuosl.org
>Subject
Hello,
I upgraded a machine from 3.14.x to v4.1.x and noted that I now have two
kworker very often on D state, just after boot while I am not doing
anything special. This issue remains indefinitely.
This machine has four network interfaces:
01:00.0 Ethernet controller: Intel Corporation 82576 G
