RE: Fw: [External] Re: [PATCH v4 0/4] Improve s0ix flows for systems i219LM

2020-12-15 Thread Limonciello, Mario
> > Absolutely - I'll ask them to look into this again. > > > we need to explain why on Windows systems required 1s and on Linux > systems up to 2.5s - otherwise it is not reliable approach - you will > encounter others buggy system. > (ME not POR on the Linux systems - is only one possible answer

RE: [PATCH v4 0/4] Improve s0ix flows for systems i219LM

2020-12-14 Thread Limonciello, Mario
> Hi All, > > Sasha (and the other intel-wired-lan folks), thank you for investigating this > further and for coming up with a better solution. > > Mario, thank you for implementing the new scheme. > Sure. > I've tested this patch set on a Lenovo X1C8 with vPRO and AMT enabled in the > BIOS >

RE: [PATCH v3 0/7] Improve s0ix flows for systems i219LM

2020-12-08 Thread Limonciello, Mario
> > Based on the earlier thread you had referenced and his comment here it > sounds like while adding time will work for most cases, it doesn't > solve it for all cases. The problem is as a vendor you are usually > stuck looking for a solution that will work for all cases which can > lead to thing

RE: [PATCH v3 0/7] Improve s0ix flows for systems i219LM

2020-12-07 Thread Limonciello, Mario
> First of all thank you for working on this. > > I must say though that I don't like the approach taken here very > much. > > This is not so much a criticism of this series as it is a criticism > of the earlier decision to simply disable s0ix on all devices > with the i219-LM + and active ME. I

RE: [PATCH v3 0/7] Improve s0ix flows for systems i219LM

2020-12-04 Thread Limonciello, Mario
> -Original Message- > From: Alexander Duyck > Sent: Friday, December 4, 2020 15:27 > To: Limonciello, Mario > Cc: Jeff Kirsher; Tony Nguyen; intel-wired-lan; LKML; Linux PM; Netdev; Jakub > Kicinski; Sasha Netfin; Aaron Brown; Stefan Assmann; David Miller; David >

RE: [PATCH v2 0/5] Improve s0ix flows for systems i219LM

2020-12-02 Thread Limonciello, Mario
> > > On Wed, 2 Dec 2020 10:17:43 -0600 Mario Limonciello wrote: > > > > commit e086ba2fccda ("e1000e: disable s0ix entry and exit flows for ME > > > systems") > > > > disabled s0ix flows for systems that have various incarnations of the > > > > i219-LM ethernet controller. This was done because

RE: [PATCH v2 0/5] Improve s0ix flows for systems i219LM

2020-12-02 Thread Limonciello, Mario
> -Original Message- > From: Jakub Kicinski > Sent: Wednesday, December 2, 2020 13:07 > To: Limonciello, Mario > Cc: Tony Nguyen; intel-wired-...@lists.osuosl.org; Linux PM; Netdev; Alexander > Duyck; Sasha Netfin; Aaron Brown; Stefan Assmann; David Miller; > dar

RE: [net-next 1/4] e1000e: allow turning s0ix flows on for systems with ME

2020-11-30 Thread Limonciello, Mario
> On Mon, Nov 30, 2020 at 2:16 PM Limonciello, Mario > wrote: > > > > > > > > Generally the use of module parameters and sysfs usage are frowned > > > upon. > > > > I was trying to build on the existing module parameters that existed >

RE: [net-next 2/4] e1000e: Add Dell's Comet Lake systems into s0ix heuristics

2020-11-30 Thread Limonciello, Mario
> On Mon, Nov 30, 2020 at 1:32 PM Tony Nguyen > wrote: > > > > From: Mario Limonciello > > > > Dell's Comet Lake Latitude and Precision systems containing i219LM are > > properly configured and should use the s0ix flows. > > > > Signed-off-by: Mario Limonciello > > Tested-by: Yijun Shen > > Sig

RE: [net-next 1/4] e1000e: allow turning s0ix flows on for systems with ME

2020-11-30 Thread Limonciello, Mario
> > Generally the use of module parameters and sysfs usage are frowned > upon. I was trying to build on the existing module parameters that existed already for e1000e. So I guess I would ask, why are those not done in ethtool? Should those parameters go away and they migrate to ethtool for the