# KERNEL PANIC - Problema forse Hardware

## Shocker580

Salve a tutti, ho un problemino con il mio "server di casa" e purtroppo, dato il pochissimo tempo a mia disposizione spero riusciate voi a darmi una mano..

Il computer è acceso H24 da circa un anno e lo uso come server SMB, FTP, Sharing ecc ed è sempre andato divinamente, da qualche giorno invece (senza averlo minimamente toccato) lo ritrovo in kernel panic e non c'è verso di ottenere qualche info in più..

A volte si riavvia anche appena tenta di caricare il kernel da grub e altre dal kernel panic. Le temperature di esercizio sono corrette e gli harddisk nuovi. Durante alcuni riavvii il bios mi ha richiesto l'immagine del bios (da cd come se non riuscisse a partire), per poi ripartire bene ad un'altro riavvio.. Cosa sarà ? Questo è 'unico "log" che ho della situazione, in message e dmesg non ce n'è traccia.

https://dl.dropbox.com/u/21152890/kernel%20panic.jpg

Un grazie anticipato a tutta la community  :Smile: 

----------

## Shocker580

C'è un modo per salvare il KERNEL PANIC in un log ? (così da averlo intero)

Ho ritrovato il BIOS con le impostazioni di default il che è strano ma non è il responsabile, ora sto facendo un ciclo con memtest86+ ma dubito siano le ram.. Ho fatto un check delle partizioni e risultano ok, inoltre a volte il panic cambia:

https://dl.dropbox.com/u/21152890/panic2.jpg

Non riesco proprio a spiegarmi come possa accadere senza un apparente motivo..

EDIT: Il risultato di memtest è questa schermata .. non è molto incoraggiante..

----------

## djinnZ

Cambia l'alimentatore.

Smonta le ram e provale individualmente, verifica i cavi degli hd e provali individualmente.

In giro c'è una vecchia patch per escludere alcune aree di memoria. Mal che vada dovrai invertire la disposizione dei moduli.

Temo che hai una ram bruciata o per sovraccarico o per sottocarico perché l'alimentatore è allo stremo e non fornisce tensione costante.

Sembra strano ma anche gli alimentatori invecchiano.

Altra possibilità è la MB "puffa" ma in genere danno problemi sin dal primo istante.

Il kernel panic lo puoi salvare usando la consolle seriale e simili.

----------

## Shocker580

Ancora una volta mi torni ad aiutare sempre tu  :Smile:  E' un piacere vedere che questa community non sia morta come tante altre..

L'alimentatore l'ho sostituito 10 minuti fa ed i kernel panic continuano, ora ho ri-lanciato memtest86 e voglio aspettare gli errori o il riavvio, poi comincio ad escludere le ram.

Che gli alimentatori saltano lo so bene, questo che era dentro aveva giusto un anno, quello precedente ne è durati soltanto due (li compro economici ?  :Smile: ).

Ti ringrazio per i consigli e procedo con i test.

Aggiornamento: memtest86+ stranamente non ha dato più errori o riavvii, ho riavviato su linux ma è riandato in kernel panic qui un esempo (il crash si verifica al 29secondo). Prima di quel momento non rispondeva agli input della tastiera.. Il motivo del crash sembra cambiare sempre. Stanotte lo lascio con memtest e domani si vedrà..

Aggiornamento2: dopo tutta una notte con memtest non si è piantato o ha dato errori (mentre prima ne dava ogni volta massimo nel giro di 10 minuti).. Che sia solo l'alimentatore ? Ma allora perché linux non va più ?

----------

## Zizo

Personalmente controllerei lo stato dei dischi fissi, sia a livello di file system che di eventuali errori smart: non dovrebbero causare kernel panic ma se hai già escluso alimentatore e memorie controllando gli hdd chiudi la cerchia dei componenti maggiormente soggetti a problemi.

Potresti quindi procedere scaricando uno degli innumerevoli live cd linux confezionati anche per tali propositi, per esempio SystemRescueCd, avviarlo e se non si presenta kernel panic accertarti dello stato smart dei dischi tramite il comando

