linux-kernel - Re: Fwd: Kernel 6.5.2 Causes Marvell Technology Group 88SE9128 PCIe SATA to Constantly Reset

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: <ZQSEXl0GB3iKoqjZ@x1-carbon>
Date:   Fri, 15 Sep 2023 16:20:47 +0000
From:   Niklas Cassel <Niklas.Cassel@....com>
To:     David Gow <david@...idgow.net>
CC:     Damien Le Moal <dlemoal@...nel.org>,
        Bagas Sanjaya <bagasdotme@...il.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        patenteng <dimitar@...kalov.co.uk>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Regressions <regressions@...ts.linux.dev>,
        Linux IDE and libata <linux-ide@...r.kernel.org>,
        Linux PCI <linux-pci@...r.kernel.org>
Subject: Re: Fwd: Kernel 6.5.2 Causes Marvell Technology Group 88SE9128 PCIe
 SATA to Constantly Reset

On Fri, Sep 15, 2023 at 08:26:58PM +0800, David Gow wrote:
> In any case, the bisect is done:
> 
> 624885209f31eb9985bf51abe204ecbffe2fdeea is the first bad commit
> commit 624885209f31eb9985bf51abe204ecbffe2fdeea
> Author: Damien Le Moal <dlemoal@...nel.org>
> Date:   Thu May 11 03:13:41 2023 +0200
> 
>     scsi: core: Detect support for command duration limits
> 
>     Introduce the function scsi_cdl_check() to detect if a device supports
>     command duration limits (CDL). Support for the READ 16, WRITE 16, READ
> 32
>     and WRITE 32 commands are checked using the function
> scsi_report_opcode()
>     to probe the rwcdlp and cdlp bits as they indicate the mode page
> defining
>     the command duration limits descriptors that apply to the command being
>     tested.
> 
>     If any of these commands support CDL, the field cdl_supported of struct
>     scsi_device is set to 1 to indicate that the device supports CDL.
> 
>     Support for CDL for a device is advertizes through sysfs using the new
>     cdl_supported device attribute. This attribute value is 1 for a device
>     supporting CDL and 0 otherwise.
> 
>     Signed-off-by: Damien Le Moal <dlemoal@...nel.org>
>     Reviewed-by: Hannes Reinecke <hare@...e.de>
>     Co-developed-by: Niklas Cassel <niklas.cassel@....com>
>     Signed-off-by: Niklas Cassel <niklas.cassel@....com>
>     Link: https://lore.kernel.org/r/20230511011356.227789-9-nks@flawful.org
>     Signed-off-by: Martin K. Petersen <martin.petersen@...cle.com>
> 
>  Documentation/ABI/testing/sysfs-block-device |  9 ++++
>  drivers/scsi/scsi.c                          | 81
> ++++++++++++++++++++++++++++
>  drivers/scsi/scsi_scan.c                     |  3 ++
>  drivers/scsi/scsi_sysfs.c                    |  2 +
>  include/scsi/scsi_device.h                   |  3 ++
>  5 files changed, 98 insertions(+)
> 
> 
> This seems to match what was found on the Arch Linux forums, too:
> https://bbs.archlinux.org/viewtopic.php?id=288723&p=3
> 
> I haven't tried it yet, but according to that forum thread, removing the
> calls to scsi_cdl_check() seems to resolve the issue. This is all well
> beyond my SCSI knowledge, but maybe a quirk to disable these CDL checks for
> these older marvell controllers is required? Though it seems odd that the
> device would be rescanned and/or scsi_add_lun called multiple times a second
> -- is that normal?
> 
> In any case, this seems to be the cause.

Hello David,

Thank you very much for your effort of bisecting this.

Could you please try this patch and see if it improves things for you:
https://lore.kernel.org/linux-scsi/20230915022034.678121-1-dlemoal@kernel.org/


Kind regards,
Niklas