From: Mark K <mark_k@iname.com>
To: linux-ide@vger.kernel.org
Subject: SATA SSD inaccessible, fails on initial end-of-drive read command
Date: Fri, 27 Aug 2021 14:21:33 +0200 [thread overview]
Message-ID: <trinity-a03ecf2a-166f-4889-99d1-fa2e31e12fe9-1630066893472@3c-app-mailcom-lxa12> (raw)
Hi,
I have a system with secondary SATA SSD (OCZ Saber 1000 480GB) which is
readable in Windows.
The drive capacity shown when probed by the kernel during boot is 937703088 =
0x37E436B0 sectors.
The drive seems to be failing the command issued by libata to read its last 8
sectors.
After reporting
ata8.00: exception Emask 0x0 SAct 0x40 SErr 0x0 action 0x6 frozen
ata8.00: failed command: READ FPDMA QUEUED
ata8.00: cmd 60/08:30:a8:36:e4/00:00:37:00:00/40 tag 6 ncq dma 4096 in
it tries resetting the link several times and eventually gives up.
In this state, while the block device and sg device (/dev/sda and /dev/sg5) are
still present, any attempt to e.g. issue INQUIRY or READ CAPACITY fails, along
with data access commands like READ and WRITE, meaning the drive is
inaccessible in Linux.
I'm not sure whether the drive itself locks up after receiving that read
command, or whether libata is giving up too soon, or whether that error could
just be ignored.
Is there any way to tell libata to avoid issuing the initial end-of-drive read
command? Or is that read issued by the block layer?
[ 1.499334] libata version 3.00 loaded.
[ 1.505518] scsi host0: ata_generic
[ 1.505703] scsi host2: ata_generic
[ 1.516083] ata8: SATA max UDMA/133 abar m2048@0xf7f12000 port 0xf7f12180 irq 41
[ 1.830511] ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 1.830975] ata8.00: ATA-8: OCZ-SABER1000, 1.01, max UDMA/133
[ 1.830978] ata8.00: 937703088 sectors, multi 1: LBA48 NCQ (depth 32), AA
[ 1.836358] ata8.00: configured for UDMA/133
[ 33.943503] ata8.00: exception Emask 0x0 SAct 0x40 SErr 0x0 action 0x6 frozen
[ 33.943585] ata8.00: failed command: READ FPDMA QUEUED
[ 33.943631] ata8.00: cmd 60/08:30:a8:36:e4/00:00:37:00:00/40 tag 6 ncq dma 4096 in
[ 33.943735] ata8.00: status: { DRDY }
[ 33.943768] ata8: hard resetting link
[ 39.295447] ata8: link is slow to respond, please be patient (ready=0)
[ 43.975468] ata8: COMRESET failed (errno=-16)
[ 43.975531] ata8: hard resetting link
[ 49.327467] ata8: link is slow to respond, please be patient (ready=0)
[ 54.007448] ata8: COMRESET failed (errno=-16)
[ 54.007512] ata8: hard resetting link
[ 59.359466] ata8: link is slow to respond, please be patient (ready=0)
[ 89.059463] ata8: COMRESET failed (errno=-16)
[ 89.059532] ata8: limiting SATA link speed to 3.0 Gbps
[ 89.059533] ata8: hard resetting link
[ 94.111441] ata8: COMRESET failed (errno=-16)
[ 94.111508] ata8: reset failed, giving up
[ 94.111545] ata8.00: disabled
[ 94.111668] ata8: EH complete
reply other threads:[~2021-08-27 12:26 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=trinity-a03ecf2a-166f-4889-99d1-fa2e31e12fe9-1630066893472@3c-app-mailcom-lxa12 \
--to=mark_k@iname.com \
--cc=linux-ide@vger.kernel.org \
/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).