[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <41b3cf11-6129-60d8-436a-b957b442a4bc@acm.org>
Date: Wed, 17 Aug 2022 12:28:46 -0700
From: Bart Van Assche <bvanassche@....org>
To: Vlastimil Babka <vbabka@...e.cz>,
Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: "Martin K . Petersen" <martin.petersen@...cle.com>,
Jaegeuk Kim <jaegeuk@...nel.org>,
scsi <linux-scsi@...r.kernel.org>,
Ming Lei <ming.lei@...hat.com>, Hannes Reinecke <hare@...e.de>,
John Garry <john.garry@...wei.com>, ericspero@...oud.com,
jason600.groome@...il.com,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-ide@...r.kernel.org,
James Bottomley <James.Bottomley@...senpartnership.com>,
regressions@...ts.linux.dev
Subject: Re: [PATCH v2 2/2] scsi: sd: Rework asynchronous resume support
On 8/17/22 12:07, Vlastimil Babka wrote:
> In my case it's
> /sys/devices/pci0000:00/0000:00:17.0/ata1/host0/scsi_host/host0/proc_name:ahci
> /sys/devices/pci0000:00/0000:00:17.0/ata2/host1/scsi_host/host1/proc_name:ahci
>
> Some more details from dmesg
>
> [ 0.849373] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> [ 0.852849] ata2.00: ACPI cmd f5/00:00:00:00:00:a0(SECURITY FREEZE LOCK) filtered out
> [ 0.854671] ata2.00: supports DRM functions and may not be fully accessible
> [ 0.856181] ata2.00: ATA-9: SAMSUNG MZ7LN512HMJP-000L7, MAV01L6Q, max UDMA/133
> [ 0.858115] ata2.00: 1000215216 sectors, multi 1: LBA48 NCQ (depth 32), AA
> [ 0.861584] ata2.00: Features: Trust Dev-Sleep NCQ-sndrcv
> [ 0.863749] ata2.00: ACPI cmd f5/00:00:00:00:00:a0(SECURITY FREEZE LOCK) filtered out
> [ 0.865481] ata2.00: supports DRM functions and may not be fully accessible
> [ 0.870043] ata2.00: configured for UDMA/133
> [ 0.871871] scsi 1:0:0:0: Direct-Access ATA SAMSUNG MZ7LN512 1L6Q PQ: 0 ANSI: 5
>
> Please Cc me on further questions/steps to try/patches to test.
Hi Vlastimil,
Thank you for having provided the above information. The root cause of
the hang is not yet clear to me. I was wondering whether the hang
perhaps would be triggered by controllers that only support queue depth
1. However, in the above output I see "depth 32".
As already reported in this email thread a revert for commit
88f1669019bd62b3 has been posted on the linux-scsi mailing list.
Additionally, Greg KH has been asked to drop that patch from the stable
trees.
Thanks,
Bart.
Powered by blists - more mailing lists