knudsen@ihwpt.UUCP (mike knudsen) (03/21/86)
Under what conditions, if any, should RS CoCo OS9 version 1.1 decide to reboot itself? This often happens to me while writing disk files in either DynaStar or the C pre-processor or Pass 1. Without any printed error message, the system just re-boots! The file being written may be garbage, truncated, or complete, but it is THERE after reboot, meaning it got "closed." I have three theories (notice how OS9 has restored the spirit of scientific research and philosphy to home computing :-] ): (1) Microware's code can detect certain error situations as being so hopeless that the best thing to do is reboot and let the user's STARTUP file restart the application. This makes a lot of sense for unattended operations. But I'm not sure that the disk driver should take such drastic measures. Could it be that OS9 realizes its kernel is corrupted? That would justify a reboot. (2) My memory, 6809, SAM, etc is buggy and takes a wild jump into the boonies, which just happens to end up in the boot code. Amazing how at least three different programs (DynaStar (really Pascal pinterp) and first two phases of C compiler) all happen to hit the right spot. (3) My disk controller, or some other happy hardware, is throwing glitches onto the RESET line. You know you can re-boot Coco OS9 anytime just by hitting the RESET button. Since I sometimes get failed disk writes (truncated files) without a reboot, possibly the reset glitches are sometimes too small to reset the 6809 and reboot, but large enough to wipe out the disk controller chips and abort the writing. I'd like to hear from some heavy hackers who can confirm the existence of deliberate reboot code in OS9, or from someone at Microware (I know you're online) who can honestly deny such things, or best of all, another Coco owner who had the same problem and fixed it. Thanks, mike k PS: I'm using a Hard Drive Specialists controller (for floppies only, despite the name). My troubles seem related to usage of large amounts of RAM, either for data (running Dynastar with 13k) or for program (C.pass1 uses 32k just for code!). Maybe I have some crummy RAM near the middle (around $8000).
dibble@rochester.ARPA (Peter C. Dibble) (03/24/86)
In article <775@ihwpt.UUCP>, knudsen@ihwpt.UUCP (mike knudsen) writes: > Under what conditions, if any, should RS CoCo OS9 > version 1.1 decide to reboot itself? My OS-9 Level Two Gimix system reboots sometimes too. It is always a symptom of a program running wild. There are places in OS-9 where it voluntarily reboots. It happens when things appear hopelessly mixed up to OS-9. I think the easiest way to get into that state on a CoCo would be to write into the system direct page. Under Level Two most of the system's memory is protected from user programs. I think that my autonomous reboots were caused by programs executing random code after a bad branch. Peter Dibble @ Rochester
emjej@uokvax.UUCP (04/01/86)
In <notes hides the message ID from me; sorry!> dibble@rochester (Peter Dibble) writes: /* Written 7:58 am Mar 24, 1986 by dibble@rochester.ARPA in net.micro.6809 */ /* ---------- "Re: Spontaneous ReBoots of OS9?" ---------- */ In article <775@ihwpt.UUCP>, knudsen@ihwpt.UUCP (mike knudsen) writes: > Under what conditions, if any, should RS CoCo OS9 > version 1.1 decide to reboot itself? My OS-9 Level Two Gimix system reboots sometimes too. It is always a symptom of a program running wild. /* End of text from uokvax.UUCP:net.micro.6809 */ The Level Two Chieftain I use at work displays the very same symptoms. Watch out for wild pointers. If I were so lucky as to have one of the really neat Gimix machines, the memory management hardware would catch me trying to fall off the edge of the world or step on someone else's memory and blow my process away. James Jones
draco@chinet.UUCP (Kent D. Meyers) (04/04/86)
In article <775@ihwpt.UUCP>, knudsen@ihwpt.UUCP (mike knudsen) writes: > Under what conditions, if any, should RS CoCo OS9 > version 1.1 decide to reboot itself? > I have three theories (notice how OS9 has restored > the spirit of scientific research and philosphy to > home computing :-] ): > (1) Microware's code can detect certain error situations as > being so hopeless that the best thing to do is reboot. > ................ Could it be that OS9 realizes its > kernel is corrupted? That would justify a reboot. The kernel is NOT reloaded on a warm boot!! Module OS9 is just restarted. If the kernel were corrupted, it would not be possible for the system to reboot and it would crash. Except if OS9 itself were damaged. The OS9 module is the only one in the system that is not verified before it is executed. The other modules in the kernel must be linked to and if they were corrupted they would not appear in the module directory. You can tell if the OS9 module is correct by doing an mdir after the system reboots. If it appears in the listing it is all right. > I'd like to hear from some heavy hackers who can confirm > the existence of deliberate reboot code in OS9. There is no code in R/S OS9 to reboot the system. The code that does the reboot is at the beginning of the kernel track and has no connection with OS9 when OS9 is running. The warm boot code is located at D.CBstart ($0071) and is put in place by Sysgo. This is why the double reset returns to BASIC. Until Sysgo has executed, the byte at D.CBstart is $00 and the BASIC reset routine will be forced to do a cold start. The actual entry point to the warm start code is at $0074. There is no direct connection to this code from within OS9. It is vectored to by the R/S BASIC reset routine. So it would appear that your errant programs are somehow executing the reboot code at either $0074 or directly at $F00C. The code that precedes the actual kernel on the kernel track loads at $F000. Interestingly enough, there are two places where OS9 attempts to abort by using JMP [$FFFE]. One is in OS9p2 and the other is in IOMan. Unfortunately, this does not work on the CoCo without going back to the ROM mode. And OS9 does not do this. This is why the system hangs when you do something silly like forgetting to put SCF in your bootfile. Kent D. Meyers ihnp4!chinet!draco