This "sent-again" to refer that I have examined the *.out file for the mpqc b3lyp MCSearch OO geometry optimization for the C22H25NO6 molekule.
max_iteration = 40 was felt, because the calculation went to iteration 13 (converged at line optimization step 3), when the system crashed (kernel panic!) at iter 5 during iteration 14, with no sign of irregularity in the output file. It seems to me that this rules out any failure due to the application. What remains open is: ---Check of the ECC 8GB memories (I don't know how in this sytem); ---Kernel failure (this is very likely the problem and I am waiting to know what to do: I am no more inclined to a purge and new install of the kernel because the existing alternative (generic kernel) seems also to deserve now little if any confidence. I must add that with the equivalent k7 kernel for i386 32bit I never had problems. francesco _________________ Sent again because there are two more kernels (k7) today and further problems arose with present kernel, as well as for a question on memories and a reply to "what do you think". Today linux-image-2.6.15-1-amd64-k8-smp starts without, however, accepting the user password. To get that accepted, I had to launch from linux-image-2.6-amd64-generic #2 Mon Mar 20 10:43:41 UTC 2006 x86_64 GNU/Linux (the one from installation) On Tuesday 11 July 2006 20:15, helices wrote: > * Francesco Pietra <[EMAIL PROTECTED]> [2006:07:11:15:56:12+0200] scribed: > > If this is the situation, I hope that a suggestion will come whether to > > unistall (I still have the generic kernel) > > linux-image-2.6.15-1-amd64-k8-smp > > and install > > linux-image-2.6.16-1-amd64-k8-smp > > should it exist. Why replacement does not occur on > > #aptitude upgrdade > > ? > > > > If I am not alone having problems, or the problems I reported seem to be > > caused by the OS system, this is a situation to clarify. One does not > > come to 64bit to run applications that can be run at the same level of > > efficiency at 32bit (personally I'll never install such applications as > > kde gnome openoffice, etc at 64bit, or 32bit chroots or ia386 (although > > lib32 are installed by the system against my will!) as I have my old pc > > for that). One comes to 64bit for the floating point and the precision. > > > > Until a clarification and a path to follow I must sadly say that I am > > stopped with quantum mechanical calculations. > > What do you get with the following? > > COLUMNS=200 dpkg -l 'linux-image*' | sed 's!^....!!;s! .*$!!' | grep ^l $ COLUMNS=200 dpkg -l 'linux-image*' | sed 's!^....!!;s! .*$!!' | grep ^l linux-image linux-image-2.6 linux-image-2.6-386 linux-image-2.6-486 linux-image-2.6-686 linux-image-2.6-686-smp linux-image-2.6-amd64-generic linux-image-2.6-amd64-k8 linux-image-2.6-amd64-k8-smp linux-image-2.6-em64t-p4 linux-image-2.6-k7 linux-image-2.6-k7-smp linux-image-2.6-em64t-p4-smp linux-image-2.6.15-1-amd64-generic linux-image-2.6.15-1-amd64-k8 linux-image-2.6.15-1-amd64-k8-smp linux-image-2.6.15-1-em64t-p4 linux-image-2.6.15-1-em64t-p4-smp linux-image-amd64-generic linux-image-amd64-k8 linux-image-amd64-k8-smp linux-image-em64t-p4 linux-image-em64t-p4-smp Memories are eight slots Kingston KVR400D4R3A/1G PC400 1GB > > Simple deduction indicates that your problem has three (3) possible root > causes: > > [1] memory[leak?] Taking into account that the above k8-smp kernel failed to start a few days ago, and the systemcould be recovered with reinstall/install, followed yesterday by a breakdown while computing, and finally failure today to accept user password, my naive impression is that of a kernel to get free of. What about, instead of reinstall/install, carry out a purge/remove from this k8-smp kernel and reinstall it freshly by downloading it? If I had no adviser I would do that. AT ANY EVENT, is it any software to carry out an exhaustive check of the 8 slots of ECC memories? You appreciate that I can not rely on a system that works correctly for a few hours only, while Sarge does not support my hardware. > [2] kernel > [3] application > > IMHO, the simplest to change, and to test, is [2]. > > What do you think? Although it may be idiosyncratic, I am very uncomfortable at the /lib32 that the system insists to install even after a purge/remove from them. See the list: /lib libwrap.so.0.76 lsb modules security terminfo udev x86_64-linux-gnu /lib64 -> /lib /lib32 -> /emul/ia32-linux/lib ld-2.3.6.so ld-linux.so.2 libanl-2.3.6.so libanl.so.1 libBrokenLocale.so.1 libc-2.3.6.so libcidn-2.3.6.so libcidn.so.1 libc.so.6 libdl.so.2 libm-2.3.6.so libmemusage.so libm.so.6 libnsl.so.1 libnss_compsat-2.3.6.2 libnss_compsat.so.2 libnss_dns-2.3.6.so libnss_files-2.3.6.so libnss_files.so.2 libnss_hesiod-2.3.6.so libnss_hesiod.so.2 libnss_nis-2.3.6.so libnss_nisplus-2.3.6.so libnss_nisplus.so.2 libnss_nis.so.2 libpcprofile.so libpthread-2.3.6.so libpthread.so.0 libresolv.so.2 librt.so.1 lib.SegFault.so libthread_db-1.0.so libthread_db.so.1 libutil-2.3.6.so libutil.so.1 I would prefer a system that allows to work with /lib64 only, thus excluding all that it is not ready for 64bit. I wonder also whether it is in the economy to bring to 64bit applications that run satisfactorily at 32bit, instead of concentrating efforts to make the system robust for 64bit. What about BSD and Solaris from the latter viewpoit (and the point of view of the 265 amd64 dual opteron)? This question because my coworkers are pressing for my contribution. What I am aswering them today is that I am down but the problem may be simpler than it appears: simply a faulty installation of the kernel, one can not be recovered with #apt-get --reinstall install linux-image-2.6.15-1-amd64-k8-smp Cheers francesco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]