Samsung EVO SSD eigenaars

[Kuusj]

Racer89 schreef op zondag 07 december 2014 @ 11:21:
Weet iemand toevallig hoe het kan dat de SSD zoemt/ sist. Ik heb de 840 EVO sinds 2 dagen nu in de Dell 6520 zitten. Gisteren avond was het vrij stil in de kamer. En toen viel het wel duidelijk op telkens.

Bij het lezen en schrijven op de SSD komt er een zoemen sissen vandaan. Ik heb op internet al liggen zoeken. Heb 2 á 3 sites gevonden waar er word gezegd dat het niet goed is. Zou van de condensatoren komen? Ik hen inmiddels al een mail gestuurd naar de webshop voor een RMA formulier. Iemand die dit ook al heeft gehad?

Dit kan inderdaad vrijwel niks anders zijn dan condensators. Terugsturen die hap.
Ik heb inmiddels 3 EVO's (2x250GB, 1x120GB) en 2 MX100's (2x256GB) in gebruik of bij in mensen hun systeem geplaatst en ik hoor nergens problemen. Zal dan wel een zeldzaam probleem zijn.

[Racer89]

Ja, het geluid lijkt er op als of je een 2.5 inch HDD er in heb zitten die doet lezen en schrijven. Ben benieuwd wat de webshop er op gaat reageren a.s. maandag. En dan gaat hij gewoon retour. Ik heb een Kingston 120 Gb SSD hier liggen. Is wel al wat ouder. Maar deze maakt ook geen geluiden.

[rikadoo]

Ik heb dit volgens mij ook. Als ik ccleaner laat laden met de settings voordat ik kan opschonen hoor ik de SSD ook zoemen. En zodra ik op schoonmaken klik ook.

Luister maar:

http://vocaroo.com/i/s1eki1CCItlp

