[QUOTE=garo;568950] I'm also running as admin so basically security nightmare. So far so good. But now when Prime95 runs the Jacobi benchmarks it is unable to write a checkpoint so forgets about progress and restarts from the last checkpoint written on disk. This seems undesirable in my opinion. If for whatever reason the disk becomes temporarily unavailable, running the Jacobi benchmarks can wipe all progress.[/QUOTE]

This has nothing to do with Jacobi. Since Prime95 cannot write a save file to resume from Jacobi, it will also not be able to write to the results file, nor the spool file prior to sending results to PrimeNet, nor the worktodo file when getting new work.

Why running as Administrator does not solve your problem? I have no idea.

[QUOTE=garo;568950]...
Kaspersky was bugging me so I said yes to some security fixes it wanted to do. I'm running Prime95 from the Program Files folder in Windows 7. Always have. I know it's frowned upon now but old habits die hard. So Prime95 stopped being able to write to the folder because Kaspersky had messed wth the ownership.
...[/QUOTE]
[QUOTE=Prime95;568956]This has nothing to do with Jacobi. Since Prime95 cannot write a save file to resume from Jacobi, it will also not be able to write to the results file, nor the spool file prior to sending results to PrimeNet, nor the worktodo file when getting new work.

Why running as Administrator does not solve your problem? I have no idea.[/QUOTE]If the folder is owned by "NT Service/TrustedInstaller", the members of the Administrator group might not have access. Better install the program in "Program Data" or in a user folder if Kapersky makes a mess of the permissions.

Jacob

Thanks for confirming that George. This is exactly what I meant: [QUOTE]Since Prime95 cannot write a save file to resume from Jacobi,[/QUOTE]Resuming from Jacobi requires reading from a savefile.

@Jacob: The owner of that folder is Administrators but Kaspersky has basically stopped my user (who is an Administrator) from doing things that require admin privileges automatically. (I accepted that setting when it asked). This means a process I own couldn't write to the Prime95 folder automatically. I changed the owner of that folder to myself and it works fine now. But really I should probably use a different folder. :no:



(Edit: Moved to Users/garo/Roaming Data)

[QUOTE=Prime95;568530]I'm still working on this. A Ubuntu build with debugging on seems to work. A CentOS build without debugging (the way official versions are built) does not. [/QUOTE]


I have my laptop back and can now work though some of the bugs backlog.

The good news is the CentOS/Ubuntu difference was a mirage -- simply a typo on my part. This nasty bug seems to be squashed.

[QUOTE=tha;568588]I put this in worktodo.txt:
Pminus1=N/A,1,2,15511381,-1,1500000[/QUOTE]

You triggered some really old code. It handles the old-format Pminus1 lines (circa 2002??).
Ignoring the "N/A," if there are 4 commas or less the old syntax is assumed:
Pminus1=exponent,B1,B2,plus1[,B2_start]

I'll remove support for this ancient syntax.

Edit: I'm removing the ancient ECM= syntax as well.

People, just make a C:\Prime95 or D:\PrimeWork, or whatever you like. P95 won't look out of this folder, you can copy everything there and restart from there, delete the old one. It is much easier to find when you look for it, it is accessible by all users in case your wife, kid, cat, dog, gerbil, snake, login to your computer when you are not at home, and it doesn't miss with the system or system files.

[QUOTE=axn;568649]Build 5 also suffers from Infinite loop bug.

Somehow when all 6 workers entered stage 2 together, I got the infinite loop for one of the worker (it just loops printing "Available memory is xxxx")..[/QUOTE]

I think I know what caused this. The P-1 stage 2 planner was told it could use X amount of memory, but it came up with a plan to use substantially more than X. The planner told the prime95 memory manager it was going to use this more than X value and the memory manager said "No, come up with a different plan". Infinite loop ensued.

I've coded 3 fixes for this.

1) The P-1 and ECM stage 2 planner now figures in the amount of memory expected to be used by the prime pairing bit map -- which can be up to 250MB. I believe this was the root cause of creating plans that used too much memory.
2) The memory manager allowed over-allocating by 32MB. This has been raised to 64MB.
3) When told to replan, which should only happen when another worker changes its memory use, P-1 and ECM now come up with a new plan using 1% less memory.

[QUOTE=petrw1;568748]After a week running 30.4 b3 without issue it "disappeared" this morning.[/QUOTE]

In re-reading this thread, I believe this is the only open issue. Unfortunately, I have no good ideas. I've started up a run with 4 ECM workers under the debugger hoping for a crash.

I have one last bug to fix before releasing build 6. It is not related to P-1 or ECM.

Is this a good time to ask about the issue that I raised last summer regarding the server not accepting new B1/B2 values if a factor has already been found and reported to the server?

Basically I want to be able to do P-1 work on exponents which have no previous P-1 work being done on them because they were already factored in the trial factoring stage. And then have the server storing the B1/B2 values. And of course find additional factors for that exponent.

(see [URL="https://www.mersenneforum.org/showpost.php?p=483083&postcount=1452"]original request[/URL])

I have no idea if this is a solemn server issue or if requires any mprime and prime95 modifications.

[QUOTE=tha;569198]Is this a good time to ask about the issue that I raised last summer regarding the server not accepting new B1/B2 values if a factor has already been found and reported to the server? ([URL="https://www.mersenneforum.org/showpost.php?p=483083&postcount=1452"]original request[/URL])
I have no idea if this is a solemn server issue or if requires any mprime and prime95 modifications.[/QUOTE]It should be a purely server-side issue.

I'm not very familiar with the data tables used on primenet, but as I recall the table that stores P-1 bounds is only applicable to unfactored exponent. I have no idea what would be involved in extending those tables to store bounds for factored exponents.

I have elsewhere received a similar request about adding a tool on mersenne.ca to both help find such factoring work and store results. Mersenne.ca does intrinsically store P-1 bounds no matter if the exponent is factored or not. But it would of course much better to have such data stored authoritatively on primenet.

[QUOTE=tha;569198]Is this a good time to ask about the issue that I raised last summer regarding the server not accepting new B1/B2 values if a factor has already been found and reported to the server?

Basically I want to be able to do P-1 work on exponents which have no previous P-1 work being done on them because they were already factored in the trial factoring stage. And then have the server storing the B1/B2 values. And of course find additional factors for that exponent.

(see [URL="https://www.mersenneforum.org/showpost.php?p=483083&postcount=1452"]original request[/URL])

I have no idea if this is a solemn server issue or if requires any mprime and prime95 modifications.[/QUOTE]

What is supposed to happen is the text message is recorded in the exponent history. Mersenne.ca should pick this up.

It did not happen in your case. This would be a server issue.