Newsgroup: it.comp.os.linux.sys
Titolo: Crash dump

Ho alcuni crash che si presentano su macchine diverse:
http://postimage.org/image/fljhapv5x/
 
 
(non ho altro modo di salvare tutto quel testo)
 
Sembra sia un bug del kernel. Considerato che ho solo quella schermata li (la tastiera è completamente morta quando si presenta il crash) c'è modo di identificarne le cause e/o forzare un reboot del sistema?
 
Non è un kernel panic, quindi presumo che il settaggio reboot on panic non abbia effetto.

 Sembra sia un bug del kernel. Considerato che ho solo quella schermata li (la tastiera è completamente morta quando si presenta il crash) c'è modo di identificarne le cause e/o forzare un reboot del sistema?
 
Dovrebbe essere una divisione per zero che fa alterare il kernel.
So che il numero indicato qui:
find_busiest_group+0x97a
indica la posizione dell'errore all'interno della funzione find_busiest_group.
Sapete dirmi come convertire tale dato in riga di codice, sempre che sia possibile?
 
In effetti nel mio kernel, dentro quella funzione, c'è una possibile divisione per zero, vorrei solo averne conferma perchè il bug di cui si parla nelle varie mailinglist sembra capiti dopo mesi di utilizzo (6 o più) nel mio caso capita molto più di frequente.

 modo di identificarne le cause e/o forzare un reboot del sistema?
 
Usa netconsole.
# modprobe netconsole
 
E poi lo configuri con la comoda interfaccia in /sys (quindi senza fare 
reboot)
 
Ti permette di mandare tutti i log del kernel ad una macchina remota via 
syslog.
 

 Usa netconsole.
 
Ok, in tal caso ricevo il dump completo (anche se dovrebbe bastare la riga indicata dal RIP), ma senza avere il kernel compilato con il debug, come risalgo alla riga di codice?
 
Son quasi certo si tratti di una divisione per zero (per avere conferma dovrei avere la prima riga di crash, che non ho) ma vorrei incrociare il dump con il sorgente.
 
Ho fatto alcune prove, ricompilando il kernel, disassemblando sched.o e sottraendo la posizione indicata dal RIP con la posizione della funzione incriminata dentro il disassemblato ottenendo quindi, in teoria, un numero di riga, ma non corrisponde a nulla.
 
Ci vorrebbe gdb ma non ho il dump e preferirei evitare di dover attendere un altro crash.

  ma senza avere il kernel compilato con il debug, come risalgo alla riga di codice?
 
Molto dura se ci sono le ottimizazioni (cosa probabile).
 
Giulia
 

 come risalgo alla riga di codice?
 
Se è un modulo che hai scritto tu, allora compilatelo con i simboli.
Se è un modulo stock, anche senza debug, i dati che il kernel fornisce 
sono sufficienti ad un kernel hacker a capire il problema (parlo per 
esperienza perchè di quei dump ne ho inviati parecchi).
 
Netconsole non aggiunge null'altro che il kernel non mostri già e lo 
invia via rete ad un server syslog remoto proprio per evitare i problemi 
di cattura che hai avuto tu.
 
Ora, ragionando, se i dati che i kernel stock delle distribuzioni non 
fossero (quasi) sempre sufficienti non pensi che il problema sarebbe 
saltato fuori prima ?
 
Abilita netconsole, "grabba" l'errore ed invialo a chi ci capisce.

 sono sufficienti ad un kernel hacker a capire il problema 
 
