Newsgroup: it.comp.os.linux.sys
Titolo: Kernel 2.4.9 e errori ext2

Ho avuto un approccio decisamente problematico con il kernel 2.4.9 su un
pc equipaggiato con scheda madre ASUS K7M (chipset VIA 686a), Athlon
550, 256 mb RAM.
Nel log mi ritrovo quanto segue:
Sep  3 04:46:15 by-tor kernel: EXT2-fs error (device ide0(3,66)):
ext2_check_page: bad entry
in directory #352757: rec_len is smaller than minimal - offset=36864,
inode=0, rec_len=0, name_len=0
Sep  3 05:02:04 by-tor kernel: EXT2-fs error (device ide1(22,1)):
ext2_check_page: bad entry
in directory #19300355: rec_len is smaller than minimal - offset=3072,
inode=0, rec_len=0, name_len=0
Sui dischi (3 hard disk IDE) eseguo regolarmente hdparm al boot con le
seguenti linee di comando:
hdparm -u 1 -A 1 -m 16 -c 3 -W 1 /dev/hda
hdparm -u 1 -A 1 -m 16 -c 3 -W 1 /dev/hdb
(per un errore nello script mi sono accorto che sul terzo disco non
viene lanciato hdparm <g>)
Negli scorsi giorni ho anche avuto dei kernel oops:
Aug 30 13:33:12 by-tor kernel: attempt to access beyond end of device
Aug 30 13:33:12 by-tor kernel: 16:01: rw=0, want=676429831,
limit=20480008
Aug 30 13:33:12 by-tor kernel: attempt to access beyond end of device
Aug 30 13:33:12 by-tor kernel: 16:01: rw=0, want=676429831,
limit=20480008
Aug 30 13:33:58 by-tor kernel: attempt to access beyond end of device
Aug 30 13:33:58 by-tor kernel: 16:01: rw=0, want=1143373831,
limit=20480008
Aug 30 13:33:58 by-tor kernel: attempt to access beyond end of device
Aug 30 13:33:58 by-tor kernel: 16:01: rw=0, want=1143373831,
limit=20480008
Aug 30 13:34:01 by-tor kernel: Unable to handle kernel paging request at
virtual address 00d05ae8
Aug 30 13:34:01 by-tor kernel:  printing eip:
Aug 30 13:34:01 by-tor kernel: c0132558
Aug 30 13:34:01 by-tor kernel: *pde = 00000000
Aug 30 13:34:01 by-tor kernel: Oops: 0000
Aug 30 13:34:01 by-tor kernel: CPU:    0
Aug 30 13:34:01 by-tor kernel: EIP:    0010:[sync_page_buffers+24/96]
Aug 30 13:34:01 by-tor kernel: EFLAGS: 00013207
Aug 30 13:34:01 by-tor kernel: eax: c0000019   ebx: 00d05ac0   ecx:
c10968dc   edx: 00d05ac0
Aug 30 13:34:01 by-tor kernel: esi: ca3891c0   edi: 000000d2   ebp:
c10968c0   esp: c52d9dfc
Aug 30 13:34:01 by-tor kernel: ds: 0018   es: 0018   ss: 0018
Aug 30 13:34:01 by-tor kernel: Process cc1 (pid: 11432,
stackpage=c52d9000)
Aug 30 13:34:01 by-tor kernel: Stack: 000000d2 ca3891c0 ca3891c0
00d05ac0 c01326c1 ca3891c0 000000d2 c10968dc
Aug 30 13:34:01 by-tor kernel:        c10968c0 000000a2 00000025
00000001 c012853e c10968c0 000000d2 00000006
Aug 30 13:34:01 by-tor kernel:        000000d2 0000003c 00000001
000000d2 c0128bf9 000000d2 00000001 c52d8000
Aug 30 13:34:01 by-tor kernel: Call Trace: [try_to_free_buffers+289/320]
[page_launder+766/1936] [do_try_to_free_pages+57/176]
[try_to_free_pages+34/48] [__alloc_pages+463/640]
Aug 30 13:34:01 by-tor kernel:    [_alloc_pages+22/32]
[do_anonymous_page+50/160] [do_no_page+47/224] [handle_mm_fault+91/192]
[do_page_fault+0/1120] [do_page_fault+355/1120]
Aug 30 13:34:01 by-tor kernel:    [do_page_fault+0/1120]
[do_munmap+86/592] [do_brk+176/368]
[sys_brk+187/240] [error_code+52/60]
Aug 30 13:34:01 by-tor kernel:
La cosa mi ha costretto a un reboot di emergenza, che tra l'altro ha
provocato pure altri oops, smontando in maniera scorretta (ovvero non
smontandoli affatto) alcuni dischi (Alt+SysRQ abilitato ma riuscito solo
parzialmente)
Naturalmente ho abbandonato il 2.4.9 per tornare al 2.2.19 (patchato
ext3+ide), anche se pure quello mi da' problemi di oops (temo sia dovuto 
al chipset VIA, notoriamente buggato), pur se non a questi livelli.
Qualcuno ha soluzioni?
-- 
Ciao,   |                        
sno...@libero.it
Lorenzo | Ringrazia Dio che porto la corazza, se fossi scorazzato farei
	| un macello (A. De Curtis)
 

 Qualcuno ha soluzioni?
