Skip to main content ↑ ↓
Topic: failed command: READ FPDMA QUEUED (Read 1916 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

failed command: READ FPDMA QUEUED

Hi. I'm having an issue that it seems to be specific to kernel 5.16, that's why I've created a PR at kernel.org.

Said that, it only occurs with kernels 5.16, I can use my pc with LTS (which is 5.15.16-1-lts by the time I'm writing this). The smartctl tests goes well, I've exchanged cables and sata ports for the sake of tests, even changed the configurations on bios from AHCI, SATA and RAID, just to be sure I was exhausting every possibility.  I've tested kernels linux and linux-zen, both give me the same issue.  I've also tested mainline and git kernels from kernel.org. Even the weekly  ISO give me the problem.  I've also tested the libata.force optins (noncq, norst, etc).
I can't provide a dmesg or any log using this kernel because the issue happens really early (not possible even to debug using a kernel with plenty of debug with verbose boot option). It boots, take some time and then this will appears on the sceren:

Code: [Select]
ata3.00: exception Emask 0x0 SAct 0x40000000 SErr 0x0 action 0x6 frozen
ata3.00: failed command: READ FPDMA QUEUED
ata3.00: cmd 60/08:f0:00:00:00/00:00:00:00:00/40 tag 30 ncq dma 4096 in
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata3.00: status: { DRDY }

For the sake of testing, I've tried also FreeBSD-CURRENT ISO since -CURRENT versions have WITNESS and some other debug facilities enabled, and no errors at all.
Any help is appreciated, I can provide logs, lspci, etc as long is from 5.15 since I can't boot 5.16 at all.

Re: failed command: READ FPDMA QUEUED

Reply #1 –
For the record, this is a known issue already on arch linux forums. Here's the thread.

Re: failed command: READ FPDMA QUEUED

Reply #2 –
It seems that this isn't going anywhere, I feel this is not gonna be fixed any time soon, so I've ended up migrating my two machines to FreeBSD. I can't afford having issues like that (isn't anything against artix, it's about linux kernel). In my opinion, from the kernel point of view, having a "feature" like that add to libata is unnaceptable.

Re: failed command: READ FPDMA QUEUED

Reply #3 –
This is above our paycheck, unfortunately, as you also acknowledged. My only question is, why isn't LTS an acceptable solution to you?
 

Re: failed command: READ FPDMA QUEUED

Reply #4 –
https://forum.endeavouros.com/t/unofficial-repo-for-older-lts-kernels/8972
It's possible to run some really old kernels, I tried the 4.4 from that repo not that long ago and it booted OK, although you need to uncomment COMPRESSION="lz4" and comment out zstd in /etc/mkinitcpio.conf. So there's no reason you can't go back to an older one for a while if you want, and some of the old lts versions still get security updates, 4.4 is going EOL about now according to the comments here:
https://aur.archlinux.org/packages/linux-lts44
Also even if you find a commit that fixes the issue there are stacks of inter - related commits in the kernel, it may just expose an issue  created by something else that was done earlier, which is why it might not get fixed quickly - or at all, if it's on less common old hw that may soon be outdated!
But it's pretty standard in a rolling release distro to downgrade version while issues are resolved and not a problem to do even for years if required ;)

Re: failed command: READ FPDMA QUEUED

Reply #5 –
Quote from: nous – on
This is above our paycheck, unfortunately, as you also acknowledged. My only question is, why isn't LTS an acceptable solution to you?
I can't risk a backport for the "new" libsata coming.

Quote from: ####### – on
But it's pretty standard in a rolling release distro to downgrade version while issues are resolved and not a problem to do even for years if required ;)
Of course, but an issue on libsata that make a machine unable to boot and isn't going to be fixed because it's the new thing is a show stopper. Said that, it means I should live with old kernels until I decide to ditch a new SSD because "it's a new thing"? Fat chance.

Re: failed command: READ FPDMA QUEUED

Reply #6 –
Didn't you say at some point you had tried several drives and had the same error? It may not be the drive itself, but the chipset, BIOS or something like that in the computer that triggers this error. From what I gather vaguely there is some command being run that your drive doesn't support. But this means the drive type and features are not being detected correctly earlier in the boot, hence the request for a video of the full boot sequence. When the boot stops, the real error has already happened, much earlier, and is scrolled off the screen. A fast fix for a kernel bug is a couple of weeks, a couple of months might be more likely, so you need to be a bit flexible about downgrading. Somehow the kernel thinks you have a different drive to what is actually fitted - I suppose another option is to find a drive that really does support that READ FDPMA thing whatever it is - but that might not work either!

Re: failed command: READ FPDMA QUEUED

Reply #7 –
Quote from: ####### – on
Didn't you say at some point you had tried several drives and had the same error? It may not be the drive itself, but the chipset, BIOS or something like that in the computer that triggers this error. From what I gather vaguely there is some command being run that your drive doesn't support. But this means the drive type and features are not being detected correctly earlier in the boot, hence the request for a video of the full boot sequence. When the boot stops, the real error has already happened, much earlier, and is scrolled off the screen. A fast fix for a kernel bug is a couple of weeks, a couple of months might be more likely, so you need to be a bit flexible about downgrading. Somehow the kernel thinks you have a different drive to what is actually fitted - I suppose another option is to find a drive that really does support that READ FDPMA thing whatever it is - but that might not work either!

Nah, two different drivers in two different computers, one of them isn't UEFI and it's a 1st gen Intel. And it seems it affects more people since 5.16 reached fedora as well.

Re: failed command: READ FPDMA QUEUED

Reply #8 –
Looking at the issue again today, it seems there's a new patch which might fix this, no doubt thanks in part to your efforts - if you test it make sure you are well backed up and have a screwdriver about in case it does something bad!  ;D