```
smartctl -s on -a /dev/sda
```

 dove "-s on" abilita smart nel caso non lo sia e "-a" stampa a video una panoramica generale sullo stato di salute del disco.

Le linee da controllare di solito sono "Reallocated_Sector_Ct" e "Current_Pending_Sector", ma non solo.

----------

## Shocker580

Purtroppo come ho scritto più su il kernel panic continua a verificarsi ma errori con memtest86 non più dopo aver cambiato  l'alimentatore.. Oggi l'ho lasciato a fare il check in loop, verso l'una torno e controllo. Per il check del filesystem consigli qualche argomento in particolare?

----------

## Zizo

Con "... se non si presenta kernel panic ..." intendevo se non si presenta kernel panic utilzzando il live cd, il che ti impedirebbe di proseguire con il controllo dei dischi e ancor peggio rafforzerebbe i sospetti su qualche difetto hw a scheda madre/processore.

Mi sembra di capire che fino ad adesso per "avviare linux" intendessi gentoo salvato sul disco fisso, o sbaglio?

Il fatto che i dischi siano nuovi non è indice della loro salute, più di una volta test smart su unità appena sballate hanno riportato decine di settori inutilizzabili.

----------

## djinnZ

 *Shocker580 wrote:*   

> Ancora una volta mi torni ad aiutare sempre tu 

 Il dover rispondere sempre io tra i primi mi rende tanto scorbutico  :Twisted Evil:   *Shocker580 wrote:*   

> E' un piacere vedere che questa community non sia morta come tante altre..

 beh ormai sono tutti "fessi" ...  :Twisted Evil:   :Twisted Evil:   :Twisted Evil: 

Alimentatori economici non garantiscono tensione costante nel momento in cui avvi il sistema od un disco esce dallo stato di risparmio energetico.

Non dimenticare che sono due le cose che mangiano più "corrente": le cpu e i motori passo quando si avviano. Ed una tensione altalenante alla lunga rovina le ram.

@Zizo: Un errore di accesso od un timeout su un disco che contiene swap pipe et similia viene riportato come errore di memeoria. Quindi quello che sostieni è più che fondato.

----------

## Shocker580

Dopo 9:40 ore di memtest ininterrotti non si è più bloccato. Provo con la live che mi ha linkato Zizo per ulteriori prove.

 *djinnZ wrote:*   

> @Zizo: Un errore di accesso od un timeout su un disco che contiene swap pipe et similia viene riportato come errore di memeoria. Quindi quello che sostieni è più che fondato.

 Quindi basterebbe disattivare la swap per provare ?

Aggiornamento: gli smart non danno valori troppo buoni, voi che dite ? http://pastebin.com/ggpvmgXW

Aggiornamento2: le partizioni sono ok 

```
root@sysresccd /root % e2fsck -c /dev/sda3

e2fsck 1.42.3 (14-May-2012)

Checking for bad blocks (read-only test): done                                  

/dev/sda3: Updating bad block inode.

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

/dev/sda3: ***** FILE SYSTEM WAS MODIFIED *****

/dev/sda3: 403591/12181504 files (4.1% non-contiguous), 7215834/48725145 blocks
```

Aggiornamento4:  *Shocker580 wrote:*   

>  *djinnZ wrote:*   @Zizo: Un errore di accesso od un timeout su un disco che contiene swap pipe et similia viene riportato come errore di memeoria. Quindi quello che sostieni è più che fondato. Quindi basterebbe disattivare la swap per provare ?

  anche disabilitando la swap ottengo il kernel panic..

Aggiornamento5: (ma continuo a parlare da solo?  :Very Happy: ) anche con la live ora ha subito un freeze.. Che sia CPU o MOBO?

Mi piacerebbe riuscire ad individuare il problema così da valutare se valga la pena sostituirlo o buttare tutto nel cestino..

----------

## xdarma

sda:

```
194 Temperature_Celsius     0x0032   047   253   000    Old_age   Always       -       49
```

sdb:

```
194 Temperature_Celsius     0x0022   102   085   000    Old_age   Always       -       45
```

Mi sembrano valori piuttosto elevati.

