Re: [PATCH v2 0/2] ATA port deferred qc fixes

[Niklas Cassel <cassel@kernel.org>]

On Thu, Apr 16, 2026 at 09:38:21PM -0700, Tommy Kelly wrote:
> Hi Niklas and Damien,
> 
> Thanks for the responses.
> I managed to build libata/for-next into rpms for my Fedora CoreOS system.

Thank you for testing!
I was worth a shot.
We will need to dig deeper then.


> I am new to this, but perhaps linux is misunderstanding the queue depth. 
> There are "32 command slots" for the PMP, but each drive advertises "NCQ (depth 32)" as well, but perhaps there is only actually 32/5=6 slots per drive.
> Not sure if that matters wrt the bug.

For a PMP with FBS, the PMP can communicate with multiple drives simultaneously.
Thus, the commands in the 32 command slots can be for different drives.
There is no fixed limit on how much each one drive can occupy. E.g. one drive
use all 32 if there is only I/O going on to a single drive.

For a PMP without FBS (only CBS), the PMP can only communicate with one drive at
a time. Thus, the commands in the 32 command slots will belong to the same
drive.


I think the problem is that the patch that implements the deferred QC logic
forgot to think about port multipliers.

A PMP with FBS can mix NCQ and non-NCQ commands (to different drives of course).
The current deferred QC design stores a single deferred QC in struct ata_port...

This must instead be stored in struct ata_device, or struct ata_link, or have
an array of deferred QCs in struct ata_port.

This means that, for PMPs with FBS, if we defer a QC to one drive (because you
cannot mix NCQ and non-NCQ commands - within a single drive), we will currently
defer commands to all other drives on the PMP.

This is obviously very bad for PMPs with FBS, as commands to other drives will
be deferred for no reason (it will kill performance).



Your problem however, is with PMPs without FBS (only CBS).

Spawned process 'ata_id --export /dev/sdb' [635] is taking longer than 59s to complete.

https://github.com/systemd/systemd/blob/main/src/udev/ata_id/ata_id.c#L93-L115

ata_id seems to send a ATA PASSTHROUGH (12) non-NCQ command.
Presumably some command is already running on sda.

https://github.com/torvalds/linux/blob/v7.0/drivers/ata/libahci.c#L1682-L1685
https://github.com/torvalds/linux/blob/v7.0/drivers/ata/libata-pmp.c#L115-L120

For CBS, it appears that sata_pmp_qc_defer_cmd_switch() will set:
ap->excl_link and will set qc->flags |= ATA_QCFLAG_CLEAR_EXCL.

and then:
__ata_qc_complete() will clear ap->excl_link, but only if qc->flags
ATA_QCFLAG_CLEAR_EXCL was set.

Once a command is completed, ata_scsi_schedule_deferred_qc() will either:
call ata_scsi_requeue_deferred_qc() which will requeue it in SCSI ML, or:
will call ap->ops->qc_defer(qc) and schedule the deferred QC worker.

Considering that we don't see any actual timeouts from SCSI or ATA in your
dmesg, my best guess is that the command is infinitely getting requeued in
SCSI ML. (Possibly by ata_scsi_requeue_deferred_qc().)

I don't really see it. I guess someone with a PMP would need to debug.
(Should be trivial to force disable FBS for a PMP that supports FBS.)

One behavior change that I see from before with a PMP CBS:
if (ap->deferred_ap) is set, we will now return SCSI_MLQUEUE_DEVICE_BUSY,
while before, sata_pmp_qc_defer_cmd_switch() would cause us to return
either SCSI_MLQUEUE_HOST_BUSY - if there was a command excuting on another
drive, or SCSI_MLQUEUE_DEVICE_BUSY - if the same drive was busy executing
NCQ commands.


Kind regards,
Niklas