Hi Damien,
On Tue, Nov 2, 2021 at 12:42 PM Damien Le Moal
<damien.lemoal@xxxxxxxxxxxxxxxxxx> 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@xxxxxxx>
> >
> > 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@xxxxxxxxxxxxxx
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
