From openmosix@democritos.it Mon Feb 3 07:51:07 2003 From: openmosix@democritos.it (openmosix@democritos.it) Date: Mon, 3 Feb 2003 08:51:07 +0100 Subject: [openMosix-it] info benchmark Message-ID: <20030203075107.GA19907@cuba.no-ip.org> Salve a tutti! Ho realizzato un cluster openMosix con 4 calcolatori: 2 Pentium 200mmx 32MB RAM 1 Pentium 200 48MB RAM 1 Athlon 800 256MB RAM e tutto sembra funzionare... (non elenco i problemi che ho avuto nell'installazione...) comunque, i processi migrano. Siccome devo relazionare per un esame dell'universita' i risultati che ho ottenuto, ho usato il benchmark omtest. Ecco allora il mio problema: come interpreto i risultati del test??? Grazie From openmosix@democritos.it Mon Feb 3 12:30:44 2003 From: openmosix@democritos.it (Premoli, Roberto [IT/0425]) Date: Mon, 3 Feb 2003 06:30:44 -0600 Subject: [openMosix-it] info benchmark Message-ID: Esiste in soft per testare il cluster? dove lo trovo? Anche io ho un cluster e verrei misurarne le effettive prestazioni. Roberto CUT >Siccome devo relazionare per un esame dell'universita' >i risultati che ho ottenuto, ho usato il benchmark omtest. > >Ecco allora il mio problema: come interpreto i risultati del >test??? From openmosix@democritos.it Mon Feb 3 13:46:25 2003 From: openmosix@democritos.it (Premoli, Roberto [IT/0425]) Date: Mon, 3 Feb 2003 08:46:25 -0500 Subject: [openMosix-it] domanda su MFS e complex network Message-ID: A proposito delle due opzioni della patch, [ ] Support clusters with a complex network topology e [ ] openMosix file-system Quando le devo attivare? Cosa si intende per topologia "complessa" ? Ce ne e' un esempio? Per l'openMosix file-system, quando lo devo attivare e perche? Grazie per le risposte. Roberto From openmosix@democritos.it Tue Feb 4 02:42:49 2003 From: openmosix@democritos.it (Moshe Bar) Date: Mon, 3 Feb 2003 18:42:49 -0800 Subject: [openMosix-it] info benchmark In-Reply-To: <20030203075107.GA19907@cuba.no-ip.org> Message-ID: <595EC9F6-37EA-11D7-95D1-000393CE0D6C@moelabs.com> No capisco la domanda. Se ci fai vedere i risultati forse riusciamo a interpretarli, ma senza non e' proprio possibile. Grazie Moshe On Sunday, Feb 2, 2003, at 23:51 US/Pacific, shutdown@cuba.no-ip.org wrote: > Salve a tutti! > > Ho realizzato un cluster openMosix con 4 calcolatori: > > 2 Pentium 200mmx 32MB RAM > 1 Pentium 200 48MB RAM > 1 Athlon 800 256MB RAM > > e tutto sembra funzionare... > (non elenco i problemi che ho avuto nell'installazione...) > > comunque, i processi migrano. > > Siccome devo relazionare per un esame dell'universita' > i risultati che ho ottenuto, ho usato il benchmark omtest. > > Ecco allora il mio problema: come interpreto i risultati del > test??? > > > Grazie > _______________________________________________ > openMosix mailing list > openMosix@democritos.it > http://www.democritos.it/mailman/listinfo/openmosix > From openmosix@democritos.it Tue Feb 4 02:41:27 2003 From: openmosix@democritos.it (Moshe Bar) Date: Mon, 3 Feb 2003 18:41:27 -0800 Subject: [openMosix-it] New Cluster-Mask Feature In-Reply-To: Message-ID: <28DC4FDC-37EA-11D7-95D1-000393CE0D6C@moelabs.com> Hi folks Several people have asked for a feature in openMosix which allows to specifiy to which nodes a given process and it's children can migrate and to which nodes it cannot. Simone Ettore has just committed a new patch to the CVS which allows you to do just that. Here is how ti works: /proc/[pid]/migfilter enable/disable the capability of filter migration. /proc/[pid]/mignodes is a bit-list of nodes. The bit position of a node is calculated as 2^(PE-1). PE is node number. /proc/[pid]/migpolicy is the policy of the filtering: 0=DENY: the process can migrate in all nodes except when the relative bit on mignodes is 1 1=ALLOW: the process can migrate in all nodes where the relative bit on mignodes is 1 We are shortly going to release also a simple user-land tool to set the node mask, but I would like you guys to give it a try asap before we release it as openMosix 2.4.20-3. Kind regards and many thanks to Ettore. Moshe On Monday, Feb 3, 2003, at 07:09 US/Pacific, Paul Millar wrote: > Hi Moshe, > > Sorry for the delay in replying. After installing some more memory on > the > nodes, I started to get some weird errors, random kernel oops, ... > Turns > out some of the memory on one of the nodes was bad (using distcc > for kernel compilation, ouch!) > > So I've run all of memtest86 tests on all nodes and went back and > verify > the previous results, which took a bit of time ... > > On Wed, 22 Jan 2003, Moshe Bar wrote: >> Do you get interrupt overrun messages in your log files? You might >> have >> lost some interrupts and therefor the protocol gets all confused by >> your ifconfig wouldn't show errors just because it doesn't know about >> missed interrupts. > > I don't see any mention of them in the syslog or dmesg. They could be > occurring and just not reported, but that seems unlikely. I've also > tried > 2.4.20-2, but that has the same problems. > > I've started to narrow down the problem. Its occurring in the > deputy_main_loop() (in hpc/deputy.c line 215) because comm_recv() is > failing: > > p->mosix.dflags |= DSYNC; > if(delay_sigs) > evaluate_pending_signals_in_mosix_context(); > if((type = comm_recv(&head, &hlen)) < 0) > deputy_die_on_communication(); > if(type & ANYTIME) > { > if(deputy_handle_interim_request(type, head, > hlen)) > deputy_die_on_communication(); > } > > I haven't found out why comm_recv() is failing, that's next on todo > list. > > Any ideas appreciated :) > > Cheers, > > Paul. > > >> On Wednesday, Jan 22, 2003, at 09:57 US/Eastern, Paul Millar wrote: >> >>> On Tue, 14 Jan 2003, Mirko Caserta wrote: >>>> Try compiling with CONFIG_MOSIX_PIPE_EXCEPTIONS set. It should help. >>>> >>>> Also try a newest kernel (2.4.20) and patch against that, then let >>>> us >>>> know. >>> >>> Ok, I've tried 2.4.19-7 and 2.4.20-1 (both with and without >>> CONFIG_MOSIX_PIPE_EXCEPTIONS set). All combinations have the same >>> problem: OM kills off processes with messages like >>>> Process 24613(make), uid=501, killed because it lost communication >>>> with the remote site where it was running >>> >>>> From watching this happening, subjectively there's a complete loss >>>> of >>> activity; although the kernel seems to be functioning fine. Then, >>> after a >>> short delay (a few minutes) the kernel kills off the process. >>> >>> Its as if the network has dropped a packet. Yet after this happens, >>> ifconfig doesn't report any lost packets on any of the nodes (OM uses >>> TCP >>> though so this shouldn't matter, right?). So I suspect the problem >>> isn't >>> with the network cards or the switch. >>> >>> As no one else is getting this error and the machines are quite slow >>> (1x >>> P-200 & 3x P-166) it looks to me like there's a race-condition within >>> the >>> comms section of OM -- admittedly, I haven't looked at the >>> source-code >>> yet. >>> >>> Does this sound at all likely to anyone? Any ideas how to go about >>> isolating the bug? >>> >>> Cheers, >>> >>> Paul. >>> >>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >>> -- -- -- >>> Particle Physics (Theory & Experimental) Groups Dr >>> Paul >>> Millar >>> Department of Physics and Astronomy >>> paulm@astro.gla.ac.uk >>> University of Glasgow >>> paulm@physics.gla.ac.uk >>> Glasgow, G12 8QQ, Scotland >>> http://www.astro.gla.ac.uk/users/paulm >>> +44 (0)141 330 4717 A54C A9FC 6A77 1664 2E4E 90E3 FFD2 704B >>> BF0F 03E9 >>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >>> -- -- -- >>> >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by: Scholarships for Techies! >>> Can't afford IT training? All 2003 ictp students receive >>> scholarships. >>> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. >>> www.ictp.com/training/sourceforge.asp >>> _______________________________________________ >>> Openmosix-devel mailing list >>> Openmosix-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/openmosix-devel >>> >> >> >> >> ------------------------------------------------------- >> This SF.NET email is sponsored by: >> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! >> http://www.vasoftware.com >> _______________________________________________ >> Openmosix-devel mailing list >> Openmosix-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/openmosix-devel >> >> > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > -- -- -- > Particle Physics (Theory & Experimental) Groups Dr Paul > Millar > Department of Physics and Astronomy > paulm@astro.gla.ac.uk > University of Glasgow > paulm@physics.gla.ac.uk > Glasgow, G12 8QQ, Scotland > http://www.astro.gla.ac.uk/users/paulm > +44 (0)141 330 4717 A54C A9FC 6A77 1664 2E4E 90E3 FFD2 704B > BF0F 03E9 > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > -- -- -- > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Openmosix-devel mailing list > Openmosix-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openmosix-devel > From openmosix@democritos.it Tue Feb 4 14:19:02 2003 From: openmosix@democritos.it (openmosix@democritos.it) Date: Tue, 4 Feb 2003 15:19:02 +0100 Subject: [openMosix-it] info benchmark In-Reply-To: <595EC9F6-37EA-11D7-95D1-000393CE0D6C@moelabs.com> References: <20030203075107.GA19907@cuba.no-ip.org> <595EC9F6-37EA-11D7-95D1-000393CE0D6C@moelabs.com> Message-ID: <20030204141902.GA23007@cuba.no-ip.org> On Mon, Feb 03, 2003 at 06:42:49PM -0800, Moshe Bar wrote: > No capisco la domanda. Se ci fai vedere i risultati forse riusciamo a > interpretarli, ma senza non e' proprio possibile. > > >Siccome devo relazionare per un esame dell'universita' > >i risultati che ho ottenuto, ho usato il benchmark omtest. > > > >Ecco allora il mio problema: come interpreto i risultati del > >test??? > > ormai la relazione l'abbiamo consegnata. per interpretare i dati abbiamo registrato il load average dei nodi durante il test ad intervalli di 10 secondi!!! (il tempo tatale del test e' stato di circa 2 ore!!!!) Ciao From openmosix@democritos.it Tue Feb 4 16:10:25 2003 From: openmosix@democritos.it (openmosix@democritos.it) Date: 4 Feb 2003 16:10:25 -0000 Subject: [openMosix-it] MFS-NFS overload 2 Message-ID: <20030204161025.22552.qmail@mail.supereva.it> Salve a tutti, nel secondo giro di test, relativi all'overload del frontend nel caso di una condivisione MFS su di un mount NFS, si sono verificate delle situazioni molto interessanti, pur persistendo il problema. Il kernel utilizzato rimane il 2.4.20-2 con le patch NFS. Abbiamo notato che, nell'unico nodo in cui un processo sia sopravvissuto, c'era una connessione sulla porta 4660 ESTABLISHED (quella del migration daemon) verso il front-end, anche se il front-end era in "up,stay,lstay,block,quiet", ma non c'era alcuna connessione sulla porta 723 (MFS daemon). Abbiamo provato a togliere lo stato "quiet" in modo tale che il front-end ridistribuisse le informazioni sul suo stato ma la situazione e' rimasta invariata; rimaneva un nodo con la connessione sulla 4660 ESTABLISHED. Togliendo il block dal front-end e riducendo la speed a 3000, per evitare la migrzione di tutti i jobs su tale nodo (preferito dai processi in quanto l'I/O viene eseguito fisicamente li), siamo passati da 10 min. circa a 1 ora circa di elaborazione prima che si verifichi il sovraccarico. Disattivando il servizio nscd e amd abbiamo ottenuto un ulteriore incremento del tempo di elaborazione di poche ore (3 - 4). Data la caduta di alcuni nodi abbiamo deciso di disattivare l'OOM killer cosa che ha avuto un effetto stabilizzante sugli altri nodi del cluster i quali non sono piu "crashati". Disattivando pressoche tutti i servizi, ad eccezione di ypbind e portmap, abbiamo ottenuto un incremento notevole di elaborazione, siamo arrivati a 36 ore di elaborazione, tuttavia non sufficienti. I servizi disabilitati sono: amd nscd pbs_sched (installato ma non ancora usato) pbs_mom (installato ma non ancora usato) gmond (ganglia modificato per rilevare le metriche openmosix da /proc/hpc/nodes/current_node/xxx) gmetad (come sopra) httpd (utilizzato da ganglia per i report) E questo e' cio' che rimane in esecuzione: UID PID PPID C STIME TTY TIME CMD root 1 0 0 Feb01 ? 00:00:10 init [3] root 2 1 0 Feb01 ? 00:00:00 [keventd] root 3 1 0 Feb01 ? 00:00:00 [ksoftirqd_CPU0] root 4 1 0 Feb01 ? 00:00:00 [ksoftirqd_CPU1] root 5 1 0 Feb01 ? 00:00:31 [kswapd] root 6 1 0 Feb01 ? 00:00:00 [bdflush] root 7 1 0 Feb01 ? 00:00:00 [kupdated] root 8 1 0 Feb01 ? 00:00:00 [mdrecoveryd] root 10 1 0 Feb01 ? 00:00:02 [kjournald] root 11 1 0 Feb01 ? 00:00:03 [oMfs_main_serve] root 12 1 0 Feb01 ? 00:00:00 [oM_migd] root 13 1 0 Feb01 ? 00:00:00 [oMFS_gc] root 14 1 0 Feb01 ? 00:00:07 [oM_infoD] root 15 1 0 Feb01 ? 00:00:05 [memsorter] root 93 1 0 Feb01 ? 00:00:00 [khubd] root 172 1 0 Feb01 ? 00:00:01 [kjournald] root 606 1 0 Feb01 ? 00:00:00 syslogd -m 0 root 611 1 0 Feb01 ? 00:00:00 klogd -2 rpc 631 1 0 Feb01 ? 00:00:00 portmap root 759 1 0 Feb01 ? 00:00:00 ypbind root 761 759 0 Feb01 ? 00:00:00 ypbind root 762 761 0 Feb01 ? 00:00:00 ypbind root 763 761 0 Feb01 ? 00:00:00 ypbind root 957 1 0 Feb01 tty2 00:00:00 /sbin/mingetty tty2 root 958 1 0 Feb01 tty3 00:00:00 /sbin/mingetty tty3 root 959 1 0 Feb01 tty4 00:00:00 /sbin/mingetty tty4 root 960 1 0 Feb01 tty5 00:00:00 /sbin/mingetty tty5 root 961 1 0 Feb01 tty6 00:00:00 /sbin/mingetty tty6 root 1006 1 0 Feb01 tty1 00:00:00 /sbin/mingetty tty1 root 1007 812 0 Feb01 ? 00:00:00 /usr/sbin/sshd root 1010 1007 0 Feb01 pts/0 00:00:00 -bash root 1051 1 0 Feb01 ? 00:00:00 ssh-agent root 1258 1 0 Feb01 ? 00:00:36 [rpciod] root 1259 1 0 Feb01 ? 00:00:00 [lockd] grass 6943 1 0 01:35 ? 00:00:00 ssh-agent grass 19656 1 5 04:37 ? 00:00:13 [mfs_server] grass 19696 1 5 04:37 ? 00:00:13 [mfs_server] grass 19717 1 5 04:37 ? 00:00:13 [mfs_server] grass 19718 1 5 04:37 ? 00:00:13 [mfs_server] grass 19720 1 5 04:39 ? 00:00:08 [mfs_server] Un altro problema che abbiamo visto riguarda la copia di file di piccole dimensioni (0-400 byte circa) da un disco locale ad uno share NFS passando per MFS: il file sullo share NFS viene creato vuoto. Con uno strace del cp si vede che la write ha successo e ritorna correttamente in numero di byte "scritti" ma la scrittura non avviene fisicamente. La scrittura diretta su NFS funziona perfettamente. Suggerimenti ?? Grazie Soraruf Alessandro ----------------------------------------------------- Invia un sms gratis! http://freesms.supereva.it/index.php messaggio inviato con Freemail by www.superEva.it ----------------------------------------------------- From openmosix@democritos.it Tue Feb 4 19:01:14 2003 From: openmosix@democritos.it (Ettore Simone) Date: 04 Feb 2003 20:01:14 +0100 Subject: [openMosix-it] New Cluster-Mask Feature In-Reply-To: <28DC4FDC-37EA-11D7-95D1-000393CE0D6C@moelabs.com> References: <28DC4FDC-37EA-11D7-95D1-000393CE0D6C@moelabs.com> Message-ID: <1044385273.16508.15.camel@miu.esimone.suse.it> Sorry Moshe, I'm not able to update CVS till now. On commit I get no permission to write. Ettore On Tue, 2003-02-04 at 03:41, Moshe Bar wrote: > Hi folks > > Several people have asked for a feature in openMosix which allows to > specifiy to which nodes a given process and it's children can migrate > and to which nodes it cannot. > > Simone Ettore has just committed a new patch to the CVS which allows > you to do just that. > > Here is how ti works: > > /proc/[pid]/migfilter enable/disable the capability of filter migration. > /proc/[pid]/mignodes is a bit-list of nodes. The bit position of a node > is calculated as 2^(PE-1). PE is node number. > /proc/[pid]/migpolicy is the policy of the filtering: > 0=DENY: the process can migrate in all nodes except when the relative > bit on mignodes is 1 > 1=ALLOW: the process can migrate in all nodes where the relative bit on > mignodes is 1 > > We are shortly going to release also a simple user-land tool to set the > node mask, but I would like you guys to give it a try asap before we > release it as openMosix 2.4.20-3. > > Kind regards and many thanks to Ettore. > > Moshe -- Ettore Simone Responsabile supporto tecnico SuSE Linux srl Via Montanara, 26 41051 Castelnuovo R. (MO) Tel. +39 059 5395 11 Fax +39 059 5332009 From openmosix@democritos.it Tue Feb 4 19:40:17 2003 From: openmosix@democritos.it (Moshe Bar) Date: Tue, 4 Feb 2003 11:40:17 -0800 Subject: [openMosix-it] New Cluster-Mask Feature In-Reply-To: <1044385273.16508.15.camel@miu.esimone.suse.it> Message-ID: <7D1691D1-3878-11D7-95D1-000393CE0D6C@moelabs.com> metto a posto e ti informo Moshe On Tuesday, Feb 4, 2003, at 11:01 US/Pacific, Ettore Simone wrote: > Sorry Moshe, > I'm not able to update CVS till now. On commit I get no permission to > write. > > Ettore > > On Tue, 2003-02-04 at 03:41, Moshe Bar wrote: >> Hi folks >> >> Several people have asked for a feature in openMosix which allows to >> specifiy to which nodes a given process and it's children can migrate >> and to which nodes it cannot. >> >> Simone Ettore has just committed a new patch to the CVS which allows >> you to do just that. >> >> Here is how ti works: >> >> /proc/[pid]/migfilter enable/disable the capability of filter >> migration. >> /proc/[pid]/mignodes is a bit-list of nodes. The bit position of a >> node >> is calculated as 2^(PE-1). PE is node number. >> /proc/[pid]/migpolicy is the policy of the filtering: >> 0=DENY: the process can migrate in all nodes except when the relative >> bit on mignodes is 1 >> 1=ALLOW: the process can migrate in all nodes where the relative bit >> on >> mignodes is 1 >> >> We are shortly going to release also a simple user-land tool to set >> the >> node mask, but I would like you guys to give it a try asap before we >> release it as openMosix 2.4.20-3. >> >> Kind regards and many thanks to Ettore. >> >> Moshe > > -- > Ettore Simone > Responsabile supporto tecnico > > SuSE Linux srl > Via Montanara, 26 > 41051 Castelnuovo R. (MO) > > Tel. +39 059 5395 11 > Fax +39 059 5332009 > _______________________________________________ > openMosix mailing list > openMosix@democritos.it > http://www.democritos.it/mailman/listinfo/openmosix > From openmosix@democritos.it Tue Feb 4 22:20:28 2003 From: openmosix@democritos.it (Moshe Bar) Date: Tue, 4 Feb 2003 14:20:28 -0800 Subject: [openMosix-it] MFS-NFS overload 2 In-Reply-To: <20030204161025.22552.qmail@mail.supereva.it> Message-ID: Interessante. Controllo un po' di cose e ti faccio sapere. Moshe On Tuesday, Feb 4, 2003, at 08:10 US/Pacific, asoraruf@supereva.it wrote: > > Salve a tutti, > > nel secondo giro di test, relativi all'overload del frontend nel caso > di una condivisione MFS su di un mount NFS, si sono verificate delle > situazioni molto interessanti, pur persistendo il problema. > Il kernel utilizzato rimane il 2.4.20-2 con le patch NFS. > Abbiamo notato che, nell'unico nodo in cui un processo sia > sopravvissuto, c'era una connessione sulla porta 4660 ESTABLISHED > (quella del migration daemon) verso il front-end, anche se il > front-end era in "up,stay,lstay,block,quiet", ma non c'era alcuna > connessione sulla porta 723 (MFS daemon). > Abbiamo provato a togliere lo stato "quiet" in modo tale che il > front-end ridistribuisse le informazioni sul suo stato ma la > situazione e' rimasta invariata; rimaneva un nodo con la connessione > sulla 4660 ESTABLISHED. > Togliendo il block dal front-end e riducendo la speed a 3000, per > evitare la migrzione di tutti i jobs su tale nodo (preferito dai > processi in quanto l'I/O viene eseguito fisicamente li), siamo passati > da 10 min. circa a 1 ora circa di elaborazione prima che si verifichi > il sovraccarico. > Disattivando il servizio nscd e amd abbiamo ottenuto un ulteriore > incremento del tempo di elaborazione di poche ore (3 - 4). > Data la caduta di alcuni nodi abbiamo deciso di disattivare l'OOM > killer cosa che ha avuto un effetto stabilizzante sugli altri nodi del > cluster i quali non sono piu "crashati". > Disattivando pressoche tutti i servizi, ad eccezione di ypbind e > portmap, abbiamo ottenuto un incremento notevole di elaborazione, > siamo arrivati a 36 ore di elaborazione, tuttavia non sufficienti. > I servizi disabilitati sono: > > amd > nscd > pbs_sched (installato ma non ancora usato) > pbs_mom (installato ma non ancora usato) > gmond (ganglia modificato per rilevare le metriche openmosix da > /proc/hpc/nodes/current_node/xxx) > gmetad (come sopra) > httpd (utilizzato da ganglia per i report) > > E questo e' cio' che rimane in esecuzione: > > UID PID PPID C STIME TTY TIME CMD > root 1 0 0 Feb01 ? 00:00:10 init [3] > root 2 1 0 Feb01 ? 00:00:00 [keventd] > root 3 1 0 Feb01 ? 00:00:00 [ksoftirqd_CPU0] > root 4 1 0 Feb01 ? 00:00:00 [ksoftirqd_CPU1] > root 5 1 0 Feb01 ? 00:00:31 [kswapd] > root 6 1 0 Feb01 ? 00:00:00 [bdflush] > root 7 1 0 Feb01 ? 00:00:00 [kupdated] > root 8 1 0 Feb01 ? 00:00:00 [mdrecoveryd] > root 10 1 0 Feb01 ? 00:00:02 [kjournald] > root 11 1 0 Feb01 ? 00:00:03 [oMfs_main_serve] > root 12 1 0 Feb01 ? 00:00:00 [oM_migd] > root 13 1 0 Feb01 ? 00:00:00 [oMFS_gc] > root 14 1 0 Feb01 ? 00:00:07 [oM_infoD] > root 15 1 0 Feb01 ? 00:00:05 [memsorter] > root 93 1 0 Feb01 ? 00:00:00 [khubd] > root 172 1 0 Feb01 ? 00:00:01 [kjournald] > root 606 1 0 Feb01 ? 00:00:00 syslogd -m 0 > root 611 1 0 Feb01 ? 00:00:00 klogd -2 > rpc 631 1 0 Feb01 ? 00:00:00 portmap > root 759 1 0 Feb01 ? 00:00:00 ypbind > root 761 759 0 Feb01 ? 00:00:00 ypbind > root 762 761 0 Feb01 ? 00:00:00 ypbind > root 763 761 0 Feb01 ? 00:00:00 ypbind > root 957 1 0 Feb01 tty2 00:00:00 /sbin/mingetty tty2 > root 958 1 0 Feb01 tty3 00:00:00 /sbin/mingetty tty3 > root 959 1 0 Feb01 tty4 00:00:00 /sbin/mingetty tty4 > root 960 1 0 Feb01 tty5 00:00:00 /sbin/mingetty tty5 > root 961 1 0 Feb01 tty6 00:00:00 /sbin/mingetty tty6 > root 1006 1 0 Feb01 tty1 00:00:00 /sbin/mingetty tty1 > root 1007 812 0 Feb01 ? 00:00:00 /usr/sbin/sshd > root 1010 1007 0 Feb01 pts/0 00:00:00 -bash > root 1051 1 0 Feb01 ? 00:00:00 ssh-agent > root 1258 1 0 Feb01 ? 00:00:36 [rpciod] > root 1259 1 0 Feb01 ? 00:00:00 [lockd] > grass 6943 1 0 01:35 ? 00:00:00 ssh-agent > grass 19656 1 5 04:37 ? 00:00:13 [mfs_server] > grass 19696 1 5 04:37 ? 00:00:13 [mfs_server] > grass 19717 1 5 04:37 ? 00:00:13 [mfs_server] > grass 19718 1 5 04:37 ? 00:00:13 [mfs_server] > grass 19720 1 5 04:39 ? 00:00:08 [mfs_server] > > Un altro problema che abbiamo visto riguarda la copia di file di > piccole dimensioni (0-400 byte circa) da un disco locale ad uno share > NFS passando per MFS: il file sullo share NFS viene creato vuoto. > Con uno strace del cp si vede che la write ha successo e ritorna > correttamente in numero di byte "scritti" ma la scrittura non avviene > fisicamente. > La scrittura diretta su NFS funziona perfettamente. > > Suggerimenti ?? > > Grazie > Soraruf Alessandro > > > ----------------------------------------------------- > Invia un sms gratis! > http://freesms.supereva.it/index.php > > messaggio inviato con Freemail by www.superEva.it > ----------------------------------------------------- > > _______________________________________________ > openMosix mailing list > openMosix@democritos.it > http://www.democritos.it/mailman/listinfo/openmosix > From openmosix@democritos.it Mon Feb 10 14:37:42 2003 From: openmosix@democritos.it (Premoli, Roberto [IT/0425]) Date: Mon, 10 Feb 2003 08:37:42 -0600 Subject: [openMosix-it] spazio su disco fittizio Message-ID: Ho due nodi con kernel 2.4.20 e relativa patch openMosix. Nel file /etc/default/openmosix, to impostato MFS=yes, quindi da un nodo vedo il disco dell'altro nodo e viceversa. Ora, se su un nodo do il comando df -h la risposta che ottengo e': Filesystem Size Used Avail use% Mounted on /dev/hda2 1.8G 318M 1.4G 18$ / /mfs 1.3T 0 953G 0% /mfs caspita! in /mfs ci sono 1.3T totali di cui disponibili 953Giga! Tutto cio sarebbe molto bello se fosse vero. Pero' io ho due nodi, uno con un disco ca 11G e l'altro con un disco da 2G.... Allora, dov'e' il trucco? Perche' oM mi dice che ce' dello spazio in realta' inesistente? Roberto From openmosix@democritos.it Mon Feb 10 15:06:07 2003 From: openmosix@democritos.it (Moshe Bar) Date: Mon, 10 Feb 2003 07:06:07 -0800 Subject: [openMosix-it] spazio su disco fittizio In-Reply-To: Message-ID: <2E8241A3-3D09-11D7-990A-000393CE0D6C@moelabs.com> Quando ho implementato la system call "statfs" qualche mese fa per oMFS non c'era modo di avere un dato affidabile nel cluster dei blocchi disponibili su un disco remoto. Ho quindi messo una long var = 99999999999; che risulta nei 1.3Tera che vedi. M On Monday, Feb 10, 2003, at 06:37 US/Pacific, Premoli, Roberto [IT/0425] wrote: > Ho due nodi con kernel 2.4.20 e relativa patch openMosix. > Nel file /etc/default/openmosix, to impostato MFS=yes, > quindi da un nodo vedo il disco dell'altro nodo e viceversa. > Ora, se su un nodo do il comando > > df -h > > la risposta che ottengo e': > > Filesystem Size Used Avail use% Mounted on > /dev/hda2 1.8G 318M 1.4G 18$ / > /mfs 1.3T 0 953G 0% /mfs > > caspita! > in /mfs ci sono 1.3T totali di cui disponibili 953Giga! > > Tutto cio sarebbe molto bello se fosse vero. > Pero' io ho due nodi, uno con un disco ca 11G e l'altro > con un disco da 2G.... > Allora, dov'e' il trucco? > Perche' oM mi dice che ce' dello spazio in realta' inesistente? > Roberto > _______________________________________________ > openMosix mailing list > openMosix@democritos.it > http://www.democritos.it/mailman/listinfo/openmosix > From openmosix@democritos.it Mon Feb 10 15:18:52 2003 From: openmosix@democritos.it (openmosix@democritos.it) Date: 10 Feb 2003 15:18:52 -0000 Subject: [openMosix-it] MFS overload Message-ID: <20030210151852.3170.qmail@mail.supereva.it> Salve a tutti, grazie all'ultima serie di esperimenti lanciati sul cluster openmosix ci siamo accorti che l'overload del front-end non e' dovuto all'utilizzo di MFS su di un mount NFS ma bensi all'MFS stesso. Percio mi scuso per le informazioni imprecise. In generale, abbiamo notato che l'MFS server non riesce a gestire 30-40 file aperti in lettura contemporaneamente. I nostri processi leggono una matrice da file (attraverso MFS) e la ricreano in memoria per poi elaborarla, scrivono su file i risultati ed inoltre hanno lo stdout e lo stderr rediretti su file sempre passando per MFS(data la bassa frequenza di scrittura quest'ultimi non hanno mai dato problemi). Lanciando i 50 processi, con un intervallo abbastanza breve tra l'uno e l'altro, in modo tale che nessun processo abbia finito di leggere la matrice da file mentre il successivo inizia la lettura, il front-end va in crash con solo 36 processi. I nostri jobs, come sempre, sono stati lanciati in round robin su tutte le macchine del cluster usando l'ssh. La soluzione temporanea e' stata quella di inserire un intervallo maggiore (15 sec) tra lo start di un processo e l'atro, in modo che non ci fossero piu di 15-30 processi contemporaneamente in lettura. Questa soluzione non e' pero applicabile ai processi di grass, che come avevo descritto nelle mail precedenti, leggono le mappe passo passo durante tutto il tempo di elaborazione, quindi per tali processi l'MFS risulta inutilizzabile. Un possibile soluzione e' quella di condividere le mappe, su tutti i nodi, attraverso NFS e di accedervi attraverso /mfs/home/nfsmount/ in modo tale da permettere il DFSA ai processi migrati, dato che l'NFS non risulta essere DFSA compliant. Questa soluzione pero' ha il problema dei file di piccole dimensioni descritto nella mail precedente. Nota: in alcuni test la copia dei file di di piccole dimensioni e' riuscita, ma non siamo ancora riusciti a scoprire: a) la situazione per cui questa avviene con successo b) la dimensione "minima dei file" Suggerimenti? Grazie Soraruf Alessandro ----------------------------------------------------- Invia un sms gratis! http://freesms.supereva.it/index.php messaggio inviato con Freemail by www.superEva.it ----------------------------------------------------- From openmosix@democritos.it Mon Feb 10 16:04:13 2003 From: openmosix@democritos.it (Premoli, Roberto [IT/0425]) Date: Mon, 10 Feb 2003 11:04:13 -0500 Subject: [openMosix-it] spazio su disco fittizio Message-ID: ok. Si tratta di un dato fittizio, bene. Ora, questa cosa e' "under construction" cioe' ci state lavorando per implementare un dato "vero" o ce la terremo cosi' come e'? grazie, Ciao PS: A proposito del "santo graal" (migrazione processi a memoria condivisa) Come siete messi? hai delle novita' in proposito? -----Original Message----- From: Moshe Bar [mailto:moshe@moelabs.com] Sent: Monday, February 10, 2003 4:06 PM To: openmosix@democritos.it Subject: Re: [openMosix-it] spazio su disco fittizio Quando ho implementato la system call "statfs" qualche mese fa per oMFS non c'era modo di avere un dato affidabile nel cluster dei blocchi disponibili su un disco remoto. Ho quindi messo una long var = 99999999999; che risulta nei 1.3Tera che vedi. M From openmosix@democritos.it Fri Feb 14 16:50:33 2003 From: openmosix@democritos.it (Ettore Simone) Date: 14 Feb 2003 17:50:33 +0100 Subject: [openMosix-it] New Cluster-Mask Feature In-Reply-To: <7D1691D1-3878-11D7-95D1-000393CE0D6C@moelabs.com> References: <7D1691D1-3878-11D7-95D1-000393CE0D6C@moelabs.com> Message-ID: <1045241433.2512.28.camel@miu.esimone.suse.it> Ok, tutto on-line. :) Bye. On Tue, 2003-02-04 at 20:40, Moshe Bar wrote: > metto a posto e ti informo > > Moshe > > > On Tuesday, Feb 4, 2003, at 11:01 US/Pacific, Ettore Simone wrote: > > > Sorry Moshe, > > I'm not able to update CVS till now. On commit I get no permission to > > write. > > > > Ettore > > > > On Tue, 2003-02-04 at 03:41, Moshe Bar wrote: > >> Hi folks > >> > >> Several people have asked for a feature in openMosix which allows to > >> specifiy to which nodes a given process and it's children can migrate > >> and to which nodes it cannot. > >> > >> Simone Ettore has just committed a new patch to the CVS which allows > >> you to do just that. > >> > >> Here is how ti works: > >> > >> /proc/[pid]/migfilter enable/disable the capability of filter > >> migration. > >> /proc/[pid]/mignodes is a bit-list of nodes. The bit position of a > >> node > >> is calculated as 2^(PE-1). PE is node number. > >> /proc/[pid]/migpolicy is the policy of the filtering: > >> 0=DENY: the process can migrate in all nodes except when the relative > >> bit on mignodes is 1 > >> 1=ALLOW: the process can migrate in all nodes where the relative bit > >> on > >> mignodes is 1 > >> > >> We are shortly going to release also a simple user-land tool to set > >> the > >> node mask, but I would like you guys to give it a try asap before we > >> release it as openMosix 2.4.20-3. > >> > >> Kind regards and many thanks to Ettore. > >> > >> Moshe > > > > -- > > Ettore Simone > > Responsabile supporto tecnico > > > > SuSE Linux srl > > Via Montanara, 26 > > 41051 Castelnuovo R. (MO) > > > > Tel. +39 059 5395 11 > > Fax +39 059 5332009 > > _______________________________________________ > > openMosix mailing list > > openMosix@democritos.it > > http://www.democritos.it/mailman/listinfo/openmosix > > > > _______________________________________________ > openMosix mailing list > openMosix@democritos.it > http://www.democritos.it/mailman/listinfo/openmosix -- Ettore Simone Responsabile supporto tecnico SuSE Linux srl Via Montanara, 26 41051 Castelnuovo R. (MO) Tel. +39 059 5395 11 Fax +39 059 5332009 From openmosix@democritos.it Fri Feb 14 16:50:27 2003 From: openmosix@democritos.it (Moshe Bar) Date: Fri, 14 Feb 2003 08:50:27 -0800 Subject: [openMosix-it] New Cluster-Mask Feature In-Reply-To: <1045241433.2512.28.camel@miu.esimone.suse.it> Message-ID: <6B907339-403C-11D7-990A-000393CE0D6C@moelabs.com> grazie!! M On Friday, Feb 14, 2003, at 08:50 US/Pacific, Ettore Simone wrote: > Ok, tutto on-line. :) > > Bye. > > On Tue, 2003-02-04 at 20:40, Moshe Bar wrote: >> metto a posto e ti informo >> >> Moshe >> >> >> On Tuesday, Feb 4, 2003, at 11:01 US/Pacific, Ettore Simone wrote: >> >>> Sorry Moshe, >>> I'm not able to update CVS till now. On commit I get no permission to >>> write. >>> >>> Ettore >>> >>> On Tue, 2003-02-04 at 03:41, Moshe Bar wrote: >>>> Hi folks >>>> >>>> Several people have asked for a feature in openMosix which allows to >>>> specifiy to which nodes a given process and it's children can >>>> migrate >>>> and to which nodes it cannot. >>>> >>>> Simone Ettore has just committed a new patch to the CVS which allows >>>> you to do just that. >>>> >>>> Here is how ti works: >>>> >>>> /proc/[pid]/migfilter enable/disable the capability of filter >>>> migration. >>>> /proc/[pid]/mignodes is a bit-list of nodes. The bit position of a >>>> node >>>> is calculated as 2^(PE-1). PE is node number. >>>> /proc/[pid]/migpolicy is the policy of the filtering: >>>> 0=DENY: the process can migrate in all nodes except when the >>>> relative >>>> bit on mignodes is 1 >>>> 1=ALLOW: the process can migrate in all nodes where the relative bit >>>> on >>>> mignodes is 1 >>>> >>>> We are shortly going to release also a simple user-land tool to set >>>> the >>>> node mask, but I would like you guys to give it a try asap before we >>>> release it as openMosix 2.4.20-3. >>>> >>>> Kind regards and many thanks to Ettore. >>>> >>>> Moshe >>> >>> -- >>> Ettore Simone >>> Responsabile supporto tecnico >>> >>> SuSE Linux srl >>> Via Montanara, 26 >>> 41051 Castelnuovo R. (MO) >>> >>> Tel. +39 059 5395 11 >>> Fax +39 059 5332009 >>> _______________________________________________ >>> openMosix mailing list >>> openMosix@democritos.it >>> http://www.democritos.it/mailman/listinfo/openmosix >>> >> >> _______________________________________________ >> openMosix mailing list >> openMosix@democritos.it >> http://www.democritos.it/mailman/listinfo/openmosix > -- > Ettore Simone > Responsabile supporto tecnico > > SuSE Linux srl > Via Montanara, 26 > 41051 Castelnuovo R. (MO) > > Tel. +39 059 5395 11 > Fax +39 059 5332009 > _______________________________________________ > openMosix mailing list > openMosix@democritos.it > http://www.democritos.it/mailman/listinfo/openmosix > From openmosix@democritos.it Mon Feb 17 09:40:57 2003 From: openmosix@democritos.it (Premoli, Roberto [IT/0425]) Date: Mon, 17 Feb 2003 04:40:57 -0500 Subject: [openMosix-it] Differenze Mosix-openMosix Message-ID: Ieri ho dato una occhiata al sito di Mosix. Non mi e' sembrato di scorgere differenze sostanziali dal punto di vista tecnico-prestazionale (correggetemi se sbaglio). Vorrei sapere se la principale differenza e' incentrata sul differente tipo di licenza (GPL o no) sotto il quale i due sistemi vengono sviluppati. Grazie, Roberto From openmosix@democritos.it Mon Feb 17 10:48:59 2003 From: openmosix@democritos.it (Alberto Brosich) Date: Mon, 17 Feb 2003 11:48:59 +0100 Subject: [openMosix-it] Testing Openmosix & LTSP con setiathome. Message-ID: <1045478939.3e50be1b92ade@webmail.units.it> Stiamo testando openmosix (2.4.20-1) su PC in configurazione thin-client (LTSP - www.ltsp.org). Abbiamo riscontrato un numero notevole di migrazioni dei processi. Piu` in dettaglio con 12 processi di setiathome su 16 macchine in circa 35 h abbiamo avuto 20 migrazioni/h in media per processo (11 mig/h min - 27 mig/h max) e in totale dalle 800 alle 950 migrazioni per nodo. Tutte le macchine, ovviamente, erano completamente dedicate al test. Visualizzando i processi su homenode solo pochi (3-4) risultavano con piu` del 90% di cpu mentre gli altri non arrivavano al 5%. E` normale? E` un problema di tuning e/o configurazione? Segue un dettaglio della configurazione. 1 x PIII 450MHz (speed 4500) (homenode) thin-client 6 x PIII 500 (speed 5000) 8 x PIII 600 (speed 6000) 1 x PIII 750 (speed 7500) Tutti i nodi sono collegati al medesimo switch (3com 4400) 100 Mbit/s. Non utilizziamo l'auto-discovery. Utilizziamo mfs. Segue la configurazione del kernel CONFIG_MOSIX=y CONFIG_MOSIX_TOPOLOGY=y CONFIG_MOSIX_MAXTOPOLOGY=4 CONFIG_MOSIX_SECUREPORTS=y CONFIG_MOSIX_DISCLOSURE=1 CONFIG_MOSIX_FS=y CONFIG_MOSIX_DFSA=y CONFIG_MOSIX_PIPE_EXCEPTIONS=y # CONFIG_openMosix_NO_OOM is not set Grazie in anticipo Alberto Brosich Stefano Catani From openmosix@democritos.it Mon Feb 17 15:09:38 2003 From: openmosix@democritos.it (Moshe Bar) Date: Mon, 17 Feb 2003 07:09:38 -0800 Subject: [openMosix-it] Differenze Mosix-openMosix In-Reply-To: Message-ID: all'inizio di openMosix (versione 2.4.13) non c'era nessuna differenza fra Mosix e openMosix, tranne una mare di differenza nella licenza e nel modo di condurre il progetto. In Mosix (ancora oggi) delle persone vengono cacciate dalla mailing list per avere chiesto domande scomode. Oggi invece ci sono tantissime differenze. Per elencarne alcune: 1. abbiamo una DSM per openMosix che sara' rilasciata a breve 2. Abbiamo un integrazione con openAFS 3. Abbiamo un porting a IA64 e presto a AMD-64 4. oMFS e' stato migliorato di parecchio 5. openMosix e' effettivamente una piattaforma di clustering con piu' di 10 prodotti che si basano su di esso (openMosixView, RxLinux, K12LTSP, LTSP e tanti altri) 6. openMosix e' un prodotto sviluppato dagli stessi utilizzatori. Per definizione e' piu' vicino all'utente 7. C'e' un user group italiano. Una mailing lista in italiano :-) 8. Ci sono persone com Davini, Cozzini, Caserta, UniPisa, Cineca, e tante altre in Italia che si basano su openMosix 9. openMosix e' vivo. MOSIX sta morendo velocemente. Moshe On Monday, Feb 17, 2003, at 01:40 US/Pacific, Premoli, Roberto [IT/0425] wrote: > Ieri ho dato una occhiata al sito di Mosix. > > Non mi e' sembrato di scorgere differenze sostanziali > dal punto di vista tecnico-prestazionale (correggetemi se sbaglio). > > Vorrei sapere se la principale differenza e' incentrata sul differente > tipo di licenza (GPL o no) sotto il quale i due sistemi vengono > sviluppati. > Grazie, > Roberto > _______________________________________________ > openMosix mailing list > openMosix@democritos.it > http://www.democritos.it/mailman/listinfo/openmosix > From openmosix@democritos.it Mon Feb 17 15:12:05 2003 From: openmosix@democritos.it (Moshe Bar) Date: Mon, 17 Feb 2003 07:12:05 -0800 Subject: [openMosix-it] Testing Openmosix & LTSP con setiathome. In-Reply-To: <1045478939.3e50be1b92ade@webmail.units.it> Message-ID: <2CD41237-428A-11D7-801B-000393CE0D6C@moelabs.com> I processi migrano perche' nella fase computazionale vanno verso nodi piu' veloci mentre nella fase di I/O ritornano a casa. Se usi oMFS con DFSA dovresti potere evitare le migrazioni. Un altro modo e di settare la velocita' dei nodi sinteticamente con mosctl setspeed Moshe On Monday, Feb 17, 2003, at 02:48 US/Pacific, Alberto Brosich wrote: > > Stiamo testando openmosix (2.4.20-1) su PC in configurazione > thin-client (LTSP - > www.ltsp.org). Abbiamo riscontrato un numero notevole di migrazioni > dei processi. > Piu` in dettaglio con 12 processi di setiathome su 16 macchine in > circa 35 h > abbiamo avuto > 20 migrazioni/h in media per processo (11 mig/h min - 27 mig/h max) e > in totale > dalle 800 alle 950 migrazioni per nodo. > Tutte le macchine, ovviamente, erano completamente dedicate al test. > Visualizzando i processi su homenode solo pochi (3-4) risultavano con > piu` del > 90% di cpu mentre gli altri non arrivavano al 5%. > > E` normale? E` un problema di tuning e/o configurazione? > > Segue un dettaglio della configurazione. > > 1 x PIII 450MHz (speed 4500) (homenode) > > thin-client > 6 x PIII 500 (speed 5000) > 8 x PIII 600 (speed 6000) > 1 x PIII 750 (speed 7500) > > Tutti i nodi sono collegati al medesimo switch (3com 4400) 100 Mbit/s. > Non utilizziamo l'auto-discovery. > Utilizziamo mfs. > Segue la configurazione del kernel > > CONFIG_MOSIX=y > CONFIG_MOSIX_TOPOLOGY=y > CONFIG_MOSIX_MAXTOPOLOGY=4 > CONFIG_MOSIX_SECUREPORTS=y > CONFIG_MOSIX_DISCLOSURE=1 > CONFIG_MOSIX_FS=y > CONFIG_MOSIX_DFSA=y > CONFIG_MOSIX_PIPE_EXCEPTIONS=y > # CONFIG_openMosix_NO_OOM is not set > > Grazie in anticipo > > Alberto Brosich > Stefano Catani > _______________________________________________ > openMosix mailing list > openMosix@democritos.it > http://www.democritos.it/mailman/listinfo/openmosix > From openmosix@democritos.it Wed Feb 19 11:25:24 2003 From: openmosix@democritos.it (Premoli, Roberto [IT/0425]) Date: Wed, 19 Feb 2003 05:25:24 -0600 Subject: [openMosix-it] Presentazione openMosix Message-ID: Siccome ho realizzato un cluster con oM, mi e' stato chiesto di realizzare un talk introduttivo sull'argomento. Io ho realizzato una dozzina di slide di presentazione con (scusate) Microsoft Powerpoint. Siccome pero' ho paura di avere scritto cose non esatte, c'e' un volontario che gli darebbe una guardata? Grazie. Roberto From openmosix@democritos.it Wed Feb 19 11:27:14 2003 From: openmosix@democritos.it (Moshe Bar) Date: Wed, 19 Feb 2003 03:27:14 -0800 Subject: [openMosix-it] Presentazione openMosix In-Reply-To: Message-ID: <1871A093-43FD-11D7-AF29-000393CE0D6C@moelabs.com> manda pure a me. Moshe On Wednesday, Feb 19, 2003, at 03:25 US/Pacific, Premoli, Roberto [IT/0425] wrote: > Siccome ho realizzato un cluster con oM, > mi e' stato chiesto di realizzare un talk introduttivo sull'argomento. > Io ho realizzato una dozzina di slide di presentazione con (scusate) > Microsoft Powerpoint. > > Siccome pero' ho paura di avere scritto cose non esatte, c'e' un > volontario > che gli darebbe una guardata? > Grazie. > Roberto > _______________________________________________ > openMosix mailing list > openMosix@democritos.it > http://www.democritos.it/mailman/listinfo/openmosix > From openmosix@democritos.it Wed Feb 19 17:14:06 2003 From: openmosix@democritos.it (Valperix) Date: Wed, 19 Feb 2003 18:14:06 +0100 Subject: [openMosix-it] Presentazione openMosix References: <1871A093-43FD-11D7-AF29-000393CE0D6C@moelabs.com> Message-ID: <001201c2d83a$4fc839a0$0300a8c0@pc1> Moshe sei sempre piu' grande. ciao. > manda pure a me. > > Moshe From openmosix@democritos.it Wed Feb 19 17:15:23 2003 From: openmosix@democritos.it (Valperix) Date: Wed, 19 Feb 2003 18:15:23 +0100 Subject: [openMosix-it] x Moshe Message-ID: <002901c2d83a$7fdb5aa0$0300a8c0@pc1> This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C2D842.DE609D30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable distributed shared memory tienici informati, 8-)) ------=_NextPart_000_0026_01C2D842.DE609D30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
distributed shared memory
 
