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

[cheesehead]

Originally Posted by cheesehead

What non-Microsoft operating system

I should have specified "multitasking": "What non-Microsoft multitasking operating system ..."

I'm not concerned with systems that do only one thing at a time.

[xilman]

Originally Posted by cheesehead

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

All of them.

A device driver has complete accesses to the raw hardware, including physical memory, page tables, TLB entires, the works. It can do anything it likes, including corrupting operating system data structures. One such data structure is the copy of the original registers now stored somewhere in memory.

Paul

[cheesehead]

xilman,

OK, now I see that we've been referring to different aspects of the relationship of device driver to OS. I was commenting on the entry/exit interface, but when you wrote

Originally Posted by xilman

an interrupt driver can do whatever the hell it likes and there is nothing the operating system can do to protect itself

, you were referring to the entire span of driver execution time while processing the interrupt. Right?

When I wrote

Originally Posted by cheesehead

lets a device driver receive direct control, with no operating system intermediation

, I was referring to only the segment of processing between the occurrence of an interrupt and the execution of the first instruction within the device driver, whereas you interpreted my use of "control" to refer to the entire span of driver instruction execution while processing the interrupt. Right?

So do I presume correctly that you agree with me that upon an I/O interrupt, the sequence of events goes like the following?
1. Interrupt causes machine to branch to some fixed location (details vary from machine to machine).
2. At that fixed location an instruction or event (like loading PSW on 360s) or indirect branch causes iinstruction execution pointer to point to some location within the OS.
3. At that OS location, the OS saves the context (on some machines this may be all or partly done automatically during firmware execution of the interrupt event) including saving register contents,
4. OS transfers execution to device driver's interrupt-handling entry point.

Sorry for the detail, but I want to align my view with yours here.

(I have more to say about what happens after driver's interrupt-handling entry, but want to wait until you confirm that my latest revised interpretations of what you wrote are correct.)

[xilman]

Originally Posted by cheesehead

(I have more to say about what happens after driver's interrupt-handling entry, but want to wait until you confirm that my latest revised interpretations of what you wrote are correct.)

Confirmed.

Paul

[Wacky]

Originally Posted by xilman

All of them.

A device driver has complete accesses to the raw hardware, including physical memory, page tables, TLB entires, the works. It can do anything it likes, including corrupting operating system data structures. One such data structure is the copy of the original registers now stored somewhere in memory.

Paul

Sorry, Paul, but that only applies to certain hardware situations. Back "in the dark ages", the OS had hardware that it could, and did, use to protect itself from the third party "driver". Look at the design of the MULTICS kernel. We are slowly returning to that level of design that disappeared with the advent of micro-controller chips (e.g. x86) being used as "CPUs".

I believe that VMWare is currently using similar techniques to allow it to run multiple OSes on the modern incarnation of the x86 architecture.

[xilman]

Originally Posted by Wacky

Sorry, Paul, but that only applies to certain hardware situations. Back "in the dark ages", the OS had hardware that it could, and did, use to protect itself from the third party "driver". Look at the design of the MULTICS kernel. We are slowly returning to that level of design that disappeared with the advent of micro-controller chips (e.g. x86) being used as "CPUs".

I believe that VMWare is currently using similar techniques to allow it to run multiple OSes on the modern incarnation of the x86 architecture.

Fair enough, I accept that, though with reservations.

There were a number of such operating systems back in the 60s and 70s. One of which I have personal experience is VME/B which ran on ICL 2900 series mainframes. There are very few such operating systems today though they are starting to make a comeback.

My comment "all of them" is therefore incorrect and should be replaced by "all but one of them". My excuse is that I last used VME/B in 1981 or so and had long forgotten about it. Even then, I didn't have particularly great exposure and certainly not at the system programming level --- I was strictly scientific Fortran and Algol68.

A common flaw of virtual machine environments is that they tend to provide adequate protection only if processes do not share a virtual machine. VMWare and the like do indeed allow multiple OSes on the same x86 architecture. Unfortunately, a prime95 running in an instance of an OS running under VMWare is still vulnerable to bugs in the device drivers running in that OS. At least, that is my understanding of the situation. If anyone can point me to reliable documentation which proves otherwise I would be grateful.

Paul

[Arthanis]

Lol, well... Getting back to my problem, I tesed my components in my cousin´s mobo to check if everything was fine... Then I got illegal sumeout errors with my processor with his mobo, memory and stuff.. So I went back to the store I bought my barton and traded it.. Im waiting it to get therte so I can pick it back.. See ya guys, thanks a lot for the help, I will tell you if everything ended up right...

[cheesehead]

Cleaning up a loose end:

Now that Wacky's mentioned the hardware protection, I'll just say that in view of Intel CPUs' lack of various protections available on mainframes, I think Microsoft had an obligation, once they saw how popular their OS was going to be, to incorporate as many protective software mechanisms as feasible.

Example: Memory allocation.

I was astonished to learn that (early) Windows apparently relied on user programs to free storage, in the sense that the OS did not keep a record of memory allocations that was separate from user programs. So when a user task aborted before freeing memory, (early) Windows couldn't be sure it recovered all its allocated memory. Also, this feature seems related to the "memory leak" phenomenon, blamed for some crashes.

Since my editorial was off-topic to begin with, I'll consider that I've tied up the loose end sufficiently to let it rest.

[ColdFury]

Intel CPUs'

x86 processors actually have very complicated protection structures. It's just that no OS has used them because of their complexity.