Linux kernels en Samsung 840 SSD

[Buntmans]

Ik had een ubuntu systeempje draaien was super stabiel.

Toen voegde ik een Samsung 840 SSD toe als systeemschijf en was het constant vastlopers.

Alles geprobeerd ik kwam er niet uit. Topic gemaakt en op advies van een medetweaker een andere kernel geinstalleerd.

Probleem opgelost alles weer ontzettend stabiel.

Totdat ik vorige week van 14.04 LTS naar 16.04 LTS ging. Weer precies hetzelfde probleem. Oude kernel er weer opgezet en in GRUB aangegeven de oude kernel te gebruiken. Alles weer ok.

3.16.0-44-generic -> kernel die ik draaide op moment dat ik de SSD installeerde. met deze kernel loopt hij steeds vast

4.1.6-040106-generic -> met deze kernel is alles stabiel

4.4nogwat -> kernel die standaard bij 16.04 wordt geinstalleerd. met deze kernel zijn de problem weer terug

Dit is toch wel verontrustend. Dat de SSD niet goed werkte op een oudere kernel kon ik begrijpen. Dat een nieuwe versie het probleem oploste leek me dus ook logisch. Maar dat het probleem weer terugkomt in een nieuwere versie vind ik vreemd.

Is er iemand bij wie er een belletje gaan rinkelen bij mij namelijk niet. Maar ik weet ook weinig van de verschillen tussen kernels. Nieuwere kernel = meer hardware support heb ik geleerd. Maar die vlieger lijkt dus niet op te gaan.

[DJMaze]

Ik heb zelf een 840 Pro en een 850 Pro en nog nooit echt problemen mee gehad (Fedora welke kernel dan ook).
In het andere topic heb je het over de EVO maar de problemen zijn redelijk gelijk.

Mijn probleem is dat het systeem soms even "vast" zit, maar dat verwijt ik aan de slechte nVidia driver onder KDE, en werkt paar seconden later gewoon weer.

Ik heb /home wel op een HDD staan en dat maakt misschien uit.