Probabilmente non c'entrano niente con il kernel panic, ma se fossi al tuo posto, comunque cercherei di abbassare la temperatura dei dischi.

Ooops: sda

```
195 Hardware_ECC_Recovered  0x000a   252   251   000    Old_age   Always       -       41462
```

Prova a tenerlo d'occhio se cambia tra un crash e l'altro.

----------

## Shocker580

Il problema temperatura è relativo perché ora il pc è smontato e con l'aria condizionata accesa dubito soffrano gli hdd eppure continua ad andare in panic..

Qualche idea ?

----------

## xdarma

 *Shocker580 wrote:*   

> Qualche idea ?

 

Lasciando il Maxtor spento riesci a fare il boot della live per rifare i test o si blocca anche in quel caso?

----------

## djinnZ

Non ho detto che disabilitando la swap risolvi.

Se un errore di accesso od un timeout si verifica nel momento in cui il kernel va a leggere o scrivere sul disco per una pipe, un buffer, una swap od un socket è sempre riportato come memory error.

Dovresti salvare gli indirizzi riportati ed andare a vedere a cosa corrispondono, potrebbe essere la ram, il controller, la scheda grafica. od il disco ma sempre è errore di gestione della memoria.

Ci sono una serie di opzioni in "processor type and features" ed in "kernel hacking" inizia a documentarti su quelle.

A suo tempo ho risolto (non del tutto ma i crash sono diventati episodici) agendo sulla gestione degli mtrr.

Per il resto ti hanno risposto gli altri.

----------

## Shocker580

 *xdarma wrote:*   

> Lasciando il Maxtor spento riesci a fare il boot della live per rifare i test o si blocca anche in quel caso?

 

Con la live (da quando ho cambiato alimentatore) non si riavvia più ma a volte si congela (sia con maxtor mountato che non).

 *djinnZ wrote:*   

> Non ho detto che disabilitando la swap risolvi..

 

L'ho scoperto da solo  :Laughing: 

 *djinnZ wrote:*   

> Se un errore di accesso od un timeout si verifica nel momento in cui il kernel va a leggere o scrivere sul disco per una pipe, un buffer, una swap od un socket è sempre riportato come memory error.
> 
> Dovresti salvare gli indirizzi riportati ed andare a vedere a cosa corrispondono, potrebbe essere la ram, il controller, la scheda grafica. od il disco ma sempre è errore di gestione della memoria..

  Indirizzi tipo "<ffffffff8102edcf> ?

 *djinnZ wrote:*   

> Ci sono una serie di opzioni in "processor type and features" ed in "kernel hacking" inizia a documentarti su quelle.
> 
> A suo tempo ho risolto (non del tutto ma i crash sono diventati episodici) agendo sulla gestione degli mtrr.

  "processor type and features" nel kernel credevo si riferisse ad ottimizzazioni specifiche di alcune cpu, kernel hacking ? Di che tipo di opzioni parliamo ? Cosa risolverebbero ?

----------

## .:deadhead:.

Da quanto tempo hai la mobo ?

Non per fare il praticone, ma se "prima andava" e d'amblè s'è messo a fare le bizze, qualcosa s'è rotto ed in tutte le prove che hai fatto uno solo elemento è rimasto costante: la mobo, che come il maggiordomo, il più delle volte è la colpevole.

Magari non era pensata o in grado di sopportare carichi di lavoro così costanti.

Onestamente oggi con 50€ una mobo la cambi. Il numero di ore che hai già speso su un problema così pernicioso forse già pareggia l'investimento sul nuovo hardware.

I guasti fisici sono bastardi, non sempre riproducibili, quasi mai predicibili.

 :Wink:  Forse, con umiltà si potrebbe accettare la sconfitta ed il fallimento dell'hw, prender un nuovo pezzo, e sperar che sia duraturo...  :Wink: 

----------

## Shocker580

Sarei più che felice di accettare un guasto hw da 50€ ma lo sarei ancora di più essendone assolutamente certo..   :Sad: 

