PCIe kan ge i alla fall 1-2 Ampere i ström via kortkontakterna och borde räcka för SSD utan hjälpström utifrån.
Grafikkort är ju helat annan sak med hundratals Watt i effektförbrukning och då kan inte allt matas via kortkontakterna.
Om det är uppräknad CRC-fel i SMART så är det indikation att det är problem i kontakterna/ledarna mellan SSD:n och chipet som gör inteface mot PCIe - om det beror på glapp eller RF-mässigt dålig designade dataledare låter jag vara osagt, men i vissa fall har en bit kabeln ha 'lugnande verkan' dvs. med sin dämpning i kabeln också dämpar reflekterade reflexer av impedanshopp från tex. kontakten till SATA-anslutningen mot disken på signaleringen i jämförelse med en kort, rätt på-anslutningen utan ledarlängder till SATA-kontakten med sin något stökiga impedanshopp.
När man får CRC-fel betyder det att man fått misstolkningar av signaleringen att det ger 1 eller flera bitflip i bitströmmen per 512 byte-block överfört - systemet är sådant att vid den typen av fel så skickas blocket om igen tills helt lyckad överföring sker och därmed är det ingen fel när det anländer mjukvara som ropade efter datat, men tar extra tid.
Nu är detta med 'inget fel' en statistisk historia då om det är för många CRC-fel per tid (typ tusental i timmen) så kan oupptäckta fel smita förbi om det är så mycket bitfel i strömmen att det kan bilda ett mönster som ger samma CRC-summa som det korrekta datat och går då förbi oupptäckt. Har man checksummande filsystem som ZFS och BTRFS så kan många av de oupptäckta felen fångas i tid den vägen - dock ZFS normalt använda fletchersumma är ett rätt vekt kontrollsystem med glest fångstnät med stora hål och stor chans att även missa de felaktiga blocken som tidigare lurat sig förbi SATA CRC-check, medans BTRFS som använder CRC32C är betydligt tätare 'nät' än CRC32 som används i SATA och risken är typ 0.01% av de oupptäckta felaktiga blocken som lurat sig genom SATA:s CRC även missas av CRC32C. [1]
Sedan hade varit intressant att veta vilket chip det är på kortet, typ om det är Marvell eller Jmicron och dessa är inte utan mer eller mindre stor andel buggar, var av man använder egna drivrutiner för dessa för att minska verkan och dölja problemen (tex att minska timeout-tiden som kan vara 30 s till delar av sekunden var gång bussen hänger sig i tex fallen med SATA/USB externa adaptrar/diskdocka)
Om man startar upp med en bootbar Linux-USB-sticka så kan i dess 'dmesg' hitta vilka chip den har identifierat under bootningen och tex se vilken familj chip som tex. finns på sagda SATA-PCIe-korten och där om det finns kända problem som på olika sätt är fixat i linux-kärnan eller är blacklistat/nerfat till enklare användning - är det Marvel eller jmicron-chip så brukar det vara en bunt var av dessa buggar som måste hanteras på olika sätt.
[1]
Vid slumpmässig (termisk brus-modell) introducerad bitfel av BER 1*10^-10 på bitströmmen (~1 fel per 1 GByte) i SATA-sladden med felrättningsmekanism (dvs. omfrågning av paket som detekterats felaktig) så ger fletchersumma en 'förbättring' till 1*10^-12 - 1*10^-13, användning av CRC32 som i SATA ger BER 1*10^-17 och användning av CRC32C som i SAS ger felsannolikhetsnivå av BER 1*10^-21
