SSD niet stabiel onder Linux

[Buntmans]

Ik heb een simpele machine draaien op Ubuntu die ik voornamelijk gebruik als HTPC (Kodi).

ASRock Q1900-ITX + wat geheugen en voeding, meer is het niet. Voorheen had ik daar een HDD in zitten en het system was uiterst stabiel. Ik heb het nooit vast zien lopen of crashen. Wel eens een app die vastloopt oid maar valt altijd eenvoudig te killen.

Ik heb onlangs de HDD vervangen door een SSD (Samsung 840 EVO 120GB) en krijg het systeem maar niet stabiel. Ik heb nu 3 weken bezig en mijn ideeen beginnen op te raken.

Wat gebeurt er precies?

Het systeem loopt op random momenten vast. Soms gaat het een hele dag goed, soms gaat het 3x op een dag mis. En het systeem loopt dan ook ECHT vast. Reageert nergens meer op behalve op een harde reset. In syslog zie ik geen foutmeldingen, ik zie zelfs helemaal geen meldingen die vooraf lijken te gaan aan de freeze-up. In Kodi logs zie ik ook niets. Hij gaat gewoon POEF freeze nergens een foutmelding. Met de HDD is alles stabiel, dus het moet aan de SSD liggen. De SSD zelf is prima heeft 1.5 jaar zonder fouten gedraaid in een windows machine en ik heb ook checks uitgevoerd voor ik hem eruit haalde.

Wat heb ik al geprobeerd?

-ubuntu opnieuw geinstalleerd.. (zon 8x in totaal nu ) -> zowel 14.04 en 14.10
(ik heb de nieuwe firmware erop gezet nog op de windows machine. als je gaat zoeken vind je dat het mogelijk aan queued trim support ligt. in de nw firmware stond die ineens aan, terwijl hji niet werkte. echter in de nieuwe kernel is dit aangepast (geblacklist) dus dit kan het niet zijn)
-andere sata poort gepakt (er zitten 2*sataII en 2*sataIII poorten op mobo)
-NCQ uitgeschakeld
-op IDE mode gezet ipv AHCI
-cronjob gemaakt en voor dagelijks TRIM
-bios en sdd beide nieuwste firmware
-begon op gegeven moment te twijfelen... ligt het toch ergens anders aan? HDD gepakt, en alles is weer 100% stabiel...

Nu wil ik best een nieuwe/andere SSD kopen maar zolang ik niet weet waarom het nu niet werkt lijkt me dat niet verstandig.

Iemand nog een idee wat ik kan proberen? Hoeft niet perse de oplossing te zijn met het weten van de oorzaak ben ik ook al een stuk verder.

[Blokker_1999]

heb je al eens geprobeerd met TRIM volledig uit te schakelen? Is er iets vreemds op te merken wanneer je de S.M.A.R.T. data uitleest?

Je hebt een andere SATA poort geprobeerd, maar heb je ook de bekabeling al veranderd?

Ik ben op dit moment zelf bezig met de uitrol van een 15tal debian systemen met dezelfde SSD (840 evo, 120GB) en ben tot op heden nog geen problemen tegengekomen.

[gekkie]

Welke kernel draait die ubuntu ?

Ik heb zelf momenteel ook problemen op m'n x220 dat alles vast loopt, met een 3.16 niet
met recente kernels wel. Moet nog eens kijken of ik er met een serial console achter kan komen wat het is. Is op LKML ook al een melding van een andere thinkpad gebruiker die ook complete freezes heeft, die verwijte dan weer bluetooth, maar had ook geen stacktraces en zonder dat blijft het toch gokken wat het is.

[Buntmans]

Blokker_1999 schreef op donderdag 20 augustus 2015 @ 18:17:
heb je al eens geprobeerd met TRIM volledig uit te schakelen? Is er iets vreemds op te merken wanneer je de S.M.A.R.T. data uitleest?

Je hebt een andere SATA poort geprobeerd, maar heb je ook de bekabeling al veranderd?

Ik ben op dit moment zelf bezig met de uitrol van een 15tal debian systemen met dezelfde SSD (840 evo, 120GB) en ben tot op heden nog geen problemen tegengekomen.

Ik deed eerst helemaal niets met TRIM. Later tijdens de zoektocht heb ik een cronjob gemaakt voor fstrim -v.

