peter@nox.se (Peter Levin) (01/04/91)
There have been some discussion on the subject of running 486 computers and 386 Unix (SCO, Interactive, Dell etc). I know that when buying an Intel 486 computer you were at least one month ago obliged to sign a paper stating that you were aware of that the 486 processor was not working properly with Unix under alla circumstances. It sounds like Intel got a bug in the processor. I also suppose this has been passed on to the computer manufacturers. The 486 is today making money to vendors like IBM, Compaq, AST, Dell etc. Such a powerful computer will be used for Unix in more than a negliable amount of installations. To state that the machine might not run properly could possibly harm sales. Can it be that the vendors just don't give infomation about the problem, because it could hurt sales? I don't want to think it works that way, but perharps... Just giving some information. Peter Levin peter@nox.se
james@bigtex.cactus.org (James Van Artsdalen) (01/06/91)
In <712@nox.se>, peter@nox.se (Peter Levin) wrote: > I know that when buying an Intel 486 computer you were at least one > month ago obliged to sign a paper stating that you were aware of that > the 486 processor was not working properly with Unix under alla > circumstances. Nonsense on their part. Sounds like they've been thinking with their lawyers instead of their brains again. bigtex has been running a C step 486 for a couple of months, no problems. raid.dell.com ran a B step 486 for about 6 months until it was replaced with a new machine. I never encountered any CPU problems with either. > It sounds like Intel got a bug in the processor. I also suppose this > has been passed on to the computer manufacturers. I have not seen a 486 C step errata sheet, but I assume there are bugs. After all, the 386 is several years old, much simpler than a 486, and still has bugs. > To state that the machine might not run properly could possibly harm > sales. Can it be that the vendors just don't give infomation about > the problem, because it could hurt sales? If the 486 were incapable of running unix, I think it would be a little hard to keep it a secret, especially after delivering the machine to Customers. Customers tend to complain loud and long about any problem, real or imagined, and I don't see Customers as likely to be willing to conspire with Vendors to keep it all a big secret. In addition, there are vendors like Dell that have 30 day return policies and one year warranties. If we sent it out and it didn't work, everyone would just send it back for a refund, at a great loss to us. It would never make economic sense to have this happen. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789
jca@pnet01.cts.com (John C. Archambeau) (01/07/91)
peter@nox.se (Peter Levin) writes: >There have been some discussion on the subject of running 486 computers and >386 Unix (SCO, Interactive, Dell etc). I know that when buying an Intel >486 computer you were at least one month ago obliged to sign a paper >stating that you were aware of that the 486 processor was not working >properly with Unix under alla circumstances. It sounds like Intel got >a bug in the processor. I also suppose this has been passed on to the >computer manufacturers. Are you sure you're not referring to the older 486's with the infamous bug that caused them to be recalled awhile back? It's difficult to hide when something is not working. As for hurting sales. Yes, it can and will hurt sales, but the customer will scream louder if you sell him or her a product that doesn't worked as promised. Case and point, we sold a Gigatrend DAT drive to a customer as part of a Sun 4/470 system. Guess what, the DAT doesn't work. After going through all sorts of bull, we finally find out from Gigatrend's development staff in England that there's currently no way to make their DAT work with a Sun 4/470. The problem deals with an incompatability with the SCSI host adaptor. Well, that was fine and dandy, but we were cautious (or tried to be) we asked the distributor and Gigatrend in Carlsbad if the DAT would work with a Sun 4/470. And during this whole time we were screaming at Gigatrend about it, the customer was screaming at us even louder. Not pretty at all. Not knowing about incompatabilities can be as bad, if not worse, than trying to pass off an incompatability as a product that will work. // JCA /* **--------------------------------------------------------------------------* ** Flames : /dev/null | What to buy? ** ARPANET : crash!pnet01!jca@nosc.mil | EISA or MCA? ** INTERNET: jca@pnet01.cts.com | When will the bus wars end? ** UUCP : {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca **--------------------------------------------------------------------------* */
peter@nox.se (Peter Levin) (01/07/91)
jca@pnet01.cts.com (John C. Archambeau) writes: >peter@nox.se (Peter Levin) writes: >>There have been some discussion on the subject of running 486 computers and >>386 Unix (SCO, Interactive, Dell etc). I know that when buying an Intel >>486 computer you were at least one month ago obliged to sign a paper >>stating that you were aware of that the 486 processor was not working >>properly with Unix under alla circumstances. It sounds like Intel got >>a bug in the processor. I also suppose this has been passed on to the >>computer manufacturers. >Are you sure you're not referring to the older 486's with the infamous bug >that caused them to be recalled awhile back? It's difficult to hide when >something is not working. This was new Intel computers (not just chips) manufactured in Ireland for the European market. >As for hurting sales. Yes, it can and will hurt sales, but the customer will >scream louder if you sell him or her a product that doesn't worked as >promised. [.........] All problems don't show up as you boot the machine. Talking about SCSI I sold a system with SCO Unix 3.2v0 almost a year ago. The system was rather buggy at start, but fixes from SCO has corrected most of the problems up today (now running 3.2v2). The machine had 4 Mbytes of memory (the recomended size by SCO for a small machine with limited number of users). The big problem was the SCSI tape drive (Archive 150 Mbyte internal). The tape drive worked perfectly in single user mode. In multiuser mode it hanged after a couple of tape actions. Sometimes it started up again after one minute or an hour. SCO had no solution. After adding 4 Mbytes extra, the drive was working without error. Errors and bugs might not always show up in a way that make them obvious. You might get a process that hangs, a device driver not working as it should or some other problem like it. Who to blaim????? Hardware, Unix or the software encountering problems? I don't know what the bug was (only affecting Unix, not any other operating system) and I haven't the errata sheet for the 486 processor. But I think that if Intel themself point to a possible error affecting Unix performance/function, there could be some substance behind their policy. I must admit that they said at the same time that Unix normaly worked, but under certain conditions there would be problems. ------------------------------------------------------------------------------- Peter Levin peter@nox.se
flint@gistdev.gist.com (Flint Pellett) (01/08/91)
peter@nox.se (Peter Levin) writes: >There have been some discussion on the subject of running 486 computers and >386 Unix (SCO, Interactive, Dell etc). I know that when buying an Intel >486 computer you were at least one month ago obliged to sign a paper >stating that you were aware of that the 486 processor was not working >properly with Unix under alla circumstances. Who/where do you "know" this from? I didn't have to sign any such thing when I got my 486, can you tell us of anyone who has? My vendor says they've tested the machine with SCO and ISC and Microport and had no problems. When deciding what machine to buy I talked with several vendors, and no other vendor I talked with mentioned any such thing, and I told them all I intended to use UNIX on the machine. The 486's bugs are in floating point operations that are performed in a particular sequence that is relatively rare. (At least that is what the Intel internal docs I have say, and that has been my experience in using the machine for the past 9 months.) That may affect some UNIX applications, but it is very unlikely that it will affect UNIX itself. >Just giving some information. It is either incorrect info, or incomplete. Which 486 was it that was asking people to sign such a paper? In what country? Did it refer to a specific UNIX? Or are you just repeating an unsubstantiated rumor? -- Flint Pellett, Global Information Systems Technology, Inc. 1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165 uunet!gistdev!flint or flint@gistdev.gist.com
peter@nox.se (Peter Levin) (01/08/91)
In article <6758@crash.cts.com>, jca@pnet01.cts.com (John C. Archambeau) writes: >peter@nox.se (Peter Levin) writes: >>There have been some discussion on the subject of running 486 computers and >>386 Unix (SCO, Interactive, Dell etc). I know that when buying an Intel >>486 computer you were at least one month ago obliged to sign a paper >>stating that you were aware of that the 486 processor was not working >>properly with Unix under alla circumstances. It sounds like Intel got >>a bug in the processor. I also suppose this has been passed on to the >>computer manufacturers. >Are you sure you're not referring to the older 486's with the infamous bug >that caused them to be recalled awhile back? It's difficult to hide when >something is not working. This was new Intel computers (not just chips) manufactured in Ireland for the European market. >As for hurting sales. Yes, it can and will hurt sales, but the customer will >scream louder if you sell him or her a product that doesn't worked as >promised. [.........] All problems don't show up as you boot the machine. Talking about SCSI I sold a system with SCO Unix 3.2v0 almost a year ago. The system was rather buggy at start, but fixes from SCO has corrected most of the problems up today (now running 3.2v2). The machine had 4 Mbytes of memory (the recomended size by SCO for a small machine with limited number of users). The big problem was the SCSI tape drive (Archive 150 Mbyte internal). The tape drive worked perfectly in single user mode. In multiuser mode it hanged after a couple of tape actions. Sometimes it started up again after one minute or an hour. SCO had no solution. After adding 4 Mbytes extra, the drive was working without error. Errors and bugs might not always show up in a way that make them obvious. You might get a process that hangs, a device driver not working as it should or some other problem like it. Who to blaim????? Hardware, Unix or the software encountering problems? I don't know what the bug was (only affecting Unix, not any other operating system) and I haven't the errata sheet for the 486 processor. But I think that if Intel themself point to a possible error affecting Unix performance/function, there could be some substance behind their policy. I must admit that they said at the same time that Unix normaly worked, but under certain conditions there would be problems. ------------------------------------------------------------------------------- Peter Levin peter@nox.se
pcg@aber-cs.UUCP (Piercarlo Grandi) (01/10/91)
In article <713@nox.se> peter@nox.se (Peter Levin) writes:
The machine had 4 Mbytes of memory (the recomended size by SCO for a small
machine with limited number of users). The big problem was the SCSI tape
drive (Archive 150 Mbyte internal). The tape drive worked perfectly in
single user mode. In multiuser mode it hanged after a couple of tape
actions. Sometimes it started up again after one minute or an hour. SCO
had no solution. After adding 4 Mbytes extra, the drive was working
without error.
The reason is obvious -- you were using the special device files that imply
tape buffering to access the tape. When you do this, the driver allocates a
number of pages of memory to buffer IO to/from the tape, so as to give the
illusion of asynchronous operation, and make the tape stream. If there are
not enough (contiguous, usually) pages to sustain the buffering, which is
easily the case on a loaded machine, problems happen -- the tape driver waits
for these pages, and looks locked up.
The solution is better integration between the tape driver and the memory
management so that the tape driver does not need luck to find the free
pages; the kludge is to add so much memory that lots of it lie unused, so
that the tape driver can always be lucky. The answer is the same to the
problem of how to avoid expansion swaps, one of the most demented and
ridiculous mistakes done by AT&T: avoid exercising the troublesome code by
making sure a lot of memory is wasted.
This problem occurs, as far as I know, with nearly every buffering tape
driver around. Buffering should not be done in the driver at all -- it
should be done by a user utility. If the kernel were well implemented, this
would not just work better, it would also have small overheads.
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukdavidsen@sixhub.UUCP (Wm E. Davidsen Jr) (01/11/91)
In article <2201@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: | The reason is obvious -- you were using the special device files that imply | tape buffering to access the tape. When you do this, the driver allocates a | number of pages of memory to buffer IO to/from the tape, so as to give the | illusion of asynchronous operation, and make the tape stream. If there are | not enough (contiguous, usually) pages to sustain the buffering, which is | easily the case on a loaded machine, problems happen -- the tape driver waits | for these pages, and looks locked up. This is the source of the message "system too busy for efficient tape operation" you sometimes get when trying to start a tape job. I wonder who SCO didn't have a clue on this one. | This problem occurs, as far as I know, with nearly every buffering tape | driver around. Buffering should not be done in the driver at all -- it | should be done by a user utility. If the kernel were well implemented, this | would not just work better, it would also have small overheads. Say what you will, the SCO driver keeps the tape streaming, the standard v.3.2 drivers don't. However, the SCO SCSI drivers have not shown the same throughput, to say the least. With the disk on the same controller I could (maybe) see it, but a 670MB ESDI drive and DAT tape, on separate controllers, still don't stream the tape. Even with media changes the Wangtek 150 (5 tapes) runs faster in real time. Of course we run it overnight, so it isn't a problem. -- 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
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (01/11/91)
As quoted from <1049@gistdev.gist.com> by flint@gistdev.gist.com (Flint Pellett): +--------------- | peter@nox.se (Peter Levin) writes: | | >There have been some discussion on the subject of running 486 computers and | >386 Unix (SCO, Interactive, Dell etc). I know that when buying an Intel | >486 computer you were at least one month ago obliged to sign a paper | >stating that you were aware of that the 486 processor was not working | >properly with Unix under alla circumstances. | | Who/where do you "know" this from? I didn't have to sign any such thing | when I got my 486, can you tell us of anyone who has? My vendor says +--------------- Telotech upgraded its Altos 1000 to a 486 processor about a year ago. No fancy paper to sign, nothing. But Altos did note that they did not have problems caused by the 486 bugs on the 1000. They may have delayed the 5000 for a while because of 486 glitches, however --- I don't know. ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
sef@kithrup.COM (Sean Eric Fagan) (01/12/91)
In article <712@nox.se>, peter@nox.se (Peter Levin) writes: |> Can it be that the vendors just don't give |> infomation about the problem, because it could hurt sales? I don't |> want to think it works that way, but perharps... I have seen something like 25 different brands of '486 machines running some version of UNIX (a few at work, a few at trade shows, a few at people's houses, a few at some other companies I've been to). From what I've seen, most of these machines ran unix a lot easier than kithrup (a nice, normal '386) did at first, when I'd misconfigured the various parameters (shadow ram, in this case). The original message made some reference to Intel; I suspect Intel doesn't want to go through another fiasco as it did with early versions of the '386 (where they weren't capable of multiplication in 32-bit mode, or somesuch). All of the unix vendors I've seen have had a list of vendors and hardware they have tested and, therefore, know work with their product; if a piece of hardware is not on that list, it does not mean it won't work, it just means the vendor has not tested it. (Usually because the vendor does not have one of pieces of hardware in question.) There is no (fnord) conspiracy out to (fnord) delude you (fnord). -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
root@gold.doit.sub.org (Christian Seyb) (01/12/91)
In <2864@sixhub.UUCP> davidsen@sixhub.UUCP (Wm E. Davidsen Jr) writes: > Say what you will, the SCO driver keeps the tape streaming, the >standard v.3.2 drivers don't. However, the SCO SCSI drivers have not The reason for this is not the Driver itself. Get a copy of the GNU tar. I usually do backups with the following command line. tar -l -b 100 -cf /dev/ct usr The -l option tells GNU tar to only backup one filesystem. The -b 100 option tells GNU tar to allocat 100 x 512 Byte Buffers. Now the streamer does what his name says - It streams. regards Christian -- Christian Seyb | Internet: cs@gold.doit.sub.org uucp login: nuucp Fuchsweg 86 | Mailbox: +49-8106-34593 24h 300-19200 PEP/V.32 8011 Baldham | +49-8106-34692 24h 300-19200 HST -- Lieber fuenf vor Zwoelf, als gar keine nach Eins.
ti@altos86.Altos.COM (Ti Kan) (01/30/91)
In article <1991Jan11.024255.14681@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR) writes: >As quoted from <1049@gistdev.gist.com> by flint@gistdev.gist.com (Flint Pellett): >Telotech upgraded its Altos 1000 to a 486 processor about a year ago. No >fancy paper to sign, nothing. But Altos did note that they did not have >problems caused by the 486 bugs on the 1000. They may have delayed the 5000 >for a while because of 486 glitches, however --- I don't know. There were a couple of 486-related bugs that caused concern in the early days of the 486 (circa end of 1989). The first of these was the bug with certain floating point operations, and the second was the bug with the 486 EISA chip set. The Altos 486/1000 was the first dedicated 486 UNIX machine to ship in December 1989, but all the units shipped were equipped with B6 or later stepping of the 486 chip, which does not have the floating point bug. Also, since the 486/1000 is not ISA or EISA based, it does not suffer from the second problem. The Altos 486/5000 is EISA-based, but by the time the systems hit the market, the EISA chip set bugs were already fixed. Again, the none of the Altos systems shipped has the above bugs. We use the 486/5000 extensively in house here in Altos software engineering, and have not seen any problems inherent in the 486. Our main development system, where all UNIX kernel, device driver, utilities, communication software, and other work is done, is an Altos 486/5000 at 33MHz. It has typically an average of 30+ users logged on, often with several users doing extensive kernel code compilations. This system also has in excess of 2GB of disk space (6 SCSI hard disks and two SCSI tape drives, one of which is an Exabyte 8mm, connected to two SCSI host adapters) and over 30 serial ports enabled, running on an ethernet of some 80+ systems. This should suffice to illustrate that the system is quite well loaded with real work, and again, no 486 problems. -Ti -- Ti Kan | vorsprung durch technik! \\\ Internet: ti@altos.com \\\ UUCP: ...!{sun|sco|pyramid|amdahl|uunet}!altos!ti /// \\\ The opinions herein are not necessarily those of Altos. ////////\