aiuto kernel panic

[rob84]

ciao a tutti ho assemblato di recente un nuovo mini pc con una asrock h97itx/ac, 8gb di kingston fury 1600 ddr3, i5-5675c con grafica integrata e ssd samsung 850 evo. la distro è fedora xfce, ma ho provato anche debian, ubuntu, mint, archlinux.

molto spesso il sistema si blocca e non posso fare altro se non riavviarlo premendo 5 secondi il tasto di alimentazione, a volte il sistema si riavvia da solo con la dicitura kernel panic, purtroppo non riesco a venirne a capo, non riesco a capire cosa può essere... all'inizio credevo fossero le ram ma dopo 12 ore di memtest non danno errori.
come posso capire se è un problema di driver che vanno in crash o se effettivamente c'è qualcosa di difettoso a livello HW?

i crash sembra si presentino in modo casuale quando il pc esegue dei compiti, ad esempio video in full screen oppure installazione aggiornamenti oppure anche solo aprendo gnome tweak tool, è casuale anche come "tempo", magari posso tenerlo acceso per un'ora intera con browser aperto e poi mentre ridimensiono una finestra si blocca tutto
che ne pensate?

aggiungo anche che ho provato a far partire il sistema da una usb live scollegando fisicamente l' ssd, e va in crash lo stesso, talvolta anche prima di far comparire il desktop.

tra le altre cose ho aggiornato il bios all'ultima versione disponibile e lasciato tutti i valori con i dati di fabbrica
ho provato un reset cmos
ho provato un alimentatore differente
ho fisicamente smontato e riassemblato tutto il pc
tutto senza risolvere

oggi finalmente tramite mcelog ,che scrive gli eventi mce nel journal di sitema, ho trovato questo errore che causa il blocco del sistema e il reboot in maniera casuale ad ogni sessione

Hardware event. This is not a software error.
MCE 0
CPU 0 BANK 3
MISC 7fa1756627af ADDR 0
TIME 1449770353 Thu Dec 10 18:59:13 2015
MCG status:
MCi status:
Uncorrected error
Error enabled
MCi_MISC register valid
MCi_ADDR register valid
Processor context corrupt
MCA: Internal Timer error
STATUS be00000000800400 MCGSTATUS 0
MCGCAP 1000c0a APICID 0 SOCKETID 0
CPUID Vendor Intel Family 6 Model 71

a volte l' errore è su CPU1 o CPU2 ma sempre su BANK 3 e la costante è questa
Processor context corrupt
MCA: Internal Timer error
STATUS be00000000800400 MCGSTATUS 0

detto cio...processore difettoso? scheda madre? ideee?
spero non sia il processore...dato che è il componente piu costoso

[sacarde]

quali driver grafici usi ?

provati i generici vesa ?

[rob84]

Originariamente inviato da sacarde

quali driver grafici usi ?

provati i generici vesa ?

[root@Host-004 roberto]# lshw -c display | grep drive
configuration: driver=i915 latency=0

pensi possa essere un problema di driver? x i vesa come faccio?

[sacarde]

e' soltanto un'ipotesi

- su ubuntu si puo' passare al kernel il parametro "xforcevesa"

- oppure costruire il file /etc/X11/xorg.conf e dichiarare: Driver "vesa"

- oppure eliminare il pacchetto relativo ai driver xorg *intel* e inserire quello *vesa*

[rob84]

rieccomi qua...dunque ho provato a fare come dici e non è cambiato nulla, ora per l' ennesima volta ho provato con memtest (preso da una usb live di una distro che avevo) e lanciando l'opzione F2 cioè quella che fa il test della memoria con tutti i core attivi contemporaneamente il sistema si blocca sempre al 73% del test 7, devo (come sempre ormai) spegnere a mano il pc e riavviarlo...se lascio girare memtest con un core alla volta (quindi senza schiacciare F2) il test della memoria va sempre a buon fine con 0 errori
potrebbe essere un problema di scheda madre o di processore?

[sacarde]

problemi di raffreddamento?

polvere sulle ventole?

[kernelex]

mi gioco una palla che è un problema di ram.

rimedia una ram compatibile e usa il pc con quella.
se tutto fila per il giusto, prova un banco per volta delle tue kingston fury.
se sono 2x4 GB.

