Re: [PATCH v2] scsi: core: Clear power-on UNIT ATTENTION on BIWIN UFS devices

[Alexey Charkov]

On Thu, Oct 29, 2026 at 9:20 PM Bart Van Assche <bvanassche@xxxxxxx> wrote:
>
> On 10/29/26 3:41 AM, Alexey Charkov wrote:
> > The SCSI core retries a command that receives a UNIT ATTENTION and relies
> > on the device to clear the condition once reported. The BIWIN
> > BWU2A0526B128G and BWU2A0516B064G UFS devices do not clear a power on or
> > reset UNIT ATTENTION when reporting it to a WRITE. After a device reset,
> > such as on resume with the UFS link off or in UFS error recovery, writes
> > then fail on every retry for the full 180s retry window and end in I/O
> > errors. A TEST UNIT READY or READ clears it.
>
> Does the attached untested patch help?

Hi Bart,

Thanks a lot for this! I've tested it on five boards: three with BIWIN
UFS (BWU2A0526B128G x2, BWU2A0516B064G) and two with FORESEE C2G071,
on next-20261027. Tests: UFS error-handler resets under light writes
and under fio keeping 128 direct writes outstanding, runtime PM with a
WRITE as the first command after resume, and suspend to RAM.

The core idea works well: on the BIWIN devices the TEST UNIT READY
from the error handler clears the stuck UNIT ATTENTION about 50ms
after the reset, with no I/O errors, including the saturated-queue
case that broke my v2. Since the EH commands reuse the failed
command's tag, they don't need a scheduler tag. The FORESEE devices
never enter the error handler.

I did run into one regression though. The new scsi_noretry_cmd() check
in scsi_io_completion_action() is reachable for a UNIT ATTENTION on
data commands, since blk_stat stays BLK_STS_OK for them and the "Kill
remainder" path doesn't catch them. So a REQ_FAILFAST_DEV command that
happens to be the first to see a reset UA now fails instead of being
retried, on any device. I confirmed this by issuing a readahead during
a UFS reset: with your patch it failed with "I/O error ... flags
0x84700" in all 20 runs, on both the BIWIN and the FORESEE devices,
while without it the READ was retried and succeeded. With md
raid1/raid10 failfast this would mark a healthy member faulty after a
bus reset.

Dropping that term fixes it:

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -849,9 +849,8 @@ static void scsi_io_completion_action(struct
scsi_cmnd *cmd, int result)
  */
  cmd->device->changed = 1;
  action = ACTION_FAIL;
- } else if (scsi_noretry_cmd(cmd) ||
-   (cmd->allowed != SCSI_CMD_RETRIES_NO_LIMIT &&
-    cmd->retries > max(cmd->allowed, 3))) {
+ } else if (cmd->allowed != SCSI_CMD_RETRIES_NO_LIMIT &&
+   cmd->retries > max(cmd->allowed, 3)) {
  action = ACTION_FAIL;
  } else {
  /* Must have been a power glitch, or a

With it, all readaheads in the same test (25 runs) were retried and
succeeded, and the error-handler, runtime PM and suspend tests above
passed on all five boards.

This keeps failfast commands on today's behaviour for UNIT ATTENTION,
so failfast WRITEs to a device like the BIWIN ones still go through
the old uncounted retry loop. Sending them through the new path as
well (dropping the scsi_noretry_cmd() exclusion in scsi_check_sense()
too) works, but then scsi_eh_flush_done_q() needs to count their EH
rounds, or a target that never clears the UA keeps them cycling
through EH with LU resets until the runtime limit. That seemed like
more than this fix needs: I'm not aware of anyone running md failfast
on UFS, and readahead is a READ, which clears the UA on these devices
anyway.

With that change:
Tested-by: Alexey Charkov <alchark@xxxxxxxxxxx>

Small nit: the BIWIN parts don't only clear the UA on TEST UNIT READY:
READ and SYNCHRONIZE CACHE clear it too. It's WRITE that doesn't.

Best regards,
Alexey