Come ho detto prima dopo aver sostituito l'alimentatore memtest86 non produce più riavvii o errori ma il kernel panic continua a verificarsi. Questo mi fa quasi pensare che magari ho già risolto il problema ma ho comunque qualche file corrotto sull'hdd che fa andare in panic. Può essere ? Però ho anche dei freeze sporadici con la live resque che mi hanno consigliato.. (cosa che con la live di gentoo non sembra accadere)..

La mobo ha sulle spalle almeno 8 anni di vita e almeno 4 passati sempre accesa. E' un'Asus P5GD1 PRO con su un Celeron D.

Insomma vorrei trovare un metodo per capire con certezza cos'è ad essere saltato..  :Rolling Eyes: 

----------

## djinnZ

 *.:deadhead:. wrote:*   

> Non per fare il praticone, ma se "prima andava" e d'amblè s'è messo a fare le bizze, qualcosa s'è rotto ed in tutte le prove che hai fatto uno solo elemento è rimasto costante: la mobo, che come il maggiordomo, il più delle volte è la colpevole.

 Oppure un nuovo kernel richiede apposite opzioni per poter gestire le sue particolarità (legacy di natura proprietaria).

Alla MB va aggiunto probabilmente il costo della RAM e della nuova CPU in questi grami tempi infami di bimbiminkia, soloni del piffero ed obsolescenza programmata.  :Wink: 

NB: non ricordo per quale controller scsi puffo (dello zip-drive o dello scanner) il kernel è buggato ma, dato che nessuno si è mai scomodato a segnalarlo (si faceva prima a comprarne un altro), ed ora non è una rarità di valore prettamente archeologico (bus isa) è rimasto tra i driver validi del kernel.

Poi ognuno fa quel che vuole e reputa opportuno.

----------

## Shocker580

 *djinnZ wrote:*   

> Oppure un nuovo kernel richiede apposite opzioni per poter gestire le sue particolarità (legacy di natura proprietaria).

 

Me la spieghi ?  :Shocked:  Nessuno ha toccato il kernel..

----------

## Shocker580

Ho capito che le soluzioni "facili" non preferisci darle djinnZ, potresti però dirmi da dove partire (cosa studiare) per interpretare il panic ?

Ho il computer fermo da una settimana e zero tempo per provare..

----------

## djinnZ

 *Shocker580 wrote:*   

> Ho capito che le soluzioni "facili" non preferisci darle

 non è vero, è che non esistono soluzioni facili. Non sto facendo il solone a suon di RTFM ed indovinelli per "farti ragionare". *Shocker580 wrote:*   

> potresti però dirmi da dove partire (cosa studiare) per interpretare il panic ?

 devi fare debugging del kernel *Shocker580 wrote:*   

> Nessuno ha toccato il kernel..

 Questo non lo sapevo. E comunque nulla esclude che un bug del kernel non possa aver danneggiato l'hardware. Ci sono stati casi clamorosi con lettori dvd e masterizzatori in passato. *Shocker580 wrote:*   

> Ho il computer fermo da una settimana e zero tempo per provare..

 allora non so che dirti perchè per venire a capo di simili problemi il tempo ci vuole.

L'unica cosa che posso dirti è di iniziare a procedere per esclusione sia sul piano hardware che sul piano software.

Potrebbe essere qualsia cosa, l'hypertreading, la necessità di abilitare la voce spread spectrum nel bios perchè la MB è vecchia ormai, la schda ram che non fa bene contatto, la ram bruciata, il controller andato, un cavo consumato, un hd in procinto di passare a miglior vita, la scheda grafica, la scheda di rete.

Fatti un elenco dell'hardware, prova sconnettendo un componente alla volta, poi fai un elenco dei relativi driver e prova a disabilitarli uno dopo l'altro. Acpi, controllo errori HW sono ulteriori fonti di problemi.

Ripulisci la configurazione del kernel, ovviamente, meno cose hai da verificare e meglio è.

L'ultima volta che mi sono applicato ad un simile problema si era passati da poco dai kernel 2.4 ai 2.6. Li per li niente poi con il tempo hanno inziato a manifestarsi problemi sempre maggiori fino a che il sistema andava in crash dopo un paio d'ore.

