What about detaching and re-attaching the project?
Haven't tried that, and not sure I'd want to do that very often, with one HT Prescott at home and three more at the office. Also, doesn't the detaching of a project delete its cached WUs?
The only time I ever detached a box from a project was when I had to return a system I was testing, and I set it to "No more work" ahead of time so that it would run down the cache and wouldn't abandon anything. I have no experience with detaching a project that still has queued work.
Use boinc studio, it can fake your cpu count upwards. The UI's french, so unless you can read it, setup will be 'fun', but there's a thread on it here that should be able to get you through it, if not just ask for help there.
AthlonXP Barton 2600+ (running on 190FSB)
D41.12: 2998 +/-45 av. 11
S41.07: 2807 +/-27 av. 29
So S41.07 is faster here too, but I recived unacceptable many computation error results with S-version on this PC. It seems 3DNow! part of processor with all x86 logic can work with such overclocking but SSE-part fails.
So it seems SSE-part is weakest at least on my AthlonXP sample.
(But SSE-optimized version of SETI works w/o errors here. Probably SETI is now much less optimized than Einstein application and cant manifest unstability of SSE block)
So S41.07 is faster here too, but I recived unacceptable many computation error results with S-version on this PC. It seems 3DNow! part of processor with all x86 logic can work with such overclocking but SSE-part fails.
So it seems SSE-part is weakest at least on my AthlonXP sample.
(But SSE-optimized version of SETI works w/o errors here. Probably SETI is now much less optimized than Einstein application and cant manifest unstability of SSE block)
Hi![pre]***UNHANDLED EXCEPTION****
Reason: Access Violation (0xc0000005) at address 0x0040AA1E read attempt to address 0x00000000[/pre]The same fault appeared on one of my overclocked Applebread. I know, the CPU core is the same (Applebread has less enabled cache), but i don't think that the overclocking caused this problem. It's strange at moment.
edit: Perhaps I'm was wrong. It doesn't seem to be programming fault.
Is is possible that the 0xc0000005 is caused by a side effect of other programs using DirectX ?
I had one of those too with S41.06 today and it happened while WinAmp was running. The last time I had this error, WinAmp was sitting in the tray doing nothing - but it was there.
I don't use it much and I don't have many 0xc0000005 errors. There is a known problem with CPDN Sulphur together with DirectX/DirectDraw, which became worse when they started to use optimized compiler options for their Fortran part. I could even cause a crash in Sulphur by just starting a 3D chat program and waiting a while (did that for testing reasons, had a backup).
I think that's something we should keep an eye on, i.e. which other programs have been active when the crash happened.
I have more than one Athlon XP running Einstein but the only crashes I had so far were on the only box that runs DX programs now and then (an Athlon MP).
Another 0xc0000005 crash - just when I started IrfanView with the Flash plugin.
The chance is getting higher that DirectX causes those crashes.
p.s.: the second task crashed with the same error code just a few minutes later.
This is definitely not caused by S41.06, it must be a side effect of DirectX
p.s.s.: I compared the crashes, it's the same memory access everytime, both location and destination address are identical : address 0x0040A8D8 read attempt to address 0x00040015
Hi![pre]***UNHANDLED EXCEPTION****
Reason: Access Violation (0xc0000005) at address 0x0040AA1E read attempt to address 0x00000000[/pre]The same fault appeared on one of my overclocked Applebread. I know, the CPU core is the same (Applebread has less enabled cache), but i don't think that the overclocking caused this problem. It's strange at moment.
edit: Perhaps I'm was wrong. It doesn't seem to be programming fault.
Hi :)
Well, the same error on the same adress is really pretty strange for more or less random errors due to hardware fault... but in more old WUs I found little different error:
***UNHANDLED EXCEPTION****
Reason: Access Violation (0xc0000005) at address 0x0040AA17 read attempt to address 0xFFFFFFFF result_ID=28069885
All other bad results have error at 0x0040AA1E. I didn't run profiler so dont's know relative frequences of access to these 2 adresses. Maybe they are simple too different and access count for 0x0040AA1E is too high so this place has best chance to fail?
Quote:
Is is possible that the 0xc0000005 is caused by a side effect of other programs using DirectX ?
Yes,it's possible in my case cause there is some DirectX program "in background" ;) that time.
I will try to check these possibilities.
Thanks for suggestions.
RE: What about detaching
)
Haven't tried that, and not sure I'd want to do that very often, with one HT Prescott at home and three more at the office. Also, doesn't the detaching of a project delete its cached WUs?
The only time I ever detached a box from a project was when I had to return a system I was testing, and I set it to "No more work" ahead of time so that it would run down the cache and wouldn't abandon anything. I have no experience with detaching a project that still has queued work.
Use boinc studio, it can fake
)
Use boinc studio, it can fake your cpu count upwards. The UI's french, so unless you can read it, setup will be 'fun', but there's a thread on it here that should be able to get you through it, if not just ask for help there.
Athlon Thoroughbred
)
Athlon Thoroughbred 2400+
S41.07
3620 +/-10 av. 46 -validated/pending
0 invalidated so far.
(for comparision
D41.12 - 3914 with some zero-granted credits)
AthlonXP Barton 2600+
)
AthlonXP Barton 2600+ (running on 190FSB)
D41.12: 2998 +/-45 av. 11
S41.07: 2807 +/-27 av. 29
So S41.07 is faster here too, but I recived unacceptable many computation error results with S-version on this PC. It seems 3DNow! part of processor with all x86 logic can work with such overclocking but SSE-part fails.
So it seems SSE-part is weakest at least on my AthlonXP sample.
(But SSE-optimized version of SETI works w/o errors here. Probably SETI is now much less optimized than Einstein application and cant manifest unstability of SSE block)
RE: So S41.07 is faster
)
Hi![pre]***UNHANDLED EXCEPTION****
Reason: Access Violation (0xc0000005) at address 0x0040AA1E read attempt to address 0x00000000[/pre]The same fault appeared on one of my overclocked Applebread. I know, the CPU core is the same (Applebread has less enabled cache), but i don't think that the overclocking caused this problem. It's strange at moment.
edit: Perhaps I'm was wrong. It doesn't seem to be programming fault.
Is is possible that the
)
Is is possible that the 0xc0000005 is caused by a side effect of other programs using DirectX ?
I had one of those too with S41.06 today and it happened while WinAmp was running. The last time I had this error, WinAmp was sitting in the tray doing nothing - but it was there.
I don't use it much and I don't have many 0xc0000005 errors. There is a known problem with CPDN Sulphur together with DirectX/DirectDraw, which became worse when they started to use optimized compiler options for their Fortran part. I could even cause a crash in Sulphur by just starting a 3D chat program and waiting a while (did that for testing reasons, had a backup).
I think that's something we should keep an eye on, i.e. which other programs have been active when the crash happened.
I have more than one Athlon XP running Einstein but the only crashes I had so far were on the only box that runs DX programs now and then (an Athlon MP).
Another 0xc0000005 crash -
)
Another 0xc0000005 crash - just when I started IrfanView with the Flash plugin.
The chance is getting higher that DirectX causes those crashes.
p.s.: the second task crashed with the same error code just a few minutes later.
This is definitely not caused by S41.06, it must be a side effect of DirectX
p.s.s.: I compared the crashes, it's the same memory access everytime, both location and destination address are identical :
address 0x0040A8D8 read attempt to address 0x00040015
AMD-Athlon-XP 4 wu´s
)
AMD-Athlon-XP
4 wu´s ready....each in 2500-2600sec
2 with granted credits
2 pending
before-> 2900-3200sec
great work akos!!!!
greetings
ralf
Boinc runs here on:
Intel i7-3770K + IntelHD4000
Android-Stick-ARM-Cotex-A17
Sony-Z5C-ARM-Cortex-A53/A57
Nvidia GT-630 / Nvidia GTX-750Ti
RE: Hi![pre]***UNHANDLED
)
Hi :)
Well, the same error on the same adress is really pretty strange for more or less random errors due to hardware fault... but in more old WUs I found little different error:
***UNHANDLED EXCEPTION****
Reason: Access Violation (0xc0000005) at address 0x0040AA17 read attempt to address 0xFFFFFFFF
result_ID=28069885
All other bad results have error at 0x0040AA1E. I didn't run profiler so dont's know relative frequences of access to these 2 adresses. Maybe they are simple too different and access count for 0x0040AA1E is too high so this place has best chance to fail?
Yes,it's possible in my case cause there is some DirectX program "in background" ;) that time.
I will try to check these possibilities.
Thanks for suggestions.
RE: [pre]***UNHANDLED
)
Three of my computers run S41.06/S41.07.
Dothan 1,86GHz: 108 valid / 0 invalid
ThoroughbredB 1,54GHz: 85 valid / 0 invalid
Applebread 2,07GHz: 27 valid / 23 invalid (each unit with access violation)
I didn't get new errors since the FSB was set back to 150MHz from 153MHz.
code snipet:
0x0040AA17 SUBPS XMM0,[0x0040AD30]
0x0040AA1E ADDPS XMM1,[0x0040AD30]
Both instructions access only the 0x0040AD30 memory area directly, not the '0x00000000' (invalid address).
It seems to be the same problem.
I think the processor could not prepare the address in time.
It has lots of work with this code...