Bekabeling is denk ik niet het probleem aangezien ik datzelfde kabeltje gebruik voor de HDD en dan is alles ok. Maar ik zal het toch vervangen wie weet, ik heb ze toch liggen.

Device Model: Samsung SSD 840 EVO 120GB
Serial Number: S1D5NSAF292954J
LU WWN Device Id: 5 002538 8a024fc83
Firmware Version: EXT0BB6Q
User Capacity: 120,034,123,776 bytes [120 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: 3.0 Gb/s)
Local Time is: Thu Aug 20 21:04:33 2015 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Ik heb een SMART selftest gedaan:

SMART overall-health self-assessment test result: PASSED

Wat verder van de smartdata belangrijk is weet ik niet, maar ik zie zo iig geen errors.

gekkie schreef op donderdag 20 augustus 2015 @ 18:26:
Welke kernel draait die ubuntu ?

Ik heb zelf momenteel ook problemen op m'n x220 dat alles vast loopt, met een 3.16 niet
met recente kernels wel. Moet nog eens kijken of ik er met een serial console achter kan komen wat het is. Is op LKML ook al een melding van een andere thinkpad gebruiker die ook complete freezes heeft, die verwijte dan weer bluetooth, maar had ook geen stacktraces en zonder dat blijft het toch gokken wat het is.

3.16.0-44-generic

[ Voor 29% gewijzigd door Buntmans op 20-08-2015 21:07 ]

[gekkie]

Hmm en je hebt op de hdd en de ssd een exacte kopie (inclusief dezelfde kernel ?)

[johnkeates]

Hoe weet je dat het de SSD is? Puur een gokje om dat het het enige verwisselde onderdeel is? Het kan namelijk ook zijn dat je tijdens het onderhoud iets anders stuk gemaakt hebt he.

[Buntmans]

johnkeates schreef op donderdag 20 augustus 2015 @ 21:42:
Hoe weet je dat het de SSD is? Puur een gokje om dat het het enige verwisselde onderdeel is? Het kan namelijk ook zijn dat je tijdens het onderhoud iets anders stuk gemaakt hebt he.

Zoals je kunt lezen heb ik de HDD als eens teruggeplaatst en dan is alles weer ok. Maar inderdaad omdat het probleem zich voordeed na het installeren van de SSD en weer verdween als ik dat terugdraaide.

En inderdaad de installaties zijn gelijk op de HDD en de SSD. Beide volledig geupdate versies van LTS. Op dit exacte moment toevallig even 14.10 op de SSD maar het probleem is er op 14.04 en op 14.10. Ik ga dus ook weer voor 14.04 de volgende reinstall want als het het probleem niet oplost blijf ik liever op de LTS release. Reden voor 14.10 was dat de nieuwe intel drivers 14.10 vereisten en ik dacht ach laat ik dat eens proberen. Werkte niet trouwens en dat had ik kunnen weten want LTS draait prima op de standaard intel drivers (op de HDD dus).

edit.

Ik heb net ergens gelezen dat iemand zijn SSD freeze op heeft gelost door zijn swap partitie groter te maken dan zijn geheugen. Mijn swap partie was 3.6GB en mijn geheugen 4. Ik heb de swap partie net groter gemaakt met gparted naar 4.5GB. Wie weet

bron: http://www.howtoeverythin...e-issue-after-ssd-upgrade

[ Voor 21% gewijzigd door Buntmans op 20-08-2015 21:53 ]

[WPN]

Is het ook instabiel op andere linux releases?

[Buntmans]

WPN schreef op donderdag 20 augustus 2015 @ 21:56:
Is het ook instabiel op andere linux releases?

niet geprobeerd.

[Thc_Nbl]

Ik durf te wedden dat als je een mainline kernel pakt uit 4.1 serie, dat de boel stabiel draait.

probeer deze eens
http://kernel.ubuntu.com/...mainline/v4.1.6-unstable/

ik draai zelf ook met een evo op ubuntu met de 4.2 rc6 kernel, werkt bij mij prima stabiel.
SSD support is flink verbeterd in de 4.x kernels.

[ Voor 11% gewijzigd door Thc_Nbl op 20-08-2015 22:03 ]

[Buntmans]

Thc_Nbl schreef op donderdag 20 augustus 2015 @ 22:00:
Ik durf te wedden dat als je een mainline kernel pakt uit 4.1 serie, dat de boel stabiel draait.

probeer deze eens
http://kernel.ubuntu.com/...mainline/v4.1.6-unstable/