Alla fine il problema era nel driver dei sensori hardware che devo tenere disabilitati. Ma c'erano anche un alimentatore ed un cassetto estraibile che davano problemi.

In un altro caso mi è bastato impostare la ram manualmente come se volessi fare underclocking. Non so per quale ragione il bios si autoconfigurava per una 400 ed invece era una 333.

Senza arrivare al debugging del kernel, dato che non mi è mai servito mai mi sono applicato e quindi va a finire che ti riporto documentazione ed indicazioni datate.

Un'altra volta mi è bastato sostituire la scheda di rete, scheda che uso ancora oggi, su un altro pc. Ma su quella MB fa saltare il sistema.

Non so perchè (sospetto che sia mezza cotta dalla statica dato che la ho usata in modo improprio passando un cavo sul balcone) e, ad un certo punto, non me ne può fregare di meno.

Comincia a leggere l'help del menuconfig per le voci che riguardano l'hardware, ripulisci la conf del kernel e, quando sei certo che tutto l'hardware è ok, 

posta i log completi sulla ML del kernel.

Questo è quello che posso suggerirti.

NB: tempo non ne perdi perchè se il problema è software eviti di buttare il pc, se è hardware almeno puoi capire cosa è andato storto e prevenire il medesimo danno in futuro. E comunque impari qualcosa che ti può servire in futuro.

ps: la pasta termoconduttiva usata per le cup (ma anche per le gpu e per i componenti dotati di dissipatore in genere) non è eterna.  :Wink: 

----------

## zolar czakl

Batteria della scheda madre?

----------

## Shocker580

 *djinnZ wrote:*   

> L'unica cosa che posso dirti è di iniziare a procedere per esclusione sia sul piano hardware che sul piano software.
> 
> Potrebbe essere qualsia cosa, l'hypertreading, la necessità di abilitare la voce spread spectrum nel bios perchè la MB è vecchia ormai, la schda ram che non fa bene contatto, la ram bruciata, il controller andato, un cavo consumato, un hd in procinto di passare a miglior vita, la scheda grafica, la scheda di rete.

  L'hypertreading purtroppo il mio Celeron D non ce l'ha proprio  :Smile: , purtroppo la possibilità di provare con lo spread spectrum si esclude da sola in quanto il bios non ce l'ha. Le ram ho già provato ad escluderle una dopo l'altra ma i panic si verificano ugualmente. Controller, hd, scheda grafica, scheda di rete, potrebbero essere ma allora perché non fanno crashare anche la live ? Ho visto che hai escluso un problema software, era quello che preoccupava me, non potrebbe quindi essere semplicemente un file danneggiato dai continui riavvii dovuti al vecchio alimentatore che ora mi manda in panic tutto ?

 *djinnZ wrote:*   

> Fatti un elenco dell'hardware, prova sconnettendo un componente alla volta, poi fai un elenco dei relativi driver e prova a disabilitarli uno dopo l'altro. Acpi, controllo errori HW sono ulteriori fonti di problemi.

  Quello che potevo disconnettere l'ho disconnesso, provo con i moduli..

 *djinnZ wrote:*   

> Ripulisci la configurazione del kernel, ovviamente, meno cose hai da verificare e meglio è.

 Ricordo che quando compilai tolsi tutto il possibile

 *djinnZ wrote:*   

> Comincia a leggere l'help del menuconfig per le voci che riguardano l'hardware, ripulisci la conf del kernel e, quando sei certo che tutto l'hardware è ok, 
> 
> posta i log completi sulla ML del kernel.

 ML ?? Cos'è ?

 *djinnZ wrote:*   

> NB: tempo non ne perdi perchè se il problema è software eviti di buttare il pc, se è hardware almeno puoi capire cosa è andato storto e prevenire il medesimo danno in futuro. E comunque impari qualcosa che ti può servire in futuro.

 Assolutamente.

 *djinnZ wrote:*   

> ps: la pasta termoconduttiva usata per le cup (ma anche per le gpu e per i componenti dotati di dissipatore in genere) non è eterna. 

 Le paste le ho sostituite tutte circa un anno fa con una di ottima marca proprio per non avere problemi in futuro. Comunque dubito sia un problema di temperatura perché il kernel panic si verifica anche appena acceso il computer, basta fargli caricare l'os dall'hdd.

