Re: Constant ata messages on console with commit 28361c403683 ("libata: add extra internal command") (was Re: [GIT PULL 2/2] libata changes for v4.18-rc1)
From: Michael Ellerman <mpe@ellerman.id.au>
Date: 2018-06-19 23:36:02
Also in:
linux-ide, lkml
Jens Axboe [off-list ref] writes:
On 6/19/18 1:29 AM, Michael Ellerman wrote:quoted
Jens Axboe [off-list ref] writes:quoted
On 6/18/18 1:33 AM, Michael Ellerman wrote:quoted
Tejun Heo [off-list ref] writes: ...quoted
Jens Axboe (10): libata: introduce notion of separate hardware tags libata: convert core and drivers to ->hw_tag usage libata: bump ->qc_active to a 64-bit type libata: use ata_tag_internal() consistently libata: remove assumption that ATA_MAX_QUEUE - 1 is the max sata_nv: set host can_queue count appropriately libata: add extra internal commandReplying here because I can't find the original mail. The above commit is causing one of my machines to constantly spew ata messages on the console, according to bisect: # first bad commit: [28361c403683c2b00d4f5e76045f3ccd299bf99d] libata: add extra internal command To get it to boot I have to also apply: 88e10092f6a6 ("sata_fsl: use the right type for tag bitshift") The system boots OK and seems fine, except that it's just printing multiple of these per second: ata2: Signature Update detected @ 0 msecs ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: configured for UDMA/100 ata2: Signature Update detected @ 0 msecs ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: configured for UDMA/100 ata2: Signature Update detected @ 0 msecs ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: configured for UDMA/100 ata2: Signature Update detected @ 0 msecs ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: configured for UDMA/100 ata2: Signature Update detected @ 0 msecs
...
Actually, just try this one on top of current -git.
Yep that fixes it. No more message spam, and when I try to mount sr0 it says "no medium". I'll have to go into the office to actually put a disc in the drive to check it's really working, but it seems likely. Thanks for debugging it, here's a tested-by if you like: Tested-by: Michael Ellerman <mpe@ellerman.id.au> cheers
quoted hunk ↗ jump to hunk
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c index b8d9cfc60374..4007a9ae650d 100644 --- a/drivers/ata/sata_fsl.c +++ b/drivers/ata/sata_fsl.c@@ -395,12 +395,6 @@ static inline unsigned int sata_fsl_tag(unsigned int tag, { /* We let libATA core do actual (queue) tag allocation */ - /* all non NCQ/queued commands should have tag#0 */ - if (ata_tag_internal(tag)) { - DPRINTK("mapping internal cmds to tag#0\n"); - return 0; - } - if (unlikely(tag >= SATA_FSL_QUEUE_DEPTH)) { DPRINTK("tag %d invalid : out of range\n", tag); return 0;@@ -1229,7 +1223,7 @@ static void sata_fsl_host_intr(struct ata_port *ap) /* Workaround for data length mismatch errata */ if (unlikely(hstatus & INT_ON_DATA_LENGTH_MISMATCH)) { - for (tag = 0; tag < ATA_MAX_QUEUE; tag++) { + for (tag = 0; tag <= ATA_MAX_QUEUE; tag++) { qc = ata_qc_from_tag(ap, tag); if (qc && ata_is_atapi(qc->tf.protocol)) { u32 hcontrol;-- Jens Axboe