ik draai zelf ook met een evo op ubuntu met de 4.2 rc6 kernel, werkt bij mij prima stabiel.
SSD support is flink verbeterd in de 4.x kernels.

ok ga ik proberen. help me eens op weg.

linux-image-4.1.6-040106-generic_4.1.6-040106.201508170230_amd64.deb

die installen met dpkg -i ?

[gekkie]

Thc_Nbl schreef op donderdag 20 augustus 2015 @ 22:00:
Ik durf te wedden dat als je een mainline kernel pakt uit 4.1 serie, dat de boel stabiel draait.

probeer deze eens
http://kernel.ubuntu.com/...mainline/v4.1.6-unstable/

ik draai zelf ook met een evo op ubuntu met de 4.2 rc6 kernel, werkt bij mij prima stabiel.
SSD support is flink verbeterd in de 4.x kernels.

4.2-rc6 zitten nog wel wat bugjes in (rc-7 ook, denk dat er opzich wel een kansje op een rc-8 is) .. maar die bugs oopsen ipv een freeze.

[Thc_Nbl]

1 regel is het hieronder..

wget http://kernel.ubuntu.com/...06.201508170230_amd64.deb http://kernel.ubuntu.com/...0106.201508170230_all.deb http://kernel.ubuntu.com/...06.201508170230_amd64.deb

en
dpkg -i *.deb

[Thc_Nbl]

heb erg... dat je niet de regels als http://kernel.ubuntu.com/...06.201508170230_amd64.deb kopieert.. ;-)

[Thc_Nbl]

en mocht je je probleem exact willen weten.

https://bugs.launchpad.ne...ource/fstrim/+bug/1449005

zet zowiezo je scriptje uit met het trim commando.
lees het linkje maar even goed.

[Buntmans]

Thanks ik draai nu op

4.1.6-040106-generic

ik wist dat er iets mis was met die firmware maar ik dacht dat ik al op de kernel zat waarin dat vervolgens weer is opgelost, dank en we wachten af!

[gekkie]

Pffrt zouden ze nu ook de normale fstrim nog gesloopt hebben.
Zijn ze toch wel een toppertje en een breezert ananananas.

[ Voor 32% gewijzigd door gekkie op 20-08-2015 22:29 ]

[Thc_Nbl]

Nou, nu afwachten dan, we horen wel of het goed gaat nu.

[Hero of Time]

Thc_Nbl schreef op donderdag 20 augustus 2015 @ 22:10:
1 regel is het hieronder..

wget http://kernel.ubuntu.com/...06.201508170230_amd64.deb http://kernel.ubuntu.com/...0106.201508170230_all.deb http://kernel.ubuntu.com/...06.201508170230_amd64.deb

en
dpkg -i *.deb

Zeg eens prutser, wel eens van [code] tags gehoord? Dan komt het er fatsoenlijk in te staan en hoef je ook niet te tripple posten, dat is nog veel erger dan dubbelposten.

Dit dus:

code:

wget  http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.1.6-unstable/linux-headers-4.1.6-040106-generic_4.1.6-040106.201508170230_amd64.deb http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.1.6-unstable/linux-headers-4.1.6-040106_4.1.6-040106.201508170230_all.deb http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.1.6-unstable/linux-image-4.1.6-040106-generic_4.1.6-040106.201508170230_amd64.deb

[Thc_Nbl]

Hero... Je hebt helemaal gelijk..
Maar om mij nu prutser te noemen, vind ik wel flauw hoor...
Ik wilde deze meneer/mevrouw gewoon even snel helpen gezien deze ook op hetzelfde moment online was en zodoende dus de tags vergeten...
Ik zal volgende keer de code tags gebruiken.
Mijn Excuses hoor..... (return mode... zeikert.) ;-)

[Allard Pruim]

Thc_Nbl schreef op donderdag 20 augustus 2015 @ 22:14:
en mocht je je probleem exact willen weten.

https://bugs.launchpad.ne...ource/fstrim/+bug/1449005

zet zowiezo je scriptje uit met het trim commando.
lees het linkje maar even goed.

Bedankt voor dit linkje naar het bugreport, ik heb ook een Samsung 840 EVO 120GB en ik was van plan om de allerlaatse firmware erop te zetten. Ik wacht echter wel eventjes.

[Hero of Time]