per caso usi programmi della famiglia 4kvideodownload?

[rob84]

onestamente non credo sia un problema di raffreddamento, ora come ora il pc gira con tutto il case aperto ed è tutto nuovo, dissipatore incluso, per le ram come è possible che passino un test di 12 ore di memtest senza dare errori? memtest si blocca solo se lo avvio con tutti i core attivi altrimenti il test va a buon fine

[rob84]

aggiornamento
ho scaricato l'ultima versione di memtest86 la 6.2, creato una penna usb avviabile e lanciato il test su tutti i core attivi contemporaneamente...risultato 0 errori e 0 blocchi temperatura cpu massima 42°...
tanto per conoscenza la versione di memtest86 che ho provato prima è la 5.01 ed era inclusa nella penna usb che avevo creato della distro
ora come ora non so piu che pensare...

[sacarde]

se pensi sia un problema software...

o prova un'altra distro con kernel vecchi (2.4 o 2.6)

o prova una bsd

[rob84]

allora...eccomi di nuovo qua....una mezza idea forse me la sono fatta, dal bios ho impostato il processore a frequenza fissa, disabilitando ogni risparmio energetico, lo speed step e il turbo boost (impostato a 3,5 ghz su tutti e 4 i core con vcore di 1.050V) subito ho notato una maggiore stabilità, si sono verificati solo un paio di blocchi in un arco di tempo abbastanza esteso...
poi per puro caso mi sono accorto che toccando il case (interamente di alluminio) avvertivo una leggera vibrazione, ciò avveniva anche a pc spento e con cavo di alimentazione staccato dalla presa elettrica...la vibrazione cessa solo se scollego fisicamente dalla presa anche i vari componenti che ho connessi al pc ovvero monitor e casse amplificate.
morale della favola non ho l'impianto di terra...ho smontato la presa e ho effettivamente verificato che ci sono solo 2 fili collegati.
quindi penso che l'aver impostato una frequenza fissa al processore, impedendogli così di saltare da una frequenza all'altra, abbia di fatto migliorato la tolleranza ai disturbi che la mobo può ricevere.
ora come ora ho collegato un filo volante tra il termosifone e l'attacco per la terra della presa e magicamente la vibrazione è sparita...
in attesa di realizzare un impianto di terra decente continuo a testare il pc sperando di aver definitivamente risolto....

[rob84]

ho provato a fare il boot con i seguenti parametri passati al kernel
acpi=off -> il sistema fa il boot ma mi segnala mce error come quello riportato al''inizio del thread e poi si riavvia dopo 30 secondi
acpi=noirq -> come sopra
acpi_enforce_resources=lax -> non completa il boot
noapic e nolapic -> mi vede solo un processore invece di 4 e il sistema si è bloccato nel desktop mentre aprivo il terminale
nomodeset -> idem come sopra

è normale sta cosa? soprattutto per acpi=off

[sacarde]

quando funzionava meglio ... era senza parametri al kernel?


p.s.
1 cpu invece di 4 certo e' strano

[rob84]

esatto
l'unica cosa è che mi pare strano non poter disabilitare acpi senza incorrere in queti problemi
in teoria mettendo acpi=off dovrei solo rinunciare a qualche risparmio energetico o cose così
anche se guardando dmesg pare che acpi venga utilizzato per qualche irq di qualche componente nel pc

per ora analizzando dmesg le uniche cose su cui ho dei dubbi sono
ACPI Warning: SystemIO range 0x000000000000F040-0x000000000000F05F conflicts with OpRegion 0x000000000000F040-0x000000000000F04F (\_SB_.PCI0.SBUS.SMBI) (20150619/utaddress-254)

e

refresh thread[1351]: segfault at 20 ip 00007f05dcadfa40 sp 00007f05c73caee8 error 4 in libglib-2.0.so.0.4600.2[7f05dca5b000+10c000]

[sacarde]

libglib-2.0.so.0.4600 e' in libglib2.0-0

[rob84]

non riesco a trovare quel pacchetto su pacman neanche tra quelli installati....
ora come ora sto scrivendo dalla usb live avviata in modalit' uefi e mi sembra un po piu reattiva rispetto a quella che ho sull SSD, stavo pensando... avrei dovuto installare il sistema in modalita UEFI per caso ?

