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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <9bac261e-0efb-fe07-7c3e-6c4ff156bb67@intel.com>
Date:   Tue, 15 Dec 2020 20:36:18 +0200
From:   "Neftin, Sasha" <sasha.neftin@...el.com>
To:     "Limonciello, Mario" <Mario.Limonciello@...l.com>,
        Mark Pearson <markpearson@...ovo.com>,
        Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        Tony Nguyen <anthony.l.nguyen@...el.com>,
        "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
        David Miller <davem@...emloft.net>,
        Aaron Ma <aaron.ma@...onical.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Netdev <netdev@...r.kernel.org>,
        Alexander Duyck <alexander.duyck@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Aaron Brown <aaron.f.brown@...el.com>,
        Stefan Assmann <sassmann@...hat.com>,
        "darcari@...hat.com" <darcari@...hat.com>,
        "Shen, Yijun" <Yijun.Shen@...l.com>,
        "Yuan, Perry" <Perry.Yuan@...l.com>,
        "anthony.wong@...onical.com" <anthony.wong@...onical.com>,
        "Ruinskiy, Dima" <dima.ruinskiy@...el.com>,
        "Efrati, Nir" <nir.efrati@...el.com>,
        "Lifshits, Vitaly" <vitaly.lifshits@...el.com>,
        "Neftin, Sasha" <sasha.neftin@...el.com>
Subject: Re: Fw: [External] Re: [PATCH v4 0/4] Improve s0ix flows for systems
 i219LM

On 12/15/2020 19:20, Limonciello, Mario wrote:
> 
>>> 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)
> 
> Sasha: In your opinion does this information need to block the series?
> or can we follow up with more changes later on as more information becomes
> available?
> 
I do not think this should block the patches series.
> For now v5 of the series extends the timeout but at least makes a mention
> that there appears to be a firmware bug when more than 1 second is taken.
>