Problem with kernel 2.6.11

Problem with kernel 2.6.11

[FyD]

Dear All,

I have a problem with a program named Gaussian (http://www.gaussian.com)
(versions g98 or g03) and FC 4.0 (default kernel 2.6.11): I am used to take
Gaussian binaries compiled on the RedHat 9.0 version, and used them on FC 2.0
or FC 3.0. If I try to do so, on FC 4.0. (with the default kernel) Gaussian
stops (both g98 and g03 versions) with the following error message:

[fyd@localhost ~]$ g98 < toto-g98.com> toto-g98.log
[fyd@localhost ~]$ g03 < toto-g03.com> toto-g03.log
Erroneous write during file extend. write 208 instead of 4096
Probably out of disk space.
Write error in NtrExt1: No such file or directory

And obviously, I do _not_ have any problem of space and no NFS server on my
machine...

Now if I compile and use the kernel 2.6.12, this message dispears and the
program Gaussian g98 works fine, but I still have problems with the version g03
which stops without providing any message...

>From my tests, it seems to be a problem relative to the kernel. Being not a
programmer, it is difficult for me to imagine the problem, and even to describe
it...

Any idea what could be the problem ? Any suggestions about options I should
use/not_use in the kernel, or about a specific kernel 2.6 version I should use
?

Thank you, best regards, Francois

PS Please add my email address in CC since I did not register...

Re: Problem with kernel 2.6.11

[Alistair John Strachan]

On Thursday 14 Jul 2005 20:34, FyD wrote:
> Dear All,
>
> I have a problem with a program named Gaussian (http://www.gaussian.com)
> (versions g98 or g03) and FC 4.0 (default kernel 2.6.11): I am used to take
> Gaussian binaries compiled on the RedHat 9.0 version, and used them on FC
> 2.0 or FC 3.0. If I try to do so, on FC 4.0. (with the default kernel)
> Gaussian stops (both g98 and g03 versions) with the following error
> message:
>
> [fyd@localhost ~]$ g98 < toto-g98.com> toto-g98.log
> [fyd@localhost ~]$ g03 < toto-g03.com> toto-g03.log
> Erroneous write during file extend. write 208 instead of 4096
> Probably out of disk space.
> Write error in NtrExt1: No such file or directory
>
> And obviously, I do _not_ have any problem of space and no NFS server on my
> machine...
>
> Now if I compile and use the kernel 2.6.12, this message dispears and the
> program Gaussian g98 works fine, but I still have problems with the version
> g03 which stops without providing any message...
>
> From my tests, it seems to be a problem relative to the kernel. Being not a
> programmer, it is difficult for me to imagine the problem, and even to
> describe it...

Install "strace", then run the programs like:

strace g98 < toto-g98.com> toto-g98.log

You'll be able to see what syscalls fail and their decoded return values. This 
is extremely useful for determining how a binary application is interacting 
with libc and, inevitably, the kernel.

-- 
Cheers,
Alistair.

personal:   alistair()devzero!co!uk
university: s0348365()sms!ed!ac!uk
student:    CS/CSim Undergraduate
contact:    1F2 55 South Clerk Street,
            Edinburgh. EH8 9PP.

Re: Problem with kernel 2.6.11

[FyD]

Quoting Alistair John Strachan <s0348365@sms.ed.ac.uk>:

> > I have a problem with a program named Gaussian (http://www.gaussian.com)
> > (versions g98 or g03) and FC 4.0 (default kernel 2.6.11): I am used to take
> > Gaussian binaries compiled on the RedHat 9.0 version, and used them on FC
> > 2.0 or FC 3.0. If I try to do so, on FC 4.0. (with the default kernel)
> > Gaussian stops (both g98 and g03 versions) with the following error
> > message:
> >
> > [fyd@localhost ~]$ g98 < toto-g98.com> toto-g98.log
> > [fyd@localhost ~]$ g03 < toto-g03.com> toto-g03.log
> > Erroneous write during file extend. write 208 instead of 4096
> > Probably out of disk space.
> > Write error in NtrExt1: No such file or directory
> >
> > And obviously, I do _not_ have any problem of space and no NFS server on my
> > machine...
> >
> > Now if I compile and use the kernel 2.6.12, this message dispears and the
> > program Gaussian g98 works fine, but I still have problems with the version
> > g03 which stops without providing any message...
> >
> > From my tests, it seems to be a problem relative to the kernel. Being not a
> > programmer, it is difficult for me to imagine the problem, and even to
> > describe it...
>
> Install "strace", then run the programs like:
> strace g98 < toto-g98.com> toto-g98.log
> You'll be able to see what syscalls fail and their decoded return values.
> This
> is extremely useful for determining how a binary application is interacting
> with libc and, inevitably, the kernel.

If I do strace g98 < toto-g98.com> toto-g98.log
The job finished well and the end of the strace output is:

stat64("/usr/local/g98/l1.exe", {st_mode=S_IFREG|0755, st_size=516678, ...}) = 0
write(1, " Entering Gaussian System, Link "..., 137) = 137
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD,
parent_tidptr=0xbf9db204) = 3175
waitpid(3175, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 3175
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
stat64("/home/fyd/0QM_SCR/Gau-3174.inp", 0xbf9db114) = -1 ENOENT (No such file
or directory)
munmap(0x43a45000, 4096)                = 0
exit_group(0)                           = ?


If I do strace g03 < toto-g03.com> toto-g03.log
The job finished stop with any warning and the end of the strace output is:

stat64("/usr/local/g03/l1.exe", {st_mode=S_IFREG|0750, st_size=460870, ...}) = 0
write(1, " Entering Gaussian System, Link "..., 137) = 137
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [RTMIN], 8) = 0
fork()                                  = 3237
wait4(3237, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], 0, NULL) = 3237
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
stat64("/home/fyd/0QM_SCR/Gau-3236.inp", {st_mode=S_IFREG|0644, st_size=554,
...}) = 0
unlink("/home/fyd/0QM_SCR/Gau-3236.inp") = 0
_exit(1)                                = ?

There is a difference at the end of each strace log file. But what does it mean
?

Thanks, Francois

PS Please once again, add my email address in CC since I did not register...

Re: Problem with kernel 2.6.11

[Bernd Schubert]

Hello Francois,

> > > I have a problem with a program named Gaussian (http://www.gaussian.com)
> > > (versions g98 or g03) and FC 4.0 (default kernel 2.6.11): I am used to take
> > > Gaussian binaries compiled on the RedHat 9.0 version, and used them on FC
> > > 2.0 or FC 3.0. If I try to do so, on FC 4.0. (with the default kernel)
> > > Gaussian stops (both g98 and g03 versions) with the following error
> > > message:

could you please tell me which compiler you used to compile Gaussian?
Its rather probably pgf77 (PGI), but the version is also important. If
it was 5.2, you just ran into bugs we already experienced some time ago.
I also posted a warning about that to the CCL list. On the CCL list I also saw
there were problems with PGI-6.0, but I never bothered to test this
myself, as our gaussian-binaries compiled with PGI-5.1 seem to work
fine. Also, binaries from the PGI compiler are to our experience rather
sensible to the glibc version. I'm not absolutely sure whats causing
that, but somehow I'm under the impression that the PGI-libraries, which all
binaries created with the PGI compiler are linked with, do some odd
optimizations.  So to make sure that its really a kernel issue you should use the 
libc of the compiler system (via LD_LIBRARY_PATH) or compile Gaussian
statically.

> stat64("/home/fyd/0QM_SCR/Gau-3174.inp", 0xbf9db114) = -1 ENOENT (No such file

I'm a bit tired now and maybe I'm interpreting it wrong, but I think you
should use strace -f ...

> rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0
> --- SIGCHLD (Child exited) @ 0 (0) ---

Same here.

Cheers,
	Bernd

-- 
Bernd Schubert
PCI / Theoretische Chemie
Universität Heidelberg
INF 229
69120 Heidelberg
e-mail: bernd.schubert@pci.uni-heidelberg.de