From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Cc: Damien Le Moal <damien.lemoal@wdc.com>,
Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, linux-ide@vger.kernel.org,
"Martin K . Petersen" <martin.petersen@oracle.com>,
scsi <linux-scsi@vger.kernel.org>,
linux-renesas@vger.kernel.org
Subject: Re: [PATCH v9 3/5] libata: support concurrent positioning ranges log
Date: Tue, 2 Nov 2021 15:02:05 +0100 [thread overview]
Message-ID: <CAMuHMdVyUDp1YMkq7e7tu30L=7U7-WV-Ota5KdMddUivUzt50Q@mail.gmail.com> (raw)
In-Reply-To: <63c29948-24ac-1cc3-5c1a-1e5b82c9b19f@opensource.wdc.com>
Hi Damien,
On Tue, Nov 2, 2021 at 12:42 PM Damien Le Moal
<damien.lemoal@opensource.wdc.com> wrote:
> On 2021/11/02 19:40, Geert Uytterhoeven wrote:
> > On Wed, 27 Oct 2021, Damien Le Moal wrote:
> >> Add support to discover if an ATA device supports the Concurrent
> >> Positioning Ranges data log (address 0x47), indicating that the device
> >> is capable of seeking to multiple different locations in parallel using
> >> multiple actuators serving different LBA ranges.
> >>
> >> Also add support to translate the concurrent positioning ranges log
> >> into its equivalent Concurrent Positioning Ranges VPD page B9h in
> >> libata-scsi.c.
> >>
> >> The format of the Concurrent Positioning Ranges Log is defined in ACS-5
> >> r9.
> >>
> >> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> >
> > Thanks for your patch, which is now commit fe22e1c2f705676a ("libata:
> > support concurrent positioning ranges log") upstream.
> >
> > During resume from s2ram on Renesas Salvator-XS, I now see more scary
> > messages than before:
> >
> > ata1: link resume succeeded after 1 retries
> > ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> > +ata1.00: qc timeout (cmd 0x2f)
> > +ata1.00: Read log page 0x00 failed, Emask 0x4
> > +ata1.00: ATA Identify Device Log not supported
> > +ata1.00: failed to set xfermode (err_mask=0x40)
> > ata1: link resume succeeded after 1 retries
> > ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> > +ata1.00: ATA Identify Device Log not supported
> > +ata1.00: ATA Identify Device Log not supported
> > ata1.00: configured for UDMA/133
> >
> > I guess this is expected?
>
> Nope, it is not. The problem is actually not the concurrent positioning log, or
> any other log, being supported or not.
>
> Notice the qc timeout ? On device scan after coming out of sleep, or even simply
> doing a rmmod ahci+modprobe ahci, the read log commands issued during device
> revalidate timeout fairly easily as they are issued while the drive is not
> necessarilly fully restarted yet. These errors happen fairly easily due to the
> command timeout setting in libata being too short, I think, for the "restart"
> case. On a clean boot, they do not happen as longer timeouts are used in that case.
>
> I identified this problem recently while testing stuff: I was doing rmmod of ata
> modules and then modprobe of newly compiled modules for tests and noticed these
> timeouts. Increasing the timeout values, they disappear. I am however still
> scratching my head about the best way to address this. Still digging about this
> to first make sure this is really about timeouts being set too short.
There's indeed something timing-related going on. Sometimes I get
during resume (s2idle or s2ram):
ata1.00: qc timeout (cmd 0x2f)
ata1.00: Read log page 0x00 failed, Emask 0x4
ata1.00: ATA Identify Device Log not supported
ata1.00: failed to set xfermode (err_mask=0x40)
ata1.00: limiting speed to UDMA/133:PIO3
ata1: link resume succeeded after 1 retries
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: NODEV after polling detection
ata1.00: revalidation failed (errno=-2)
ata1.00: disabled
ata1: link resume succeeded after 1 retries
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
sd 0:0:0:0: [sda] Start/Stop Unit failed: Result: hostbyte=0x04
driverbyte=DRIVER_OK
sd 0:0:0:0: [sda] Read Capacity(16) failed: Result: hostbyte=0x04
driverbyte=DRIVER_OK
sd 0:0:0:0: [sda] Sense not available.
sd 0:0:0:0: [sda] Read Capacity(10) failed: Result: hostbyte=0x04
driverbyte=DRIVER_OK
sd 0:0:0:0: [sda] Sense not available.
sd 0:0:0:0: [sda] 0 512-byte logical blocks: (0 B/0 B)
sda: detected capacity change from 320173056 to 0
after which the drive is no longer functional...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
next prev parent reply other threads:[~2021-11-02 14:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-27 2:22 [PATCH v9 0/5] Initial support for multi-actuator HDDs Damien Le Moal
2021-10-27 2:22 ` [PATCH v9 1/5] block: Add independent access ranges support Damien Le Moal
2021-10-27 2:22 ` [PATCH v9 2/5] scsi: sd: add concurrent positioning " Damien Le Moal
2021-10-27 2:22 ` [PATCH v9 3/5] libata: support concurrent positioning ranges log Damien Le Moal
2021-11-02 10:40 ` Geert Uytterhoeven
2021-11-02 11:42 ` Damien Le Moal
2021-11-02 14:02 ` Geert Uytterhoeven [this message]
2021-11-04 6:20 ` Damien Le Moal
2021-10-27 2:22 ` [PATCH v9 4/5] doc: document sysfs queue/independent_access_ranges attributes Damien Le Moal
2021-10-27 2:22 ` [PATCH v9 5/5] doc: Fix typo in request queue sysfs documentation Damien Le Moal
2021-10-27 2:37 ` (subset) [PATCH v9 0/5] Initial support for multi-actuator HDDs Jens Axboe
2021-10-27 2:38 ` Jens Axboe
2021-10-27 2:46 ` Damien Le Moal
2021-10-27 2:52 ` Martin K. Petersen
2021-10-27 2:53 ` Damien Le Moal
2021-10-27 2:49 ` Damien Le Moal
2021-10-27 3:03 ` Jens Axboe
2021-10-27 3:42 ` Damien Le Moal
2021-10-27 3:03 ` (subset) " Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMuHMdVyUDp1YMkq7e7tu30L=7U7-WV-Ota5KdMddUivUzt50Q@mail.gmail.com' \
--to=geert@linux-m68k.org \
--cc=axboe@kernel.dk \
--cc=damien.lemoal@opensource.wdc.com \
--cc=damien.lemoal@wdc.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-renesas@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).