Thc_Nbl schreef op vrijdag 21 augustus 2015 @ 12:53:
Hero... Je hebt helemaal gelijk..
Maar om mij nu prutser te noemen, vind ik wel flauw hoor...
Ik wilde deze meneer/mevrouw gewoon even snel helpen gezien deze ook op hetzelfde moment online was en zodoende dus de tags vergeten...
Ik zal volgende keer de code tags gebruiken.
Mijn Excuses hoor..... (return mode... zeikert.) ;-)

Ik bedoelde 't uiteraard met een knipoog.

[Buntmans]

Inmiddels heel wat uurtjes gedraaid op de nieuwe kernel en helemaal geen vastlopers meer gehad.

Het lijkt er dus op dat het probleem is opgelost! Dank voor de assistentie!

[Thc_Nbl]

Dat is fijn om te horen, dan kan dit topic gesloten worden met SOLVED !

@Hero .. tuurlijk dat snapte ik ook wel.. maar.. je kan soms wat "hard" overkomen.
uiteindelijk willen we beide het zelfde, een goed lopend forum met goede en duidelijke oplossingen voor de mensen.

Groetjes !

[HollowGamer]

Hier totaal geen problemen met Samsung SSD 840/850.
Wilde nog even vragen of je TRIM (nu wel) hebt ingeschakeld of niet?
Gebruik hiervoor een timer (of cronjob) i.p.v. discard. Heb je al naar een andere FS gekeken? Klinkt gek, maar Btrfs draait bij mij beter en sneller dan ext4 op mijn ssd's. Ook over ZFS lees ik veel positieve verhalen.

Kijk ook eens op de Arch Linux SSD wiki page, veel tips, ook over het inrichten van de partities, etc. Die kunnen vastlopers namelijk ook voorkomen.

[Buntmans]

TRIM gaat gewoon goed lijkt het. Wekelijkse FSTRIM (cronjob), dus geen discard.

File system is standaard (ext4). Geen andere geprobeerd.

Inmiddels ben ik vastloper-vrij. Het gebeurde gemiddeld 1x per 4 uur actief gebruik. Inmiddels een uptime van 10 dagen zonder errors of wat dan ook.

Nu ben ik wel nieuwsgierig. Gebruik jij de EXT0BB6Q firmware op de 3.16.x kernel ? Want dat lijkt hier de combinatie te zijn waarbij het mis gaat.

[ Voor 6% gewijzigd door Buntmans op 30-08-2015 13:07 ]

[cooper_s1]

Buntmans, welke kernel draait jouw systeem? Ik heb een asrock Q1900-ITX die op SuSe Tumbleweed draait met kernel 4.1.6-3 en die hangt geregeld, al is het niet meet een ssd maar een gewone sata hdd.
Mij lijkt het naar dit:
https://bugs.freedesktop.org/show_bug.cgi?id=88012
te verwijzen.....

[letatcest]

Fijn dat ik deze post tegenkom. Ik heb ook last van af en toe random keiharde, u kunt niks meer doen, vastlopers. Heel irritant. Maar omdat mijn hele opstelling nieuw is, wilde ik beginnen met een Memtest-momentje.Iets wat spontaan ruzie heeft gemaakt met Uefi (en nu kan ik die ubuntu-partitie niet meer booten, maar nog geen tijd gehad uit te zoeken hoe ik daar iets tegen kan doen).. Nu uitgezocht. Eens kijken of ik iets heb aan bovengenoemde oplossingen

[ Voor 9% gewijzigd door letatcest op 08-09-2015 21:48 ]

[HollowGamer]

Buntmans schreef op zondag 30 augustus 2015 @ 13:06:
TRIM gaat gewoon goed lijkt het. Wekelijkse FSTRIM (cronjob), dus geen discard.

File system is standaard (ext4). Geen andere geprobeerd.

Inmiddels ben ik vastloper-vrij. Het gebeurde gemiddeld 1x per 4 uur actief gebruik. Inmiddels een uptime van 10 dagen zonder errors of wat dan ook.

Nu ben ik wel nieuwsgierig. Gebruik jij de EXT0BB6Q firmware op de 3.16.x kernel ? Want dat lijkt hier de combinatie te zijn waarbij het mis gaat.

Dat klinkt goed.

Ik heb eerlijk gezegd geen idee, maar kom erachter dat ik in mijn NAS een cheap SSD van Intel erin heb zitten (330?). Ook deze draait al een paar jaren zonder problemen, ook daarvoor heb ik hem intensief gebruikt (maar dan op Windows). Maar altijd voorzichtig zijn..