Is het zo`n geluid?

[Racer89]

Het lijkt er inderdaad heel erg op. Alleen is het bij mij nog niet zo duidelijk te horen. Is nog iets zachter. Schijnbaar gaat het hier om hetzelfde probleem wat videokaarten ook wel een hebben "Coil Whine"

[rikadoo]

Ik heb het eigenlijk al heel lang, ik merk het ook bij het scrollen bijvoorbeeld. In een webpagina. Maar verder vaak alleen in ccleaner. Tijdens het laden.

[Reepje]

Dat geluidje bij het scrollen op een webpagina heb ik ook, maar dat komt uit het speakertje van mijn monitor. Ik zou toch eens even goed luisteren waar het geluid precies vandaan komt.
Ik neem natuurlijk aan dat als jij aan het scrollen bent je oor tegelijkertijd op de ssd legt, zodat je zeker weet dat het geluid van de ssd komt?

[Racer89]

Ja het klinkt dom haha, maar zo heb ik het wel gedaan. Geluid heb ik helemaal uitstaan. Maar het is inderdaad onder het scrollen. Of een pagina openen of iets anders openen. Hoor je dat geluid direct. Het komt duidelijk uit de SSD.

Vandaag al antwoord gehad van de webshop. tevens net een retour formulier ontvangen dat het goed was gekeurd. Morgen gaat hij terug op de post.

[robj28]

Mijn Samsung EVO 840 maakt ook geluid, klinkt bij veel lezen of schijven een beetje als het seek geluid van een normale HDD.

[rikadoo]

Reepje schreef op maandag 08 december 2014 @ 15:14:
Dat geluidje bij het scrollen op een webpagina heb ik ook, maar dat komt uit het speakertje van mijn monitor. Ik zou toch eens even goed luisteren waar het geluid precies vandaan komt.
Ik neem natuurlijk aan dat als jij aan het scrollen bent je oor tegelijkertijd op de ssd legt, zodat je zeker weet dat het geluid van de ssd komt?

Ja, het komt niet uit de videokaart, of voeding. Ik heb ook zonder getest en heb tijdens het scrollen de ssd los gehad en getest en het komt echt daar vandaan....

[Racer89]

Maja nu is de vraag is het normaal of niet? Is het slecht voor de SSD of niet?

In de werklaptop zit ook een SSD 120 Gb van Samsung deze maakt totaal geen geluid. Meningen op internet verschillen hier over. De ene zegt dat het normaal is terwijl de andere zegt dat het niet goed is en komt door slechte condensatoren.

[peter123]

Ik heb ooit piepende condensatoren gehad in 2 voedingen van Be Quiet!. Zijn alle 2 kapot gegaan buiten de garantietijd. Als ik nu spullen krijg die piepen, stuur ik ze direct RMA.

[JwJw01]

Kan iemand het volgende verklaren?



Sinds ik RAPID mode heb aangezet, haal ik achterlijke waarden bij sequential read en write. Dit kan niet kloppen toch?

[Swordlord]

Het is een systeem dat bedoeld is om achterlijke waardes mee te halen...
Want je gebruikt het RAM geheugen als buffer naar SSD voor writes enzo.

Dus dit is je RAM geheugen op de benchmark

[ Voor 12% gewijzigd door Swordlord op 11-12-2014 15:55 ]

[temp00]

Wat Swordlord zegt. Niet aan te raden om aan te hebben staan maar dat had je zelf overigens ook kunnen vinden, er is al zo veel over geschreven.

[Buzz_Fuzz]

Lijkt inmiddels duidelijk dat Samsung de 840 non-evo een stille dood laat sterven... Niemand nog iets nieuws opgevangen?

[Hell-Slave]

Niet weer (nog steeds) snelheid probleem?

http://nl.hardware.info/n...mpleet-opgelost-na-update

http://www.pcper.com/revi...-Only-Partially-Effective

[temp00]

Ik was er al bang voor dat de fix niet permanent zou/kon zijn. 3de plaatje is de huidige situatie en geeft weliswaar veel minder ernstig, maar toch een andere situatie dan 15 oktober weer.

voor FW fix (thumb):


na FW fix (thumb) (15-11-2014):


nu (thumb) (2-2-2015)

[temp00]

cross post, kan weg

[ Voor 97% gewijzigd door temp00 op 05-02-2015 15:11 ]

[Maj-Maj]

Moet ik de performance restoration ook doen? Twee benchmarks met de volgende resultaten:





Liggen nogal uit elkaar dus, terwijl er 1 minuut tussenzit. Heb niet zoveel zin om de restoration te doen als het wellicht toch niet werkt/geen zin heeft.

EDIT: Heb overigens nog maar 2.74 TB geschreven. Ben geen grootverbruiker

[ Voor 10% gewijzigd door Maj-Maj op 13-02-2015 10:50 ]

[Swordlord]

De performance restoration tool en de daarbij horende firmware update. Is eigenlijk niet een gevalletje... Laat ik het doen zodra ik vertraging merk.
Waarom handelen als het kalf is verdronken??

Updaten die handel, dan blijf je ook van het gezeik weg.


Waarom de drive trouwens zo groot verschil heeft tussen de 2 benchmarks.
Samsung gebruikt een klein deel van het geheugen, in een snelle configuratie, als schrijf buffer om het langzame geheugen te maskeren.
Dus een paar GB aan data, kan makkelijk verwerkt worden met schrijven en wordt dan verplaatst naar de permanente opslag.

Draai je een benchmark die aantal GB schrijft en met een 2de benchmark daarna weer aantal GB erachteraan dumpt, dan zit die buffer vol en zit je dus te schrijven naar het langzame deel van het geheugen.

[ Voor 10% gewijzigd door Swordlord op 13-02-2015 11:42 ]

[Reepje]

Of je de tool moet draaien?
Jij zit zelf achter de computer. Is hij super traag? Dan zou ik de tool draaien. Is alles zo snel als het moet zijn? Dan zou ik de tool niet draaien.

Als er zaken super traag gaan, bijv het openen van photoshop met de hele bieb aan fotos geladen kost veel tijd, dan zou ik voordat je de tool draait, eerst eens meten hoelang het openen van een dergelijk programma gaat: gewoon met een stopwatch. Hetzelfde kan je doen voor het opstarten van windows: dat zijn de oudste files, dus volgens de theorie zou het opstarten van windows het ergste lijden, het zijn immers de oudste files op je SSD.

Nadat je de tool hebt gedraaid, kan je dan mooi vergelijken hoeveel snelheidswinst je hebt behaald.

Of je staart je dood op benchmarks, die niet alles zeggen, maar voor velen het heilige der heiligen is. Zoals je zelf al ziet, je draaid de benchmark 2 keer met exact dezelfde computer, komt er 80% " snelheidsverschil" uit voor de 4k third (2e bench 80% sneller voor de writes) en de seg write is weer 50% sneller in de 1 bench, best een groot verschil uit.

[Swordlord]

Reepje, vergeet niet dat samen met de performance restoration tool, ook een firmware update wordt uitgevoerd. Dat voorkomt dat de drive zo extreem traag kan worden met lezen.

Voorkomen is beter dan genezen.

[ Voor 10% gewijzigd door Swordlord op 13-02-2015 12:41 ]

[Reepje]

Swordlord, dat was ik inderdaad vergeten.

[Verwijderd]

Ik heb een poosje geleden de Samsung firmware update en de Performance Restoration Tool op mijn Evo 120 en mijn Evo 1 GB gedraaid. Op de 120 GB werkt het goed, hij is overal even snel en de curve van HDTune is vlak. Op de 1 GB werkt het niet (goed). Zie bijgaand plaatje. De disks waren niet in gebruik op het moment van de meting. Zowel de firmware update als de restoration zijn beide compleet en zonder foutmelding uitgevoerd.

Ik ben al aan het verschuiven en kopiëren geweest, maar dan verschuiven de dalen mee van plaats. Het gaat om grote VM images, 30-100 GB per stuk. Vermoedelijk is er dus meer aan de hand dan alleen het probleem met de "oude" data. Ik merk (meet) dat de 1 GB behoorlijk warm wordt tijdens het schrijven van grote hoeveelheden data. Geen idee of dat invloed kan hebben op de foutcorrectie tijdens het lezen.

De 1 GB:


De 120 GB:

[XVI]

Vandaag via Magician 4.6 de nieuwe firmware voor m'n 840 evo opgehaald en geïnstalleerd en het is nu al meer dan vier uur huilen met de pet op.

Het goede nieuws is dat de benchmarkprestaties zienderogen vooruitgaan.
Ten tijden van de vorige firmware waarmee de schijf is geleverd:


Degradatie die aardig oploopt:



HDtune laat eenzelfde beeld zien (15 april):


Net na de nieuwe upgrade (en enkele crashes en reboots):




Verhoging van het aantal steekproeven laat zien dat het nog niet is wat het moet zijn:


Het (zeer) slechte nieuws is dat ik nu ineens met een zwaar instabiel systeem zit.
Het leek allemaal nog goed te gaan nadat ik via Windows op een HDD mijn Linuxsysteem op de SSD had bijgewerkt aangezien vervolgens m'n Fedora-installatie (F21) met btrfs (voor 45.34GiB gevuld) prima opstartte.
Echter, wanneer ik me inogde op Gnome-Shell via Plymouth donderde het hele zaakje in elkaar:
- ata link resets
- kernel panics vanwege cpu freezes
- en btrfs checksum-fouten (mogelijk vanwege de herhaalde harde resets van mijn kant)

Ik kon dus nog gewoon tekstueel inloggen maar zodra ik grafisch inlogde crashte het systeem.
Na wat geklooi met disk schedulers (ben nu van noop weer naar de standaard cfq), het scrubben van m'n btrfs (nul fouten) en het verwijderen van m'n opgeslagen Gnome-Shell-sessie wil het langzaam weer lukken om in te loggen, echter bij elke reboot is het inloggen nog steeds een crime.

Een van de volledige crashes:


De ata-link-problemen die ik nog regelmatig zie bij het inloggen:

code:

$ journalctl --system -f
apr 26 19:04:10 XVI.lan kernel: ata1.00: exception Emask 0x0 SAct 0x800000 SErr 0x0 action 0x6 frozen
apr 26 19:04:11 XVI.lan kernel: ata1.00: failed command: WRITE FPDMA QUEUED
apr 26 19:04:11 XVI.lan kernel: ata1.00: cmd 61/70:b8:e8:9d:fa/00:00:01:00:00/40 tag 23 ncq 57344 out
                                               res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
apr 26 19:04:11 XVI.lan kernel: ata1.00: status: { DRDY }
apr 26 19:04:11 XVI.lan kernel: ata1: hard resetting link
apr 26 19:04:11 XVI.lan kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
apr 26 19:04:11 XVI.lan kernel: ata1.00: supports DRM functions and may not be fully accessible
apr 26 19:04:11 XVI.lan kernel: ata1.00: supports DRM functions and may not be fully accessible
apr 26 19:04:11 XVI.lan kernel: ata1.00: configured for UDMA/133
apr 26 19:04:11 XVI.lan kernel: ata1.00: device reported invalid CHS sector 0
apr 26 19:04:11 XVI.lan kernel: ata1: EH complete
apr 26 19:04:42 XVI.lan kernel: ata1.00: exception Emask 0x0 SAct 0xc00 SErr 0x0 action 0x6 frozen
apr 26 19:04:42 XVI.lan kernel: ata1.00: failed command: READ FPDMA QUEUED
apr 26 19:04:42 XVI.lan kernel: ata1.00: cmd 60/08:50:a8:4b:65/00:00:10:00:00/40 tag 10 ncq 4096 in
                                               res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
apr 26 19:04:42 XVI.lan kernel: ata1.00: status: { DRDY }
apr 26 19:04:42 XVI.lan kernel: ata1.00: failed command: READ FPDMA QUEUED
apr 26 19:04:42 XVI.lan kernel: ata1.00: cmd 60/20:58:20:32:16/00:00:00:00:00/40 tag 11 ncq 16384 in
                                               res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
apr 26 19:04:42 XVI.lan kernel: ata1.00: status: { DRDY }
apr 26 19:04:42 XVI.lan kernel: ata1: hard resetting link
apr 26 19:04:42 XVI.lan kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
apr 26 19:04:42 XVI.lan kernel: ata1.00: supports DRM functions and may not be fully accessible
apr 26 19:04:42 XVI.lan kernel: ata1.00: supports DRM functions and may not be fully accessible
apr 26 19:04:42 XVI.lan kernel: ata1.00: configured for UDMA/133
apr 26 19:04:42 XVI.lan kernel: ata1.00: device reported invalid CHS sector 0
apr 26 19:04:42 XVI.lan kernel: ata1.00: device reported invalid CHS sector 0
apr 26 19:04:42 XVI.lan kernel: ata1: EH complete

SMART-fouten die ineens de kop op steken (voor de firmwareupgrade was hij spotless, maar oké mogelijk veroorzaakt door de harde resets):

code:

$ sudo smartctl -a /dev/sda
smartctl 6.2 2014-07-16 r3952 [x86_64-linux-3.19.4-200.fc21.x86_64] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     Samsung SSD 840 EVO 250GB
Firmware Version: EXT0DB6Q
User Capacity:    250,059,350,016 bytes [250 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sun Apr 26 20:19:12 2015 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       2092
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       120
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       2
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   099   099   000    Old_age   Always       -       2
190 Airflow_Temperature_Cel 0x0032   066   055   000    Old_age   Always       -       34
195 Hardware_ECC_Recovered  0x001a   199   199   000    Old_age   Always       -       2
199 UDMA_CRC_Error_Count    0x003e   100   100   000    Old_age   Always       -       0
235 Unknown_Attribute       0x0012   099   099   000    Old_age   Always       -       16
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       2427381314

SMART Error Log Version: 1
No Errors Logged

Gnome-Shell en dbus die over de zeik gaan bij het inloggen:


Wat apart is dat het probleem pas de kop opsteekt zodra ik inlog op m'n grafische sessie, wat te maken lijkt te hebben met het automatisch herstellen van m'n sessie (opstarten van firefox), het inladen/voorbereiden van de Gnome tracker-database (welke in mijn geval zo'n gigabyte groot is en mogelijk zwaar onderhevig is aan fragmentatie aangezien het een database is op btrfs) en mogelijk in combinatie met het wegschrijven van data (want waarom geeft anders het opstarten zelf en het scrubben van de volledige schijf geen problemen?).
Het lijkt overigens langzaam iets beter te worden (algoritme heeft voldoende data ververst?), maar de kans lijkt me groot dat wanneer de schijf een weekje of twee uitstaat het feest weer van voor af aan begint.

Kortom, ik ben dus door de firmwareupdate van een enigszins vertraagd (in de benchmarks en bij het dumpen van de schijf, bij normaal gebruik merkte ik niks) maar absoluut stabiel systeem naar een in de benchmarks sneller maar compleet instabiel systeem gegaan.
Bedankt Samsung voor je mislukte lapmiddeltjes voor deze baggerdrive
Een recall lijkt me de enige correcte oplossing.

Ik ga nu eens kijken of ik m'n systeem weer in de gewenste staat kan krijgen (door te defragmenteren, mogelijk de tracker uit te schakelen en zo nodig een downgrade van de firmware).
Weet iemand of de firmware überhaupt kan worden gedowngraded?

Edit: na een internetzoektochtje naar "ata failed command: READ FPDMA QUEUED samsung 840" blijkt het dat samsung er wel vaker een potje van maakt (ik vind dat Samsung het nadeel van de twijfel heeft).
Heb nu NCQ uitgeschakeld en het lijkt nu weer stabiel.
Wel vreemd dat dit al een tijd een groot probleem is maar dat ik er nu pas last van heb.

Edit 2: nog wat verder gezocht en het lijkt erop dat Samsung zich op bepaalde zaken niet aan de sata-standaard houdt.
In Linux 3.19 stond het nog twee keer (blijkbaar omdat ze zelfs niet de eigen naam consistent kunnen spellen in de identifier) in de blacklist voor ATA_HORKAGE_ZERO_AFTER_TRIM voor al zijn SSD's en in 4.0 is daar een derde vermelding bijgekomen voor de 850 pro voor ATA_HORKAGE_NO_NCQ_TRIM.
Ik vermoed dat er in de toekomst nog meer van Samsung op de blacklist wordt gezet (of de specifieke regel voor de 850 wordt veralgemeniseerd) want het lijkt erop dat ze de zaken met de firmwareupgrades alleen maar meer verprutsen.
Ik vind dat de markleider in SSD's, die tevens actief adverteert met hun geweldigde NCQ (wel acht vermeldingen op deze site), zich wel eens wat professioneler mag opstellen.
Ik ga me bij mijn volgende aankoop dus maar eens flink achter m'n oren krabbelen na het hele 840 debacle.

[ Voor 12% gewijzigd door XVI op 27-04-2015 13:50 . Reden: Work-around gevonden ]

[jaaoie17]

Ik heb sinds december een Samsung evo 840 met firmware EXT0CB6Q en heb de SSDReadSpeedTester op mn windows 7 partitie gedaan. Heb nu mn twijfels als mn resultaten wel goed zijn.


http://www14.zippyshare.com/v/ZGDX3PyH/file.html

Is het nu verstandig dat ik die firmware update doe? En hoef ik over mn data geen zorgen te maken?

[LordSinclair]

jaaoie17 schreef op donderdag 30 april 2015 @ 15:29:
Is het nu verstandig dat ik die firmware update doe? En hoef ik over mn data geen zorgen te maken?

Een firmware update brengt altijd (een gering) risico met zich mee. Een backup is altijd aan te raden. Mocht je nog geen backup hebben nu dan is de data blijkbaar toch al niet zo belangrijk voor jou

[jaaoie17]

LordSinclair schreef op donderdag 30 april 2015 @ 15:52:
[...]

Een firmware update brengt altijd (een gering) risico met zich mee. Een backup is altijd aan te raden. Mocht je nog geen backup hebben nu dan is de data blijkbaar toch al niet zo belangrijk voor jou

Van de belangrijke files heb ik wel een backup gemaakt, maarja op 1 partitie heb ik 300 gig aan games staan. Maar gaat een firmware update in de meeste gevallen wel goed zonder data verlies?

En wou eigelijk ook gewoon die iso via een bootable cd gebruiken ook al gebruik ik gewoon windows. Dat kan gewoon toch?

[Tomino]

Is er hier iemand die tegen verzendkosten (of ophalen in omgeving Breda, Den Haag of Groningen) een USB to Sata kabel heeft liggen die met sommige Evo's geleverd worden? Krijg het spul niet via een bootable USB aan de gang en moet gaan klonen..

[Maj-Maj]

Ik probeer zojuist de firmware eindelijk een keer bij te werken (zit nu nog op EXT0BB6Q), krijg ik de melding "failed to update firmware on the selected drive". Weet iemand hoe ik dit wel gedaan krijg? Had ook al problemen toen ik destijds de performance retoration wilde draaien. Ligt het misschien aan de drivers?

[temp00]

Welke OS gebruik je en welke schijf?

[Maj-Maj]

Windows 7, 840 EVO.

[Reepje]

Maj-Maj schreef op vrijdag 26 juni 2015 @ 19:19:
Windows 7, 840 EVO.

En op welk moederbord, en op welke sata poort?

[Erhnam]

Hier ook na de upgrade van de firmware (840) een zwaar instabiel systeem. iMac en regelmatig hangers of Finder die ik moet rebooten...

[Maj-Maj]

Reepje schreef op vrijdag 26 juni 2015 @ 21:09:
[...]


En op welk moederbord, en op welke sata poort?

Zit in een laptop (ASUS K53SV). Heb destijds de 840 EVO erin gedaan voor mijn oude harde schijf.

[Reepje]

Realiseer je, dat deze laptop van voor het ssd-tijdperk was (4 jaar oud). Het is dus best mogelijk dat het niet helemaal "plug-and-play" is, zoals voor veel desktops wel het geval is.
Zo zit ik ook te kijken met een nog 1 jaar oudere laptop van ASUS, waar de SSD ook niet echt wil.

Waar je problemen precies aan liggen, ik weet het niet. Ga eerst eens na of er een meer recente bios is, loop daarna de windows update en kijk op de laptop dan wel beter op de SSD reageerd.

[LordSinclair]

Reepje schreef op zaterdag 27 juni 2015 @ 15:07:
Realiseer je, dat deze laptop van voor het ssd-tijdperk was (4 jaar oud).

SSD's zijn er al langer hoor ;-) In 2010 waren ze al redelijk betaalbaar zelfs.

[Maj-Maj]

Reepje schreef op zaterdag 27 juni 2015 @ 15:07:
Realiseer je, dat deze laptop van voor het ssd-tijdperk was (4 jaar oud). Het is dus best mogelijk dat het niet helemaal "plug-and-play" is, zoals voor veel desktops wel het geval is.
Zo zit ik ook te kijken met een nog 1 jaar oudere laptop van ASUS, waar de SSD ook niet echt wil.

Waar je problemen precies aan liggen, ik weet het niet. Ga eerst eens na of er een meer recente bios is, loop daarna de windows update en kijk op de laptop dan wel beter op de SSD reageerd.

Het probleem is de allereerste firmware updates wel gewoon werkten, dus heb niet het idee dat het echt aan de hardware ligt.

[nooberke]

Maj-Maj schreef op zaterdag 27 juni 2015 @ 13:50:
[...]


Zit in een laptop (ASUS K53SV). Heb destijds de 840 EVO erin gedaan voor mijn oude harde schijf.

Mijn pa heeft ook een Asus K53SV, hierop werkte de restoration tool voor Windows zonder problemen. Dit is wel een eigen "schone" Windows installatie, dus niet met Asus zooi

[Maj-Maj]

nooberke schreef op zaterdag 27 juni 2015 @ 19:52:
[...]


Mijn pa heeft ook een Asus K53SV, hierop werkte de restoration tool voor Windows zonder problemen. Dit is wel een eigen "schone" Windows installatie, dus niet met Asus zooi

Aha, dat is goed om te weten. Bij mij was dat dus niet het geval. Ik heb inderdaad ook geen schone installatie gedaan. Mijn vermoeden is toch dat het iets met de drivers te maken heeft. Dat werd ook als oplossing gegeven als die tool niet werkte.