[sacarde]

scusa, ero rimasto a ubuntu

qui parlano dell'errore simile al tuo:
https://wiki.archlinux.org/index.php..._in_Bluez_4.95



p.s.
uefi e' soltanto il metodo di avvio (credo)
l'hai installato in legacy-mode?

[Fix_metal]

Allora, piano, mi sembra ci sia troppa roba nel calderone
1) la assenza della terra sull'impianto è un grosso problema, perché non può scaricare. Le frequenze spurie sono tantissime nei PC per via delle alimentazioni switching, si creano correnti non indifferenti, ma non credo possa dare problemi all'hardware.
2) acpi non disabilitato assolutamente! Già i kernel linux lo gestiscono malino rispetto a windows (basta vedere la durata batteria sui portatili comparata fra i due OS), ma mi sento confidente che non sia quello il problema
3) stai usando ancora fedora con desktop xfce o una ubuntu? Se usi fedora, noti errori facendo journalctl -xb? Lì trovi che era il dmesg dell'ultimo boot e pure quello che era il messages
4) potresti provare con un strace a verificare le chiamate a OS , ma se il blocco è imprevedibile ti ritrovi ad analizzare tonnellate di dati senza magari trovare scritta la problematica specifica (panic prima di scrittura su FS, capita spesso sui server)


Inviato dal mio Nexus 5 utilizzando Tapatalk

[Fix_metal]

Dimenticavo: se hai un uefi e l'hai installato in legacy, devi avere sicuramente CME attivo in uefi (che non si chiama BIOS). Problemi non dovresti averne, a meno che sia buggata la retrocompatibilità in quella specifica versione di uefi/scheda madre.

P.s. per eliminare il possibile discorso terra, collega un cavo da 1,5mm² dallo chassis al calorifero con due terminali...lato PC basta averne uno ad occhiello da fissare sotto ad una vite.
Metodo barbaro, ma in mancanza d'altro....

Inviato dal mio Nexus 5 utilizzando Tapatalk

[rob84]

Originariamente inviato da Fix_metal

Dimenticavo: se hai un uefi e l'hai installato in legacy, devi avere sicuramente CME attivo in uefi (che non si chiama BIOS). Problemi non dovresti averne, a meno che sia buggata la retrocompatibilità in quella specifica versione di uefi/scheda madre.

P.s. per eliminare il possibile discorso terra, collega un cavo da 1,5mm² dallo chassis al calorifero con due terminali...lato PC basta averne uno ad occhiello da fissare sotto ad una vite.
Metodo barbaro, ma in mancanza d'altro....

Inviato dal mio Nexus 5 utilizzando Tapatalk

Scusate ragazzi il ritardo, ma finalmente "credo" e spero di aver risolto...il problema è tutto derivato dalla mancanza di microcode aggiornati per tutta la serie broadwell di intel.
Su windows il problema non si presenta, al contrario su linux è causa di freeze random e messaggi mce con conseguente riavvio della macchina.
Purtroppo ad oggi intel non ha rilasciato una nuova versione del microcode quindi sul sito intel non è reperibile nulla per i broadwell e di conseguenza il pacchetto dei microcode su qualsiasi distro contiene ancora la vecchia versione.
Sembra tuttavia che intel abbia fornito tali codici alle case produttrici di schede madri, in primis a MSI, tant'è che un appassionato ha estratto il microcode aggiornato da un aggiornamento bios di una scheda msi e l'ha reso disponibile
https://github.com/bgw/bdw-ucode-update-tool
ora come ora sono passato dalla versione 0xb alla 0x13 e tutto sembra normale, per ora niente crash o freeze vari.

adesso sto utilizzando kubuntu (lo so sembro pazzo...) e il metodo di installazione descritto nel link funziona su distro debian based, l'installazione non dovrebbe far altro che copiare una cartella chiamata "intel ucode" in /lib/firmware e poi chiede di fare un update dell' initramfs....
la domanda è....se copio tale cartella e la porto sempre in /lib/firmware di una distro basata su archlinux (che è quella che voglio utilizzare) e rigenero l'iniramfs con il comando mkinitcpio potrebbe funzionare?
cioè mi spiego meglio, rigenerando l'initramfs in automatico viene letto il contenuto della cartella /lib ?