Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!hoptoad!amdcad!decwrl!ucbvax!jade!ig!uwmcsd1!uwvax!oddjob!gargoyle!ddsw1!karl From: karl@ddsw1.UUCP Newsgroups: alt.flame Subject: Re: A new oxymoron: "Stable Microport system" Message-ID: <389@ddsw1.UUCP> Date: Wed, 2-Dec-87 14:04:45 EST Article-I.D.: ddsw1.389 Posted: Wed Dec 2 14:04:45 1987 Date-Received: Sun, 6-Dec-87 19:56:27 EST References: <445@nuchat.UUCP> Reply-To: karl@ddsw1.UUCP (Karl Denninger) Organization: Macro Computer Solutions, Inc., Mundelein, IL Lines: 115 Keywords: Microport, bugs, crashes, fed up, argh! Summary: Microport STILL can't get it right In article <445@nuchat.UUCP> jaym@nuchat.UUCP (Jay Maynard) writes: (Major flamage about Microport's problems and such) Early disclaimer: The following are my opinions. Use accordingly. First, the 'wn' error problem: This is a legitimate hardware problem. Try swapping controllers, if that doesn't work, swap drives. We have seen this one on several systems, and on each one, there was a marginal controller or drive in the system. Now, on to the fun stuff. Well, you have another user here who has the panic problem too. I've found that there are basically three solutions: 1) Wire a watch-dog timer on the system, so that if you double-panic in the kernel routine 'rmsd' (remove serial device) the machine will reboot. Then modify your 'rc' files so that the system goes back to init 2 by itself. (oh yeah, you need a daemon to do an 'out' every minute or so for the watchdog). This at least won't leave your system down if it blows up. 2) NEVER make a file-system with over 100K blocks on it, in fact, the actual limit is probably lower..... this prevents fsck from killing your disk if you should panic and reboot while unattended (you will panic if you run Microport, trust me....) 3) If you haven't already bought a '286 or '386 Unix, buy SCO. Their product doesn't destroy your file systems and panic once a day. They also don't take 2 weeks to ship product. **** FLAME ON! **** [This goes back to 1.3.6 last November, so there's a lot of steam to blow off here! Wear asbestos jackets!] Microport, you people are really out of this world. We have yelled at you so many times about the panics that we're blue in the face. In fact, I don't even bother calling anymore, because all you tell me is that my hardware is broken. It *is not* broken -- your drivers are. I have used the product on three *different* systems, (yes, one at a time) and every one exhibits the EXACT same behavior. We have 2.3.0, and it *STILL* panics. It *STILL* drops characters at even 2400 baud. UUCP *STILL* times out because your driver can't manage to receive packets without losing parts of them. 'shl', which you provided with 2.3.0, panics the system if used from a serial line. Wonderful. You promised me, and a bunch of other people, FIXES to these problems in V2.3.0. You even got my support money for the "upgrade". I paid my $99 for the ability to specify a kernel at boot time (a'la Xenix). The number of 'fatal' problems that I have seen truly RESOLVED with 2.3.0? ZERO. I feel like stopping payment on our check - since I did not receive what I was promised with this "upgrade". In V2.3.0, you have: o Given us a 'new improved' ANSI terminfo entry that doesn't work, and causes even simple things like 'vi' to blow up. Did you guys even test this at all? Doesn't look like you even edited a file! We went back to a hacked V1.3.6 terminfo entry (yes, that one was wrong too, but less wrong) It appears that your firm enhanced the ANSI driver in the console interface, but didn't debug it -- thus it doesn't work as you expected. o Renamed the sio driver to 'asy', but apparently little else, since it still panics every couple of days in 'rmsd', at the EXACT same offset that it used to. You also juggled interrupt priorities internally, which was obvious as soon as we tried to put a com 3 board on int 5 -- and it's unusable at 1200 baud! This attempt at interrupt-juggling did *not* solve the problem -- just rearranged the distribution of occurrances. o Introduced a new bug -- 'flsetdma' -- floppy access now occasionally gives this message, followed by a panic a few seconds later. This is a new problem -- but it makes floppy file-systems impossible! o Changed something in the panic handling -- now the system will sometimes (about 1/2 of the time) reboot spontaneously (and immediately) after a panic. This means that we *CANT EVEN DETERMINE WHERE IT'S CRASHING*. We're getting tired of the run-around, people. We're ALREADY tired of the 2-week wait for product. We're sick of being told "it's fixed in this release", when it is *NOT*. We're shopping for a 80386 Unix -- will be buy (and resell) yours? Somehow I doubt it. If we do, we'll need something concrete to protect ourselves -- like a 90-day evaluation during which we can test, retest, and check -- and only THEN cough up the cash. Then again, I doubt that this much trouble is worth it -- SCO Xenix V/386 is only a few hundred more, and Interactive and Bell Tech both have ports for sale which are competitive with yours..... SCO can ship product within 72 hours. You take 2-3 weeks, EVERY TIME. You are *always* backordered, out of stock, or just plain slow. "Service and support? What's that?" By the way, we're using Televideo Tele-cat 286 and Tele-386 hardware with your 80286 product -- the Telecat is listed as a SUPPORTED system -- meaning that it supposedly passed QA/QC. Did it really ever receive any of either? *** FLAME OFF *** This entire situation is even more ludicrous when one considers that it is not impossible to produce a decent Unix for small systems. We've just obtained SCO Xenix/386 -- and it's REALLY NICE. No panics, no surprises, no glitches, no nothing -- except solid performance. And before someone screams "your hardware is broken, that's why Microport blows up" remember that this same hardware is now running Xenix V/386 -- with ZERO problems. -- Karl Denninger UUCP : ...ihnp4!ddsw1!karl Macro Computer Solutions Dial : +1 (312) 566-8911 (300-1200) "Quality solutions at a fair price" Voice: +1 (312) 566-8910 (24 hrs)