| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <f82edaa2-4b1a-c747-3d58-ec86ceb4ee7e@kernel.dk>
Date: Tue, 19 Jun 2018 09:39:18 -0600
From: Jens Axboe <axboe@...nel.dk>
To: Michael Ellerman <mpe@...erman.id.au>, Tejun Heo <tj@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: 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)
On 6/19/18 1:29 AM, Michael Ellerman wrote:
> Jens Axboe <axboe@...nel.dk> writes:
>> On 6/18/18 1:33 AM, Michael Ellerman wrote:
>>> Tejun Heo <tj@...nel.org> writes:
>>> ...
>>>> 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 command
>>>
>>> Replying 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
>>>
>>> And it never seems to stop.
>>>
>>> The machine is a Freescale/NXP P5020ds, using the sata_fsl driver
>>> presumably. Any ideas?
>>
>> Hmm that's odd. Can you include the boot log from a working boot as
>> well? Would be nice to see what devices are on the sata adapter.
>> The above just looks like a hardreset loop.
>
> Ah yep. I stupidly assumed it was working, because the machine booted,
> but that's because the root disk is on ata1.
>
> Booting the good kernel:
>
> ba80c3a572f4 ("sata_nv: set host can_queue count appropriately")
>
> I see:
>
> root@...20ds:~# ls -l /sys/class/ata_port/
> total 0
> lrwxrwxrwx 1 root root 0 Jun 19 06:49 ata1 -> ../../devices/platform/ffe000000.soc/ffe220000.sata/ata1/ata_port/ata1
> lrwxrwxrwx 1 root root 0 Jun 19 17:06 ata2 -> ../../devices/platform/ffe000000.soc/ffe221000.sata/ata2/ata_port/ata2
>
> root@...20ds:~# ls -l /sys/class/block/ | grep ata
> lrwxrwxrwx 1 root root 0 Jun 19 17:11 sda -> ../../devices/platform/ffe000000.soc/ffe220000.sata/ata1/host0/target0:0:0/0:0:0:0/block/sda
> lrwxrwxrwx 1 root root 0 Jun 19 17:11 sda1 -> ../../devices/platform/ffe000000.soc/ffe220000.sata/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1
> lrwxrwxrwx 1 root root 0 Jun 19 17:11 sda2 -> ../../devices/platform/ffe000000.soc/ffe220000.sata/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda2
> lrwxrwxrwx 1 root root 0 Jun 19 17:11 sda5 -> ../../devices/platform/ffe000000.soc/ffe220000.sata/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda5
> lrwxrwxrwx 1 root root 0 Jun 19 17:11 sr0 -> ../../devices/platform/ffe000000.soc/ffe221000.sata/ata2/host1/target1:0:0/1:0:0:0/block/sr0
>
> So it's the DVD drive.
>
> root@...20ds:/sys/devices/platform/ffe000000.soc/ffe221000.sata/ata2/host1/target1:0:0/1:0:0:0/scsi_device/1:0:0:0/device# cat vendor
> Optiarc
> root@...20ds:/sys/devices/platform/ffe000000.soc/ffe221000.sata/ata2/host1/target1:0:0/1:0:0:0/scsi_device/1:0:0:0/device# cat model
> DVD RW AD-7260S
>
>
> Full boot log from a good boot attached if that's helpful.
>
> All of the above looks the same when I boot with the broken setup, it
> just spams dmesg constantly.
>
> One thing that is different, on the good kernel I see:
>
> root@...20ds:~# mount /dev/sr0 /mnt
> mount: no medium found on /dev/sr0
>
> vs bad (88e10092f6a6):
>
> root@...20ds:~# mount /dev/sr0 /mnt
> mount: /dev/sr0 is already mounted or /mnt busy
>
> cheers
Actually, just try this one on top of current -git.
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
Powered by blists - more mailing lists