tienici informati, = 8-))
------=_NextPart_000_0026_01C2D842.DE609D30-- From openmosix@democritos.it Wed Feb 19 17:17:34 2003 From: openmosix@democritos.it (Moshe Bar) Date: Wed, 19 Feb 2003 09:17:34 -0800 Subject: [openMosix-it] Presentazione openMosix In-Reply-To: <001201c2d83a$4fc839a0$0300a8c0@pc1> Message-ID: <093B761D-442E-11D7-AF29-000393CE0D6C@moelabs.com> non esageriamo. :-) M On Wednesday, Feb 19, 2003, at 09:14 US/Pacific, Valperix wrote: > Moshe sei sempre piu' grande. > ciao. > > >> manda pure a me. >> >> Moshe > > > > _______________________________________________ > openMosix mailing list > openMosix@democritos.it > http://www.democritos.it/mailman/listinfo/openmosix > From openmosix@democritos.it Wed Feb 19 17:30:09 2003 From: openmosix@democritos.it (Moshe Bar) Date: Wed, 19 Feb 2003 09:30:09 -0800 Subject: [openMosix-it] x Moshe In-Reply-To: <002901c2d83a$7fdb5aa0$0300a8c0@pc1> Message-ID: --Apple-Mail-6-796616682 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; format=flowed sara' rilasciata una prima versione di sviluppo (pre-alpha) entro fine=20= marzo. M On Wednesday, Feb 19, 2003, at 09:15 US/Pacific, Valperix wrote: > distributed shared memory > =A0 > tienici informati, 8-)) --Apple-Mail-6-796616682 Content-Transfer-Encoding: quoted-printable Content-Type: text/enriched; charset=ISO-8859-1 sara' rilasciata una prima versione di sviluppo (pre-alpha) entro fine marzo. M On Wednesday, Feb 19, 2003, at 09:15 US/Pacific, Valperix wrote: distributed shared memory =A0 Arialtienici informati, = 8-)) = --Apple-Mail-6-796616682-- From openmosix@democritos.it Wed Feb 19 17:31:32 2003 From: openmosix@democritos.it (Premoli, Roberto [IT/0425]) Date: Wed, 19 Feb 2003 11:31:32 -0600 Subject: [openMosix-it] x Moshe Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D83C.9D457A2E" ------_=_NextPart_001_01C2D83C.9D457A2E Content-Type: text/plain; charset="iso-8859-1" Guarda, anche io sono qui a rossicchiarmi le unghie nella attesa.... Roberto -----Original Message----- From: Valperix [mailto:valper@inwind.it] Sent: Wednesday, February 19, 2003 6:15 PM To: openmosix@democritos.it Subject: [openMosix-it] x Moshe distributed shared memory tienici informati, 8-)) ------_=_NextPart_001_01C2D83C.9D457A2E Content-Type: text/html; charset="iso-8859-1"
Guarda,
anche io sono qui a rossicchiarmi le unghie nella attesa....
Roberto
-----Original Message-----
From: Valperix [mailto:valper@inwind.it]
Sent: Wednesday, February 19, 2003 6:15 PM
To: openmosix@democritos.it
Subject: [openMosix-it] x Moshe