Ho visto un paio di how to su come debuggare il kernel ma non ce n'è uno che vaglia la possibilità di farlo via usb, non ho altri pc con porte seriali.. Possibile che dagli screenshot non si riesca ad intendere proprio niente ?   :Mad: 

Grazie per "l'avvio"  :Smile: 

----------

## Shocker580

 *zolar czakl wrote:*   

> Batteria della scheda madre?

 

Cambiata di recente, ma può addirittura portare a kernel panic ?

----------

## djinnZ

Pare strano ma la batteria può.

Ora sono io che non capisco. Avvii il pc con la live e funziona, avvi con il kernel gentoo e va in crash?

Mi pareva di aver capito che con il kernel gentoo va in crash più frequentemente che con la live, ma comunque il kernel panic c'è anche con la live.

Quindi hai smontato tutti i dissipatori della MB e della scheda grafica?  :Shocked:  ed io che credevo di essere paranoico...  :Crying or Very sad: 

Leggi qui e qui ma dato che uso kernel pax+grsec non mi sono mai curato di approfondire visto che non funzionano molto.

ML=Mailing List lo so che in questi tempi di libro dei fessi (o delle facce di c***o) appare come uno strumento arcaico e desueto ma è ancora in uso per qual che so.

potresti provare un kernel vanilla.

Il rischio che ci sia qualcosa che non va nelle librerie di sistema dopo una serie di crash c'è. ma ricompilare @system su una macchina instabile mi pare una fonte di ulteriori casini piuttosto che una soluzione.

Ci sono una infinità di parametri come acpi, bootmem_debug, iommu, iomem, libata.*, panic, pci, pcie_aspm e vdso per dirne qualcuno.

Ti dico che ho un portatile (sbolognato da un amico, stante l'impossibilità a trovare assistenza qualificata, forse un giorno mi deciderò a ripararlo) che richiede la sostituzione della pasta termoconduttiva. Parte e si spegne dopo poco in genere ma, se qualche volta arriva a funzionare per una trentina di secondi continua ad andare avanti senza problemi per ore.

Non è che non ti voglio aiutare ma anche a farti una lista sommaria di tutte le possibili impostazioni del kernel da verificare come causa dei crash non si finisce più.

----------

## Shocker580

 *djinnZ wrote:*   

> Ora sono io che non capisco. Avvii il pc con la live e funziona, avvi con il kernel gentoo e va in crash?
> 
> Mi pareva di aver capito che con il kernel gentoo va in crash più frequentemente che con la live, ma comunque il kernel panic c'è anche con la live.

 Solo con gentoo su hdd ho i kernel panic, dei freeze ce l'ho comunque con la live che mi ha consigliato Zizo. Con la live gentoo invece no, è accesa da 4 giorni con gli hdd montati e non ha problemi.

 *djinnZ wrote:*   

> Quindi hai smontato tutti i dissipatori della MB e della scheda grafica?  ed io che credevo di essere paranoico...  

 Confermo, tutti. E' un computer vecchio e volevo prevenire rischi futuri.

 *djinnZ wrote:*   

> Leggi qui e qui ma dato che uso kernel pax+grsec non mi sono mai curato di approfondire visto che non funzionano molto.
> 
> ML=Mailing List lo so che in questi tempi di libro dei fessi (o delle facce di c***o) appare come uno strumento arcaico e desueto ma è ancora in uso per qual che so.
> 
> potresti provare un kernel vanilla.
> ...

 Prima di tentare con il debug del kernel (cosa che mi preoccupa) può davvero aiutare tentare un rebuild completo ?

 *djinnZ wrote:*   

> Non è che non ti voglio aiutare ma anche a farti una lista sommaria di tutte le possibili impostazioni del kernel da verificare come causa dei crash non si finisce più.

 Ci mancherebbe, è che sono digiuno di gentoo da un bel pò e speravo qualcuno mi indicasse "la via"  :Laughing: 

----------

