Newsgroup: it.comp.os.linux.sys
Titolo: Bug del kernel o danno hardware?

Salve a tutti.
Mi trovo in una situazione problematica con uno dei dischi del server che
abbiamo in ufficio, purtroppo il disco di sistema.
Questa la situazione di partenza.
PC con Mandrake Linux 10.0 Official (kernel 2.4.25-2mdk) e due dischi,
disco di sistema collegato direttamente e disco di backup in cassetto
estraibile.
Per il primo mese il server funziona senza problemi (è su anche in questo
momento, nonostante tutto). Poi succede "l'incidente", ovvero un hot swap
del disco di backup... solo che la scheda madre è molto vecchia e non
supporta l'hot swap(!). Conseguenza la letterale esplosione della scheda
madre (6 condensatori, per la precisione), cottura completa di qualche
piccola parte metallica del case (questo non perché sia tecnicamente
rilevante ma così vi fate quattro risate all'idea). Ne consegue la
sostituzione dell'intero gruppo scheda madre+processore+memorie. I dischi
restano dove sono anche perché a essere backuppati sono i dati ma non il
sistema.
Il kernel sembra reagire bene alle modifiche hardware e torna su come
niente fosse... o quasi. Dall'incidente infatti il disco di sistema ha dei
problemi che portano anche al kernel panic :(
Ho fatto varie prove con diversi kernel e il risultato è: kernel 2.6.x ->
panic frequente durante operazioni normali kernel 2.4.x -> panic solo in
caso di backup dell'area dati (una sessantina di giga) kernel più vecchi
(Knopils 0.3 usata per un backup di emergenza) -> nessun blocco anche
durante il backup ma attività più lenta
Questo è un esempio di alcune righe che compaiono praticamente a tutti
gli startup (no, non sono presi tutti dallo stesso avvio, ma si ripetono
praticamente identici):
Jul 21 09:58:06 orangeserver kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Jul 21 09:58:06 orangeserver kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Jul 21 09:58:06 orangeserver kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Jul 21 09:58:06 orangeserver kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC } 
ma anche
Jul 20 12:09:10 orangeserver drakboot[2934]: test_for_bad_drives(/dev/hda)
Jul 20 12:09:10 orangeserver drakboot[2934]:
check_geometry_using_the_partition_table failed for (hda1, 64259):
3,254,62 vs 63,11,62 with geometry 238216/16/63
I test di smartctl non riportano errori particolari tranne una lista di 87
errori che credo si siano verificati ai tempi "dell'esplosione" (i log
dello smart non danno molte informazioni a riguardo salvo che prima di
quegli 87 errori quasi tutti in momenti di DMA Write c'era stato un uptime
di circa un mese, il che sarebbe coerente con la mia ipotesi). Ecco uno
dei cinque errori che sono rimasti nel log:
  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 28 78 81 f3 e0  Error: ICRC, ABRT at LBA = 0x00f38178 = 15958392
  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  ca 00 28 78 81 f3 e0 08      00:06:41.136  WRITE DMA
  ca 00 28 78 81 f3 e0 08      00:06:41.072  WRITE DMA
  10 00 3f 00 00 00 e0 08      00:06:41.072  RECALIBRATE [OBS-4]
  ca 00 28 78 81 f3 e0 08      00:06:41.008  WRITE DMA
  ca 00 28 78 81 f3 e0 08      00:06:40.848  WRITE DMA
Ed ecco il testo che appare a schermo (e nei kernel warning) quando si
verifica il blocco. È interessante notare che solo in alcuni casi (kernel
2.6.x, ma per ovvi motivi sto cercando di evitare troppi esperimenti)
porta al panic vero e proprio mentre con kernel più vecchi (2.4.x)
impedisce qualsiasi nuovo login o cambio di utente ma permette di andare
avanti con alcune operazioni. L'output su stdout/stderr è un semplice
Segmentation Fault (quando previsto).
Jul 18 04:02:47 orangeserver kernel: kernel BUG at include/linux/list.h:148!
Jul 18 04:02:47 orangeserver kernel: invalid operand: 0000 [#1]
Jul 18 04:02:47 orangeserver kernel: CPU:    0
Jul 18 04:02:47 orangeserver kernel: EIP:    0060:[__remove_from_page_cache+91/112]    Not tainted VLI
Jul 18 04:02:47 orangeserver kernel: EIP:    0060:[<c013a76b>]    Not tainted VLI
Jul 18 04:02:47 orangeserver kernel: EFLAGS: 00010217
Jul 18 04:02:47 orangeserver kernel: EIP is at __remove_from_page_cache+0x5b/0x70
Jul 18 04:02:47 orangeserver kernel: eax: c115ad10   ebx: c28ccce8   ecx: c115ad18   edx: c10c4940
Jul 18 04:02:47 orangeserver kernel: esi: c115ad10   edi: c13f1df8   ebp: c13f1dd0   esp: c13f1dc8
Jul 18 04:02:47 orangeserver kernel: ds: 007b   es: 007b   ss: 0068
Jul 18 04:02:47 orangeserver kernel: Process kswapd0 (pid: 8, threadinfo=c13f0000 task=c13f6ca0)
Jul 18 04:02:47 orangeserver kernel: Stack: c115ad10 00000000 c13f1de0 c014342d c115ad10 c115ad10 c13f1e54 c01438e9
Jul 18 04:02:48 orangeserver kernel:        c28ccce8 c115ad10 00000030 0000003e 0000000e 00000000 c115ad10 c10c4d38
Jul 18 04:02:48 orangeserver kernel:        c11317a8 c112a7f0 c11ace30 c10ee1d8 c1142030 c11af1d0 c10fc350 c103a8e0
Jul 18 04:02:48 orangeserver kernel: Call Trace:
Jul 18 04:02:48 orangeserver kernel:  [invalidate_complete_page+45/128] invalidate_complete_page+0x2d/0x80
Jul 18 04:02:48 orangeserver kernel:  [<c014342d>] invalidate_complete_page+0x2d/0x80
Jul 18 04:02:48 orangeserver kernel:  [invalidate_mapping_pages+137/224] invalidate_mapping_pages+0x89/0xe0
Jul 18 04:02:48 orangeserver kernel:  [<c01438e9>] invalidate_mapping_pages+0x89/0xe0
Jul 18 04:02:48 orangeserver kernel:  [destroy_inode+69/80] destroy_inode+0x45/0x50
Jul 18 04:02:48 orangeserver kernel:  [<c01694b5>] destroy_inode+0x45/0x50
Jul 18 04:02:48 orangeserver kernel:  [invalidate_inode_pages+16/32] invalidate_inode_pages+0x10/0x20
Jul 18 04:02:48 orangeserver kernel:  [<c0143950>] invalidate_inode_pages+0x10/0x20
Jul 18 04:02:48 orangeserver kernel:  [prune_icache+474/496] prune_icache+0x1da/0x1f0
Jul 18 04:02:48 orangeserver kernel:  [<c0169c4a>] prune_icache+0x1da/0x1f0
Jul 18 04:02:48 orangeserver kernel:  [shrink_icache_memory+29/48] shrink_icache_memory+0x1d/0x30
Jul 18 04:02:48 orangeserver kernel:  [<c0169c7d>] shrink_icache_memory+0x1d/0x30
Jul 18 04:02:48 orangeserver kernel:  [shrink_slab+267/368] shrink_slab+0x10b/0x170
Jul 18 04:02:48 orangeserver kernel:  [<c0143c5b>] shrink_slab+0x10b/0x170
Jul 18 04:02:48 orangeserver kernel:  [balance_pgdat+575/592] balance_pgdat+0x23f/0x250
Jul 18 04:02:48 orangeserver kernel:  [<c0144f4f>] balance_pgdat+0x23f/0x250
Jul 18 04:02:48 orangeserver kernel:  [kswapd+199/224] kswapd+0xc7/0xe0
Jul 18 04:02:48 orangeserver kernel:  [<c0145027>] kswapd+0xc7/0xe0
Jul 18 04:02:48 orangeserver kernel:  [autoremove_wake_function+0/64] autoremove_wake_function+0x0/0x40
Jul 18 04:02:48 orangeserver kernel:  [<c0121170>] autoremove_wake_function+0x0/0x40
Jul 18 04:02:48 orangeserver kernel:  [autoremove_wake_function+0/64] autoremove_wake_function+0x0/0x40
Jul 18 04:02:48 orangeserver kernel:  [<c0121170>] autoremove_wake_function+0x0/0x40
Jul 18 04:02:48 orangeserver kernel:  [kswapd+0/224] kswapd+0x0/0xe0
Jul 18 04:02:48 orangeserver kernel:  [<c0144f60>] kswapd+0x0/0xe0
Jul 18 04:02:48 orangeserver kernel:  [kernel_thread_helper+5/16] kernel_thread_helper+0x5/0x10
Jul 18 04:02:48 orangeserver kernel:  [<c0109275>] kernel_thread_helper+0x5/0x10
Jul 18 04:02:48 orangeserver kernel:
Jul 18 04:02:48 orangeserver kernel: Code: 02 c7 41 04 00 02 20 00 c7 46 08 00 01 10 00 c7 46 10 00 00 00 00 8b 43 30 48 89 43 30 83 05 20 f1 40 c0 ff 8d 65
f8 5b 5e 5d c3 <0f> 0b 94 00 7d 69 2e c0 eb bf 0f 0b 95 00 7d 69 2e c0 eb bd 90
Il dubbio sostanzialmente sarebbe capire se il problema è hardware o
software. Il kernel (esperimenti a parte che ho provato a fare più avanti
per capire se era veramente un bug del kernel) non è cambiato rispetto al
periodo "sano" e in quel mese non si è mai verificato nulla di simile a
questo problema (poco prima dell'incidente venne effettuato un backup
senza problemi anche se, causa problemi tra cavo e vecchia scheda madre,
con una lentezza esasperante, 12 ore contro 6 ore di KnopILS). Il disco
*potrebbe* essere rimasto danneggiato nel "botto" ma è pur vero che i
kernel più vecchi sembrano essere meno sensibili al problema. Tra l'altro
il problema sembra correlato direttamente al "carico", nel senso che si è
verificato sempre durante attività prolungate e "in velocità"). Su
bugzilla.kernel.org
 ho trovato un bug molto simile che interessa i kernel
Debian e Mandrake ma che inizia con "include/linux/list.h:149!" invece che
148.
In pratica le possibilità che sto valutando sono: 
1 - Sostituire il disco (cosa che però costringerebbe a riconfigurare
tutto: come posso fare una copia 1:1 su un disco *non* dello stesso
modello, trattandosi di un disco vecchio? Basta dd?)
2 - Gestire in qualche modo l'eventuale kernel bug? (potrebbe servire
"forzare" una modalità DMA più lenta o qualcosa del genere?)
Il tutto tenendo conto che la macchina è server web/posta/ftp (entrambi
pubblici su dominio registrato) e file server (privato) quindi qualsiasi
soluzione che preveda un downtime dovrebbe essere più rapida possibile o
magari proprio evitata anche se si paga con un rallentamento.
Che ne pensate?
Grazie mille.
See you,
	Silver Drake