distributed shared memory
 
tienici informati, 8-))
------_=_NextPart_001_01C2D83C.9D457A2E-- --------------InterScan_NT_MIME_Boundary-- From openmosix@democritos.it Wed Feb 19 17:53:15 2003 From: openmosix@democritos.it (Valperix) Date: Wed, 19 Feb 2003 18:53:15 +0100 Subject: [openMosix-it] x Moshe References: Message-ID: <004201c2d83f$c807f860$0300a8c0@pc1> This is a multi-part message in MIME format. ------=_NextPart_000_003F_01C2D848.29246090 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable mi associo, anzi io ho gia' finito le unghie, hehehehehe Guarda, anche io sono qui a rossicchiarmi le unghie nella attesa.... Roberto ------=_NextPart_000_003F_01C2D848.29246090 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
mi associo, anzi io ho gia' finito le = unghie, =20 hehehehehe

 
Guarda,
anche io sono qui a rossicchiarmi le unghie nella=20 attesa....
Roberto
 
------=_NextPart_000_003F_01C2D848.29246090-- From openmosix@democritos.it Thu Feb 20 10:36:07 2003 From: openmosix@democritos.it (openmosix@democritos.it) Date: Thu, 20 Feb 2003 11:36:07 +0100 (CET) Subject: [openMosix-it] Re: openMosix digest, versione Alpha In-Reply-To: <20030220063505.6837.21640.Mailman@democritos.sissa.it> References: <20030220063505.6837.21640.Mailman@democritos.sissa.it> Message-ID: <34167.212.29.140.22.1045737367.squirrel@webmail.entermed.it> Manda manda ...trepidante attesa ....Informaci ... :-)) > --Apple-Mail-6-796616682 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=ISO-8859-1; > format=flowed > > sara' rilasciata una prima versione di sviluppo (pre-alpha) entro > fine=20= > > marzo. > > M From openmosix@democritos.it Thu Feb 20 10:34:18 2003 From: openmosix@democritos.it (ZIGLIO Frediano) Date: Thu, 20 Feb 2003 11:34:18 +0100 Subject: [openMosix-it] Re: openMosix digest, versione Alpha Message-ID: <8336127823F7D2118D4A0008C70D63850A706040@opdmexo02.omnitel.it> > > > > sara' rilasciata una prima versione di sviluppo (pre-alpha) entro > > fine=20= > > > > marzo. > > E' gia' a CVS ? freddy77 ================================= "STRICTLY PERSONAL AND CONFIDENTIAL This message may contain confidential and proprietary material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. The contents of this message that do not relate to the official business of our company shall be understood as neither given nor endorsed by it." ================================= From openmosix@democritos.it Fri Feb 21 06:30:54 2003 From: openmosix@democritos.it (Stefano Cozzini) Date: Fri, 21 Feb 2003 07:30:54 +0100 Subject: [openMosix-it] proposta di tesi su openMosix Message-ID: <00b901c2d975$650dcf00$66191997@pio> Messaggio in formato MIME composto da più parti. ------=_NextPart_000_0007_01C2D97B.2AF68900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Salve a tutti,=20 sperando di non essere troppo off topic volevo informare tutti gli = appassionati=20 di openMosix che qui a Democritos il centro di simulazione nazionale di = INFM=20 stiamo cercando alcune persone per progetti di ricerca su openMosix e = dintorni. =20 Per dintorni intendo cluster e grid computing.=20 I progetti sono ovviamente a termine e quindi candidati ideali = potrebbero essere=20 studenti universitari in cerca di tesi di laurea (ai quali possiamo = offrire una piccola borsa di studio per coprire qualche spesuccia) oppure laureati e/o = dottorati interessati ad una=20 esperienza (un anno o giu' di li' ) nel mondo della ricerca ai quali = invece possiamo=20 offrire un assegno di ricerca. Requisito indispensabile una buona conoscenza di Linux mentre e' = sicuramente apprezzata ma non indispensabile=20 una qualche esperienza,anche minima di linux clustering. Se vi e' qualche interesse contattatemi al mio email : = cozzin@democritos.it=20 grazie per l'attenzione=20 Stefano=20 ------=_NextPart_000_0007_01C2D97B.2AF68900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Salve a tutti,
 sperando di non essere troppo off = topic=20 volevo informare tutti gli appassionati
 di openMosix che qui a Democritos = il centro=20 di simulazione nazionale di INFM
 stiamo cercando alcune persone = per progetti=20 di ricerca su openMosix e dintorni. 
 Per dintorni intendo = cluster  e grid=20 computing.
 I progetti sono ovviamente a = termine e quindi=20 candidati ideali potrebbero essere
 studenti universitari  in cerca di tesi di laurea (ai = quali=20 possiamo offrire  una piccola
 borsa di studio per coprire = qualche=20 spesuccia) oppure laureati e/o dottorati  interessati ad una =
 esperienza (un anno o giu' = di li' ) nel=20 mondo della ricerca ai quali invece possiamo
 offrire un assegno di = ricerca.
 Requisito indispensabile una = buona conoscenza=20 di Linux mentre e' sicuramente apprezzata ma non = indispensabile=20
 una qualche=20 esperienza,anche minima di linux clustering.
 Se vi e'  qualche interesse = contattatemi=20 al mio email : cozzin@democritos.it=20
 
