I never did get D@H to run on my RHEL3 machine. I was wondering if anyone had gotten D@H to get good results from a Linux 2.4.x kernel machine?
I did the "ulimit -s unlimited" fix and "ulimit -a" says the fix took but the program errors out after about 12 minutes although it's not on a segment violation as far as I can tell. It looks like it just realises it's messing up the calculations and errors out.
The machine has 2 GB of ECC memory and has run flawlessly as a web/mail/dns/usenet(text only usenet) server for 2 years. Current uptime is about 50 days and that reboot was because I changed some things and wanted to get a fresh boot to make sure they took.
____________
The views expressed are my own.
Facts are subject to memory error :-)
Have you read a good science fiction novel lately?
It runs fine on Damn Small Linux (kernel 2.4.26), for some reason this distro also doesn't need the ulimit fix either, even though the default stack limit is 8192.
____________
It runs fine on Damn Small Linux (kernel 2.4.26), for some reason this distro also doesn't need the ulimit fix either, even though the default stack limit is 8192.
Now that is really puzzling!
I gave up on RHEL3 and have even removed boinc from it, for security reasons, since it IS a server.
I'm really beginning to wonder about these Fortran compilers. From what I can tell by reading "Understanding the Linux Kernel" 2nd Edition, the expansion of the stack depends on the programs stack pointer being at, or a little below, the memory reference causing the page fault. I'm wondering if Fortran does something funny with the stack frame.
IIRC, someone in either the boinc message boards or developer/projects mailing lists said something about another project having corrupted data if interrupts occurred at the right point during Fortran execution. I was trying to find what was happening with the stack problem and found that running Fortran in the GBD debugger will cause it to get corrupted data errors. I'm beginning to think that the Fortran compiler is outputting code that references data BELOW the stack pointer in memory and it gets corrupted when the return address for the interrupt is pushed on the stack.
I'm also wondering if the reason D@H requires an unlimited stack on some Linux systems is because the stack behavior changes and when the page fault occurs, Linux just allocates the page without checking the stack pointer if it's set to "unlimited" and the page fault occurs in the address space that Linux reserves for the stack to grow into.
____________
The views expressed are my own.
Facts are subject to memory error :-)
Have you read a good science fiction novel lately?
Some very good thinking there David! Certainly something we will look into. If you find out ny more info on this, please post.
Thanks
Andre
It runs fine on Damn Small Linux (kernel 2.4.26), for some reason this distro also doesn't need the ulimit fix either, even though the default stack limit is 8192.
Now that is really puzzling!
I gave up on RHEL3 and have even removed boinc from it, for security reasons, since it IS a server.
I'm really beginning to wonder about these Fortran compilers. From what I can tell by reading "Understanding the Linux Kernel" 2nd Edition, the expansion of the stack depends on the programs stack pointer being at, or a little below, the memory reference causing the page fault. I'm wondering if Fortran does something funny with the stack frame.
IIRC, someone in either the boinc message boards or developer/projects mailing lists said something about another project having corrupted data if interrupts occurred at the right point during Fortran execution. I was trying to find what was happening with the stack problem and found that running Fortran in the GBD debugger will cause it to get corrupted data errors. I'm beginning to think that the Fortran compiler is outputting code that references data BELOW the stack pointer in memory and it gets corrupted when the return address for the interrupt is pushed on the stack.
I'm also wondering if the reason D@H requires an unlimited stack on some Linux systems is because the stack behavior changes and when the page fault occurs, Linux just allocates the page without checking the stack pointer if it's set to "unlimited" and the page fault occurs in the address space that Linux reserves for the stack to grow into.
____________
D@H the greatest project in the world... a while from now!
ID:
2439 | Rating: 0
| rate:
/
Memo
Forum moderator
Project developer
Project tester
Joined: Sep 13 06
Posts: 88
ID: 14
Credit: 1,666,392
RAC: 0
My two active linux boxes are running slackware with 2.4.X
It runs fine on Damn Small Linux (kernel 2.4.26), for some reason this distro also doesn't need the ulimit fix either, even though the default stack limit is 8192.
Now that is really puzzling!
I gave up on RHEL3 and have even removed boinc from it, for security reasons, since it IS a server.
I'm really beginning to wonder about these Fortran compilers. From what I can tell by reading "Understanding the Linux Kernel" 2nd Edition, the expansion of the stack depends on the programs stack pointer being at, or a little below, the memory reference causing the page fault. I'm wondering if Fortran does something funny with the stack frame.
IIRC, someone in either the boinc message boards or developer/projects mailing lists said something about another project having corrupted data if interrupts occurred at the right point during Fortran execution. I was trying to find what was happening with the stack problem and found that running Fortran in the GBD debugger will cause it to get corrupted data errors. I'm beginning to think that the Fortran compiler is outputting code that references data BELOW the stack pointer in memory and it gets corrupted when the return address for the interrupt is pushed on the stack.
I'm also wondering if the reason D@H requires an unlimited stack on some Linux systems is because the stack behavior changes and when the page fault occurs, Linux just allocates the page without checking the stack pointer if it's set to "unlimited" and the page fault occurs in the address space that Linux reserves for the stack to grow into.
It may also be worthwhile comparing with knoppix too. DSL is a knoppix derivative which is a debian derivative. My debian boxes with 8192 stack limit need the ulimit fix, yet dsl also with a 8192 stack limit don't.
____________