De 840 (laptop)/850 (desktop) draaien hier ook prima op de nieuwste Linux-kernel (4.3). Ik ben wel overgestapt van ext4 naar btrfs. Verder lees ik wel dat een aantal dingen gefixed zijn voor ext4 in de nieuwe kernel releases.

Vorig jaar had ik wel een paar problemen, maar die zag ik allemaal terug in mijn dmesg. Daardoor even terug naar de LTS kernel, maar het was gelukkig vrij snel allemaal weer opgelost.

Kijk dus goed in je dmesg, daar komen meestal problemen erg snel naar voren.
Ik heb nog nooit in mijn leven een (volledige) RAM-test gedraaid btw. - die dingen zijn meestal niet altijd de oorzaak.

[Buntmans]

HollowGamer schreef op dinsdag 08 september 2015 @ 22:11:
[...]

Kijk dus goed in je dmesg, daar komen meestal problemen erg snel naar voren.

Ik heb wel deze error in dmesg, altijd gehad bij deze SSD:

failed to get NCQ Send/Recv Log Emask 0x1

Als ik NCQ uitschakel is de error ook weg. Echter volgens mij duidt dit niet op een probleem aangezien alles perfect werkt nu met NCQ aan. Als ik erop google vind ik ook niet echt iets dat erop duidt dat dit een probleem is.

Het is wel vaak genoemd in verband met bovengenoemd probleem (met oude kernel). Maar probleem is nu weg en error is er nog, dus tja

Ik heb nog nooit in mijn leven een (volledige) RAM-test gedraaid btw. - die dingen zijn meestal niet altijd de oorzaak.

Nachtje memtest doe ik standaard bij een nieuw systeem/configuratie of als zich problemen voordoen. En ik ben in mijn leven heel wat errors tegengekomen

[HollowGamer]

Buntmans schreef op dinsdag 08 september 2015 @ 22:29:
Ik heb wel deze error in dmesg, altijd gehad bij deze SSD:

failed to get NCQ Send/Recv Log Emask 0x1

Als ik NCQ uitschakel is de error ook weg. Echter volgens mij duidt dit niet op een probleem aangezien alles perfect werkt nu met NCQ aan. Als ik erop google vind ik ook niet echt iets dat erop duidt dat dit een probleem is.

Dit probleem heb ik al eens gehoord: https://wiki.archlinux.or...ives#Resolving_NCQ_errors

Komt voor bij brakke firmware (SSD of het moederbord). Weet niet of het een verschil maakt, maar ik maak altijd gebruik van (U)EFI. Ik kan mij zo vaag herinneren dat ik deze ook heb (gehad?), maar tot nu toe geen problemen zoals hier vermeld:

code:

$ dmesg|grep -i ncq
[    0.629476] ahci 0000:00:1f.2: flags: 64bit ncq led clo pio slum part ems apst
[    0.957379] ata1.00: 117231408 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[    0.957785] ata6.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA

Op mijn beide nas'en gelukkig niks.

Buntmans schreef op dinsdag 08 september 2015 @ 22:29:
Het is wel vaak genoemd in verband met bovengenoemd probleem (met oude kernel). Maar probleem is nu weg en error is er nog, dus tja

En je hebt alles volledig up-to-date? Van drivers tot de kernel(-modules)?
Al eens een ander distro geprobeerd? Bijvoorbeeld Arch?
Reden waarom: een disto bakt meestal zijn eigen kernel met een aantal patches die (nog) niet in de Linux-kernel zitten.

Buntmans schreef op dinsdag 08 september 2015 @ 22:29:
Nachtje memtest doe ik standaard bij een nieuw systeem/configuratie of als zich problemen voordoen. En ik ben in mijn leven heel wat errors tegengekomen

Of ik heb altijd geluk of .. Meestal wat schoonmaken (de modules) met (de goede) alcohol en de modules gaan weer een tijd mee.

[Buntmans]

HollowGamer schreef op dinsdag 08 september 2015 @ 22:51:
[...]

Dit probleem heb ik al eens gehoord: https://wiki.archlinux.or...ives#Resolving_NCQ_errors

Deze errors zijn toch weer net anders. De specifieke error die ik krijg lijkt me redelijk onschuldig. Iets met een een log dat hij niet kan schrijven/lezen oid. Ik maak me iig nergens zorgen om en vind het dus ook verder prima zo.