From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 03953C83F2C for ; Tue, 5 Sep 2023 16:46:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229446AbjIEQqX (ORCPT ); Tue, 5 Sep 2023 12:46:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45676 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243131AbjIEQjc (ORCPT ); Tue, 5 Sep 2023 12:39:32 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 755F076BE; Tue, 5 Sep 2023 09:35:33 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6EF0A60B99; Tue, 5 Sep 2023 16:34:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2FC1FC433C7; Tue, 5 Sep 2023 16:34:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1693931651; bh=X5L10YoHz2zVk5p4qYnAUloFN9ZU4ucYAmPjaaoOySo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZiRm+ulKAd/8crD2KbxWsd8Z1u6QSPzvjsg3PZi/Ay9sIVGqFZh1oiDzQ3Iuh1tHJ q2s5rvZgpGwFwt7+D9xghQlwMy5cya4SYELzWd5VinCDXVWABFJ/oyHVo62d5UyzXp 8qhJO2iairFbbwQ+eEVxTK9It94jANP8iPShHeR6dRwnPdLUBjctZN2V1srDCPdN5J C0Z8vTh3s//RVWM9P1Wy0qmpqbSWEXj6uBT/yVxsSqgXHdNIC2whzwI5baDILCe21A LPPE9/6G9J0KwHuvHBjd0aoO4zgl+aYA34WVJf7FZQIZcUc2/ekrBPr0sYhkiV1Ady xiG14GAhJs2pg== Date: Tue, 5 Sep 2023 10:34:08 -0600 From: Keith Busch To: =?iso-8859-1?Q?Cl=E1udio?= Sampaio Cc: Linux regressions mailing list , Bagas Sanjaya , Jens Axboe , Christoph Hellwig , Sagi Grimberg , Linux Kernel Mailing List , Linux NVMe , Linux Stable Subject: Re: Fwd: Lexar NM790 SSDs are not recognized anymore after 6.1.50 LTS Message-ID: References: <8af186ba-5f64-2102-8f9c-3969b0906893@gmail.com> <2a379b3a-6ff3-444b-bbad-0fba0bc3a28b@leemhuis.info> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Tue, Sep 05, 2023 at 05:50:06PM +0200, Cláudio Sampaio wrote: > Hi Thorsten and Keith, > > Thanks for the details. I'm still unsure if responding by email is better > or adding to the ticket, but here it goes: I have tried for days both with > complete power off of the machine and cycle-booting all kernels in > succession and without exception, 6.1.x LTS and the patched 6.5.1 kernel > always recognize and operate the NVME, whilst the other kernels also fail > with the same error message. As this is my "production" desktop, though, > during the week it's more difficult to me to perform tests with it, but I > will try to do it in a more methodic way and also with 6.5.1 vanilla. > > As for the reason the Lexar doesn't catch the quirk default, I can't say I > catch the complex logic of the driver activation, but I found out how to > "fix" for my case because there are three other Lexar models in the pci.c > file: NM610, NM620 and NM760 (this one with an additional quirk marked on > it on the code, NVME_QUIRK_IGNORE_DEV_SUBNQN) -- so I guess whatever > justifies the exception for them also justifies for my model, NM790. Might > even be the case that I would need NVME_QUIRK_IGNORE_DEV_SUBNQN (not sure > what it does) like in the NM760 case, but it activates correctly without it. The existing Lexar quirks for the identifier existed before the default kernel behavior changed with respect to how identifiers are considered. But the report says the device failed to enumerate with a "device not ready" error message. That error message happens *before* identifiers are checked, so the quirk should be a no-op with respect to that error message. And the driver abandons the device after printing that message, so no futher action should be taken no matter what quirk you've set. In order for this quirk to have any effect at all, the error you should have seen should look like a "duplicate IDs" message.