Newsgroup: it.comp.os.linux.sys
Titolo: IBM supporta anche linux??? - Mah sara' ma non sembra...

Salve a tutti,
scrivo per chiedere consigli e per raccontare la mia esperienza.
Ultimamente si sente molto parlare di linux&IBM e sapere che una importante
azienda come ibm porta avanti lo l'integrazione ddell'open source nella
nostra società mi fa molto piacere.
Purttroppo, però, non sembra proprio così.
Dove lavoro abbiamo appena acquistato 3 IBM xseries 235 (biprocessori
xeon... ecc) abbiamo installato linux, ans, powerchute e tutto quello che ci
andava per rendere i server il + ridondati possibile ma... la redhat 7.3
(per la quale il server è certificato) crasha (scusate il termine un
po'...schifoso) ogni 3 gg.
Il problema sembra essere dovuto al filesystem, visto che compaiono a
monitor stringhe incomprensibili con i vari registri eax ... ecc... e tra
queste compare qualcosa che fa riferimento al journaled filesystem.
Inoltre, in /var/log/messages compare qualcosa tipo
modprobe can't locate module virtual
modprobe can't locate module eth3
modprobe can't locate module eth4
modprobe can't locate module eth5
.
.
modprobe can't locate module eth61
modprobe can't locate module eth62
e poi, nonostante sulle macchine ci siano 2 processori....
sembra che ne riconosca 4 attivati infatti
dmesg riporta quanto segue...
[root@localhost root]# dmesg | grep CPU
nown CPU [15:2] APIC version 16
CPU 2 (0x0100) enabledProcessor #1 Unknown CPU [15:2] APIC version 16
CPU 3 (0x0700) enabledProcessor #7 Unknown CPU [15:2] APIC version 16
4 CPUs total
Enabling the CPU's according to the ACPI table
Initializing CPU#0
CPU: Before vendor init, caps: 3febfbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 12K, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU: After vendor init, caps: 3febfbff 00000000 00000000 00000000
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: 3febfbff 00000000 00000000 00000000
CPU:             Common caps: 3febfbff 00000000 00000000 00000000
CPU: Before vendor init, caps: 3febfbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 12K, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU: After vendor init, caps: 3febfbff 00000000 00000000 00000000
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: 3febfbff 00000000 00000000 00000000
CPU:             Common caps: 3febfbff 00000000 00000000 00000000
CPU0: Intel(R) XEON(TM) CPU 1.80GHz stepping 04
per-CPU timeslice cutoff: 1462.93 usecs.
enabled ExtINT on CPU#0
Initializing CPU#1
masked ExtINT on CPU#1
CPU: Before vendor init, caps: 3febfbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 12K, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 0
CPU: After vendor init, caps: 3febfbff 00000000 00000000 00000000
Intel machine check reporting enabled on CPU#1.
CPU:     After generic, caps: 3febfbff 00000000 00000000 00000000
CPU:             Common caps: 3febfbff 00000000 00000000 00000000
CPU1: Intel(R) XEON(TM) CPU 1.80GHz stepping 04
Initializing CPU#2
masked ExtINT on CPU#2
CPU: Before vendor init, caps: 3febfbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 12K, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 3
CPU: After vendor init, caps: 3febfbff 00000000 00000000 00000000
Intel machine check reporting enabled on CPU#2.
CPU:     After generic, caps: 3febfbff 00000000 00000000 00000000
CPU:             Common caps: 3febfbff 00000000 00000000 00000000
CPU2: Intel(R) XEON(TM) CPU 1.80GHz stepping 04
Initializing CPU#3
masked ExtINT on CPU#3
CPU: Before vendor init, caps: 3febfbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 12K, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: Physical Processor ID: 3
CPU: After vendor init, caps: 3febfbff 00000000 00000000 00000000
Intel machine check reporting enabled on CPU#3.
CPU:     After generic, caps: 3febfbff 00000000 00000000 00000000
CPU:             Common caps: 3febfbff 00000000 00000000 00000000
CPU3: Intel(R) XEON(TM) CPU 1.80GHz stepping 04
..... CPU clock speed is 1796.0960 MHz.
CPU0<T0:997824,T1:798256,D:3,S:199565,C:997828>
CPU1<T0:997824,T1:598688,D:6,S:199565,C:997828>
CPU2<T0:997824,T1:399120,D:9,S:199565,C:997828>
CPU3<T0:997824,T1:199552,D:12,S:199565,C:997828>
checking TSC synchronization across CPUs: passed.
Qualcuno può darmi qualche dritta?
Grazie infinite
MaoX
--
--
P.I. Maurizio Proietti
C.E.D. della Provincia di Prato
0574 / 534.325

 
[cut]
mmm, questa è interessante.
cat /proc/cpuinfo
che ti dice?
(PS: non postare i numeri di telefono nei NG)
-- 
Milo Sandydowns
"Quando dico "mi pare" vuol dire che ne sono sicuro."  Graziano Ledda

 Qualcuno può darmi qualche dritta?
Aggiorna il kernel, leggi gli advisories di red-hat, e vivi felice.
Dando per scontato che usi filesystem ext3, quel problema è trito e
ritrito (semprechè tu non abbia gia aggiornato e il problema è
rimasto...)
Byez.
-- 
Emanuele Balla aka Skull
-----------------------------------------------------------------------
Besides, I think [Slackware] sounds better than 'Microsoft', don't you?
(By Patrick Volkerding)

 4 CPUs total
Corretto, i microprocessori Xeon usano hyper threading.
Fai una ricerca con google per avere piu' informazioni, 
in pratica ogni processore viene visto come una coppia di 
proc, avendo una parte dal core duplicata.
Ciak
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 
Quello dei moduli?
Mah, non vedo cosa centri il supporto ext3 con il caricamento di moduli
a cazzo. Ma magari mi sbaglio.


 modprobe can't locate module virtual
sono messaggi che indicano che non è configurato l' alias per le schede di 
ret virtual eth2 , 3 ,4 , ecc ecc , è colpa di RH che prova comunque a 
caricarli anche se non sono presenti nella macchina , nulla di grave 
comunque.
ciao


Eccolo...
[root@localhost root]# cat /etc/modules.conf
alias parport_lowlevel parport_pc
alias eth0 e100
alias eth1 e100
alias scsi_hostadapter ips
alias eth2 tg3
alias usb-controller usb-ohci
P.S.
Visto che c sono colgo l'occasione per ringraziare tutti per l'aiuto
MaoX

Salve nuovamente a tutti,
visto che siete così gentili e ben preparati :-)
[e poi non mi si dica che non vi faccio complimenti :-)]
sugli stessi sever i "tecnici" avevano rilevato un malfunzionamento del
cd-rom.
Oggi io ho provato il cd e...
ecco cosa è successo:
mount /mnt/cdrom/
OK
cp /mnt/cdrom/* /root/test_cd/
Dec  4 13:21:18 localhost kernel: hda: cdrom_decode_status: status=0x51 {
DriveReady SeekComplete Error }
Dec  4 13:21:18 localhost kernel: hda: cdrom_decode_status: error=0x30
Dec  4 13:21:25 localhost kernel: hda: cdrom_decode_status: status=0x51 {
DriveReady SeekComplete Error }
Dec  4 13:21:25 localhost kernel: hda: cdrom_decode_status: error=0x30
Dec  4 13:21:32 localhost kernel: hda: cdrom_decode_status: status=0x51 {
DriveReady SeekComplete Error }
Dec  4 13:21:32 localhost kernel: hda: cdrom_decode_status: error=0x30
Dec  4 13:21:39 localhost kernel: hda: cdrom_decode_status: status=0x51 {
DriveReady SeekComplete Error }
Dec  4 13:21:39 localhost kernel: hda: cdrom_decode_status: error=0x30
[HO PREMUTO CTRL-ALT-CANC]
Dec  4 13:21:39 localhost kernel: hda: DMA disabled
Dec  4 13:21:39 localhost kernel: hda: ATAPI reset complete
ho rismontato il cd, l'ho rimontato, ho riprovato la copia,
(ho notato che già aveva copiato i file xchè mi avvisava se volevo
sovrascriverli) e tutto ha funzionato per il meglio.
Riprovo 1 ora + tardi ed è sempre tutto OK.
Cosa potrebbe essere?
Grazie ancora.
MaoX

Io ho degli X342 biprocessori con su Suse e Reiser Fs.
Sono accesi da aprile e non ho avuto nessun problema.
Il problema del cd rom una cosa simile l'ho avuta anche io in fase di
installazione, ma era dovuto al cavo scsi che collega la Mother Board con
l'unità nastro che non era correttamente terminato.(il tecnico che aveva
assemblato il Rack aveva sbagliato il cavo)
In teoria non dovrebbe fare nessun problema al Cd ma in pratica non riuscivo
a leggere nessun CD, sostituito quello va tutto
perfettamente.
Ciao
--
"Il mondo si divide in due categorie. C'è chi ha la pistola carica e chi
scava. Tu scavi !!!"

 a cazzo. Ma magari mi sbaglio.
No, mi riferivo ai crash legati al filesystem di cui mi pare parlasse (se
non ho interpretato male il post). C'è un aggiornamento per la 7.3 per
l'eliminazione di una race condition nel supporto a ext3 che si presenta
in fasi di elevato I/O sulla partizione, con corruzione del file di
journaling.
Byez


 Visto che c sono colgo l'occasione per ringraziare tutti per l'aiuto
Figurati, se si può darsi una mano...



L'errore si è ripresentato anche stamane e a monitor vi era circa quanto
segue:
EIP is at journal_write_metadata_buffer[jbd] 0x74 2.4.18-3SMP
Process Kjournald (pid: 21 stackpage=f6d9b000)
[cut x numeri e valori di registri assurdi e incomprensibili]
code 0f 0b 5e 5f 8b 7c 24 28 8b 4f 0c 85 c9 74 2e c7 44 24 0c 01
Grazie ancora
saluti
MaoX

Visto che c sono...
pensavo di ricompilare il kernel.
ho perņ una domanda...
essendo un multiprocessore, quando vado a dare il comando
make -j NUMERO_PROCESSORI [al posto del normale make]
essendo 2 xeon (che sono visti come 4 processori singoli se non ho capito
male) che comando devo dare?
make -j 2 oppure make -j 4
Grazie ancora.
MaoX

 code 0f 0b 5e 5f 8b 7c 24 28 8b 4f 0c 85 c9 74 2e c7 44 24 0c 01
Dall'advisory redhat:
Advisory:  RHBA-2002:085-11
Advisory Type:  Bug Fix Advisory
Product:  Red Hat Linux
Relevant Channels: Red Hat Linux 7.3 i386
Bugs Fixed: Kernel Panic when running sendmail test
Topic: A few bugs, including one in ext3 that could cause a kernel panic
on SMP systems, are fixed in this kernel errata.
Description:
In the 2.4.18-3 kernel, a timing change exposed a previously-unseen
race condition in ext3 which could occasionally cause the kernel
to panic on SMP systems. The 2.4.18-4 kernel corrects this problem.
ecc...
Direi che č lui...
aggiorna via rpm o compila da sorgente...


 code 0f 0b 5e 5f 8b 7c 24 28 8b 4f 0c 85 c9 74 2e c7 44 24 0c 01
ksymops is yout friend... :-)
bye,
-- 
  Piergiorgio Sartor

   Piergiorgio Sartor

 ola
Forse "ksymoops"?
Traduce in maniera leggermente piu` leggibile i
kerne panic et similia.
Dovrebbe essere menzionato anche nei doc del kernel
(bug reporting).
bye,
-- 
  Piergiorgio Sartor

make -j 2 oppure make -j 4
make -j N
si limita ad eseguire N job contemporaneamente, non effettua
ottimizzazioni per il multiprocessore.
il risultato e' il medesimo, semplicemente ti si abbassa il tempo di
compilazione.
es. 
dual pIII 800
make -> circa 5 minuti
make -j 2 -> circa 2 e mezzo
ciao
-- 
Seti@Home Java Applets
http://maruko.cjb.net/