Re: failure to start kernel k8-smp
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 <frapietra@alice.it> [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
Reply to: