Weird Game and Prime 95 problems, may it be Hardware?

[Arthanis]

Originally Posted by TTn

This is also suspect. (SP1)

Yeah, its SP1, but its fully updated, I just didn´t update the shitty security and firewall updates, since my connection is behind a IPTABLES Slackware Linux Firewall, but the critical ones are made.

[Arthanis]

OK, here I go: I discovered something: My PC now doesnt boot my Windows, it keeps rebooting if I put my processor as a 2800+ . It only enters windows if I put manually it as a 2700+ ... O dont get why would it happens. And another thing, whenI test it with Prime95, my CPU temperature is around 55C and my PWM, which I don´t know exactly what is (please if someone can tell me I would really apreciate), is around 68C (!!!). What does that mean?

[moo]

55c is a little high its because prime95 makes the cpu do more work causeing it to draw more power and generate more heat in turn u have a small heatsink get a bigger one. also make sure it has a copper core if you do they take heat away from a cpu faster.

[Arthanis]

OK, a found out something: I tried to put my machine as a 2800 again, then it booted normally and entered windows... Then I tried to run prime 95, and it rebooted on my face. Then I tried again to enter windows, and then it rebooted even before entering windows... If I go to BIOS soft Menu and put my Athlon as a 2600 in auto mode, everything goes perfect... It passed even o Prime95. And then I went to BIOS soft menu again and changed settings to manual... I put processor´s FSB as 166 x 12.5 = Ahtlon 2800, and then it rebooted on my face again... I went back no Soft menu and put 166 x 12 = Athlon 2700, then everything was fine, I ran Prime95 for 8 hrs in a row with no problems. So thought it was memory problem and set its frequency as 266 instead of 333 as a Athlon 2800; the problem remained the same... The only way I can get my PC to work perfectly is tu put 0.5 less in the multiplier...What could that be?

[Arthanis]

Oh, another thing, my mobo has a program to monitor temperature and stuff, like many others... There are 2 temperatures to check, one is CPU and the other is PWM. PWM is getting up to 72 C under heavy loads. I thought that this PWM temperature could be the source of my problems, but it´s temperature as Athlon 2500, 2600, 2700 and 2800 are the same.. I wonder what PWM is and what to do to cool it?

[cheesehead]

Originally Posted by Arthanis

Oh, I i didn´t think that bad drivers could cause errors on prime95 stress tests, since its low-level test, very close to hardware layer.

The reason bad drivers cause errors in Prime95 is indirect, not obvious.

What happens, I've been informed, is that some drivers do not properly save and restore all the floating-point registers. So, after Prime95 is interrupted because of a I/O event, even though the I/O is being performed for an unrelated program that just happens to be running at the same time as Prime95 on the same system, it is possible that upon resumption the contents of some FP register is not what it should be, and this can cause various types of failure.


Editorial: I worked as a programmer for thirty years. In all that time, I never had to use an operating system that was so incompetent, so unprofessionally designed, as not to be able to ensure that all hardware registers were properly saved and restored during interrupt handling so that the interrupted program would never be affected by register changes made in other tasks during the interrupt.

Fortunately, I never had to use any Microsoft software in any of my professional work. Apparently, according to the evidence I have, the developers and/or managers of Microsoft operating systems were so professionally inept that they did not incorporate certain basic protections into Microsoft operating systems. I can't directly verify this because I've never seen the interrupt-handling code in Windows, as I have in other operating systems, but the evidence seems conclusive. /Editorial

[moo]

Originally Posted by cheesehead

Editorial: I worked as a programmer for thirty years. In all that time, I never had to use an operating system that was so incompetent, so unprofessionally designed, as not to be able to ensure that all hardware registers were properly saved and restored during interrupt handling so that the interrupted program would never be affected by register changes made in other tasks during the interrupt.

Fortunately, I never had to use any Microsoft software in any of my professional work. Apparently, according to the evidence I have, the developers and/or managers of Microsoft operating systems were so professionally inept that they did not incorporate certain basic protections into Microsoft operating systems. I can't directly verify this because I've never seen the interrupt-handling code in Windows, as I have in other operating systems, but the evidence seems conclusive. /Editorial

thats the sprit LOL.

[xilman]

Originally Posted by cheesehead

Editorial: I worked as a programmer for thirty years. In all that time, I never had to use an operating system that was so incompetent, so unprofessionally designed, as not to be able to ensure that all hardware registers were properly saved and restored during interrupt handling so that the interrupted program would never be affected by register changes made in other tasks during the interrupt.

Fortunately, I never had to use any Microsoft software in any of my professional work. Apparently, according to the evidence I have, the developers and/or managers of Microsoft operating systems were so professionally inept that they did not incorporate certain basic protections into Microsoft operating systems. I can't directly verify this because I've never seen the interrupt-handling code in Windows, as I have in other operating systems, but the evidence seems conclusive. /Editorial

I've been a programmer almost as long. Unfortunately, I've seen bad device drivers in almost every operating system. Hell, I've written bad device drivers

Some of your criticism of MS is justified, IMO, but not all of it. Although MS has been guilty of writing buggy drivers, the great majority are produced by third parties. The typical case is that some hardware company will create a new widget and write a driver for it so that the widget can be used under some version(s) of Windows. Quality control is not ideal outside of MS either.

As for implementing "basic protections", an interrupt driver can do whatever the hell it likes and there is nothing the operating system can do to protect itself.


Paul

[akruppa]

Could a check for corrupted fp registers be done by explicitly yielding to the scheduler at convenient times and checking that the regs are unchanged when execution continues? Or does this corruption of regs only occur in interrupt-handling routines of device drivers what would not be queued by the process scheduler anyways?

Alex

[cheesehead]

Originally Posted by xilman

I've been a programmer almost as long. Unfortunately, I've seen bad device drivers in almost every operating system. Hell, I've written bad device drivers

But there's a difference between an operating system that lets a bad device driver corrupt some other task's registers and an operating system that is designed so that bad device drivers cannot affect an unrelated task's registers.

Although MS has been guilty of writing buggy drivers, the great majority are produced by third parties. The typical case is that some hardware company will create a new widget and write a driver for it so that the widget can be used under some version(s) of Windows. Quality control is not ideal outside of MS either.

I know all that. My criticism was that the OS allows a device driver to corrupt another task. Read my editorial again -- it wasn't a criticism of device drivers.

As for implementing "basic protections", an interrupt driver can do whatever the hell it likes and there is nothing the operating system can do to protect itself.

Sorry, but I must insist that it is always possible to write an operating system that can save/restore registers on interrupts. If an OS is designed to let a device driver receive immediate control upon an interrupt, then that is an incompetently-designed OS. Wherever the machine goes upon interrupt, it is possible to have the OS get control before the device driver. Can you describe an interrupt scheme which makes this impossible? I've never seen one.

What non-Microsoft operating system have you used that lets a device driver receive direct control, with no operating system intermediation?

[cheesehead]

Originally Posted by akruppa

Could a check for corrupted fp registers be done by explicitly yielding to the scheduler at convenient times and checking that the regs are unchanged when execution continues?

This wouldn't work because an interrupt could occur between any two instructions of Prime95. Such as the two instructions immediately follwing any scheduler cross-check. To have this idea work, one would have to have the cross-check between every pair of instructions!

Almost any machine has such a feature as locking out interrupts, but there is no reason to use that in GIMPS software, and in fact it would be extremely undesireable to do so.