Purtroppo mi sa proprio che il problema sia unicamente imputabile al
chipset.
--
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.mascanc.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! Computers are not intelligent.  They only think they are. !>-

 [...]
        Io ho praticamente la tua stessa identica macchina, e con il 2.4.7 
(senza nessuna patch) va che e' un piacere. Non e' che hai problemi con 
il disco (che ti sta lasciando ?)
        Ciao, Giovanni.
-- 
   |^^^^|
   |    |  Eat my shorts !             * Linux Powered *
   |()()| /                            - Kernel  2.4.7 -
                 -> gio.bcc(at)
tin.it
 <-

 il disco (che ti sta lasciando ?)
Anche il mio 2.4.9 era liscio, senza patch di alcun tipo.
Non penso sia una questione di dischi, in quanto gli errori si
verificano su almeno due dei tre che ho:
Sep  3 04:46:15 by-tor kernel: EXT2-fs error (device ide0(3,66)):
ext2_check_page: bad entry in directory #352757: rec_len is smaller than
minimal - offset=36864, inode=0, rec_len=0, name_len=0
Sep  3 05:02:04 by-tor kernel: EXT2-fs error (device ide1(22,1)):
ext2_check_page: bad entry in directory #19300355: rec_len is smaller
than minimal - offset=3072, inode=0, rec_len=0, name_len=0
anzi per l'esattezza su due partizioni
hdb2 e hdc1 (rispettivamente /var e /usr/local)
che risultano danneggiate al reboot successivo, mentre le altre sono ok
(anche sullo stesso disco). Il controllo di fsck per settori difettosi
non ha trovato nulla di anomalo.
(queste sono le mie)
/dev/hda1               947060    688700    209364  77% /
/dev/hdb2              3028108    604128   2270160  21% /var
/dev/hdb3              2988524    584452   2252260  21% /tmp
/dev/hda4              9343264   5046108   3814808  57% /usr
/dev/hda2              1707300   1432026    177680  89% /usr/src
/dev/hdc1             17913640   6249158  10640482  37% /usr/local
/dev/hdc2              8956885   2262586   6182286  27% /home
/dev/hdc3              8237016    270336   7548260   3% /www
Appena avro' tempo credo che qualcuna se non la maggior parte di queste
partizioni passera' in reiserfs... ;-)
Il problema pero' resta negli oops che si beccano alcuni processi, cosa
che poi aumenta progressivamente, fino ad impedire un reboot... questo
mi avviene anche con il 2.2.19 patchato con la patch di 
linux-ide.org
Boh?
-- 
Ciao,    |              
sno...@libero.it
Lorenzo  |  Annus horribilis in decade malefica
	 |  decade malefica in stolto secolo  
	 |  grondante sangue e vacuo di promesse         

 chipset.
Infatti su kernel traffic avevo letto di seri problemi con i chipset VIA
686... :-(
Speriamo nel futuro...
-- 
Ciao,  |                        
sno...@libero.it
Lorenzo|Ma que bela causa, d'estar tuchi i seras a beicar a casa la television
       |ma que bela causa, d'estre tuchi i seras da solets a casa, que 
       |sodisfacion!  (Lou Dalfin)

 Speriamo nel futuro...
In situazioni di IO intenso il chipset impazzisce. Non sono a conoscenza dei
dettagli ma credo proprio che sia ora di considerare un controller ide pci.
 
--
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.mascanc.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
The primary purpose of the DATA statement is to give names to constants;
instead of referring to pi as 3.141592653589793 at every appearance,
the variable PI can be given that value with a DATA statement and
used instead of the longer form of the constant.  This also
simplifies modifying the program, should the value of pi change.
                        -- FORTRAN manual for Xerox computers

 Boh?
        Non so che dirti, se non di provare il 2.4.7 che qua da me va bene. 
Magari prova pure ad usare hdparm 'liscio liscio', magari e' quello che 
da' problemi (io uso 'hdparm -d -m 16 -u1 -c 3')
        Saluti, Giovanni.


 da' problemi (io uso 'hdparm -d -m 16 -u1 -c 3')
Ok grazie, provero'...
Ieri poi ho avuto un problema anche col 2.2.19 (patch ide+reiser) a
livello di memoria (sessioni di terminale sotto X abortivano con un
messaggio di memoria insufficiente) tutto partito da
Sep  4 13:23:53 by-tor kernel: Unable to handle kernel paging request at
virtual address 80fac4f8
Sep  4 13:23:53 by-tor kernel: current->tss.cr3 = 0db1b000, %cr3 =
0db1b000
Sep  4 13:23:53 by-tor kernel: *pde = 00000000
Sep  4 13:23:53 by-tor kernel: Oops: 0000
Sep  4 13:23:53 by-tor kernel: CPU:    0
Alt+SysRQ mi ha salvato :-)
Cmq deve essere una questione di DMA col chipset VIA 686, se lo
disattivo i problemi sembrano sparire... pero' le prestazioni calano
vistosamente...


 dettagli ma credo proprio che sia ora di considerare un controller ide pci.
