at 100% get error 77

[derrickmcc]

OK, This box has been untouched in all respects (dedicated folding box) for over 30 days with no problems. It is a Intel [email protected] ghz, running 2 gtx460 video cards, and an smp client running bigadv. Now I have the 3rd client in a row that has finished sucessfully, but get the below (and no 70k points !)
This box runs WinXP32, and has 4 gig of memory, and it has 2 gig used (1.5 gig available physical and says 2048 or 4927 memory used, and 300 gig of hard disk free.

The main point, is that for a month running 24/7 it had no problems, and now this starts showing up. AND NO CHANGES OR REBOOTS AT ALL.

Code: Select all

[07:48:54] Completed 250000 out of 250000 steps  (100%)
[07:49:08] DynamicWrapper: Finished Work Unit: sleep=10000
[07:49:18] 
[07:49:18] Finished Work Unit:
[07:49:18] Could not allocate memory for arcfile
[07:49:18] 
[07:49:18] Folding@home Core Shutdown: UNKNOWN_ERROR
[07:49:21] CoreStatus = 77 (119)
[07:49:21] Client-core communications error: ERROR 0x77

WinXP32 is limited to 3Gb memory.
This looks potentially to be a memory leak, given that you have not rebooted the system at all.
I would suggest rebooting the system and seeing if it can then successfully complete the SMP WU.

[PantherX]

You seniors please don't beat me up over this ... but didn't someone here say you couldn't run bigadv on 32 bit systems. There simply wasn't enough memory. What's the word?...

This is the current situation:
SMP2 WUs (Normal/Bigadv)
Windows 32 bit
Windows 64 bit
Linux 64 bit (The bug that prevents bigadv from running is being worked at)
OSX (not sure of the bit)

Classic WUs:
Windows 32 bit
Windows 64 bit
Linux 32 bit

We prefer to have 64 bit OS for bigadv WUs since we can address >4 GB of RAM which is helpful.

[markfw]

I have 5 I7's running bigadv's, all 32 bit XP. Even this one box was working fine until this (for 3 weeks). Probably 10-15 bigadv's OK, then its just started doing this.

[Eno]

I don't think that would be a limitation judging by what I'd seen in another thread. The A3s only draw slightly over a gig- (1.3) I stumbled into that on the beta testing thread in these forums.

[bruce]

There are some bigadv WUs that will run in 32-bit systems, but not all of them. That could be the problem, depending on how many cores you're running.

I don't remember seeing anything later than this, but it's possible that it has changed.

Q: Do these units require anything else besides 8 or more hardware cores?
A: A hardware speed of 2.4 GHz or higher, and plenty of RAM. For the initial units in this trial, your machine should have at least 0.5 Gb of RAM available per folding core. 0.75 is better. 1 Gb per core is more than enough.

[Pick2]

Between 100% complete and the uploading of the WU , the client takes the files it generated and combines and compresses them into a single file. There is a lot more disk activity at this step then any other time during folding. I have some low ram rigs that also page out to disk during this time , adding to the disk usage.

[markfw]

OK, nobody is listening...This same rig, no changes worked for 10-15 bigadv WU's, then stopped.

What changed to make it not work ?

[Qinsp]

Just ramblin':

First capture a 95% bigadv WU from another machine and put it on a stick.

Now make a new FAH2 directory and copy.

Run it and see if it still occurs.

If it does occur, it's not the client, core, or WU.

That leaves the O/S and the H/W.

Put the HDD into another box, and run the captured WU.

If it fails, it's not the hardware, it's the O/S installation and vice versa.

[Grandpa_01]

Nothing as far as the WU's / Client and core goes as far as you hardware you OC drivers I do not know you say nothing and want to blame the WU the client or the core. The sandy bridge chipset is known to have a problem perhaps it is connected to that or your OC has become unstable for some reason. Why aren't your other rigs having problems they are all running the same OS and everything is the same with them but yet they are doing fine running the same F@H and WU's. If it were me I would be looking for problems with the machine.

[gwildperson]

OK, nobody is listening...This same rig, no changes worked for 10-15 bigadv WU's, then stopped.

What changed to make it not work ?

You're on the second page of this topic so obviously you've gotten a number of suggestions from a number of people. How can you say nobody is listening

It might be more accurate to say that nobody knows the answer but folks ARE listening and ARE trying to help.

[markfw]

OK, I give you that... Nobody knows... I thought somebody at the pande group might answer. Being number 11 and still clueless, this concerns me. If we can't figure this out, I may as well quit. Somebody with more experience than is hard to find, so it the gurus at pande can't help me I may as well quit.

I guess they don't care about 250k ppd.

[Qinsp]

One thing hasn't changed since the first computers. It's either the App, the H/W, or the O/S. You need to isolate the problem by process of elimination. Or you could call Microsoft and have them ask you if your computer is plugged in. Or call Intel and they will tell you contact the mobo mfr.

You could also do the inverse of my path above. When a WU gets to 95% on The Destroyer, load it on another box and see if it finishes. If it does, bad box.

I got a dollar that says it's your H/W.

Double or nothing on an issue with the SATA/HDD. Did you think Intel just spent $700+ million on a minor issue that seldom occurs? No, that's not how things work.

Why are you so sure Intel or Microsoft isn't to blame?

[toTOW]

I'm pretty sure it's not hardware related.

I've just noticed that my dual xeon (24 threads) has been getting this error 77 for almost a week ... it's running Seven 64 bits.

[Qinsp]

Hmmm.... Guess I better take a look at mine. I have 2 bigadv Wintels running, but I'll admit that I don't keep track of points. I'm running about 2000w and I'd be pissed also if it was wasted.

But getting pissed at a computer is ineffective behavior (I'm still learning this after 35 years).

I'd still isolate between the three areas if you have multiple machines.

Pragmatically, when debugging, giving the programmer as much info as possible will shorten the fix time.

[Grandpa_01]

I think we need more info. markfw could you post your complete log / logs we need to see what similarities / differences there are between your set up and toTOW, use the code tags to post the log, it makes it easier.