grazie per l'attenzione
Stefano
------=_NextPart_000_0007_01C2D97B.2AF68900-- From openmosix@democritos.it Fri Feb 21 20:47:31 2003 From: openmosix@democritos.it (Gian Paolo Ghilardi) Date: Fri, 21 Feb 2003 21:47:31 +0100 Subject: [openMosix-it] openMosix su Linux Magazine (IT) di Marzo !!! Message-ID: <001701c2d9ea$74ac2a90$5bd11e97@antares> Salve a tutti... WOW! Volevo segnalarvi l'articolo (su oM) su Linux Magazine di Marzo del buon Mirko Caserta, con tanto di gustosa intervista a Moshe... Grande, Mirko (e grande Moshe, ovviamente) !!! From openmosix@democritos.it Fri Feb 21 22:34:09 2003 From: openmosix@democritos.it (Mirko Caserta) Date: Fri, 21 Feb 2003 23:34:09 +0100 Subject: [openMosix-it] openMosix su Linux Magazine (IT) di Marzo !!! In-Reply-To: <001701c2d9ea$74ac2a90$5bd11e97@antares> References: <001701c2d9ea$74ac2a90$5bd11e97@antares> Message-ID: <20030221233409.6c067bee.mirko@mcaserta.com> On Fri, 21 Feb 2003 21:47:31 +0100 "Gian Paolo Ghilardi" wrote: > Volevo segnalarvi l'articolo (su oM) su Linux Magazine di Marzo del buon > Mirko Caserta, con tanto di gustosa intervista a Moshe... > Grande, Mirko (e grande Moshe, ovviamente) !!! JP, sei il solito esagerato! ;P Cmq, l'articolo si =E8 guadagnato addirittura la cover page :) Ecco una bella scansione hi-res della copertina: http://mcaserta.com/linuxMagazine200303-openMosix.png Moshe: domani ti invio una copia della rivista! Mi dispiace solo che il logo di openMosix non sia pi=F9 evidente nella cope= rtina :( E poi hanno installato KDE su tutte le macchine... mhh... :) Vabb=E8, meglio di niente :) Scusate la pubblicit=E0 gratuita. Mirko From openmosix@democritos.it Fri Feb 21 22:50:10 2003 From: openmosix@democritos.it (Moshe Bar) Date: Fri, 21 Feb 2003 14:50:10 -0800 Subject: [openMosix-it] openMosix su Linux Magazine (IT) di Marzo !!! In-Reply-To: <20030221233409.6c067bee.mirko@mcaserta.com> Message-ID: Grazie, Mirko. :-) Moshe On Friday, Feb 21, 2003, at 14:34 US/Pacific, Mirko Caserta wrote: > On Fri, 21 Feb 2003 21:47:31 +0100 > "Gian Paolo Ghilardi" wrote: > >> Volevo segnalarvi l'articolo (su oM) su Linux Magazine di Marzo del=20= >> buon >> Mirko Caserta, con tanto di gustosa intervista a Moshe... >> Grande, Mirko (e grande Moshe, ovviamente) !!! > > JP, sei il solito esagerato! ;P > > Cmq, l'articolo si =E8 guadagnato addirittura la cover page :) > > Ecco una bella scansione hi-res della copertina: > > http://mcaserta.com/linuxMagazine200303-openMosix.png > > Moshe: domani ti invio una copia della rivista! > > Mi dispiace solo che il logo di openMosix non sia pi=F9 evidente nella=20= > copertina :( > > E poi hanno installato KDE su tutte le macchine... mhh... :) > > Vabb=E8, meglio di niente :) > > Scusate la pubblicit=E0 gratuita. > > Mirko > > _______________________________________________ > openMosix mailing list > openMosix@democritos.it > http://www.democritos.it/mailman/listinfo/openmosix > From openmosix@democritos.it Sat Feb 22 06:57:04 2003 From: openmosix@democritos.it (Valperix) Date: Sat, 22 Feb 2003 07:57:04 +0100 Subject: [openMosix-it] openMosix e HA Message-ID: <002001c2da3f$9c14f850$0300a8c0@pc1> This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C2DA47.FD35CD50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ho due nodi con openMosix, ora chiedevo c'e' qualche soluzione per far = si che diventino anche cluster per l'alta affidabilit=E0 (AH), ho visto = che ci sono i vari Kimberlite, heartbeat, etc, ma su un sistema oM cosa = potrei utilizzare? Vi allego uno script che mi hanno dato, in pratica dovrebbe verificare i = servizi dei nodi e attivare il nodo2 qualora il nodo1 abbia problemi ma = non ne sono sicuro potete dargli un'occhiata e dirmi se la cosa =E8 = fattibile. X Moshe, sarebbe gradito anche un tuo commento. In mattina vado a prendermi Linux Magazine visto che c'e' un articolo = sul "nostro" grande openMosix. ------=_NextPart_000_001D_01C2DA47.FD35CD50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ho due nodi con openMosix, ora chiedevo = c'e'=20 qualche soluzione per far si che diventino anche cluster per l'alta = affidabilit=E0=20 (AH), ho visto che ci sono i vari Kimberlite, heartbeat, etc, ma su un = sistema=20 oM cosa potrei utilizzare?
 
Vi allego uno script che mi hanno dato, = in pratica=20 dovrebbe verificare i servizi dei nodi e attivare il nodo2 qualora il = nodo1=20 abbia problemi ma non ne sono sicuro potete dargli un'occhiata e dirmi = se la=20 cosa =E8 fattibile.
 
X Moshe, sarebbe gradito anche un tuo=20 commento.
In mattina vado a prendermi Linux = Magazine visto=20 che c'e' un articolo sul "nostro" grande openMosix.
 
