| Message ID | 20210814134709.16085-1-Reimar.Doeffinger@gmx.de |
|---|---|
| State | New |
| Headers | show |
| Series | libata: add kernel parameter to force ATA_HORKAGE_NO_DMA_LOG | expand |
Please just add quirks for the affected setups instead of requiring the user to pass an obscure parameter.
Hi! On Sun, Aug 15, 2021 at 09:18:42AM +0100, Christoph Hellwig wrote: > Please just add quirks for the affected setups instead of requiring > the user to pass an obscure parameter. I sent a patch for that and still adding the parameter. For completeness, my original reply which did not make it to the list (it seems emails from gmx.de do not make it through): The point of the parameter is to be able to gather data and find out which setups are affected, enabling less knowledgeable users to help. The sample size so far is 2, and with quite different setups, it's not even clear to me if it's a controller issue, a drive issue, or a combination. If this feature is not very relevant it would be possible to apply a fairly broad quirk, but I feel a bit hesitant about that.
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index bdb22006f713..191502e8fa74 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2551,6 +2551,8 @@ * [no]ncqtrim: Turn off queued DSM TRIM. + * [no]dmalog: Turn off use of ATA_CMD_READ_LOG_DMA_EXT (0x47) command + * nohrst, nosrst, norst: suppress hard, soft and both resets. diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 61c762961ca8..7fb865333a38 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -6104,6 +6104,8 @@ static int __init ata_parse_force_one(char **cur, { "ncq", .horkage_off = ATA_HORKAGE_NONCQ }, { "noncqtrim", .horkage_on = ATA_HORKAGE_NO_NCQ_TRIM }, { "ncqtrim", .horkage_off = ATA_HORKAGE_NO_NCQ_TRIM }, + { "nodmalog", .horkage_on = ATA_HORKAGE_NO_DMA_LOG }, + { "dmalog", .horkage_off = ATA_HORKAGE_NO_DMA_LOG }, { "dump_id", .horkage_on = ATA_HORKAGE_DUMP_ID }, { "pio0", .xfer_mask = 1 << (ATA_SHIFT_PIO + 0) }, { "pio1", .xfer_mask = 1 << (ATA_SHIFT_PIO + 1) },
The ATA_CMD_READ_LOG_DMA_EXT can cause controller/device to become unresponsive until the next power cycle. This seems to particularly affect IDE to SATA adapters, possibly in combination with certain SATA SSDs, though there might be more/different cases. Comment 5 of https://bugzilla.kernel.org/show_bug.cgi?id=195895 is an example. Having an option to disable its use allows booting systems affected, which besides being a useful workaround is also a necessary step to allow gathering more debug info on these systems. Existing workarounds like forcing PIO mode do not work (in addition to the performance issues) because READ_LOG_DMA is issued even if PIO mode is forced. Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de> --- Documentation/admin-guide/kernel-parameters.txt | 2 ++ drivers/ata/libata-core.c | 2 ++ 2 files changed, 4 insertions(+)