I bought a new mobo, processor and ram after the whole intel thing went south quickly.
Mobo: MSI A620M-E
Processor: AM5 5700X (I am not very sure of the exact processor I am still new to AM so do not ridicule me please)
Ram: 16Gb ddr5 5600
After installing f40 I started noticing that SATA_2 was dropping out after a while, no matter what SSD or sata drive I have connected, even after a reboot the drive would still be missing until I removed the IEC plug from the power supply, and bled the caps down, then when re-powering everything the drive would be back for a bit and then just disappear again and would not return until I did the whole thing described above with the power.
For the past 3 weeks this pc has been at the people who sold me the mobo processor and ram as a kit. They have tested this and found it does not happen under windows and only under Fedora, claiming a faulty install.
I can not accept this as it does not make sense to me.
If this were OS related, should the SATA port not re-appear upon rebooting the PC and then dissapear agin once booted into the OS?
I need help here please as this is driving me to the clear point of insanity as this whole debacle has been happening for more than 2 months now.
I have tested with different drives and different cables.
When SATA_2 drops out, swapping the two drives sees the lost SSD on SATA_2 re-appear on SATA_1 but the drive that was on SATA_1 and is now on SATA_2 is still missing ** even inside the bios**…
I am very sceptical that this is an OS fault, if there is someone that has had this kind of fault what was your findings as to what caused this.
This is your clue. A hardware issue that may be solved by updating the bios version if an update is available.
The bios must support the OS and it seems they are not playing nicely in the same sandbox.
If the bios does not see the device then the OS certainly cannot.
Please post the output of inxi -Fzxx as that will show the information about current bios version and drives, and you can check the MSI web site for bios updates for your motherboard.
Please be aware of what I wrote in the OP, When swapping the drives.
When the SATA_2 drive disappears and I power down the PC and swap SATA_1’s SSD to SATA_2 and SATA_2’s SSD to SATA_1 the missing SSD from SATA_2 shows on SATA_1 port but the SSD that was on SATA_1 and is now on SATA_2 does not show up.
In bios even after the reboot before the OS even comes to boot the SATA_2 is shown as “empty” In other words the bios is not seeing the drive that is plugged in and also not the drive that was moved to it, Please note, this happens BEFORE the OS can even boot.
How is it that the OS will be causing this?
The bios has been updated to the newest version available, but did this even before the update.
This is just a shot in the dark, but I’d be tempted to experiment with the “SATA Active Link Power Management” settings: Power management - ArchWiki
SATA_1,3 & 4 still remain online after this drop out, the drop out is only occurring on SATA_2.
On no other drive is this happening, also, note, after a restart , the drive is still missing inside the bios, the physical drive on that specific port is missing, none of the other drives does this, only whichever drive I plugged into SATA_2 at that time will be missing.
Also the reason I am stating that this can not be an OS problem, because, if this was OS related the bios should again see the drive upon the PC being rebooted which it is not.
Unfortunately, these newer devices tend to run more and more code (firmware) within them (they aren’t just cassettes with a couple of spools of magnetic tape anymore ). I wouldn’t put it past the realm of possibility that the OS could be interacting with the device in such a way as to get it into a state that can only be recovered by bleeding the caps. But if you are seeing the same problem with different model SSDs, then that might rule out that possibility.
But if you are seeing the same problem with different model SSDs, then that might rule out that possibility.
This happens with SSD’s AND SATA drives a like. Like I said, swapping the drives between the ports when doing a restart, sees the missing drive from sata_2 been seen on sata_1 but the drive that was seen on sata_1 that is now on sata_2 is gone. Is the OS then switching off the physical SATA port?
SATA Link Power Management (LPM) puts the physical layer (PHY) of the SATA link into a power saving state. SATA Link Power Management is independent of the power state of the hard disk or SSD. This is controlled at the ATA protocol level and, in the case of hard disks for example, leads to a spinning down of the data carrier in order to save power. SATA LPM has led to a significant reduction in the overall power consumption of the SATA subsystem, both in the platform controller hub (SATA controller in the chipset or CPU) and in the SATA device itself. However, LPM is not compatible with hot-plug
I can not update the bios anymore, that has already been done. There are no more updates until the next one comes out, I have stated this now multiple times…
It sounded like you were saying that it is could be possible that the OS could be causing this, hence my question of how this could be…
@glb has eluded to a possible LPM problem, but, my question is, why only on SATA_2…
In the world of firmware bugs, pretty much anything is possible – including “it only happens when the high-order bit of a two-bit number is set and not the low-order bit” (i.e. when the value equals two).
Pin 3 in SATA revision 3.3 has been redefined as PWDIS and is used to enter and exit the POWER DISABLE mode for compatibility with SAS specification. If Pin 3 is driven HIGH (2.1–3.6 V max), power to the drive circuitry is disabled. Drives with this feature do not power up in systems designed to SATA revision 3.1 or earlier. This is because Pin 3 driven HIGH prevents the drive from powering up.
Check the specifications of your drives for PWDIS support.
You could look for a temporary workaround (such as moving 1 SSD to an ext.ernal case) in the hope of a future firmware update.
). I wouldn’t put it past the realm of possibility that the OS could be interacting with the device in such a way as to get it into a state that can only be recovered by bleeding the caps. But if you are seeing the same problem with different model SSDs, then that might rule out that possibility.