Confermo (e un po' li odio :-D)

 di cattura che hai avuto tu.
 
Lo so. Io però non riesco a scrollare in su di una pagina quando mi muore il server. E mi interessa vedere la prima riga del crash (che ovviamente è sempre fuori dallo schermo), dove quasi certamente c'è scritto division by zero.


Scusa eh...
non mi ricordo se te l'avevo già consigliato...
 
Ma hai provato ad usare netconsole che mi pareva fosse fatto proprio per 
risolvere queste problematiche ?
 
Ovviamente il syslog lo devi usare su un'altra macchina, non sulla stessa.
 

> Ma hai provato ad usare netconsole
Sicuro che dopo una division by zero in una routine dello schedule il kernel
riesca a gestire ancora il processo syslog e la tasmissione tcp/ip ?
 
Io consiglierei di piu' una console seriale se possibile o una vgamode che abbia piu' linee.
 
Giulia
 


+1
 
avevo dei server con driver intel per schede di rete bacate e non sarei 
riuscito mai con netconsole a farcela.
Messa un'altra macchina con cavo seriale e non ricordo che software che 
loggava tutto, sono riuscito a scoprire l'arcano.
 

 risolvere queste problematiche ?
 
A me serve ricostruire il dump *PRIMA* di un nuovo crash.
netconsole mi permette di inoltrare un eventuale dump ad una macchina esterna, ma non è ciò che voglio fare, io devo evitare che ricapiti e dispongo solo dello screenshot che ho inviato.
 
La riga RIP dovrebbe bastare, indica la funzione e la posizione in cui si è verificato il problema, solo che non ho idea di come fare a risalire al file sorgente incriminato (e rispettiva riga)
 
So già dove è definita tale funzione (kernel/sched.c) ed effettivamente c'è una potenziale divisione per zero, quindi i vari bug report leggi in giro sembrano essere congrui al mio problema (e teoricamente già fixati in kernel più recenti, devo solo riavviare la macchina), la mia è più una fissa mentale, voglio avere conferma che il bug di cui si legge in giro sia lo stesso che si presenta a me.

 che abbia piu' linee.
 
Accendere il cervello:
Cosa ti fa pensare che su una seriale, DOPO un qualsiasi errore perchè 
prima dell'errore nessuno sa della sua esistenza) il kernel possa inviare 
i dati su seriale e non su rete ?
 
Cioè qual'è il discriminante ?
Sai cosa è netconsole ? L'hai mai usato ?
Hai mai pensato che se hai un server a qualche centinaio di chilometri di 
distanza un cavo seriale "potrebbe" non arrivarci ?
Hai mai pensato che, per alcuni backtrace del kernel, nemmeno un 40" 
FullHD potrebbe avere le linee sufficienti ?
 
Insomma:
netconsole è fatto per quello.
Non c'è bisogno di inventarsi altra roba o riesumare le Seriali che ormai 
sono praticamente scomparse.
 

 dello screenshot che ho inviato.
 
Usa netconsole, cazzo (cit. De Falco)
 
Ho migliaia (e non scherzo) di OOPS o di PANICS raccolti con netconsole 
che provengono proprio da kernel/sched.c.
 
Usalo e levati il dubbio.
 

 Usalo e levati il dubbio.
 
Porco mondo, devo togliermi il dubbio PRIMA di un nuovo oops.
Non posso aspettare un altro crash, devo evitarlo, e per farlo devo fare con ciò che ho: un mezzo dump.
 
Già in passato ho usato netconsole con successo (me l'avevi consigliato sempre te), ma in questo caso è diverso, non posso permettermi un ulteriore crash di questo tipo. Sfiga vuole che 'sto server gestisce alcuni DB da molti, molti, molti, molti, moltissimi giga ed ogni volta fare un reboot forzato con conseguente riparazione delle tabelle non è bello.
 
Attivare netconsole adesso non servirebbe a nulla. Mi servirà in caso di futuro crash, ma io devo risolvere il problema che ho ora, non quello che avrò forse tra 1 mese.

 che ho: un mezzo dump.
 
Ahhh potevi dirlo prima che volevi la macchina del tempo ed una 
telecamera ad alta velocità per vedere il dump mentre nel passato 
scorreva sul monitor...
 
Sarebbe troppo fico per ogni programmatore risolvere i problemi di un bug 
che non si può replicare.
 
Non credo che tu potrai mai levarti il dubbio.
 

 scorreva sul monitor...
 
Eh no, non voglio la macchina del tempo, semplicemente vorrei sapere come fare a risalire al numeoro di riga partendo dalla riga RIP.
 
(e si può fare eh... il puntatore alla riga è già scritto nel messaggio di errore, solo che non ho capito come risalirci, avendo un kernel patchato da debian)
 
Però, ho visto solo ora che la mia versione del kernel è 2.6.32-45 e *dovrebbe* essere già quella bug-free. L'unico dobbio che mi rimane è: ho riavviato quando ho installato tale versione del kernel (e quindi è già quella attiva, bug-free) oppure era ancora operativa la vecchia soggetta a bug?
 
Boh

 Però, ho visto solo ora che la mia versione del kernel è 2.6.32-45 e *dovrebbe* essere già quella bug-free. L'unico dobbio che mi rimane è: ho riavviato quando ho installato tale versione del kernel (e quindi è già quella attiva, bug-free) oppure era ancora operativa la vecchia soggetta a bug?
 
 
il problema è anche un altro.
la 2.6.32-45 (che mi risulta essere l'ultima visto che apt non scarica altri aggiornamenti) dovrebbe essere bug-free eppure la divisione per zero è ancora li, bella visibile.
 
I casi son due, o sto guardando il sorgente errato oppure il bug in realtà non è stato corretto su debian.
 
Ho preso il sorgente con apt-get source linux-image-2.6-amd64 poi ho decompresso il tar.gz ma li dentro il bug c'è ancora.
 
Sbaglio qualcosa?