Voorheen liep mijn PC vooral vast door een te snel kapot gegaan "military-grade" MSI moederbord. En gebruik nu een ASUS (zo jammer dat Intel geen desktop mobo's meer maakt).

Het eerste belletje dat rinkelde was: async/queued TRIM
Maar dat is al behandeld in het vorige topic.

Dus misschien een moederbord probleem?

[Blokker_1999]

Wat zeggen de logs van je systeem?

[Buntmans]

DJMaze schreef op vrijdag 16 september 2016 @ 17:14:
Ik heb zelf een 840 Pro en een 850 Pro en nog nooit echt problemen mee gehad (Fedora welke kernel dan ook).
In het andere topic heb je het over de EVO maar de problemen zijn redelijk gelijk.

Mijn probleem is dat het systeem soms even "vast" zit, maar dat verwijt ik aan de slechte nVidia driver onder KDE, en werkt paar seconden later gewoon weer.

Ik heb /home wel op een HDD staan en dat maakt misschien uit.

Voorheen liep mijn PC vooral vast door een te snel kapot gegaan "military-grade" MSI moederbord. En gebruik nu een ASUS (zo jammer dat Intel geen desktop mobo's meer maakt).

Het eerste belletje dat rinkelde was: async/queued TRIM
Maar dat is al behandeld in het vorige topic.

Dus misschien een moederbord probleem?

Toen ik nog op de standaard 14.04 kernel zat (3.16) en OS draaide vanaf een HDD was er niets aan de hand. Ik heb dit destijds ook meermalen getest: OS op HDD -> stabiel, OS op SSD -> instabiel

En inderdaad ik dacht ook aan de TRIM. Volgens mij is hij in 4.1.6 geblacklist voor queued TRIM. Maar dat zal in 4.4 dan toch nog steeds wel zo zijn zou je zeggen.

Het is vreemd.

[Buntmans]

Blokker_1999 schreef op vrijdag 16 september 2016 @ 17:48:
Wat zeggen de logs van je systeem?

Helemaal niets rond het moment van freezen. Enige wat je ziet zijn de berichten in de syslog van het opnieuw opstarten nadat ik op de reset knop heb gedrukt.

[Basz0r]

Wat zie je in dmesg als je machine een tijdje aan het draaien is? (nog voordat deze gecrasht is)

Je had het aan het eindje van je vorige topic over een onschuldige melding. Maar misschien is die juist wel relevant

[Hero of Time]

Je ziet dus niets als je de logs met tailf volgt? Heb je nog een firmware update voor je SSD? Die kan ook wel wat fixen voor je, want als het in 4.1.6 was uitgeschakeld en nu niet meer, zou dat eerder zijn omdat er behoorlijk wat fixes voor zijn gedaan, maar dan moet wel de firmware op de SSD zijn bijgewerkt om hiermee fatsoenlijk overweg te kunnen.

Overigens, als het systeem vast loopt, en dan echt zo hangen dat je niets meer kan, ook niet naar een TTY schakelen ofzo, dan vraag ik mij af wat er echt aan de hand is. Als je SSD opeens niet meer bruikbaar is, het reageert bijvoorbeeld niet meer, zou ik toch ander gedrag verwachten zoals I/O errors en crashes van software oid.
Ik heb een HDD gehad die spontaan uit ging (was een Maxtor die tegen z'n einde aan zat), maar zolang ik geen gekke dingen deed zoals programma's starten e.d. bleef m'n systeem gewoon draaien. De schijf spinde later weer gewoon op en kon ik weer doen wat ik wilde.

[DJMaze]

Buntmans schreef op vrijdag 16 september 2016 @ 22:43:
Helemaal niets rond het moment van freezen. Enige wat je ziet zijn de berichten in de syslog van het opnieuw opstarten nadat ik op de reset knop heb gedrukt.

Ooit had ik wel eens vastloper maar dat is dan vaak de GUI.
Ik logde dan in via mijn mobiel app Vx ConnectBot op de PC en kon dan alles tracen en herstarten.
Ik kon ook gewoon live loggen met "tail -f" via andere pc/tablet/mobiel.

Verder: LVM en Swap op een SSD zijn niet raadzaam, dit geeft zeker problemen en al helemaal als de schijf meer dan 50% vol raakt.
Zorg ook voor genoeg geheugen. Ik heb zelf 8GB maar het ziet er toch zo uit:

code:

KiB Mem :  8117632 total,  4412612 free,  1725696 used,  1979324 buff/cache
KiB Swap:  8142844 total,  7292340 free,   850504 used.  5990960 avail Mem

Daarnaast is je /tmp in een ramdisk/tmpfs ook niet onbelangrijk als je genoeg geheugen hebt.

Alles draait om disk I/O

P.S. Was jou dit wel opgevallen in het vorige topic wat je zelf poste (over de sata snelheid)?

Buntmans schreef op donderdag 20 augustus 2015 @ 21:03:
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)

[ Voor 10% gewijzigd door DJMaze op 17-09-2016 00:04 . Reden: P.S. toegevoegd ]

[Blokker_1999]

DJMaze schreef op vrijdag 16 september 2016 @ 23:54:
[...]Verder: LVM en Swap op een SSD zijn niet raadzaam, dit geeft zeker problemen en al helemaal als de schijf meer dan 50% vol raakt.

[...]

Waar komt die wijsheid vandaan?

[DJMaze]

Blokker_1999 schreef op zaterdag 17 september 2016 @ 10:18:
Waar komt die wijsheid vandaan?

Ik zou zeggen, begin eens hier: https://lwn.net/Articles/428584/
En lees daarna verder over de voor/nadelen van VLC NAND en de grote van de GNU/Linux bestanden die je dagelijks wegschijft naar de disk.
En calculeer eens hoeveel GB aan writes dat is per dag (dat kan prima met dstat).

[ Voor 39% gewijzigd door DJMaze op 17-09-2016 13:11 ]

[Blokker_1999]

Daar wil ik toch direct 2 dingen tegen opwerpen:

Het artikel is 5 jaar oud, een eeuwigheid in de IT. Daarnaast verstond men in die tijd onder "cheap flash drives" zeker geen SSDs maar wel CF, SD en (e)MMC geheugen.

Moderne SSDs hebben een veel betere controller aan boord en de betere SSDs hebben een grote overprovisioning die wear leveling eenvoudiger maakt en bijvoorbeeld een SSD goed kan laten werken zelfs zonder TRIM ondersteuning. Met de lange levensduur van moderne SSDs vormt het plaatsen van SWAP space op een SSD ook helemaal geen probleem meer.

[gekkie]

Meh als ik nou ergens geen problemen mee heb is het met LVM (en dm-crypt) op de SSD in m'n laptop.
Swappen doet tie niet snel want ik heb de swapiness aangepast naar alleen swappen in uiterste nood. Aangezien ik op linux (vanwege xfce als DE) niet zo snel uit m'n 12GB geheugen loop.

Daarnaast is die wijsheid van dat artikel gebaseerd op simpele flashkaartjes en niet op SSD's en daarnaast uit 2011.

[ECP0WERS]

Heb je ook al een nieuwere kernel gebruikt? (4.7.2/4.8 RC)

[H!GHGuY]

DJMaze schreef op zaterdag 17 september 2016 @ 13:02:
[...]

Ik zou zeggen, begin eens hier: https://lwn.net/Articles/428584/
En lees daarna verder over de voor/nadelen van VLC NAND en de grote van de GNU/Linux bestanden die je dagelijks wegschijft naar de disk.
En calculeer eens hoeveel GB aan writes dat is per dag (dat kan prima met dstat).

Lees vervolgens dit even:
https://lwn.net/Articles/690079/

[DJMaze]

Blokker_1999 schreef op zaterdag 17 september 2016 @ 13:09:
Moderne SSDs hebben een veel betere controller aan boord en de betere SSDs hebben een grote overprovisioning die wear leveling eenvoudiger maakt en bijvoorbeeld een SSD goed kan laten werken zelfs zonder TRIM ondersteuning. Met de lange levensduur van moderne SSDs vormt het plaatsen van SWAP space op een SSD ook helemaal geen probleem meer.

Natuurlijk heb je daar een punt. Volgens de volgende test ben ik ook blij met mijn 840 PRO en dat ik niet voor de andere 840's heb gekozen.
http://techreport.com/rev...xperiment-theyre-all-dead

En ja ik gebruik SWAP op mijn SSD prima.

Het gaat hier om zijn setup en hij zou alle opties eens moeten onderzoeken.

[Hero of Time]

DJMaze schreef op zaterdag 17 september 2016 @ 13:02:
[...]

Ik zou zeggen, begin eens hier: https://lwn.net/Articles/428584/
En lees daarna verder over de voor/nadelen van VLC NAND en de grote van de GNU/Linux bestanden die je dagelijks wegschijft naar de disk.
En calculeer eens hoeveel GB aan writes dat is per dag (dat kan prima met dstat).

Zoals door anderen aangegeven gaat het om goedkoop flash geheugen. Dat is dan alleen voor de writes. Maar je had 't ook over LVM dat je niet moet gebruiken op een SSD. Waar heb je dat vandaan? Want in je aangehaalde artikel staat er niets over. Wat is er zo 'slecht' aan LVM dan dat je 't bij een SSD niet moet gebruiken?

[DJMaze]

Ik heb het verkeerd verwoord. Het was meer bedoelt om zoveel mogelijk alle software lagen uit te sluiten om zo beter tot de kern te komen van het probleem.

Meten = weten

[Buntmans]

ECP0WERS schreef op zaterdag 17 september 2016 @ 13:12:
Heb je ook al een nieuwere kernel gebruikt? (4.7.2/4.8 RC)

Dit is wel een poging waard.

Was sowieso van plan andere kernels te proberen maar inderdaad wel een goed idee om een nieuwere te pakken ipv een oudere .

Hero of Time schreef op vrijdag 16 september 2016 @ 23:40:
Je ziet dus niets als je de logs met tailf volgt?

Heb je nog een firmware update voor je SSD? Die kan ook wel wat fixen voor je, want als het in 4.1.6 was uitgeschakeld en nu niet meer, zou dat eerder zijn omdat er behoorlijk wat fixes voor zijn gedaan, maar dan moet wel de firmware op de SSD zijn bijgewerkt om hiermee fatsoenlijk overweg te kunnen.

Overigens, als het systeem vast loopt, en dan echt zo hangen dat je niets meer kan, ook niet naar een TTY schakelen ofzo, dan vraag ik mij af wat er echt aan de hand is. Als je SSD opeens niet meer bruikbaar is, het reageert bijvoorbeeld niet meer, zou ik toch ander gedrag verwachten zoals I/O errors en crashes van software oid.

Firmware zal ik checken heb ik destijds wel geupdated maar we zijn immiddels al weer een stuk verder in de tijd. Ik zag toevallig wel dat er sinds deze zomer een update was voor mijn moederbord en die release notes hadden het over "update NTFS module" dus ik dacht hah ik heb je! Maar helaas maakt geen verschil.

Tail -f is mij niet bekend, maar ga ik uitzoeken en kom ik op terug!

En wat je zegt over de manier waarop het systeem vastloopt. Dat klopt precies. En daarom valt er ook niet mee te werken. Daardoor is lastig erachter te komen wat er steeds gebeurt. En daarom had ik ook meteen het vermoeden dat het aan de kernel lag en dat het hetzelfde probleem was wat ik eerder had (en dat is bevestigd want als ik terug ga naar de oude kernel is alles weer ok).

Het irriteert want bij zoiets toch relatief dramatisch zou je verwachten dat er meer mensen zijn die hier tegenaan lopen. Maar met google search is er dus opmerkelijk weinig te vinden. En wat er is is allemaal over queued TRIM. De vorige keer daarom dus ook enorm lopen prutsen met configureren van TRIM/queue gedeelte uitschakelen. Maakte allemaal geen verschil.

Je snapt mijn vreugde toen een kernel update het probleem verhielp. Ik had er ook niet op gerekend dat een eventueel nieuwere kernel het probleem weer zou terugbrengen.

Ik maak overigens geen gebruik van LVM. Mijn swap staat op mijn SSD (waar hij hoort imo) en geeft geen problemen (met de juiste kernel).

[Blokker_1999]

tail is een commando dat zonder parameters de laatste 10 lijnen van een bestand weergeeft. Door het argument -f weer te geven blijft tail het bestand monitoren en worden nieuwe lijnen die aan het bestand worden toegevoegd ook weergegeven. Dit werkt evenwel niet wanneer je bijvoorbeeld dmesg piped naar tail -f. Dan moet je op zoek naar andere oplossingen, In geval van dmesg kan je het oplossen door dmesg de -w parameter mee te geven wat eenzelfde effect heeft.

Best guess is inderdaad een nieuwere kernel proberen of de oudere kernel blijven gebruiken (wat meestal niet veel kwaad kan).

[DJMaze]

Och ik ben eindelijk wakker hoor. Natuurlijk staat er niks in de logs als de SSD daadwerkelijk niet reageert.
Er kan dan immers niks naar de logs op die SSD worden geschreven.

Mount /var/log op een andere schijf of gebruik rsyslog! Duh...

[ Voor 5% gewijzigd door DJMaze op 17-09-2016 21:07 ]

[DJMaze]

Buntmans schreef op zaterdag 17 september 2016 @ 18:12:
ga ik uitzoeken en kom ik op terug!

Al wat verder gekomen?

[Buntmans]

DJMaze schreef op woensdag 21 september 2016 @ 13:52:
[...]

Al wat verder gekomen?

nee nog geen tijd gehad. wat ik ga doen is een nieuwere kernel installeren en dan met tail -f wachten tot/of het misgaat. aangezien het gemiddeld een 2-4 uur duurt voor hij vastloopt moet ik even wachten op een goed moment.

[CAPSLOCK2000]

Kun je misschien iets meer over de rest van de hardware vertellen. Is het nog steeds dat ASRock Q1900-ITX moederbord uit het vorige topic?

Ik ga er van uit dat het probleem voortkomt uit een combinatie van hardware/software die groter is dan alleen die SSD. Die Samsung 840's zijn zo populair dat we het wel hadden geweten als er een groot probleem mee is.

Een bug in TRIM zou een verklaring kunnen zijn, veel mensen hebben dat uit staan of gebruiken het slechts incidenteel, maar eigenlijk vind ik de groep die het wel gebruikt nog te groot voor die na een paar uur je systeem vast laten lopen.


Denk ook eens aan power management. De ondersteuning voor power management is onder Linux flink in beweging, dat zou wel eens het belangrijkste verschil tussen die 4.1 en 4.4 kernel kunnen zijn.
Het zou kunnen dat je systeem vast loopt omdat de kernel besluit de stroom naar je SSD/SATA-controller uit te schakelen. Voel direct na zo'n vastloper eens aan je SSD en aan je voeding om te controleren of een van die twee componenten niet warmer of kouder dan normaal is. Ik denk niet dat je iets gaat voelen, al is het maar omdat SSDs erg zuinig zijn, maar even voelen is een kleine moeite.

[Buntmans]

Druk geweest met andere dingen maar ik wil dit probleem nog steeds graag oplossen.

CAPSLOCK2000 schreef op zondag 25 september 2016 @ 13:03:
Kun je misschien iets meer over de rest van de hardware vertellen. Is het nog steeds dat ASRock Q1900-ITX moederbord uit het vorige topic?

Klopt is nog steeds de ASRock q1900-ITX. Recentelijk was er een firmware update die iets met de sata controller zou doen. Maar dat heeft helaas niets veranderd aan de situatie. Voor de rest geen hardware behalve 3 hdd's (ook zonder hdd's is het probleem er).

Blokker_1999 schreef op zaterdag 17 september 2016 @ 20:00:
tail is een commando dat zonder parameters de laatste 10 lijnen van een bestand weergeeft. Door het argument -f weer te geven blijft tail het bestand monitoren en worden nieuwe lijnen die aan het bestand worden toegevoegd ook weergegeven. Dit werkt evenwel niet wanneer je bijvoorbeeld dmesg piped naar tail -f. Dan moet je op zoek naar andere oplossingen, In geval van dmesg kan je het oplossen door dmesg de -w parameter mee te geven wat eenzelfde effect heeft.

Best guess is inderdaad een nieuwere kernel proberen of de oudere kernel blijven gebruiken (wat meestal niet veel kwaad kan).

Ok ik kan dus door tail -f te gebruiken mijn syslog monitoren en mogelijk iets zien dat ik nu niet kan zien ? Hoe precies gaat dat in zijn werk dan?

Ik ben nu aan het testen met de 4.4.0-36 dat is de nieuwste kernel die aanwezig is zonder specifiek een nieuwe te installeren. Volgens mij is dat een hele oude? Doet ubuntu niet automatisch kernels updaten. Ik houd altijd alles netjes bij met apt-get update/upgrade. Daar staan wel dat linux-image-generic is "kept back".

Welke (nieuwe) kernel kan ik het beste pakken? De nieuwste niet-rc uit de http://kernel.ubuntu.com/~kernel-ppa/mainline/ lijst ? Dus 4.9.6 ?

CAPSLOCK2000 schreef op zondag 25 september 2016 @ 13:03:

Een bug in TRIM zou een verklaring kunnen zijn, veel mensen hebben dat uit staan of gebruiken het slechts incidenteel, maar eigenlijk vind ik de groep die het wel gebruikt nog te groot voor die na een paar uur je systeem vast laten lopen.


Denk ook eens aan power management. De ondersteuning voor power management is onder Linux flink in beweging, dat zou wel eens het belangrijkste verschil tussen die 4.1 en 4.4 kernel kunnen zijn.
Het zou kunnen dat je systeem vast loopt omdat de kernel besluit de stroom naar je SSD/SATA-controller uit te schakelen. Voel direct na zo'n vastloper eens aan je SSD en aan je voeding om te controleren of een van die twee componenten niet warmer of kouder dan normaal is. Ik denk niet dat je iets gaat voelen, al is het maar omdat SSDs erg zuinig zijn, maar even voelen is een kleine moeite.

TRIM heb ik echt elke optie geprobeerd want ik vermoedde zelf ook dat het daaraan lag.

Voelen zal ik proberen maar ik weet niet zo goed of dat me iets vertelt. Hij is normaal al niet echt warm en als hij vastloopt heeft hij dus de minuut ervoor nog gewoon gewerkt. Lijkt me niet dat me dan of na 15 minuten gaat opvallen dat hij kouder is dan normaal. Zo bedoel je het toch?

[Verwijderd]

tail -f doet weinig anders dan de inhoud van de file die je wilt zien tonen en ook direct de wijzigingen in de file. Ubuntu update je kernel, niet upgrade. Dus de versie blijft hetzelfde maar wordt wel gepatcht.

De LTS versie is 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

De laatste versie (16.10) 4.8.0-34-generic #36-Ubuntu SMP Wed Dec 21 17:24:18 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Dus de zojuist uitgebrachte kernel wordt standaard niet aangeboden in Ubuntu. Ik heb jaren een probleem gehad met een nieuwere kernel en heb deze gedowngrade naar een oudere maar wel door Ubuntu (LTS) ondersteunde versie. PPA builds lopen vaak voor de muziek uit en zijn niet altijd even goed en stabiel.

[ Voor 56% gewijzigd door Verwijderd op 27-01-2017 19:01 ]

[Buntmans]

Aah ok wel update geen upgrade. Got it.

Inmiddels kernel 4.9 geinstalleerd. Fingers crossed.

Edit: na 10 minuten liep hij onder 4.9 al vast exact zo als onder de 3.16 en 4.4 kernels

hier wordt ik echt verdrietig van. wat is er zo super speciaal aan kernel 4.1.6 dat dat de enige is die werkt bij mij?

ik wil een videokaart in deze machine zetten en ik vermoed dat ik voor de nieuwe generatie toch echt ook de nieuwe kernel nodig heb. ik wil dit dus oplossen en liever zonder een nieuw moederbord aan te schaffen.

[ Voor 74% gewijzigd door Buntmans op 27-01-2017 22:01 ]

[Hero of Time]

Als je geen nieuw mobo wilt, dan haal je een ander merk SSD. Spijtig, maar ik heb met m'n Crucial M4 echt 0 problemen. Maar n=1 en dat zegt dus nogal weinig. Net zoals dat jij deze problemen hebt, terwijl anderen met een EVO 840 nergens last van hebben met Linux.

Overigens is de reden dat je bij een apt update de melding krijgt dat linux-image-generic wordt vastgehouden omdat er een andere dependency aan hangt. Je moet dan een apt dist-upgrade doen, dan worden nieuwe vereisten ook meegenomen om te installeren.

[Buntmans]

Hero of Time schreef op vrijdag 27 januari 2017 @ 22:37:
Als je geen nieuw mobo wilt, dan haal je een ander merk SSD. Spijtig, maar ik heb met m'n Crucial M4 echt 0 problemen. Maar n=1 en dat zegt dus nogal weinig. Net zoals dat jij deze problemen hebt, terwijl anderen met een EVO 840 nergens last van hebben met Linux.

Als ik er niet uitkom is er helaas geen andere keus. Ik heb overigens nog een EVO 850 liggen ik kan het eens daarmee proberen. Ik dacht het is een SSD probleem maar inderdaad vrij goed mogelijk dat het alleen bij deze SSD niet goed gaat.

Ik ga dat proberen (na het weekend helaas pas) en zal erop terugkomen of het werkt.

Overigens is de reden dat je bij een apt update de melding krijgt dat linux-image-generic wordt vastgehouden omdat er een andere dependency aan hangt. Je moet dan een apt dist-upgrade doen, dan worden nieuwe vereisten ook meegenomen om te installeren.

Ik heb met een dist-upgrade ook de boel wel eens om zeep geholpen. Dus voor ik dat doe wil ik tot in detail weten wat er precies aan de hand is. Is dat normaal dat er voor een kernel ook extra software moet worden geinstalleerd? Ik heb nu handmatig kernel 4.9 erop gezet. Het kan zijn dat ik nu dus iets mis qua dependancies?

[Hero of Time]

Buntmans schreef op vrijdag 27 januari 2017 @ 23:04:
[...]

Ik heb met een dist-upgrade ook de boel wel eens om zeep geholpen. Dus voor ik dat doe wil ik tot in detail weten wat er precies aan de hand is. Is dat normaal dat er voor een kernel ook extra software moet worden geinstalleerd? Ik heb nu handmatig kernel 4.9 erop gezet. Het kan zijn dat ik nu dus iets mis qua dependancies?

Als je wilt weten wat er gebeurt, dan pak je aptitude of synaptic. Zie je de stappen die uitgevoerd worden en eventuele conflicten voordat je 't toepast.
Als je een kernel update hebt, dan komen er extra packages bij omdat je alleen het metapackage markeert als update. Die is dan weer afhankelijk van de werkelijke kernel image die dus in z'n eigen package staat. Jouw linux-image-generic is afhankelijk van linux-image-generic-amd64-4.4.0-39 en de update is afhankelijk van linux-image-generic-amd64-4.4.0-59.

Als je iets mist, zou apt moeten klagen als je die draait, zou je dat bij installatie al moeten zien en zou het ook niet moeten werken omdat de configuratie niet wordt uitgevoerd/afgerond.

[Thralas]

Met de SSD ansich lijkt me niet zo snel iets mis. Ik kan me niet voorstellen hoe dat er ooit voor kan zorgen dat de boel vastslaat - dan verwacht je dat hij gewoon van de bus afvalt en that's it.

Loopt de boel ook enigzins vast, maar dan kun je nog wel bij de kernel logs (als je een terminal hebt..)

CAPSLOCK2000 schreef op zondag 25 september 2016 @ 13:03:
Denk ook eens aan power management. De ondersteuning voor power management is onder Linux flink in beweging, dat zou wel eens het belangrijkste verschil tussen die 4.1 en 4.4 kernel kunnen zijn.

Dat lijkt me een goede hoek om zeker verder uit te zoeken. Zet bijvoorbeeld in powertop power saving features uit. Zelfde in je BIOS/UEFI, zaken als C6/C7 idle states kun je uitzetten.

Zo heb ik hier een Skylake-systeem wat ook compleet vastliep (HDMI output valt weg). C6/C7 power states uitgezet en alles is wel stabiel (ik vermoed dat de oorzaak een oude voeding is). Food for thought, in ieder geval.