root@uwspan.UUCP (John Plocher) (12/31/87)
[ I am posting this for the 286 moderator who is out of town for a week's vacation -John ] (This is cross-posted to comp.unix.xenix and alt.flame, since the original flame was posted there. Followups have been redirected to comp.unix.microport. --JM) About a month ago, I had had serious problems with my System V/AT system. I had gotten numerous hard disk I/O errors, serial link double panics, trashed file systems, and general aggravation. I posted an article in which I took a blowtorch to Microport and its support policy. I wasn't quite prepared for the response I got from Microport. Within two days, I got a letter from Dwight Leu, in which he expressed his willingness to do what was necessary to resolve my problems. By that time, the sales people were telling me that the upgrade to 2.3 had shipped, so I asked Dwight to keep an eye on it for me. A week later, I got the upgrade, which wasn't bad except for one minor problem - I had two copies of the runtime.3 disk, and no copies of the runtime.2 disk. I called Dwight. He had Greg Chavez (sp? - apologies if I messed up) call me, who shipped a replacement via UPS Red. (I got it the next day.) I also mentioned my problems with DOSMerge 286. Dwight had Garrett Tolson (again, sp?), the manager of the 286 Merge product call. Garrett spent the better part of an hour on the phone with me going over various hypotheses on why there was a problem. (Refresh: on booting the Merge kernel, my system hangs - right before it prints the 'drive type 0 = 15; drive type 1 = 10' message.) We reached the conclusion that I probably have a hardware problem with my system, most likely in the CMOS RAM's clock tick output. (That's the only initialization difference between the Merge kernel and the regular kernel.) I believe that Microport is getting sensitized to the voluminous flames they've received. Dwight told me that they were mounting an active campaign to satisfy people who had been vocal in their dissatisfaction. I recommend that anyone who is having problems call Dwight, and give him the chance to work them out. Part of my problem turned out to be the ST225 disk drive that I was running as my root filesystem. I pointed the fusion torch that I had previously aimed at Microport at the drive, and rendered it into a puddle of molten slag, after I got my ST4051 back from being repaired. It's now beginning to give me I/O errors, but this time I'm gonna run a full drive surface analysis before I flame Microport again. I got asked about the fsck bug I mentioned before. Here's the analysis that Steve Nuchia (uunet!nuchat!steve) gave me as to the problem: If fsck needs to use a work file, it gets confused. During phase 1, it builds a map of all the used sectors in memory, using the work file as a virtual memory extension. During phase 2, it clobbers that file. During phase 5, it uses the (now clobbered) file to check the free list, and, if it finds a discrepancy (which it is likely to do), then it uses the (still clobbered) file during phase 6 to rebuild the free list. I don't know what parameters fsck uses to determine that he needs a work file, but it's easy enough to determine if your file system is big enough to require one: fsck it with 'fsck -n /dev/dsk/0s2' (or whichever). If it asks you for a file name, then it's big enough. In that case, I recommend that you d o the following to avoid having the bug trash your file system: 1) Edit /etc/bcheckrc and /etc/mountall and remove the -y flags from the fsck commands. This will make fsck ask before it does anything to your file system. 2) If you get fsck invoked, answer 'no' to the question "BAD FREE LIST. SALVAGE?". This will cause your file system to still be bad, but does not use the clobbered map information to rebuild (==clobber) your free list. 3) Rerun fsck manually, as 'fsck -f /dev/dsk/0s2' (or whatever). This only invokes passes 1 and 5, and 6 if needed, avoiding the corruption from pass 2. Allow it to set the 'file system OK' flag. This procedure will rebuild the file system, and do so cleanly. I haven't gotten a serial I/O double panic lately. According to Dwight, this problem affected about 20% of users initially. They had trouble reproducing it, and only were able to during 2.2 testing. They fixed it - they thought. In reality, they only cut it down to 5%. If you still get double panics on 2.3, call Microport and complain - and tel them about your serial I/O configuration. The problem appears to be configuration dependent. New in 2.3 is an enhanced ANSI console driver. It added some new features, like support for a 25th status line and 15 virtual consoles. Unfortunately, it also added a bug which makes it get confused on cursor position commands. There is a problem with the ansi terminfo file; to fix it, you must: 1) untic ansi >ansi.tic This will produce an editable copy of the terminfo source. 2) Edit ansi.tic, and change: cbt=\E[Z, bel=^G, cr=\r, csr=\E[%p1%d;%p2%dr, to: cbt=\E[Z, bel=^G, cr=\r, csr=\E[%i%p1%d;%p2%dr, ^^ 3) tic ansi.tic This will install the fixed terminfo definition. The fix improves the console driver's behavior, but does not completely cure the problem. It shows up especially badly when using vnews (mine's 2.11, at patchlevel 12). In summary: 2.3 does fix some problems, and is a generally nicer release. It's not a panacea. Microport knows that they're not exactly the most well-loved company around at the moment. They'd like to change that. Unfortunately, it'll take them a while. They have had a tremendous increase in business, and are just now staffing up. (Greg Chavez, the guy who talked to me about my disk screw-up, was hired as the manager of quality control only a couple of weeks prior to my talking to him.) It'll be rough for a while. If you have a problem, tell them about it! The squeaky wheel gets the grease, and, from my conversations with Dwight, they're laying in a big stock of grease... -- Jay Maynard, K5ZC (@WB5BBW)...>splut!< | GEnie: JAYMAYNARD CI$: 71036,1603 uucp: {uunet!nuchat,academ!uhnix1,{ihnp4,bellcore,killer}!tness1}!splut!jay Never ascribe to malice that which can adequately be explained by stupidity. The opinions herein are shared by none of my cats, much less anyone else. -- Email to microport-request@uwspan for info on the newsgroup comp.unix.microport, otherwise mail to microport@uwspan with a Subject: line containing one of: 6300+, 386, 286, Bug, Source, Merge, "Send Buglist", or "Send Version" (UUCP: ...!uwvax!uwspan!microport & ...!uwvax!uwspan!microport-request)