S41.xx Observation Thread

Clay Ruth
Clay Ruth
Joined: 28 Dec 05
Posts: 17
Credit: 662,723
RAC: 0

RE: What about detaching

Message 30020 in response to message 30017

Quote:
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.

DanNeely
DanNeely
Joined: 4 Sep 05
Posts: 1,360
Credit: 3,066,514,474
RAC: 3,027,406

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.

Raistmer*
Raistmer*
Joined: 20 Feb 05
Posts: 206
Credit: 98,788,730
RAC: 129,368

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)

Raistmer*
Raistmer*
Joined: 20 Feb 05
Posts: 206
Credit: 98,788,730
RAC: 129,368

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)

Akos Fekete
Akos Fekete
Joined: 13 Nov 05
Posts: 561
Credit: 4,527,270
RAC: 0

RE: So S41.07 is faster

Message 30024 in response to message 30023

Quote:
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.

Ananas
Ananas
Joined: 22 Jan 05
Posts: 272
Credit: 2,500,681
RAC: 0

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).

Ananas
Ananas
Joined: 22 Jan 05
Posts: 272
Credit: 2,500,681
RAC: 0

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

Ralf02061973
Ralf02061973
Joined: 28 Mar 05
Posts: 4
Credit: 10,810,519
RAC: 0

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

Raistmer*
Raistmer*
Joined: 20 Feb 05
Posts: 206
Credit: 98,788,730
RAC: 129,368

RE: Hi![pre]***UNHANDLED

Message 30028 in response to message 30024

Quote:

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.

Akos Fekete
Akos Fekete
Joined: 13 Nov 05
Posts: 561
Credit: 4,527,270
RAC: 0

RE: [pre]***UNHANDLED

Message 30029 in response to message 30028

Quote:
[pre]***UNHANDLED EXCEPTION****
Reason: Access Violation (0xc0000005) at address 0x0040AA1E read attempt to address 0x00000000[/pre]

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).

Quote:
[pre]***UNHANDLED EXCEPTION****
Reason: Access Violation (0xc0000005) at address 0x0040AA17 read attempt to address 0xFFFFFFFF[/pre]

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...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.