linux-kernel - 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)

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87sh5jxmif.fsf@concordia.ellerman.id.au>
Date:   Tue, 19 Jun 2018 17:29:12 +1000
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Jens Axboe <axboe@...nel.dk>, 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)

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


View attachment "good-boot.txt" of type "text/plain" (30972 bytes)