shepperd@dms.UUCP (Dave Shepperd) (03/16/90)
Well, we got ESIX/rev C. Naturally, I wanted to put in my device driver that works just fine on SCO Xenix and SCO Unix (and even sort of ok on Ix) and naturally it didn't work. ESIX tech support was no help. Anybody have a clue? Symptom: System reports ESIX booting... (or something like that) as normal and the console screen blanks as normal but nothing more is forthcoming. Dead, dead dead... Some facts: My driver init routine is being called which initialises some local variables in the driver proper. The problem persists even if I reduce the init down to setting just ANY ONE variable and exiting, however, the init routine completes successfully and the system boots if it changes none of the local variables. These variables are declared in the Driver.c code not in the Space.c code (there is no Space.c code). This driver is currently being used in SCO Xenix, SCO/Unix and Interactive Systems Unix without this problem (although, on Ix, it has a different problem). What the hell?: If I change the driver so it does the init the first time a process uses it instead of at boot time, it works just fine (BTW: This is an acceptable work around, however, it is not an optimum solution). Guess: The kernel memory that contains the driver code has not been set to R/W (ie perhaps read-only) so any updates to kernel space result in a protection violation but the boot process hasn't gotten around to setting up a handler for such an event and it weeds out. Ok, I admit this is not too plausible, so never mind. -- Dave Shepperd. shepperd@dms.UUCP or motcsd!dms!shepperd Atari Games Corporation, 675 Sycamore Drive, Milpitas CA 95035. Nobody knows what I'm saying. I don't even know what I'm saying.