Comincio a penare anche io che questa sia l'unica soluzione... :-(


 
sicuro che non sia un problema di RAM? e` vero che i via686 sono
buggati, ma non credo *cosi`* buggati! Da come dici l'hw e` praticamente
inutilizzabile mentre con gli ultimi 2.4.x (che tra l'altro includono un
workaround) x incappare in un errore del chip devi essere abbastanza
"fortunato". credo.
Okkio poi che passare a reiserfs non penso sia sufficiente a risolve
davvero tutti i problemi (e metti in preventivo che, per quanto
affidabile e per quanto lo sviluppo proceda spedito, non e` ancora
abbastanza "vecchio" per essere considerato affidabile al 100%)!
-- 
Ciao,  |     Gott weiss ich will kein Engel sein
Matteo |                     -- Rammstein, Engel

 vistosamente...
        Boh, qua' lo uso e va bene (con una mano scrivo e con l'altra faccio i 
necessari scongiuri ;) Tanto per curiosita', ma i dischi hanno vita 
dura ? Perche' a qual che so il chipset da' problemi sotto forte 
carico, non in condizioni normali.
        E comunque proprio non so che dirti, sorry...
        Ciao, Giovanni.


 davvero tutti i problemi (e metti in preventivo che, per quanto
Quantomeno a ridurre i tempi di fermo macchina per il check dei
dischi... ho sotto 56 GB di dischi, e per controllarmi il tutto fsck ci
impiega oltre un'ora... ;-)


 carico, non in condizioni normali.
Beh, la macchina e' abbastanza sotto carico (vedi altro mio post in
questo thread: fa da server per una lan da 10 client: smtp, pop3, ftp,
dns, nntp, httpd e chi piu' ne ha piu' ne metta :-)) il problema e' che
non ho un'altra macchina alla quale affidare un po' di servizi, il mio
capo e' decisamente tirchio e non ci sono a tiro macchine affidabili da
usare, anche di recupero (l'unico e' un 486/25 che mi fa da dns
secondario, ma di piu' non posso fargli fare perche' si riavvia da solo
ogni tanto...)


 da solo ogni tanto...)
        E' strano pure quello ? Hai provato con uno stregone ? Oh, puoi pure 
appendere una croce (o dell'aglio) al monitor, magari aiuta... :-)
        Ciao, Giovanni.
        ps: seriamente, prova con un altro controller ide, non mi pare che 
costino troppo.


 costino troppo.
Forse e' l'unica, mi informero'... grazie.


 impiega oltre un'ora... ;-)
Io ti consigli di usare ext3, almeno se qualcosa va male puoi sempre
rimontare le partizioni in ext2
Henryx
-- 
Questo senso di approssimazione che pervade i windowsFan a volte mi
sconforta (V. Valvano)

 rimontare le partizioni in ext2
Anche questa e' un'opzione che ho considerato, e ho anche testato, pero'
sono un po' perplesso dato che lo sviluppo e' piu' indietro rispetto a
reiserfs...


 reiserfs...
Sono due cose differenti, pero`. ReiserFS e` un filesystem con altre
caratteristiche, rispetto a ext2, e, di conseguenza, ad ext3.
Bye,
 Emmanuele.
-- 
I ... Owe ... You ... Pain! -- Willow, "Tough Love"
Italian Buffy Resource Site (Beta) - 
http://www.ibrs.f2s.com
GnuPG Key ID: 0x788E3A3A
GnuPG Key FP: 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 caratteristiche, rispetto a ext2, e, di conseguenza, ad ext3.
Su questo siamo perfettamente d'accordo, e' tutt'altro :-)
Cmq per il momento ho creato il journal su quasi tutte le partizioni e
alla prima occasione utile vado di reboot (o di umount/mount da telinit
1)