------=_NextPart_000_001D_01C2DA47.FD35CD50-- From openmosix@democritos.it Sat Feb 22 07:17:01 2003 From: openmosix@democritos.it (Valperix) Date: Sat, 22 Feb 2003 08:17:01 +0100 Subject: [openMosix-it] Avevo dimenticato lo script Message-ID: <003d01c2da42$656379f0$0300a8c0@pc1> This is a multi-part message in MIME format. ------=_NextPart_000_0039_01C2DA4A.C6A91500 Content-Type: multipart/alternative; boundary="----=_NextPart_001_003A_01C2DA4A.C6A91500" ------=_NextPart_001_003A_01C2DA4A.C6A91500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_003A_01C2DA4A.C6A91500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_001_003A_01C2DA4A.C6A91500-- ------=_NextPart_000_0039_01C2DA4A.C6A91500 Content-Type: text/plain; name="script per ipotetico AH.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="script per ipotetico AH.txt" #!/bin/sh # stress check della rete in secondi STRESS=3D15 # settare debug=3D"" per nessun debug debug=3D"" # logfile LOGFILE=3D"/var/log/net_gemini.log" # delay iniziale - inserire per la macchina di backup # sleep 60 # daemon start while test ! $infinite_loop ; do { #########################################################################= # fase di controllo - vengono monitorizzati gli IP "ufficiali" # # se liberi vengono presi dalla macchina e si passa alla fase operativa = # #########################################################################= loop=3D"" echo `date +%d.%m.%Y-%T` " Entering in checking mode" >> $LOGFILE while test ! $loop ; do { if test $debug ; then date ; fi ping 192.168.168.192 -s 10 -c 1 -w 1 >/dev/zero || Net0=3D$? ping 10.250.250.253 -s 10 -c 1 -w 1 >/dev/zero || Net1=3D$? ping 172.16.2.10 -s 10 -c 1 -w 1 >/dev/zero || Net2=3D$? # se i tre IP sono TUTTI liberi: if test $Net0 && test $Net1 && test $Net2 ; then =09 if test $debug ; then echo Enter in working mode ; fi=09 # inizializza la macchina =09 ifconfig eth0 192.168.168.192 netmask 255.255.255.0 ifconfig eth1 10.250.250.253 netmask 255.255.255.0 ifconfig eth2 172.16.2.10 netmask 255.255.0.0 # route add default gw 192.168.168.168 /usr/sbin/rcroute start /usr/sbin/rcsmb start mv /etc/hosts /etc/hosts.netcluster /usr/sbin/rcnamed restart /sbin/rcrinetd restart =09 loop=3D"end" else =09 if test $debug ; then if test $debug ; then=20 if ! test $Net0 ;then Net0=3D"Up"; else Net0=3D"Down" ;fi =20 if ! test $Net1 ;then Net1=3D"Up"; else Net1=3D"Down" ;fi =20 if ! test $Net2 ;then Net2=3D"Up"; else Net2=3D"Down" ;fi =20 echo $Net0 " " $Net1 " " $Net2 =20 fi =20 fi Net0=3D"" ; Net1=3D"" ; Net2=3D"" fi if test ! $loop ; then sleep $STRESS ; fi =20 } done sleep 20 #################################################################### # Fase operativa - qui si auto controlla il funzionamento regolare # #################################################################### echo `date +%d.%m.%Y-%T` " Entering in working mode" >> $LOGFILE loop=3D"" while test ! $loop ; do { if test $debug ; then date ; fi # controllo macchine 192.168.168.0 ping 192.168.168.20 -s 10 -c 1 -w 1 >/dev/zero || Net0_A=3D$? ping 192.168.168.100 -s 10 -c 1 -w 1 >/dev/zero || Net0_B=3D$? if test $Net0_A && test $Net0_B ; then if test $debug ; then echo Rete 192.168.168.0 caduta! ; fi echo `date +%d.%m.%Y-%T` " Rete 192.168.168.0 caduta" >> $LOGFILE Net0=3D"down" ; Net0_A=3D"" ; Net0_B=3D"" else =09 if test $debug ; then=20 if ! test $Net0_A ;then Net0_A=3D"Up"; else Net0_A=3D"Down" ;fi =20 if ! test $Net0_B ;then Net0_B=3D"Up"; else Net0_B=3D"Down" ;fi = =20 echo $Net0_A " " $Net0_B fi Net0=3D"" ; Net0_A=3D"" ; Net0_B=3D"" fi # controllo macchine 172.16.0.0 ping 172.16.2.100 -s 10 -c 1 -w 1 >/dev/zero || Net1_A=3D$? ping 172.16.2.2 -s 10 -c 1 -w 1 >/dev/zero || Net1_B=3D$? ping 172.16.2.3 -s 10 -c 1 -w 1 >/dev/zero || Net1_C=3D$? ping 172.16.2.4 -s 10 -c 1 -w 1 >/dev/zero || Net1_D=3D$? ping 172.16.1.1 -s 10 -c 1 -w 1 >/dev/zero || Net1_E=3D$? if test $Net1_A && test $Net1_B && test $Net1_C && test $Net1_D && = test $Net1_E ; then if test $debug ; then echo Rete 172.16.0.0 caduta! ;fi echo `date +%d.%m.%Y-%T` " Rete 172.16.0.0 caduta" >> $LOGFILE Net1=3D"down" ; Net1_A=3D"" ; Net1_B=3D"" ; Net1_C=3D"" ; = Net1_D=3D""; Net1_E=3D"" else if test $debug ; then=20 if ! test $Net1_A ;then Net1_A=3D"Up"; else Net1_A=3D"Down" ;fi =20 if ! test $Net1_B ;then Net1_B=3D"Up"; else Net1_B=3D"Down" ;fi = =20 if ! test $Net1_C ;then Net1_C=3D"Up"; else Net1_C=3D"Down" ;fi =20 if ! test $Net1_D ;then Net1_D=3D"Up"; else Net1_D=3D"Down" ;fi = =20 if ! test $Net1_E ;then Net1_E=3D"Up"; else Net1_E=3D"Down" ;fi =20 echo $Net1_A " " $Net1_B " " $Net1_C " " $Net1_D " " $Net1_E fi Net1=3D"" ; Net1_A=3D"" ; Net1_B=3D"" ; Net1_C=3D"" ; Net1_D=3D""; = Net1_E=3D"" fi # controllo macchine 10.0.0.0 ping 10.250.250.100 -s 10 -c 1 -w 1 >/dev/zero || Net2_A=3D$? ping 10.250.250.3 -s 10 -c 1 -w 1 >/dev/zero || Net2_B=3D$? ping 10.250.250.1 -s 10 -c 1 -w 1 >/dev/zero || Net2_C=3D$? if test $Net2_A && test $Net2_B && test $Net2_C ; then if test $debug ; then echo Rete 10.250.250.0 caduta! ; fi echo `date +%d.%m.%Y-%T` " Rete 10.250.250.0 caduta" >> $LOGFILE Net2=3D"down" ; Net2_A=3D"" ; Net2_B=3D"" ; Net2_C=3D""=20 else if test $debug ; then=20 if ! test $Net2_A ;then Net2_A=3D"Up"; else Net2_A=3D"Down" ;fi =20 if ! test $Net2_B ;then Net2_B=3D"Up"; else Net2_B=3D"Down" ;fi = =20 if ! test $Net2_C ;then Net2_C=3D"Up"; else Net2_C=3D"Down" ;fi =20 echo $Net2_A " " $Net2_B " " $Net2_C =20 fi Net2=3D"" ; Net2_A=3D"" ; Net2_B=3D"" ; Net2_C=3D""=20 fi if test $Net0 || test $Net1 || test $Net2 ; then if test $debug ; then echo switching Ip address to neutral ; fi echo `date +%d.%m.%Y-%T` " Switching Ip address to neutral" >> = $LOGFILE ------=_NextPart_000_0039_01C2DA4A.C6A91500-- From openmosix@democritos.it Sat Feb 22 22:26:28 2003 From: openmosix@democritos.it (openmosix@democritos.it) Date: Sat, 22 Feb 2003 23:26:28 +0100 (CET) Subject: [openMosix-it] Re: OpenMosix su Linux Magazine In-Reply-To: <20030222063525.507.52184.Mailman@democritos.sissa.it> References: <20030222063525.507.52184.Mailman@democritos.sissa.it> Message-ID: <3143.151.29.20.248.1045952788.squirrel@webmail.entermed.it> Ciao a tutti Ho appena letto l'articolo su openMosix in questione e volevo fare i complimenti a Mirko Caserta, non solo per l'ottima qualità dell'articolo stesso, ma per il metodo espositivo. Ho apprezzatto infatti, la volonta di trattare un argomento interessante e particolare come il mondo dei cluster e di openMosix con una trattazione alla portata di tutti, pur mantenendo un profilo professionale abbastanza alto, basti vedere la sezione "come spiegare il cluster a mia nonna". Questo metodo lascia riflettere molto, poichè si evince la forte volonta di trasmettere a chiunque abbia un minimo interesse per l'argomento o per l'informatica in generale, che i cluster non sono un argomento dedicato solo a persone che mangiano pane e shell tutti i giorni. Per cui complimenti Mirko, e spero che molti altri professionisti che scrivono su altrettante testate informatiche seguano il tuo esempio. Giancarlo del Rossi ps perdonate l'OT > Message: 3 > Date: Fri, 21 Feb 2003 23:34:09 +0100 > From: Mirko Caserta > To: openmosix@democritos.it > Subject: Re: [openMosix-it] openMosix su Linux Magazine (IT) di Marzo > !!! Reply-To: openmosix@democritos.it > > On Fri, 21 Feb 2003 21:47:31 +0100 > "Gian Paolo Ghilardi" wrote: > >> Volevo segnalarvi l'articolo (su oM) su Linux Magazine di Marzo del >> buon Mirko Caserta, con tanto di gustosa intervista a Moshe... >> Grande, Mirko (e grande Moshe, ovviamente) !!! > > JP, sei il solito esagerato! ;P > > Cmq, l'articolo si =E8 guadagnato addirittura la cover page :) > > Ecco una bella scansione hi-res della copertina: > > http://mcaserta.com/linuxMagazine200303-openMosix.png > > Moshe: domani ti invio una copia della rivista! > > Mi dispiace solo che il logo di openMosix non sia pi=F9 evidente nella > cope= rtina :( > > E poi hanno installato KDE su tutte le macchine... mhh... :) > > Vabb=E8, meglio di niente :) > > Scusate la pubblicit=E0 gratuita. > > Mirko From openmosix@democritos.it Mon Feb 24 08:04:57 2003 From: openmosix@democritos.it (Alberto Brosich) Date: Mon, 24 Feb 2003 09:04:57 +0100 Subject: [openMosix-it] Testing Openmosix & LTSP con setiathome. Message-ID: <3E59D229.7090600@units.it> This is a multi-part message in MIME format. From openmosix@democritos.it Mon Feb 24 08:44:23 2003 From: openmosix@democritos.it (Alberto Brosich) Date: Mon, 24 Feb 2003 09:44:23 +0100 Subject: [openMosix-it] Testing Openmosix & LTSP con setiathome. Message-ID: <1046076263.3e59db67f323e@webmail.units.it> > > > I processi migrano perche' nella fase computazionale vanno verso nodi piu' veloci mentre nella fase di I/O ritornano a casa. > > Se usi oMFS con DFSA dovresti potere evitare le migrazioni. Un altro modo e di settare la velocita' dei nodi sinteticamente con mosctl setspeed > > Moshe > > Mi scuso innanzitutto per il precedente mail malformato. Tutti i kernel hanno oMFS con DFSA abilitato ed il filesystem /mfs montato in /etc/fstab. Abbiamo notato che sui nodi diskless (LTSP), che hanno il filesystem root montato via NFS, al boot del kernel compare la scritta "Disabling DFSA" che sembra sembra abbastanza esplicita. :-) Quali possono essere i motivi per cui compare? Alberto Brosich Stefano Catani From openmosix@democritos.it Mon Feb 24 09:07:54 2003 From: openmosix@democritos.it (Premoli, Roberto [IT/0425]) Date: Mon, 24 Feb 2003 04:07:54 -0500 Subject: [openMosix-it] openMosix con molti nodi Message-ID: Cercavo info, link, documenti, siti, etc. dove si parli di cluster openMosix con un grande (100+) numero di nodi... Fino ad ora ho letto documentazioni che si riferivano a cluster con massimo 24 nodi, ora vorrei ampliare le mie conoscenze su cluster piu' grossi. Grazie, Roberto From openmosix@democritos.it Mon Feb 24 12:39:09 2003 From: openmosix@democritos.it (Moshe Bar) Date: Mon, 24 Feb 2003 04:39:09 -0800 Subject: [openMosix-it] openMosix con molti nodi In-Reply-To: Message-ID: ne conosco io alcuni con piu' di 1000 nodi. Ma se te ne parlo, poi dovrei ucciderti... :-) Moshe On Monday, Feb 24, 2003, at 01:07 US/Pacific, Premoli, Roberto [IT/0425] wrote: > Cercavo info, link, documenti, siti, etc. dove si parli di > cluster openMosix con un grande (100+) numero di nodi... > Fino ad ora ho letto documentazioni che si riferivano a > cluster con massimo 24 nodi, ora vorrei ampliare le mie > conoscenze su cluster piu' grossi. > Grazie, > Roberto > _______________________________________________ > openMosix mailing list > openMosix@democritos.it > http://www.democritos.it/mailman/listinfo/openmosix > From openmosix@democritos.it Mon Feb 24 12:47:46 2003 From: openmosix@democritos.it (Premoli, Roberto [IT/0425]) Date: Mon, 24 Feb 2003 06:47:46 -0600 Subject: [openMosix-it] openMosix con molti nodi Message-ID: No, no, no, grazie, non voglio che quelli del mossad vengano a cercarmi con il mio nome scritto sulle pallottole... Quelli non scherzano: "un colpo, un morto"! :-/ A proposito, per la domanda che ti avevo fatto (in provato) inerente la creazione del cluster a 4 nodi e con 3 schede di rete per nodo, con le connessioni peer-to-peer, mi sai/puoi dare una risposta su COME devo fare per implementarlo? Roberto -----Original Message----- From: Moshe Bar [mailto:moshe@moelabs.com] Sent: Monday, February 24, 2003 1:39 PM To: openmosix@democritos.it Subject: Re: [openMosix-it] openMosix con molti nodi ne conosco io alcuni con piu' di 1000 nodi. Ma se te ne parlo, poi dovrei ucciderti... :-) Moshe On Monday, Feb 24, 2003, at 01:07 US/Pacific, Premoli, Roberto [IT/0425] wrote: > Cercavo info, link, documenti, siti, etc. dove si parli di > cluster openMosix con un grande (100+) numero di nodi... > Fino ad ora ho letto documentazioni che si riferivano a > cluster con massimo 24 nodi, ora vorrei ampliare le mie > conoscenze su cluster piu' grossi. > Grazie, > Roberto > _______________________________________________ > openMosix mailing list > openMosix@democritos.it > http://www.democritos.it/mailman/listinfo/openmosix > _______________________________________________ openMosix mailing list openMosix@democritos.it http://www.democritos.it/mailman/listinfo/openmosix From openmosix@democritos.it Mon Feb 24 15:07:01 2003 From: openmosix@democritos.it (ZIGLIO Frediano) Date: Mon, 24 Feb 2003 16:07:01 +0100 Subject: [openMosix-it] 3c905c e openMosix Message-ID: <8336127823F7D2118D4A0008C70D63850A706053@opdmexo02.omnitel.it> Sto tentando di configurare un cluster con openMosix (5 macchine identiche collegate in una rete privata con un HUB a 100). Devo dire che l'installazione del software non e' stato un problema. Il problema sono state le schede di rete (3Com 905C). Se qualcuno dovesse configurare un cluster con questo tipo di scheda spiego i miei problemi: - il driver sembra non prendere i parametri settati nel bios della scheda. Ho risolto ponendo i parametri della eeprom (mediante programma dos fornito con i vari driver 3com) in autoselect - il driver sembra non gradire il settaggio via parametri. Ho risolto usando il programmino mii-diag che trovate al sito del driver 3c59x e fissando cosi' la velocita'. - per ultimo ho sbagliato a configurare il duplex (avevo impostao full al posto di half). Facendo un ifconfig si vede dal fatto che i pacchetti con problemi di carrier sono il 90% e piu' di quelli trasmessi. Devo sinceramente ringraziare Donald Becker (sviluppatore del driver della scheda) per il suo supporto. So che i miei problemi non sono molto correlati a openMosix ma dato che le schede 3com sono molto diffuse e questo modello e' specialmente venduto in questi ultimi tempi mi sembrava di dover informare la ML. freddy77 PS: Adesso il cluster va alla grande, provvedero' a fargli fare qualcosa di piu' utile che semplici test... ================================= "STRICTLY PERSONAL AND CONFIDENTIAL This message may contain confidential and proprietary material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. The contents of this message that do not relate to the official business of our company shall be understood as neither given nor endorsed by it." ================================= From openmosix@democritos.it Mon Feb 24 16:24:35 2003 From: openmosix@democritos.it (Federico Nati) Date: Mon, 24 Feb 2003 17:24:35 +0100 Subject: [openMosix-it] openMosix & WindowMaker Message-ID: <20030224172435.22c4f478.federico.nati@tiscalinet.it> Ciao, esiste un'applicazioncina tipo mosmon ma che funziona come dock application in Window Maker? Per capirci quelle cosette carine che si mettono insieme alle icone :) ciao, Federico. From openmosix@democritos.it Mon Feb 24 16:28:50 2003 From: openmosix@democritos.it (Moshe Bar) Date: Mon, 24 Feb 2003 08:28:50 -0800 Subject: [openMosix-it] openMosix & WindowMaker In-Reply-To: <20030224172435.22c4f478.federico.nati@tiscalinet.it> Message-ID: <0E514A57-4815-11D7-ADFC-000393CE0D6C@moelabs.com> Si, ci sono paio di soluzioni del genere: openMosixView openMosixApplet e altre Moshe On Monday, Feb 24, 2003, at 08:24 US/Pacific, Federico Nati wrote: > Ciao, > > esiste un'applicazioncina tipo mosmon ma che funziona come dock > application in Window Maker? Per capirci quelle cosette carine che si > mettono insieme alle icone :) > > ciao, Federico. > _______________________________________________ > openMosix mailing list > openMosix@democritos.it > http://www.democritos.it/mailman/listinfo/openmosix > From openmosix@democritos.it Mon Feb 24 17:32:42 2003 From: openmosix@democritos.it (Mirko Caserta) Date: Mon, 24 Feb 2003 18:32:42 +0100 Subject: [openMosix-it] openMosix & WindowMaker In-Reply-To: <0E514A57-4815-11D7-ADFC-000393CE0D6C@moelabs.com> References: <20030224172435.22c4f478.federico.nati@tiscalinet.it> <0E514A57-4815-11D7-ADFC-000393CE0D6C@moelabs.com> Message-ID: <20030224183242.446b5470.mirko@mcaserta.com> Scusa Moshe se mi intrometto ma credo che lui cercasse un'applicazione da usare come "dock status monitor/icon-sized", non so se mi sono spiegato :) Non credo ci siano applicazioni del genere per openMosix/WindowMaker (AFAIK), tuttavia ritengo che cercare di visualizzare lo status di un cluster su una tale applicazione sarebbe un po' troppo impegnativo dal punto di vista grafico/spazio a disposizione per cui ti consiglio vivamente di usare openMosixView e/o le altre soluzioni come openMosixWebView/openMosixApplet per il monitoring di un cluster oM. Se poi vuoi divertirti a scrivere una tale applicazione, facci sapere! :) Ciao, Mirko On Mon, 24 Feb 2003 08:28:50 -0800 Moshe Bar wrote: > Si, ci sono paio di soluzioni del genere: > > openMosixView > openMosixApplet > > e altre > > Moshe > > > On Monday, Feb 24, 2003, at 08:24 US/Pacific, Federico Nati wrote: > > > Ciao, > > > > esiste un'applicazioncina tipo mosmon ma che funziona come dock > > application in Window Maker? Per capirci quelle cosette carine che > > si mettono insieme alle icone :) > > > > ciao, Federico. From openmosix@democritos.it Tue Feb 25 10:00:25 2003 From: openmosix@democritos.it (Federico Nati) Date: Tue, 25 Feb 2003 11:00:25 +0100 Subject: [openMosix-it] openMosix & WindowMaker In-Reply-To: <20030224183242.446b5470.mirko@mcaserta.com> References: <20030224172435.22c4f478.federico.nati@tiscalinet.it> <0E514A57-4815-11D7-ADFC-000393CE0D6C@moelabs.com> <20030224183242.446b5470.mirko@mcaserta.com> Message-ID: <20030225110025.2f2235ab.federico.nati@tiscalinet.it> si, infatti cercavo esattamente questa :) mi rendo conto che non e' molto piu' di un giochino... ma sarebbe carino. si in effetti lo spazio e' un po' piccolino, ma se i nodi non sono troppi... ciao, Federico. On Mon, 24 Feb 2003 18:32:42 +0100 Mirko Caserta wrote: > > Scusa Moshe se mi intrometto ma credo che lui cercasse un'applicazione > da usare come "dock status monitor/icon-sized", non so se mi sono > spiegato :) > > Non credo ci siano applicazioni del genere per openMosix/WindowMaker > (AFAIK), tuttavia ritengo che cercare di visualizzare lo status di un > cluster su una tale applicazione sarebbe un po' troppo impegnativo dal > punto di vista grafico/spazio a disposizione per cui ti consiglio > vivamente di usare openMosixView e/o le altre soluzioni come > openMosixWebView/openMosixApplet per il monitoring di un cluster oM. > > Se poi vuoi divertirti a scrivere una tale applicazione, facci sapere! > :) > > Ciao, Mirko > > On Mon, 24 Feb 2003 08:28:50 -0800 > Moshe Bar wrote: > > > Si, ci sono paio di soluzioni del genere: > > > > openMosixView > > openMosixApplet > > > > e altre > > > > Moshe > > > > > > On Monday, Feb 24, 2003, at 08:24 US/Pacific, Federico Nati wrote: > > > > > Ciao, > > > > > > esiste un'applicazioncina tipo mosmon ma che funziona come dock > > > application in Window Maker? Per capirci quelle cosette carine che > > > si mettono insieme alle icone :) > > > > > > ciao, Federico. > _______________________________________________ > openMosix mailing list > openMosix@democritos.it > http://www.democritos.it/mailman/listinfo/openmosix From openmosix@democritos.it Tue Feb 25 21:44:47 2003 From: openmosix@democritos.it (Gian Paolo Ghilardi) Date: Tue, 25 Feb 2003 22:44:47 +0100 Subject: [openMosix-it] openMosix & WindowMaker References: <20030224172435.22c4f478.federico.nati@tiscalinet.it><0E514A57-4815-11D7-ADFC-000393CE0D6C@moelabs.com> <20030224183242.446b5470.mirko@mcaserta.com> Message-ID: <008701c2dd17$1ea82ec0$05d61e97@antares> > > Scusa Moshe se mi intrometto ma credo che lui cercasse un'applicazione > da usare come "dock status monitor/icon-sized", non so se mi sono > spiegato :) > > Non credo ci siano applicazioni del genere per openMosix/WindowMaker > (AFAIK), tuttavia ritengo che cercare di visualizzare lo status di un > cluster su una tale applicazione sarebbe un po' troppo impegnativo dal > punto di vista grafico/spazio a disposizione per cui ti consiglio > vivamente di usare openMosixView e/o le altre soluzioni come > openMosixWebView/openMosixApplet per il monitoring di un cluster oM. > > Se poi vuoi divertirti a scrivere una tale applicazione, facci sapere! > :) > Beh, Mirko... Non so te... Ma la oM applet puoi ridurla a dimensioni minime. Ho notato, per esempio, che Konqueror usa in ogni caso l'appletviewer, quindi non ci sono finestre mastodontiche, ma una minuscola finestrella "resizable". Solitamente, qundo la uso, ho aperto anche Se il problema è l'integrazione con uno specifico WM, beh... quello è tutto un altro paio di maniche... :) Personalmente se qualcuno riuscisse a creare un wrapper per inserirla in gkrellm, sarei iperfelice (io ultimamente sono iperimpegnato e non ho tempo)... Bye. From openmosix@democritos.it Tue Feb 25 21:54:14 2003 From: openmosix@democritos.it (Gian Paolo Ghilardi) Date: Tue, 25 Feb 2003 22:54:14 +0100 Subject: [openMosix-it] openMosix & WindowMaker References: <20030224172435.22c4f478.federico.nati@tiscalinet.it><0E514A57-4815-11D7-ADFC-000393CE0D6C@moelabs.com> <20030224183242.446b5470.mirko@mcaserta.com> <008701c2dd17$1ea82ec0$05d61e97@antares> Message-ID: <000901c2dd18$705864f0$05d61e97@antares> Scusate per la mail "effetto puzzle" (incompleta/con pezzi mancanti). Ho dimenticato di finire la frase "ho aperto anche altri programmi per monitorare il sistema, come gkrellm e xosview,... E la applet, opportunamente ridotta, non è affatto fastidiosa quanto a dimensioni... :) Bye. From openmosix@democritos.it Wed Feb 26 13:26:04 2003 From: openmosix@democritos.it (openmosix@democritos.it) Date: 26 Feb 2003 13:26:04 -0000 Subject: [openMosix-it] openAFS oops Message-ID: <20030226132604.1078.qmail@mail.supereva.it> Salve a tutti seguendo i consigli avuti in mailinglist ho provato ad installare openAFS come filesystem per sharare i dati alle applicazioni che girano sul cluster. Ho scaricato i sorgenti e gli rpm della versione 1.2.8 per la redhat 7.1 che stiamo utilizzando sul cluster. Ho ricreato i pacchetti rpm applicando l'ultima patch di Clement Omine e ricompilando non trovava degli include relativi ad hpc quindi ho creato una patch per includere tale directory nei sorgenti: ------------------------------------------------------------------------------------------------------------ diff -bwur openafs-1.2.8/src/libafs/MakefileProto.LINUX.in openafs-1.2.8oM/src/libafs/MakefileProto.LINUX.in --- openafs-1.2.8/src/libafs/MakefileProto.LINUX.in Thu Nov 14 23:18:04 2002 +++ openafs-1.2.8oM/src/libafs/MakefileProto.LINUX.in Fri Feb 21 15:30:40 2003 @@ -123,6 +123,8 @@ # Compile SP and MP clients as requested ${COMPDIRS} ${INSTDIRS} ${DESTDIRS}: + $(RM) -f hpc + ln -s ${LINUX_KERNEL_PATH}/include/hpc hpc $(RM) -f h ln -s ${LINUX_KERNEL_PATH}/include/linux h $(RM) -f linux ------------------------------------------------------------------------------------------------------------ In questo modo aggiungendo le due patch nello spec file sono riuscito ad ottenere gli rpm aggiornati che ho installato su due nodi per testarli. Lato server tutto ok Lato client allo startup di afs si ottengono una serie di oops, dopo che ha caricato il modulo e sta tentando di far partire l'afsd ,che bloccano la macchina. Feb 21 13:20:03 cls32 rc: Starting sshd: succeeded Feb 21 13:20:04 cls32 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Feb 21 13:20:04 cls32 kernel: printing eip: Feb 21 13:20:04 cls32 kernel: c0122149 Feb 21 13:20:04 cls32 kernel: *pde = 00000000 Feb 21 13:20:04 cls32 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Feb 21 13:20:04 cls32 kernel: printing eip: Feb 21 13:20:04 cls32 kernel: c0122149 Feb 21 13:20:04 cls32 kernel: *pde = 00000000 Feb 21 13:20:04 cls32 kernel: Oops: 0002 Feb 21 13:20:04 cls32 kernel: CPU: 1 Feb 21 13:20:04 cls32 kernel: EIP: 0010:[wait_for_completion+121/224] Tainted: PF Feb 21 13:20:04 cls32 kernel: EIP: 0010:[] Tainted: PF Feb 21 13:20:04 cls32 kernel: EFLAGS: 00010046 Feb 21 13:20:04 cls32 kernel: eax: f742dc4c ebx: f742c000 ecx: f742dbdc edx: 00000000 Feb 21 13:20:04 cls32 kernel: esi: f742dc44 edi: bfffc840 ebp: f742dbec esp: f742dbc4 Feb 21 13:20:04 cls32 kernel: ds: 0018 es: 0018 ss: 0018 Feb 21 13:20:04 cls32 kernel: Process afsd (pid: 744, stackpage=f742d000) Feb 21 13:20:04 cls32 kernel: Stack: 00000000 f742c000 00000000 00000000 00000001 f742c000 f742dc4c 00000000 Feb 21 13:20:04 cls32 kernel: f742dc44 00000030 00000030 f898345f f742dc14 00000000 00000000 00000000 Feb 21 13:20:04 cls32 kernel: 00000000 00000000 00000030 f742dc44 c02f8be0 f7429c14 00000001 f8983340 Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [__alloc_pages+65/432] [do_wp_page+620/704] Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [] [] Feb 21 13:20:04 cls32 kernel: [do_wp_page+658/704] [handle_mm_fault+162/272] [do_page_fault+285/1067] [] [local_pre_usermode_actions+21/240] [local_syscall+7/19] Feb 21 13:20:04 cls32 kernel: [] [] [] [] [] [] Feb 21 13:20:04 cls32 kernel: Feb 21 13:20:04 cls32 kernel: Code: 89 0a 90 8d 74 26 00 c7 03 02 00 00 00 b0 01 86 46 04 fb e8 Feb 21 13:20:04 cls32 kernel: <1>Unable to handle kernel paging request at virtual address 800006c5 Feb 21 13:20:04 cls32 kernel: printing eip: Feb 21 13:20:04 cls32 kernel: c0121f5b Feb 21 13:20:04 cls32 kernel: *pde = 00000000 Feb 21 13:20:04 cls32 kernel: Oops: 0002 Feb 21 13:20:04 cls32 kernel: CPU: 1 Feb 21 13:20:04 cls32 kernel: EIP: 0010:[complete+91/464] Tainted: PF Feb 21 13:20:04 cls32 kernel: EIP: 0010:[] Tainted: PF Feb 21 13:20:04 cls32 kernel: EFLAGS: 00010086 Feb 21 13:20:04 cls32 kernel: eax: 800006c5 ebx: 00000000 ecx: 00000001 edx: 80000001 Feb 21 13:20:04 cls32 kernel: esi: f7429c48 edi: f7ef066c ebp: f7427fcc esp: f7427f9c Feb 21 13:20:04 cls32 kernel: ds: 0018 es: 0018 ss: 0018 Feb 21 13:20:04 cls32 kernel: Process keventd (pid: 746, stackpage=f7427000) Feb 21 13:20:04 cls32 kernel: Stack: f7429c40 00000001 f7429c48 00000296 f7429c44 f742623e 08bd9dc2 f8995daa Feb 21 13:20:04 cls32 kernel: f7427fdc 00000000 f7429c0c f7ef066c f7ef0000 f8983034 f742623e f8995d9f Feb 21 13:20:04 cls32 kernel: f7426000 f7426000 00004111 00004111 f7ef1f40 c0107296 f7429c0c f8982ff0 Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [kernel_thread+38/48] [] Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [] [] Feb 21 13:20:04 cls32 kernel: Feb 21 13:20:04 cls32 kernel: Code: f0 83 28 01 0f 88 4e 16 00 00 8b 82 c0 06 00 00 83 f8 10 75 Feb 21 13:20:04 cls32 kernel: Oops: 0002 Feb 21 13:20:04 cls32 kernel: CPU: 0 Feb 21 13:20:04 cls32 kernel: EIP: 0010:[wait_for_completion+121/224] Tainted: PF Feb 21 13:20:04 cls32 kernel: EIP: 0010:[] Tainted: PF Feb 21 13:20:04 cls32 kernel: EFLAGS: 00010046 Feb 21 13:20:04 cls32 kernel: Unable to handle kernel paging request at virtual address 800006c5 Feb 21 13:20:04 cls32 kernel: printing eip: Feb 21 13:20:04 cls32 kernel: c0121f5b Feb 21 13:20:04 cls32 kernel: *pde = 00000000 Feb 21 13:20:04 cls32 kernel: eax: f7429c4c ebx: f7428000 ecx: f7429bdc edx: 00000000 Feb 21 13:20:04 cls32 kernel: esi: f7429c44 edi: bfffc840 ebp: f7429bec esp: f7429bc4 Feb 21 13:20:04 cls32 kernel: ds: 0018 es: 0018 ss: 0018 Feb 21 13:20:04 cls32 kernel: Process afsd (pid: 745, stackpage=f7429000) Feb 21 13:20:04 cls32 kernel: Stack: 00000000 f7428000 00000000 00000000 00000001 f7428000 f7429c4c 00000000 Feb 21 13:20:04 cls32 kernel: f7429c44 00000000 00000000 f898345f f7429c14 00000000 00000000 00000000 Feb 21 13:20:04 cls32 kernel: 00000000 00000000 00000000 f7429c44 f742dc14 f7ef1f70 00000000 f8983340 Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [__alloc_pages+65/432] [do_wp_page+620/704] Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [] [] Feb 21 13:20:04 cls32 kernel: [do_wp_page+658/704] [handle_mm_fault+162/272] [do_page_fault+285/1067] [] [local_pre_usermode_actions+21/240] [local_syscall+7/19] Feb 21 13:20:04 cls32 kernel: [] [] [] [] [] [] Feb 21 13:20:04 cls32 kernel: Feb 21 13:20:04 cls32 kernel: Code: 89 0a 90 8d 74 26 00 c7 03 02 00 00 00 b0 01 86 46 04 fb e8 Feb 21 13:20:04 cls32 kernel: Oops: 0002 Feb 21 13:20:04 cls32 kernel: CPU: 1 Feb 21 13:20:04 cls32 kernel: EIP: 0010:[complete+91/464] Tainted: PF Feb 21 13:20:04 cls32 kernel: EIP: 0010:[] Tainted: PF Feb 21 13:20:04 cls32 kernel: EFLAGS: 00010086 Feb 21 13:20:04 cls32 kernel: eax: 800006c5 ebx: f742423e ecx: 00000001 edx: 80000001 Feb 21 13:20:04 cls32 kernel: esi: f742dc48 edi: f7ef066c ebp: f7425fcc esp: f7425f9c Feb 21 13:20:04 cls32 kernel: ds: 0018 es: 0018 ss: 0018 Feb 21 13:20:04 cls32 kernel: Process keventd (pid: 747, stackpage=f7425000) Feb 21 13:20:04 cls32 kernel: Stack: f742dc40 00000001 f742dc48 00000296 f742dc44 f742423e 08bdbdc2 f8995e37 Feb 21 13:20:04 cls32 kernel: f7425fdc f742423e f742dc0c f7ef066c f7ef0000 f89832da f742423e f8995e2b Feb 21 13:20:04 cls32 kernel: f7424000 f7424000 00004111 00004111 f7ef1f40 c0107296 f742dc0c f8982ff0 Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [kernel_thread+38/48] [] Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [] [] Feb 21 13:20:04 cls32 kernel: Feb 21 13:20:04 cls32 kernel: Code: f0 83 28 01 0f 88 4e 16 00 00 8b 82 c0 06 00 00 83 f8 10 75 Feb 21 13:20:04 cls32 kernel: <1>Unable to handle kernel paging request at virtual address 050001e3 Feb 21 13:20:04 cls32 kernel: printing eip: Feb 21 13:20:04 cls32 kernel: c0122149 Feb 21 13:20:04 cls32 kernel: *pde = 00000000 Feb 21 13:20:04 cls32 kernel: Oops: 0002 Feb 21 13:20:04 cls32 kernel: CPU: 1 Feb 21 13:20:04 cls32 kernel: EIP: 0010:[wait_for_completion+121/224] Tainted: PF Feb 21 13:20:04 cls32 kernel: EIP: 0010:[] Tainted: PF Feb 21 13:20:04 cls32 kernel: EFLAGS: 00010046 Feb 21 13:20:04 cls32 kernel: eax: f742bc4c ebx: f742a000 ecx: f742bbdc edx: 050001e3 Feb 21 13:20:04 cls32 kernel: esi: f742bc44 edi: bfffc840 ebp: f742bbec esp: f742bbc4 Feb 21 13:20:04 cls32 kernel: ds: 0018 es: 0018 ss: 0018 Feb 21 13:20:04 cls32 kernel: Process afsd (pid: 748, stackpage=f742b000) Feb 21 13:20:04 cls32 kernel: Stack: 00000000 f742a000 00000000 00000000 00000001 f742a000 f742bc4c 050001e3 Feb 21 13:20:04 cls32 kernel: f742bc44 00000013 00000013 f898345f f742bc14 00000000 00000000 000001e3 Feb 21 13:20:04 cls32 kernel: 004001e3 <1>Unable to handle kernel paging request008001e3 00000013 f742bc44 f7ef1f70 f7ef1f70 00000000 f8983340 Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [__alloc_pages+65/432] [__alloc_pages+65/432] printing eip: Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [] [] printing eip: Feb 21 13:20:04 cls32 kernel: c0121f5b Feb 21 13:20:04 cls32 kernel: *pde = 00000000 Feb 21 13:20:04 cls32 kernel: [do_wp_page+620/704] Feb 21 13:20:04 cls32 kernel: [] Feb 21 13:20:04 cls32 kernel: [do_wp_page+658/704] [handle_mm_fault+162/272] [do_page_fault+285/1067] [] [local_pre_usermode_actions+21/240] [local_syscall+7/19] Feb 21 13:20:04 cls32 kernel: [] [] [] [] [] [] Feb 21 13:20:04 cls32 kernel: Feb 21 13:20:04 cls32 kernel: Code: 89 0a 90 8d 74 26 00 c7 03 02 00 00 00 b0 01 86 46 04 fb e8 Feb 21 13:20:04 cls32 kernel: Oops: 0002 Feb 21 13:20:04 cls32 kernel: CPU: 0 Feb 21 13:20:04 cls32 kernel: EIP: 0010:[complete+91/464] Tainted: PF Feb 21 13:20:04 cls32 kernel: EIP: 0010:[] Tainted: PF Feb 21 13:20:04 cls32 kernel: EFLAGS: 00010086 Feb 21 13:20:04 cls32 kernel: eax: 800006c5 ebx: 00000013 ecx: 00000001 edx: 80000001 Feb 21 13:20:04 cls32 kernel: esi: f742bc48 edi: f7ef066c ebp: f7419fcc esp: f7419f9c Feb 21 13:20:04 cls32 kernel: ds: 0018 es: 0018 ss: 0018 Feb 21 13:20:04 cls32 kernel: Process keventd (pid: 751, stackpage=f7419000) Feb 21 13:20:04 cls32 kernel: Stack: <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000 Feb 21 13:20:04 cls32 kernel: printing eip: Feb 21 13:20:04 cls32 kernel: c0122149 Feb 21 13:20:04 cls32 kernel: *pde = 00000000 Feb 21 13:20:04 cls32 kernel: f742bc40 00000001 f742bc48 00000296 f742bc44 f741823e 08be7dc2 f8995e1e Feb 21 13:20:04 cls32 kernel: f7419fdc 00000013 f742bc0c f7ef066c f7ef0000 f8983274 f741823e f8995e12 Feb 21 13:20:04 cls32 kernel: 00000000 00000000 00004111 00004111 f7ef1f40 c0107296 f742bc0c f8982ff0 Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [kernel_thread+38/48] [] Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [] [] Feb 21 13:20:04 cls32 kernel: Feb 21 13:20:04 cls32 kernel: Code: f0 83 28 01 0f 88 4e 16 00 00 8b 82 c0 06 00 00 83 f8 10 75 Feb 21 13:20:04 cls32 kernel: Oops: 0002 Feb 21 13:20:04 cls32 kernel: CPU: 1 Feb 21 13:20:04 cls32 kernel: EIP: 0010:[wait_for_completion+121/224] Tainted: PF Feb 21 13:20:04 cls32 kernel: EIP: 0010:[] Tainted: PF Feb 21 13:20:04 cls32 kernel: EFLAGS: 00010046 Feb 21 13:20:04 cls32 kernel: eax: f7425c4c ebx: f7424000 ecx: f7425bdc edx: 00000000 Feb 21 13:20:04 cls32 kernel: esi: f7425c44 edi: bfffc840 ebp: f7425bec esp: f7425bc4 Feb 21 13:20:04 cls32 kernel: ds: 0018 es: 0018 ss: 0018 Feb 21 13:20:04 cls32 kernel: Process afsd (pid: 749, stackpage=f7425000) Feb 21 13:20:04 cls32 kernel: Stack: 00000000 f7424000 00000000 00000000 00000001 f7424000 f7425c4c 00000000 Feb 21 13:20:04 cls32 kernel: f7425c44 00000001 00000001 f898345f f7425c14 00000000 00000000 00000000 Feb 21 13:20:04 cls32 kernel: 00000000 00000000 00000001 f7425c44 c02f8be0 c02f8be0 00000001 f8983340 Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [scrup+105/288]<1>Unable to handle kernel paging request at virtual address 800006c5 Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] []<1>Unable to handle kernel paging request at virtual address 800006c5 Feb 21 13:20:04 cls32 kernel: printing eip: Feb 21 13:20:04 cls32 kernel: c0121f5b Feb 21 13:20:04 cls32 kernel: *pde = 00000000 Feb 21 13:20:04 cls32 kernel: [ignored_signal+46/64] Feb 21 13:20:04 cls32 kernel: [] Feb 21 13:20:04 cls32 kernel: [send_sig_info+90/160] [wake_up_parent+37/64] [do_notify_parent+223/240] [poke_blanked_console+100/112] [vt_console_print+678/704] [exit_notify+1133/1152] Feb 21 13:20:04 cls32 kernel: [] [] [] [] [] [] Feb 21 13:20:04 cls32 kernel: [do_exit+760/784] [bust_spinlocks+80/96] [do_wp_page+149/704] [handle_mm_fault+162/272] [do_page_fault+285/1067] [] Feb 21 13:20:04 cls32 kernel: [] [] [] [] [] [] Feb 21 13:20:04 cls32 kernel: [do_page_fault+0/1067] [local_pre_usermode_actions+21/240] [local_syscall+7/19] Feb 21 13:20:04 cls32 kernel: [] [] [] Feb 21 13:20:04 cls32 kernel: Feb 21 13:20:04 cls32 kernel: Code: 89 0a 90 8d 74 26 00 c7 03 02 00 00 00 b0 01 86 46 04 fb e8 Feb 21 13:20:04 cls32 kernel: Oops: 0002 Feb 21 13:20:04 cls32 kernel: CPU: 0 Feb 21 13:20:04 cls32 kernel: EIP: 0010:[complete+91/464] Tainted: PF Feb 21 13:20:04 cls32 kernel: EIP: 0010:[] Tainted: PF Feb 21 13:20:04 cls32 kernel: EFLAGS: 00010086 Feb 21 13:20:04 cls32 kernel: eax: 800006c5 ebx: 00000001 ecx: 00000001 edx: 80000001 Feb 21 13:20:04 cls32 kernel: Unable to handle kernel NULL po<1ntf741nabc le po f741 f9cdle k<4>ernel NULL pointf7419fcc esp: f7419f9c Feb 21 13:20:04 cls32 kernel: ds: 0018 es: 0018 ss: 0018 Feb 21 13:20:04 cls32 kernel: Process keventd (pid: 752, stackpage=f7419000) Feb 21 13:20:04 cls32 kernel: Stack: f7425c40 00000001 f7425c48 00000296 at virtual address 00000000 Feb 21 13:20:04 cls32 kernel: printing eip: Feb 21 13:20:04 cls32 kernel: c0122149 Feb 21 13:20:04 cls32 kernel: *pde = 00000000 Feb 21 13:20:04 cls32 kernel: f7425c44 f741823e 08be7dc2 f8995dc4 Feb 21 13:20:04 cls32 kernel: f7419fdc 00000001 f7425c0c f7ef066c f7ef0000 f89830b3 f741823e f8995db8 Feb 21 13:20:04 cls32 kernel: 00000001 00000001 00004111 00004111 f7ef1f40 c0107296 f7425c0c f8982ff0 Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [kernel_thread+38/48] [] Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [] [] Feb 21 13:20:04 cls32 kernel: Feb 21 13:20:04 cls32 kernel: Code: f0 83 28 01 0f 88 4e 16 00 00 8b 82 c0 06 00 00 83 f8 10 75 Feb 21 13:20:04 cls32 kernel: Oops: 0002 Feb 21 13:20:04 cls32 kernel: CPU: 1 Feb 21 13:20:04 cls32 kernel: EIP: 0010:[wait_for_completion+121/224] Tainted: PF Feb 21 13:20:04 cls32 kernel: EIP: 0010:[] Tainted: PF Feb 21 13:20:04 cls32 kernel: EFLAGS: 00010046 Feb 21 13:20:04 cls32 kernel: eax: f741fc4c ebx: f741e000 ecx: f741fbdc edx: 00000000 Feb 21 13:20:04 cls32 kernel: esi: f741fc44 edi: bfffc840 ebp: f741fbec esp: f741fbc4 Feb 21 13:20:04 cls32 kernel: Unable to handle kernel paging request at virtual address 800006c5 Feb 21 13:20:04 cls32 kernel: printing eip: Feb 21 13:20:04 cls32 kernel: c0121f5b Feb 21 13:20:04 cls32 kernel: *pde = 00000000 Feb 21 13:20:04 cls32 kernel: ds: 0018 es: 0018 ss: 0018 Feb 21 13:20:04 cls32 kernel: Process afsd (pid: 750, stackpage=f741f000) Feb 21 13:20:04 cls32 kernel: Stack: 00000000 f741e000 00000000 00000000 00000001 f741e000 f741fc4c 00000000 Feb 21 13:20:04 cls32 kernel: f741fc44 00000004 00000004 f898345f f741fc14 00000000 00000000 00000000 Feb 21 13:20:04 cls32 kernel: 00000000 00000000 00000004 f741fc44 f7ef1f70 f7ef1f70 00000000 f8983340 Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [__alloc_pages+65/432] [do_wp_page+620/704] Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [] [] Feb 21 13:20:04 cls32 kernel: [do_wp_page+658/704] [handle_mm_fault+162/272] [do_page_fault+285/1067] [] [local_pre_usermode_actions+21/240] [local_syscall+7/19] Feb 21 13:20:04 cls32 kernel: [] [] [] [] [] [] Feb 21 13:20:04 cls32 kernel: Feb 21 13:20:04 cls32 kernel: Code: 89 0a 90 8d 74 26 00 c7 03 02 00 00 00 b0 01 86 46 04 fb e8 Feb 21 13:20:04 cls32 kernel: Oops: 0002 Feb 21 13:20:04 cls32 kernel: CPU: 0 Feb 21 13:20:04 cls32 kernel: EIP: 0010:[complete+91/464] Tainted: PF Feb 21 13:20:04 cls32 kernel: EIP: 0010:[] Tainted: PF Feb 21 13:20:04 cls32 kernel: EFLAGS: 00010086 Feb 21 13:20:04 cls32 kernel: eax: 800006c5 ebx: 00000004 ecx: 00000001 edx: 80000001 Feb 21 13:20:04 cls32 kernel: esi: f741fc48 edi: f7ef066c ebp: f7419fcc esp: f7419f9c Feb 21 13:20:04 cls32 kernel: ds: 0018 es: 0018 ss: 0018 Feb 21 13:20:04 cls32 kernel: Process keventd (pid: 753, stackpage=f7419000) Feb 21 13:20:04 cls32 kernel: Stack: f741fc40 00000001 f741fc48 00000296 f741fc44 f741823e 08be7dc2 f8995e11 Feb 21 13:20:04 cls32 kernel: f7419fdc 00000004 f741fc0c f7ef066c f7ef0000 f8983243 f741823e f8995e02 Feb 21 13:20:04 cls32 kernel: 00000004 00000004 00004111 00004111 f7ef1f40 <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000 Feb 21 13:20:04 cls32 kernel: printing eip: Feb 21 13:20:04 cls32 kernel: c0122149 Feb 21 13:20:04 cls32 kernel: *pde = 00000000 Feb 21 13:20:04 cls32 kernel: c0107296 f741fc0c f8982ff0 Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [kernel_thread+38/48] [] Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [] [] Feb 21 13:20:04 cls32 kernel: Feb 21 13:20:04 cls32 kernel: Code: f0 83 28 01 0f 88 4e 16 00 00 8b 82 c0 06 00 00 83 f8 10 75 Feb 21 13:20:04 cls32 kernel: Oops: 0002 Feb 21 13:20:04 cls32 kernel: CPU: 1 Feb 21 13:20:04 cls32 kernel: EIP: 0010:[wait_for_completion+121/224] Tainted: PF Feb 21 13:20:04 cls32 kernel: EIP: 0010:[] Tainted: PF Feb 21 13:20:04 cls32 kernel: EFLAGS: 00010046 Feb 21 13:20:04 cls32 kernel: eax: f7417c4c ebx: f7416000 ecx: f7417bdc edx: 00000000 Feb 21 13:20:04 cls32 kernel: esi: f7417c44 edi: bfffc840 ebp: f7417bec esp: f7417bc4 Feb 21 13:20:04 cls32 kernel: Unable to handle kernel paging request at virtual address 800006c5 Feb 21 13:20:04 cls32 kernel: printing eip: Feb 21 13:20:04 cls32 kernel: c0121f5b Feb 21 13:20:04 cls32 kernel: *pde = 00000000 Feb 21 13:20:04 cls32 kernel: ds: 0018 es: 0018 ss: 0018 Feb 21 13:20:04 cls32 kernel: Process afsd (pid: 754, stackpage=f7417000) Feb 21 13:20:04 cls32 kernel: Stack: 00000000 f7416000 00000000 00000000 00000001 f7416000 f7417c4c 00000000 Feb 21 13:20:04 cls32 kernel: f7417c44 00000002 00000002 f898345f f7417c14 00000000 00000000 00000000 Feb 21 13:20:04 cls32 kernel: 00000000 00000000 00000002 f7417c44 f7ef1f70 f7ef1f70 00000000 f8983340 Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [do_wp_page+149/704] [handle_mm_fault+162/272] Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [] [] Feb 21 13:20:04 cls32 kernel: [do_page_fault+285/1067] [] [local_pre_usermode_actions+21/240] [local_syscall+7/19] Feb 21 13:20:04 cls32 kernel: [] [] [] [] Feb 21 13:20:04 cls32 kernel: Feb 21 13:20:04 cls32 kernel: Code: 89 0a 90 8d 74 26 00 c7 03 02 00 00 00 b0 01 86 46 04 fb e8 Feb 21 13:20:04 cls32 kernel: Oops: 0002 Feb 21 13:20:04 cls32 kernel: CPU: 0 Feb 21 13:20:04 cls32 kernel: EIP: 0010:[complete+91/464] Tainted: PF Feb 21 13:20:04 cls32 kernel: EIP: 0010:[] Tainted: PF Feb 21 13:20:04 cls32 kernel: EFLAGS: 00010086 Feb 21 13:20:04 cls32 kernel: eax: 800006c5 ebx: 00000002 ecx: 00000001 edx: 80000001 Feb 21 13:20:04 cls32 kernel: esi: f7417c48 edi: f7ef066c ebp: f7411fcc esp: f7411f9c Feb 21 13:20:04 cls32 kernel: ds: 0018 es: 0018 ss: 0018 Feb 21 13:20:04 cls32 kernel: Process keventd (pid: 757, stackpage=f7411000) Feb 21 13:20:04 cls32 kernel: Stack: <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000 Feb 21 13:20:04 cls32 kernel: printing eip: Feb 21 13:20:04 cls32 kernel: c0122149 Feb 21 13:20:04 cls32 kernel: *pde = 00000000 Feb 21 13:20:04 cls32 kernel: f7417c40 00000001 f7417c48 00000296 f7417c44 f741023e 08befdc2 f8995dd6 Feb 21 13:20:04 cls32 kernel: f7411fdc 00000002 f7417c0c f7ef066c f7ef0000 f8983154 f741023e f8995dca Feb 21 13:20:04 cls32 kernel: f7410000 f7410000 00004111 00004111 f7ef1f40 c0107296 f7417c0c f8982ff0 Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [kernel_thread+38/48] [] Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [] [] Feb 21 13:20:04 cls32 kernel: Feb 21 13:20:04 cls32 kernel: Code: f0 83 28 01 0f 88 4e 16 00 00 8b 82 c0 06 00 00 83 f8 10 75 Feb 21 13:20:04 cls32 kernel: Oops: 0002 Feb 21 13:20:04 cls32 kernel: CPU: 1 Feb 21 13:20:04 cls32 kernel: EIP: 0010:[wait_for_completion+121/224] Tainted: PF Feb 21 13:20:04 cls32 kernel: EIP: 0010:[] Tainted: PF Feb 21 13:20:04 cls32 kernel: EFLAGS: 00010046 Feb 21 13:20:04 cls32 kernel: eax: f7415c4c ebx: f7414000 ecx: f7415bdc edx: 00000000 Feb 21 13:20:04 cls32 kernel: esi: f7415c44 edi: bfffc840 ebp: f7415bec esp: f7415bc4 Feb 21 13:20:04 cls32 kernel: ds: 0018 es: 0018 ss: 0018 Feb 21 13:20:04 cls32 kernel: Process afsd (pid: 755, stackpage=f7415000) Feb 21 13:20:04 cls32 kernel: Stack: 00000000 f7414000 00000000 00000000 00000001 f7414000 f7415c4c 00000000 Feb 21 13:20:04 cls32 kernel: <1>Unable to handle kernel paging request at virtual address 800006c5 Feb 21 13:20:04 cls32 kernel: printing eip: Feb 21 13:20:04 cls32 kernel: c0121f5b Feb 21 13:20:04 cls32 kernel: *pde = 00000000 Feb 21 13:20:04 cls32 kernel: f7415c44 00000002 00000002 f898345f f7415c14 00000000 00000000 00000000 Feb 21 13:20:04 cls32 kernel: 00000000 00000000 00000002 f7415c44 f7ef1f70 f7ef1f70 00000000 f8983340 Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [do_wp_page+149/704] [handle_mm_fault+162/272] Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [] [] Feb 21 13:20:04 cls32 kernel: [do_page_fault+285/1067] [] [local_pre_usermode_actions+21/240] [local_syscall+7/19] Feb 21 13:20:04 cls32 kernel: [] [] [] [] Feb 21 13:20:04 cls32 kernel: Feb 21 13:20:04 cls32 kernel: Code: 89 0a 90 8d 74 26 00 c7 03 02 00 00 00 b0 01 86 46 04 fb e8 Feb 21 13:20:04 cls32 kernel: Oops: 0002 Feb 21 13:20:04 cls32 kernel: CPU: 0 Feb 21 13:20:04 cls32 kernel: EIP: 0010:[complete+91/464] Tainted: PF Feb 21 13:20:04 cls32 kernel: EIP: 0010:[] Tainted: PF Feb 21 13:20:04 cls32 kernel: EFLAGS: 00010086 Feb 21 13:20:04 cls32 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Feb 21 13:20:04 cls32 kernel: printing eip: Feb 21 13:20:04 cls32 kernel: c0122149 Feb 21 13:20:04 cls32 kernel: *pde = 00000000 Feb 21 13:20:04 cls32 kernel: eax: 800006c5 ebx: 00000002 ecx: 00000001 edx: 80000001 Feb 21 13:20:04 cls32 kernel: esi: f7415c48 edi: f7ef066c ebp: f7419fcc esp: f7419f9c Feb 21 13:20:04 cls32 kernel: ds: 0018 es: 0018 ss: 0018 Feb 21 13:20:04 cls32 kernel: Process keventd (pid: 758, stackpage=f7419000) Feb 21 13:20:04 cls32 kernel: Stack: f7415c40 00000001 f7415c48 00000296 f7415c44 f741823e 08be7dc2 f8995dd6 Feb 21 13:20:04 cls32 kernel: f7419fdc 00000002 f7415c0c f7ef066c f7ef0000 f8983154 f741823e f8995dca Feb 21 13:20:04 cls32 kernel: f7418000 f7418000 00004111 00004111 f7ef1f40 c0107296 f7415c0c f8982ff0 Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [kernel_thread+38/48] [] Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [] [] Feb 21 13:20:04 cls32 kernel: Feb 21 13:20:04 cls32 kernel: Code: f0 83 28 01 0f 88 4e 16 00 00 8b 82 c0 06 00 00 83 f8 10 75 Feb 21 13:20:04 cls32 kernel: Oops: 0002 Feb 21 13:20:04 cls32 kernel: CPU: 1 Feb 21 13:20:04 cls32 kernel: EIP: 0010:[wait_for_completion+121/224] Tainted: PF Feb 21 13:20:04 cls32 kernel: EIP: 0010:[] Tainted: PF Feb 21 13:20:04 cls32 kernel: EFLAGS: 00010046 Feb 21 13:20:04 cls32 kernel: eax: f7413c4c ebx: f7412000 ecx: f7413bdc edx: 00000000 Feb 21 13:20:04 cls32 kernel: esi: f7413c44 edi: bfffc840 ebp: f7413bec esp: f7413bc4 Feb 21 13:20:04 cls32 kernel: ds: 0018 es: 0018 ss: 0018 Feb 21 13:20:04 cls32 kernel: Process afsd (pid: 756, stackpage=f7413000) Feb 21 13:20:04 cls32 kernel: Stack: 00000000 f7412000 00000000 00000000 00000001 f7412000 f7413c4c 00000000 Feb 21 13:20:04 cls32 kernel: f7413c44 00000002 00000002 f898345f f7413c14 00000000 00000000 00000000 Feb 21 13:20:04 cls32 kernel: 00000000 00000000 00000002 f7413c44 c02f8be0 c02f8be0 00000001 f8983340 Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [__alloc_pages+65/432] [do_wp_page+620/704] Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [] [] Feb 21 13:20:04 cls32 kernel: [do_wp_page+658/704] [handle_mm_fault+162/272] [do_page_fault+285/1067] []<1>Unable to handle kernel paging request [local_pre_usermode_actions+21/240] [local_syscall+7/19] Feb 21 13:20:04 cls32 kernel: [] [] [] []<1>Unable to handle kernel paging request [] [] Feb 21 13:20:04 cls32 kernel: Feb 21 13:20:04 cls32 kernel: Code: 89 0a 90 8d 74 26 00 c7 at virtual address 800006c5 Feb 21 13:20:04 cls32 kernel: 03 02 00 00 00 b0 01 86 46 04 fb e8 Feb 21 13:20:04 cls32 kernel: printing eip: Feb 21 13:20:04 cls32 kernel: c0121f5b Feb 21 13:20:04 cls32 kernel: *pde = 00000000 Feb 21 13:20:04 cls32 kernel: Oops: 0002 Feb 21 13:20:04 cls32 kernel: CPU: 0 Feb 21 13:20:04 cls32 kernel: EIP: 0010:[complete+91/464] Tainted: PF Feb 21 13:20:04 cls32 kernel: EIP: 0010:[] Tainted: PF Feb 21 13:20:04 cls32 kernel: EFLAGS: 00010086 Feb 21 13:20:04 cls32 kernel: eax: 800006c5 ebx: 00000002 ecx: 00000001 edx: 80000001 Feb 21 13:20:04 cls32 kernel: esi: f7413c48 edi: f7ef066c ebp: f7419fcc esp: f7419f9c Feb 21 13:20:04 cls32 kernel: ds: 0018 es: 0018 ss: 0018 Feb 21 13:20:04 cls32 kernel: Process keventd (pid: 759, stackpage=f7419000) Feb 21 13:20:04 cls32 kernel: Stack: f7413c40 00000001 f7413c48 00000296 f7413c44 f741823e 08be7dc2 f8995dd6 Feb 21 13:20:04 cls32 kernel: f7419fdc 00000002 f7413c0c f7ef066c f7ef0000 f8983154 f741823e f8995dca Feb 21 13:20:04 cls32 kernel: f7418000 f7418000 00004111 00004111 f7ef1f40 c0107296 f7413c0c f8982ff0 Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [kernel_thread+38/48] [] Feb 21 13:20:04 cls32 kernel: Call Trace: [] [] [] [] [] Feb 21 13:20:04 cls32 kernel: Feb 21 13:20:04 cls32 kernel: Code: f0 83 28 01 0f 88 4e 16 00 00 8b 82 c0 06 00 00 83 f8 10 75 La stessa cosa si ottiene modificando lo spec file in modo che non utilizzi il .h relativo alle redhat fix. # Now build all the kernel modules for vers in $kvers ; do # Reconfigure sources for this kernel version, to catch various # kernel params in the configure script. Yes. this takes more time, # but it's worth it in the long run.. But first remove config.cache # to be sure we get a clean configuration. rm -f config.cache ./configure --with-afs-sysname=${sysname} \ --with-linux-kernel-headers=%{kbase}$vers%{kend} \ $config_opts KTL="SP MP" %if %{enterprisekernelsupport} # See if we should build EP support if grep -q -r __BOOT_KERNEL_ENTERPRISE %{kbase}$vers%{kend}/include then KTL="${KTL} EP" fi %endif %if %{bigmemkernelsupport} # See if we should build BM support if grep -q -r __BOOT_KERNEL_BIGMEM %{kbase}$vers%{kend}/include then KTL="${KTL} BM" fi %endif for mp in $KTL; do # ... for all appropriate 'architectures'... if [ %{kernvers} = 22 ]; then # For 2.2 kernels, just do MP and SP kernels; force EP into i686 arch=${sysbase} if [ $mp = EP -a ${sysbase} = i386 ]; then arch=i686 fi #PrintRedhatKernelFix $arch $mp src/config/redhat-fix.h #make dest_only_libafs LOCAL_SMP_DEF=-DREDHAT_FIX MPS=$mp make dest_only_libafs MPS=$mp elif [ %{kernvers} = 24 ]; then # For 2.4 kernels, need to build modules for each architecture! for arch in $archlist ; do # build SP and MP on all architectures. # build EP and BM only on i686 if [ $mp = SP -o $mp = MP -o \ \( $mp = EP -a $arch = i686 \) -o \ \( $mp = BM -a $arch = i686 \) ]; then #PrintRedhatKernelFix $arch $mp src/config/redhat-fix.h #make dest_only_libafs LOCAL_SMP_DEF=-DREDHAT_FIX \ # LINUX_MODULE_NAME="-$arch" MPS=$mp make dest_only_libafs LINUX_MODULE_NAME="-$arch" MPS=$mp fi done else echo "I don't know how to build $sysname" exit 1 fi done done #rm -f src/config/redhat-fix.h Idee ? Grazie Soraruf Alessandro ----------------------------------------------------- Invia un sms gratis! http://freesms.supereva.it/index.php messaggio inviato con Freemail by www.superEva.it ----------------------------------------------------- From openmosix@democritos.it Wed Feb 26 14:16:56 2003 From: openmosix@democritos.it (ZIGLIO Frediano) Date: Wed, 26 Feb 2003 15:16:56 +0100 Subject: [openMosix-it] openAFS oops Message-ID: <8336127823F7D2118D4A0008C70D63850A70606A@opdmexo02.omnitel.it> > > Salve a tutti > > seguendo i consigli avuti in mailinglist ho provato ad > installare openAFS come filesystem per sharare i dati alle > applicazioni che girano sul cluster. > Ho scaricato i sorgenti e gli rpm della versione 1.2.8 per la > redhat 7.1 che stiamo utilizzando sul cluster. > Ho ricreato i pacchetti rpm applicando l'ultima patch di > Clement Omine e ricompilando non trovava degli include Non so a che patch ti riferisci, suppongo che sia una patch per integrarsi con openMosix e magari avere il supporto DFSA... Credo tu ti sia rivolto alla mailing list inglese perche' e' la prima mail su openAFS che vedo. > relativi ad hpc quindi ho creato una patch per includere tale > directory nei sorgenti: > -------------------------------------------------------------- > ---------------------------------------------- > diff -bwur openafs-1.2.8/src/libafs/MakefileProto.LINUX.in > openafs-1.2.8oM/src/libafs/MakefileProto.LINUX.in > --- openafs-1.2.8/src/libafs/MakefileProto.LINUX.in Thu > Nov 14 23:18:04 2002 > +++ openafs-1.2.8oM/src/libafs/MakefileProto.LINUX.in Fri > Feb 21 15:30:40 2003 > @@ -123,6 +123,8 @@ > # Compile SP and MP clients as requested > > ${COMPDIRS} ${INSTDIRS} ${DESTDIRS}: > + $(RM) -f hpc > + ln -s ${LINUX_KERNEL_PATH}/include/hpc hpc > $(RM) -f h > ln -s ${LINUX_KERNEL_PATH}/include/linux h > $(RM) -f linux > -------------------------------------------------------------- > ---------------------------------------------- > In questo modo aggiungendo le due patch nello spec file sono > riuscito ad ottenere gli rpm aggiornati che ho installato su due nodi > per testarli. > Lato server tutto ok Cioe' il cluster? > Lato client allo startup di afs si ottengono una serie di > oops, dopo che ha caricato il modulo e sta tentando di far > partire l'afsd ,che bloccano la macchina. > Qui sono macchine fuori non cluster immagino. > > Feb 21 13:20:03 cls32 rc: Starting sshd: succeeded > Feb 21 13:20:04 cls32 kernel: Unable to handle kernel NULL > pointer dereference at virtual address 00000000 !!! dovrebbe essere un bug molto severo del driver (o modulo) openAFS. Hanno risolto degli errori a riguardo per la 1.2.8 (vedendo il changelog) ma forse ne e' rimasto qualcuno. ... omissis ... > > La stessa cosa si ottiene modificando lo spec file in modo > che non utilizzi il .h relativo alle redhat fix. > Le RedHat fix erano quindi relative alla patch di Omine ? .. omissis... > > Idee ? > Magari... ciao freddy77 ================================= "STRICTLY PERSONAL AND CONFIDENTIAL This message may contain confidential and proprietary material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. The contents of this message that do not relate to the official business of our company shall be understood as neither given nor endorsed by it." ================================= From openmosix@democritos.it Wed Feb 26 14:30:16 2003 From: openmosix@democritos.it (openmosix@democritos.it) Date: 26 Feb 2003 14:30:16 -0000 Subject: [openMosix-it] openAFS oops Message-ID: <20030226143016.1928.qmail@mail.supereva.it> >> >> Salve a tutti >> >> seguendo i consigli avuti in mailinglist ho provato ad >> installare openAFS come filesystem per sharare i dati alle >> applicazioni che girano sul cluster. >> Ho scaricato i sorgenti e gli rpm della versione 1.2.8 per la >> redhat 7.1 che stiamo utilizzando sul cluster. >> Ho ricreato i pacchetti rpm applicando l'ultima patch di >> Clement Omine e ricompilando non trovava degli include > >Non so a che patch ti riferisci, suppongo che sia una patch per integrarsi con >openMosix e magari avere il supporto DFSA... >Credo tu ti sia rivolto alla mailing list inglese perche' e' la prima mail >su openAFS che vedo. In effetti la patch di Omine e' apparsa solo sulla mailinglist inglese. Questa patch corregge un bug del modulo del kernel che causa il freez della macchina quando e' usato con openmoisix, a causa di un problema con la mmap. Non aggiunge il supporto DFSA. >> relativi ad hpc quindi ho creato una patch per includere tale > directory nei >sorgenti: >> -------------------------------------------------------------- >> ---------------------------------------------- >> diff -bwur openafs-1.2.8/src/libafs/MakefileProto.LINUX.in >> openafs-1.2.8oM/src/libafs/MakefileProto.LINUX.in >> --- openafs-1.2.8/src/libafs/MakefileProto.LINUX.in Thu >> Nov 14 23:18:04 2002 >> +++ openafs-1.2.8oM/src/libafs/MakefileProto.LINUX.in Fri >> Feb 21 15:30:40 2003 >> @@ -123,6 +123,8 @@ >> # Compile SP and MP clients as requested >> >> ${COMPDIRS} ${INSTDIRS} ${DESTDIRS}: >> + $(RM) -f hpc >> + ln -s ${LINUX_KERNEL_PATH}/include/hpc hpc >> $(RM) -f h >> ln -s ${LINUX_KERNEL_PATH}/include/linux h >> $(RM) -f linux >> -------------------------------------------------------------- >> ---------------------------------------------- >> In questo modo aggiungendo le due patch nello spec file sono >> riuscito ad ottenere gli rpm aggiornati che ho installato su due nodi >> per testarli. >> Lato server tutto ok > >Cioe' il cluster? No. nelle mail precedenti ho riportato alcuni problemi con MFS ed NFS e quindi mi e' stato consigliato di utilizzare openafs per distribuire i dati dal front-end del cluster verso gli altri nodi e da li poi passare su MFS per permettere la migrazione. >> Lato client allo startup di afs si ottengono una serie di > oops, dopo che ha >caricato il modulo e sta tentando di far >> partire l'afsd ,che bloccano la macchina. >> > >Qui sono macchine fuori non cluster immagino. No. sono i nodi del cluster ;-) > >> >> Feb 21 13:20:03 cls32 rc: Starting sshd: succeeded >> Feb 21 13:20:04 cls32 kernel: Unable to handle kernel NULL >> pointer dereference at virtual address 00000000 > >!!! dovrebbe essere un bug molto severo del driver (o modulo) openAFS. Hanno >risolto degli errori a riguardo per la 1.2.8 (vedendo il changelog) ma forse ne >e' rimasto qualcuno. Non ho riscontrato nulla di simile nell'archivio della ml... :-( > >... omissis ... >> >> La stessa cosa si ottiene modificando lo spec file in modo >> che non utilizzi il .h relativo alle redhat fix. >> > >Le RedHat fix erano quindi relative alla patch di Omine ? No. Ho visto che nello spec file c'e una funzione che genera un include .h per adattare il modulo ai kernel redhat che come e' noto hanno applicate sulle 100 patch ;-) ecco il perche i kernel si chiamano 2.4.18-18.7 ad esempio. > >.. omissis... > >> Idee ? >> > >Magari... L'hai detto ;-) > >ciao > freddy77 > ciao Soraruf Alessandro >================================= >"STRICTLY PERSONAL AND CONFIDENTIAL > >This message may contain confidential and proprietary material for the sole use >of the intended recipient. Any review or distribution by others is >strictly prohibited. If you are not the intended recipient please contact >the sender and delete all copies. >The contents of this message that do not relate to the official business of our >company shall be understood as neither given nor endorsed by it." > >================================= >_______________________________________________ >openMosix mailing list >openMosix@democritos.it >http://www.democritos.it/mailman/listinfo/openmosix > > ----------------------------------------------------- Invia un sms gratis! http://freesms.supereva.it/index.php messaggio inviato con Freemail by www.superEva.it ----------------------------------------------------- From openmosix@democritos.it Wed Feb 26 14:37:35 2003 From: openmosix@democritos.it (ZIGLIO Frediano) Date: Wed, 26 Feb 2003 15:37:35 +0100 Subject: [openMosix-it] openAFS oops Message-ID: <8336127823F7D2118D4A0008C70D63850A70606B@opdmexo02.omnitel.it> ... > >Le RedHat fix erano quindi relative alla patch di Omine ? > > No. Ho visto che nello spec file c'e una funzione che genera > un include .h per > adattare il modulo ai kernel redhat che come e' noto hanno > applicate sulle 100 > patch ;-) ecco il perche i kernel si chiamano 2.4.18-18.7 ad esempio. > Due cose ho visto che fa l'rpm. Primo controlla che ci sia il pacchetto kernel-source (hai installato un kernel-source per open-mosix), secondo cerca la versione del kernel e il metodo che usa a me trovava il kernel di RedHat e non quello openMosix (potendo causare infiniti problemi dato che alcune strutture sono differenti). Quello che fa dovrebbe essere vedere dove punta linux-2.4 e usare quella directory. Non so se ti puo' servire ma meglio provare. Te ne accorgi perche' dando rpmbuild --rebuild un po' prima della configurazione scrive la directory dove trova il kernel. freddy77 ================================= "STRICTLY PERSONAL AND CONFIDENTIAL This message may contain confidential and proprietary material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. The contents of this message that do not relate to the official business of our company shall be understood as neither given nor endorsed by it." ================================= From openmosix@democritos.it Wed Feb 26 14:53:28 2003 From: openmosix@democritos.it (openmosix@democritos.it) Date: 26 Feb 2003 14:53:28 -0000 Subject: [openMosix-it] openAFS oops Message-ID: <20030226145328.26930.qmail@mail.supereva.it> >... > >> >Le RedHat fix erano quindi relative alla patch di Omine ? >> >> No. Ho visto che nello spec file c'e una funzione che genera >> un include .h per >> adattare il modulo ai kernel redhat che come e' noto hanno >> applicate sulle 100 >> patch ;-) ecco il perche i kernel si chiamano 2.4.18-18.7 ad esempio. >> > >Due cose ho visto che fa l'rpm. >Primo controlla che ci sia il pacchetto kernel-source (hai installato un >kernel-source per open-mosix), secondo cerca la versione del kernel e il >metodo che usa a me trovava il kernel di RedHat e non quello openMosix >(potendo causare infiniti problemi dato che alcune strutture sono >differenti). >Quello che fa dovrebbe essere vedere dove punta linux-2.4 e usare quella >directory. >Non so se ti puo' servire ma meglio provare. >Te ne accorgi perche' dando rpmbuild --rebuild un po' prima della >configurazione scrive la directory dove trova il kernel. > >freddy77 > Ho notato che lui utilizza tutti i kernel tree che iniziano per linux- nella dir /usr/src (comportamento configurabile all'inizio dello spec file) difatti mi ha compilato i moduli per entrambe le versioni del kernel che avevo li. Per quanto rigurda il pacchetto kernel-source io ho rimosso la dipendenza dallo spec file tanto questo non e' altro che il tree dei sorgenti in /usr/src. Per quanto riguarda poi il caricamento del modulo lo fa all'avvio controllando la versione del kernel corrente e lancia il modulo corretto di conseguenza Se esamini il pacchetto risultante vedrai: -> openafs-kernel-1.2.8-rh7.1.1.i686.rpm /usr/vice/etc/modload/SymTable /usr/vice/etc/modload/libafs-2.4.20-openmosix-1-athlon.mp.o /usr/vice/etc/modload/libafs-2.4.20-openmosix-1-athlon.o /usr/vice/etc/modload/libafs-2.4.20-openmosix-1-i386.mp.o /usr/vice/etc/modload/libafs-2.4.20-openmosix-1-i386.o /usr/vice/etc/modload/libafs-2.4.20-openmosix-1-i586.mp.o /usr/vice/etc/modload/libafs-2.4.20-openmosix-1-i586.o /usr/vice/etc/modload/libafs-2.4.20-openmosix-1-i686.mp.o /usr/vice/etc/modload/libafs-2.4.20-openmosix-1-i686.o /usr/vice/etc/modload/libafs-2.4.20-openmosix2smp-athlon.mp.o /usr/vice/etc/modload/libafs-2.4.20-openmosix2smp-athlon.o /usr/vice/etc/modload/libafs-2.4.20-openmosix2smp-i386.mp.o /usr/vice/etc/modload/libafs-2.4.20-openmosix2smp-i386.o /usr/vice/etc/modload/libafs-2.4.20-openmosix2smp-i586.mp.o /usr/vice/etc/modload/libafs-2.4.20-openmosix2smp-i586.o /usr/vice/etc/modload/libafs-2.4.20-openmosix2smp-i686.mp.o /usr/vice/etc/modload/libafs-2.4.20-openmosix2smp-i686.o facendo un semplice uname -r lui sa che modulo caricare. Trascura il 2.4.20-1-... non avevo corretto l'extraversion nel makefile come fa lo spec file di openmosix utilizzando perl; tanto quel kernel non lo utilizzo. ho gia provato anche a non applicare la patch di Omine ma non cambia nulla... grazie Soraruf Alessandro > >This message may contain confidential and proprietary material for the sole use >of the intended recipient. Any review or distribution by others is >strictly prohibited. If you are not the intended recipient please contact >the sender and delete all copies. >The contents of this message that do not relate to the official business of our >company shall be understood as neither given nor endorsed by it." > >================================= >_______________________________________________ >openMosix mailing list >openMosix@democritos.it >http://www.democritos.it/mailman/listinfo/openmosix > > ----------------------------------------------------- Invia un sms gratis! http://freesms.supereva.it/index.php messaggio inviato con Freemail by www.superEva.it -----------------------------------------------------