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)