-- 
http://www.silverdrakenet.it
Australian Largest Bed, coverband extraordinaire
Live il 19 Agosto alla Festa della Birra di Granarolo Faentino

 1 - Sostituire il disco (cosa che per? costringerebbe a riconfigurare
Secondo me ti conviene sostituire il disco e reinstallare una versione
pulita.
Davide
-- 
| Every morning, I get up and look through the 'Forbes' list of the
| richest people in America.  If I'm not there, I go to work 
| 
| 

 estraibile.
Dimenticavo: tutto su partizioni Ext3.


 pulita.
Volendo sostituire il disco ma mantenendo la configurazione del sistema
(ovvero trasferendo tutti i file presenti adesso) che
strumento/comando sarebbe più adatto?


 strumento/comando sarebbe pi? adatto?
dd potrebbe andare, ma se ci sono dei danni _fisici_ sul disco rischi
di copiare roba avariata. Eventualmente controlla solo i files di 
configurazione e segnati a manella le configurazioni 'strane'.
Davide
-- 
| If two wrongs don't make a right, try three. 
| 
| 
| 

 configurazione e segnati a manella le configurazioni 'strane'.
Ok, grazie del consiglio (soprattutto vista la rapidità).


 sistema.
mmm... io direi danno fisico. quel bug è una macro che segnala condizioni
anomale, probabilmente innescate dal danno del disco.

 con la Ram.
Just FYI, il check del CRC viene fatto in hardware dal disco. Ci sono
dei settori che sono FUBAR ed il firmware non riesce a rilocarli
(probabilmente ha gia` finito i settori di scorta).
Luca
-- 
Home: 
http://kronoz.cjb.net
E' stato a causa di una donna che ho cominciato a bere e non ho mai
avuto la cortesia di ringraziarla.