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] [thread-next>] [day] [month] [year] [list]
Message-ID: <YqG/pybFg0P5yQ9a@zx2c4.com>
Date:   Thu, 9 Jun 2022 11:38:47 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     "R, Monish Kumar" <monish.kumar.r@...el.com>
Cc:     "open list:NVM EXPRESS DRIVER" <linux-nvme@...ts.infradead.org>,
        Sagi Grimberg <sagi@...mberg.me>,
        "alan.adamson@...cle.com" <alan.adamson@...cle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Yi Zhang <yi.zhang@...hat.com>,
        Keith Busch <kbusch@...nel.org>, "axboe@...com" <axboe@...com>,
        Christoph Hellwig <hch@....de>,
        "Rao, Abhijeet" <abhijeet.rao@...el.com>
Subject: Re: 2 second nvme initialization delay regression in 5.18 [Was: Re:
 [bug report]nvme0: Admin Cmd(0x6), I/O Error (sct 0x0 / sc 0x2) MORE DNR
 observed during blktests]

Hi Monish,

On Thu, Jun 09, 2022 at 09:32:02AM +0000, R, Monish Kumar wrote:
> Hi Jason,
> 
> I would like to provide justification for this Samsung X5 SSD fix added.
> We were facing SSD enumeration issue after cold / warm reboot with device 
> connected ends up with probe failures.
> 
> When I debug on this issue, I could find that this device was not enumerating 
> once the system got booted. Moreover, we were facing this enumeration issue
> specific to this device. 
> 
> Based on analysis, due to deep power state of the device fails to enumerate.
> So, added the following quirks as a workaround fixe and it helps to enumerate the device after cold/warm reboot. If new Samsung X5 SSD's are working fine as expected, we can remove those 
> fix. 

FWIW, all of that should have been in the commit message. Also, "based
on analysis" - what analysis exactly? I have no way of thinking more
about the issue at hand other than, "Monish said things are like this in
a lab".

In any case, I believe the 970 ID predates that of the X5, and
destroying battery on those laptops and introducing boot time delays
isn't really okay. So let's just revert this until somebody can work out
better how to differentiate drives that need a quirk from drives that
don't need a quirk.

I sent this in: https://lore.kernel.org/lkml/20220609084051.4445-1-Jason@zx2c4.com/

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