wmandrus@world.std.com (Wayne R Mandrus) (12/30/90)
Is there anyone who has loaded SCO UNIX 3.2.2 on a Micronics 486-25 based pc? Specifically, sco will not boot up if the internal cache is enabled. Has anyone seen this or something simular? -w
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/31/90)
In article <1990Dec30.002048.8203@world.std.com> wmandrus@world.std.com (Wayne R Mandrus) writes: | | Is there anyone who has loaded SCO UNIX 3.2.2 on a Micronics 486-25 | based pc? Specifically, sco will not boot up if the internal cache | is enabled. Has anyone seen this or something simular? I haven't seen this one, but I've seen some boards which won't run in an EISA slot with the cache on. I have some benchmarks which indicate that a 486-33 with cache OFF is slower than a 386-25 with 64k cache. I would not even consider running like that, SCO UNIX will run on 486-{25,33} with cache on, EISA and ISA, and if it won't on your system you should send the system back. I'm assurred by two Micronics distributors that all flavors of SCO {xenix,unix,odt} run on the board. Since they also distribute other products I assume they would mention one which works if Micronics doesn't. Slight caution: SCO has been know to ship the same product with "running changes" in the system. What used to be true may not be so today, check with the dealer and SCO fast, before they both claim your support has run out. Expect finger pointing. The way to get past this is to call the dealer (system or SCO) and say something like "will your product work with so-and-so?" WHen they say yes they you say "that's what you told me and I just bought it and it doesn't work. This avoids having the support critter say "I never told you that." Keep a log of times and names of people you contact, send confirming e-mail to support@sco.com with the error report number. This makes sure they have what you consider to be a statement of the problem rather than what notes were taken by the being which answers their phones. It also insures that you have a record that it was reported before the support died. I have found SCO to be pretty good about problems once they believe you can read simple directions and there is a problem and it's theirs. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
jim@shograf.UUCP (jim morris) (01/04/91)
From article <1990Dec30.002048.8203@world.std.com>, by wmandrus@world.std.com (Wayne R Mandrus): > > Is there anyone who has loaded SCO UNIX 3.2.2 on a Micronics 486-25 > based pc? Specifically, sco will not boot up if the internal cache > is enabled. Has anyone seen this or something simular? > > -w I have had the same problem on the Club AT Hawk 3, 33Mhz 486. It won't boot unless you start in non-turbo mode. After it has booted everything (except TCP/IP) works fine when switched to turbo mode. Of course SCO and Club AT pointed fingers at each other. I still don't know who is to blame (My bet is the H/W). However someone at SCO did say that a new boot program is being worked on that will work with 486's. Ask your SCO tech support person for more info. If someone actually has this new boot program let us know. My solution was to move the disk to a 33Mhz 386 where it works just fine. The 486 has been relegated to run DOS and windows!! Jim jim@shograf.UUCP or motcsd!shograf!jim
wmandrus@world.std.com (Wayne R Mandrus) (01/04/91)
In article <298@shograf.UUCP> jim@shograf.UUCP (jim morris) writes: >From article <1990Dec30.002048.8203@world.std.com>, by wmandrus@world.std.com (Wayne R Mandrus): >> >> Is there anyone who has loaded SCO UNIX 3.2.2 on a Micronics 486-25 >> based pc? Specifically, sco will not boot up if the internal cache >> is enabled. Has anyone seen this or something simular? >> >> -w > >I have had the same problem on the Club AT Hawk 3, 33Mhz 486. >It won't boot unless you start in non-turbo mode. After it has booted >everything (except TCP/IP) works fine when switched to turbo mode. > >Of course SCO and Club AT pointed fingers at each other. I still don't >know who is to blame (My bet is the H/W). However someone at SCO >did say that a new boot program is being worked on that will work with >486's. Ask your SCO tech support person for more info. > >If someone actually has this new boot program let us know. > After 'pushing' at SCO they in fact have a new boot program available that fixes boot problems on 486 type machines (i.e. micronics). The boot program did resolve my problem. To get it call sosco and get the file sosco!~/tmp/boot16.Z The file is not for general release yet, it's strictly a beta product, but again it fixed my problem. -w
debra@wsinis03.info.win.tue.nl (Paul de Bra) (01/04/91)
In article <298@shograf.UUCP> jim@shograf.UUCP (jim morris) writes: >... >I have had the same problem on the Club AT Hawk 3, 33Mhz 486. >It won't boot unless you start in non-turbo mode. After it has booted >everything (except TCP/IP) works fine when switched to turbo mode. >... Sounds like the old boot/speed problem again. A vanilla sVr3.1 unix would not boot on my 25Mhz 386 box unless I slowed it down to 8Mhz. sVr3.2 solved this problem. Since the boot program cannot use real timers or something like that to wait for asynchronous events it just loops a while, and on a 33Mhz 486 this loop may be over too soon for whatever it is the boot program wants to wait for. Once Unix has booted I could switch to 25Mhz with sVr3.1 and everything was fine. Your problem is very similar... Paul. (debra@research.att.com, debra@win.tue.nl)
james@bigtex.cactus.org (James Van Artsdalen) (01/05/91)
In <1662@svin02.info.win.tue.nl>, debra@info.win.tue.nl wrote: > Since the boot program cannot use real timers or something like that > to wait for asynchronous events it just loops a while, and on a 33Mhz > 486 this loop may be over too soon for whatever it is the boot program > wants to wait for. First of all, the boot program can use the 8254 timer on an AT to get an accurate time base for any delay. Secondly, there are other ways to get a fairly constant time base, independent of CPU speed. Remember that only the CPU complex is running that fast: all of the bus devices run on an 8MHz bus (this suggests several general solutions). To fail merely because the CPU is fast is sloppy programming. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (01/09/91)
In article <1991Jan3.195954.10767@world.std.com> wmandrus@world.std.com (Wayne R Mandrus) writes: | After 'pushing' at SCO they in fact have a new boot program available | that fixes boot problems on 486 type machines (i.e. micronics). The | boot program did resolve my problem. Let me say that ODT boots fine on Dell and HP 486's. That suggests that the problem is in the hardware, and SCO just found a way to get by it without breaking other machines. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
wmandrus@world.std.com (Wayne & Betsy Mandrus) (01/09/91)
In article <2839@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: > > Let me say that ODT boots fine on Dell and HP 486's. That suggests >that the problem is in the hardware, and SCO just found a way to get by >it without breaking other machines. >-- Actually, the individual I spoke with at SCO indicated that the problem was most likely a result of the Phoenix/486 combo in certain motherboards. The problem exists is several other manufactures products as well, or in the case of micronics, certain revs of the motherboard. You could point to the hardward and say that's the problem and you would be right. On the other hand, ISC does not suffer from the problem indicating to some extent that there probably is a 'good' generic way to handle the bios/486 that SCO didn't use. So again whose doorstep do you lay this problem on? -w
md@sco.COM (Michael Davidson) (01/12/91)
In article <2839@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: >In article <1991Jan3.195954.10767@world.std.com> wmandrus@world.std.com (Wayne R Mandrus) writes: >| After 'pushing' at SCO they in fact have a new boot program available >| that fixes boot problems on 486 type machines (i.e. micronics). The >| boot program did resolve my problem. > Let me say that ODT boots fine on Dell and HP 486's. That suggests >that the problem is in the hardware, and SCO just found a way to get by >it without breaking other machines. The problem with the Micronics 486/25 is that the original memory sizing code in /boot thought that it could detect the presence of a 4K page of memory immediately above 16Meg (even though this memory did not in fact exist). Unfortunately, memory sizing on machines with caches can be tricky depending on precisely how the cache is implemented. The new version of /boot avoids this problem.