[comp.unix.microport] System V/AT v2.4 Impressions and Bug Report

mjy@sdti.UUCP (Michael J. Young) (10/27/88)

I haven't seen much activity here of late.  Has anyone installed the
2.4 upgrade to System V/AT?  Here are my impressions of it along with
a few bug reports:

The new kernel has support for ESDI and RLL drives, although you have
to use the linkkit to get it.  Since I'm still stuck with ST506 controllers,
I haven't been able to try it out.  But I'm sure glad to see it there!

There is a new virtual console "utility" called "vcon" which eliminates
the need to create a getty for each virtual console.  Vcon is just run
once from inittab and attached to /dev/console, and it spawns gettys when
you hit the appropriate hot keys.  It's pretty nice, although there are
some strange behaviors that I don't like, and it's not configurable.
More on that later.

The hotkeys can be reconfigured using the new "mapkey" utility.  In addition
to defining a string that is sent each time a key is pressed, you can now
cause a signal to be sent to a process, or switch to any arbitrary console,
etc.  Not a bad idea, but it has problems too (below).

The disk driver seems to be better. The two-drive problem hasn't shown up
since I installed 2.4, and I'm beating 2 drives pretty bad.

The floppy driver has been improved.  Now you can access two floppies
simultaneously.  Under 2.3 I used to see erratic behavior sometimes (like
failed accesses for no reason), but everything seems clean under 2.4.

The maximum user process size is now user-configurable.  Unfortunately,
it didn't seem to help running pathalias, I still get a core dump when
I try to run it on the entire map database.  I've set the process size
to 4MB and the swap partition to 9000 blocks (I know that's less than the
recommended, but it should be enough for a single large process shouldn't
it?), but pathalias still fails when it tries to grow beyond 1MB.  Has
anyone else gotten pathalias to process the entire world?  How much
process space/swap space are needed?

There are supposed to be some fixes to the 287 support, but I haven't tried
it out yet.  There don't seem to be any substantial improvements to the
compiler, even though they issued a new SDS.  I sure wish they'd find
someone who can fix that stupid compiler.

New Bugs:
1.  Contrary to the release notes, PgUp and PgDn still seem to be
    defined backward.  It's easily fixed by putting a couple of "setkey"
    calls in an rc.d script.

2.  With the new kernel, when getty on a modem line exits (like when
    going from multi-user to single-user mode or complete shutdown), 
    DTR goes away, but then comes back!  It remains on forever!  It
    doesn't seem to cause any problems, but it was a little disconcerting.

3.  I still think the ansi terminfo entries are goofed up.  They still
    mess up jove, and even less had problems with it.  I went back to
    my (munged) 2.3 entry and everything is dandy.  I suppose the real
    problem could be in jove, etc., but I doubt it.

4.  Sometimes the keyboard locks up (scroll lock light on) and there
    doesn't seem to be a way to free it up short of reset.  Even Ctrl-Alt-Del
    stops working.  It's happened to me three times in four days, usually when
    I've accidentally hit more than one key at a time while using CTRL-S
    and CTRL-Q.  This never happened under 2.3, even though I wasn't
    any better a typist back then!

5.  Sometimes for no known reason "ixon" processing gets turned off and
    CTRL-S/CTRL-Q no longer work.  Typing "stty ixon" restores it, but
    it happens often enough to be bothersome.  I assume it has something
    to do with the previous bug as well.

6.  Control key processing has changed.  CTRL-SHIFT-2 (CTRL-'@') no longer
    emits a NUL (0x0), but a '@'.  In fact, under 2.3 CTRL-2 emitted a
    NUL.  Now it emits a '2'.  There no longer seems to be a way of getting
    the keyboard to emit a NUL.

7.  The "mapkey" utility has some bugs.  First of all, entering an
    illegal (unsupported) key name causes a core dump.  Secondly, using
    the form:
    	mapkey {keyname}
    causes an ioctl error, even though it is listed in the online man page
    as a legal construct (it should display the definition for the key).

8.  The "vcon" utility likes to assume that when you switch to a new
    virtual console you want to log in as the same user that you used
    on the previous console.  For example, say you're logged in as "guest"
    on virtual console 1 and you switch to console 2 for the first time.
    Vcon will automatically log you in on console 2 as "guest".  I'd
    rather just get a new login prompt.  The only way to get a login
    prompt is to first switch to an existing console that has a login
    prompt.  Cute,  but no thanks.

9.  A more serious problem with vcon is that creating new consoles is
    dangerous.  Creating too many (~4) new consoles too quickly causes
    a double fault panic.  You can do this by hitting Alt-F2, Alt-F3, etc.,
    in rapid succession.  This is a documented "feature".  Waiting
    until each new console is done being created before creating a new
    one seems to avoid the problem.

All in all the upgrade was an improvement, but not as much of one as I
would have liked.  I'm not as interested in new features like "vcon"
as I am in having a working compiler.  The new disk drivers are a welcome
addition, though.

Has anyone else installed the upgrade yet?  What do you think?
-- 
Mike Young
Software Development Technologies, Inc., Sudbury MA       Tel: +1 508 443 5779
Internet: mjy@sdti.sdti.com                 UUCP: {harvard,mit-eddie}!sdti!mjy

jmsully@uport.UUCP (John M. Sully) (10/29/88)

In article <319@sdti.UUCP> mjy@sdti.UUCP (Michael J. Young) writes:
>The new kernel has support for ESDI and RLL drives, although you have
>to use the linkkit to get it.  Since I'm still stuck with ST506 controllers,
>I haven't been able to try it out.  But I'm sure glad to see it there!

You don't need to use the linkkit to enable ESDI and RLL support, although
you do need to use it to enable support for an Everex tape drive.

>There are supposed to be some fixes to the 287 support, but I haven't tried
>it out yet.  There don't seem to be any substantial improvements to the
>compiler, even though they issued a new SDS.  I sure wish they'd find
>someone who can fix that stupid compiler.

Guess what?  We found someone to fix the stupid compiler.  Beta's should 
be available soon, contact Thuan-tit Ewe in the support department for
further details.

>2.  With the new kernel, when getty on a modem line exits (like when
>    going from multi-user to single-user mode or complete shutdown), 
>    DTR goes away, but then comes back!  It remains on forever!  It
>    doesn't seem to cause any problems, but it was a little disconcerting.

Hmm.... I'll take a look at this, it seems that the flag should have been
cleared at this point though.

>4.  Sometimes the keyboard locks up (scroll lock light on) and there
>    doesn't seem to be a way to free it up short of reset.  Even Ctrl-Alt-Del
>    stops working.  It's happened to me three times in four days, usually when
>    I've accidentally hit more than one key at a time while using CTRL-S
>    and CTRL-Q.  This never happened under 2.3, even though I wasn't
>    any better a typist back then!

This bug has been reported a couple of times, but we have been unable to 
reproduce it.  I'll try hitting more than one key at a time.  BTW, we have
been told that if you wait about 3 minutes that things will be returned to
normal.

>6.  Control key processing has changed.  CTRL-SHIFT-2 (CTRL-'@') no longer
>    emits a NUL (0x0), but a '@'.  In fact, under 2.3 CTRL-2 emitted a
>    NUL.  Now it emits a '2'.  There no longer seems to be a way of getting
>    the keyboard to emit a NUL.

Oops!

Thanks for the bug reports, they will be forwarded to the engineering 
department.

dave@viper.Lynx.MN.Org (David Messer) (10/30/88)

In article <248@uport.UUCP> jmsully@uport.UUCP (John M. Sully) writes:
 >In article <319@sdti.UUCP> mjy@sdti.UUCP (Michael J. Young) writes:
 >>4.  Sometimes the keyboard locks up (scroll lock light on) and there
 >>    doesn't seem to be a way to free it up short of reset.  Even Ctrl-Alt-Del
 >>    stops working.  It's happened to me three times in four days, usually when
 >>    I've accidentally hit more than one key at a time while using CTRL-S
 >>    and CTRL-Q.  This never happened under 2.3, even though I wasn't
 >>    any better a typist back then!
 >
 >This bug has been reported a couple of times, but we have been unable to 
 >reproduce it.  I'll try hitting more than one key at a time.  BTW, we have
 >been told that if you wait about 3 minutes that things will be returned to
 >normal.

The first time I got this bug, I waited considerably longer
than three minutes and it didn't clear-up.  If/when I get it
again, I will try to record the exact situation that caused it
and wait fifteen minutes or so.  I will let you know if it
happens.
-- 
If you can't convince |   David Messer - (dave@Lynx.MN.Org)
them, confuse them.   |   Lynx Data Systems
   -- Harry S Truman  | 
                      |   amdahl   --!bungia!viper!dave
                      |   hpda    /

Copyright 1988 David Messer -- All Rights Reserved
This work may be freely copied.  Any restrictions on
redistribution of this work are prohibited.

markz@ssc.UUCP (Mark Zenier) (10/30/88)

In article <319@sdti.UUCP>, mjy@sdti.UUCP (Michael J. Young) writes:
> 
> I haven't seen much activity here of late.  Has anyone installed the
> 2.4 upgrade to System V/AT?  Here are my impressions of it along with
> a few bug reports:
> ...
 
> 4.  Sometimes the keyboard locks up (scroll lock light on) and there
>     doesn't seem to be a way to free it up short of reset.  Even Ctrl-Alt-Del
>     stops working.  It's happened to me three times in four days, usually when
>     I've accidentally hit more than one key at a time while using CTRL-S
>     and CTRL-Q.  This never happened under 2.3, even though I wasn't
>     any better a typist back then!

The quick fix is to unplug the keyboard, because the microcontroller in the
keyboard is lost.  The long term fix is to get a keyboard with a faster
microcontroller.  The symptom I had was the the keyboard would lock up
under version 2.3 when I did flow control or hit the shift lock or num lock
too fast.  That problem went away with 2.4 but then the keyboard would
lock up when a string of backspaces was typed.  That was so irritating that
I bought another keyboard (My third).  This one ( a Maxiswitch) seem to
work.


Mark Zenier	uunet!pilchuck!ssc!markz		
"He did decide, though, that with more time and a great deal of mental effort,
he could probably turn the activity into an acceptable perversion"-Mick Farren

hsu@santra.HUT.FI (Heikki Suonsivu) (10/30/88)

In article <248@uport.UUCP> jmsully@uport.UUCP (John M. Sully) writes:
>In article <319@sdti.UUCP> mjy@sdti.UUCP (Michael J. Young) writes:
>>4.  Sometimes the keyboard locks up (scroll lock light on) and there
...
>This bug has been reported a couple of times, but we have been unable to 
>reproduce it.  I'll try hitting more than one key at a time.  BTW, we have

Try diconnecting and replugging the keyboard, it works when using 386
version. Bug appears often when pressing num lock, caps lock or ctrl-s
(scroll lock) after computer has been idle for long while or when I
boot up.

stever@tree.UUCP (Steve Rudek) (10/31/88)

The BIG news, at least as far as I am concerned, is that 2.4 appears to have
*finally* fixed my serial port panics!  The machine hasn't crashed in a week
--that could be just chance, but I've never before approached that
long an uptime.  Curses is also MUCH healthier and, apparently, much
more ansi/vt100 (?) compatible (hey, all I know is that vnews works like a
charm and it was totally garbaged up with 2.3).

Over the past year and a half, most of my initial good will toward Microport
for having introduced a reasonably-priced UNIX implementation has
been destroyed by miscellaneous Microport employees (in my book, epitomized
by Brian Tihista--an ignorant, unprofessional and truely obnoxious individual
who shouldn't be permitted ANY sort of contact with the public but who, at
Microport, serves as a "Customer Service Representative.") who obviously
know little and care much, much less.

Just prior to getting 2.4, however, a "John Plocher" invited me to call him
directly.  We had a long telephone conversation during which Mr. Plocher
listened patiently and gave me assurance that if 2.4 didn't fix my problem he
would personally see that a solution was pursued.  Even though I wasn't
expecting an improvement from 2.4, John Plocher's personal interest
considerably tempered my anger.  Now that my serial port "panic" problem
appears to finally be fixed I'm looking forward to healing some of the
ugly feelings I've developed toward Microport.  I'd suggest that anyone who
has ongoing experience of being maltreated by Microport call directly either
John Plocher or John Sully (another Microport employee who, in my opinion, puts
his best effort into his work).

P.S.>

By the way, I've repeatedly suggested to both John Sully and John Plocher
that a Microport quarterly newsletter might perform wonders from a public
relations standpoint.  For instance, most of my frustrations with Microport
could be considerably diffused if they would just disclose known software
problems and document their efforts toward a solution.  Not all customers
have access to the net and calling the Microport BBS is expensive,
time-consuming or impossible for others.

I expressed the opinion that the cost of distributing such a newsletter would
almost certainly be more than recouped if they sold a little bit of
advertising space.  John Plocher didn't dispute that and, in fact, said that
the cost of a newsletter wasn't his primary reservation.  He is of the
opinion that there might not be enough worthwhile information to justify a
newsletter; he doesn't want to mail out a worthless piece of paper.

John Plocher's concern is almost impossible for me to appreciate.  With the
2.3 release, for instance, two serious bug fixes--the corrections to the
inittab file and to the console terminfo entry--could have been distributed
in a newsletter costing 25 cents!  Instead I had to waste many hours and 
spend probably 25 dollars in phone calls to the Microport BBS to get the
simple answers.  The recent discussion about replacing the USART in serial
cards in order to clean-up high speed communications would more than justify
an issue all by itself!

How do you folks feel about a paper newsletter?  Maybe a sufficient volume
of interest might influence Microport to begin such a publication.  As I
told John Plocher, if he is concerned about finding personnel to help
produce a worthwhile mailing, there are probably lots of USENET folks who
would be willing to contribute substantive articles.  If you agree with me,
I'd suggest you send John some email.

det@hawkmoon.MN.ORG (Derek E. Terveer) (11/02/88)

In article <127@tree.UUCP>, stever@tree.UUCP (Steve Rudek) writes:
> How do you folks feel about a paper newsletter?

I'm not sure about a paper newsletter, but I would certainly appreciate at the
very least some sort of regular status report posted to this newsgroup.  However
I can easily see that not every microport user has access to Usenet and/or 
various editions of the Usenet newsletter would end up on the floor when
intermediate nodes overflow their disks (elric and corum, my feeds, do so
occasionally (:-().  Perhaps a paper letter that is also posted to Usenet.
-- 
Derek Terveer		det@hawkmoon.MN.ORG
			w(612)681-6986	h(612)688-0667

"A proper king is crowned" -- Thomas B. Costain

gda@creare.UUCP (Gray Abbott) (11/04/88)

In article <127@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes:
>By the way, I've repeatedly suggested to both John Sully and John Plocher
>that a Microport quarterly newsletter might perform wonders from a public
>relations standpoint.


I agree that a newsletter could be very useful.  If Microport doesn't
want to do it, why not do it as an independent user group?  You could
still fund it through advertising, or membership fees, and Microport
wouldn't need to question whether it was worth their time.  They would
probably be willing to distribute membership applications with product
distributions (especially if the group was non-profit) and could also
steer third party software and hardware vendors to the group as potential
advertisers.  If there's enough interest, I'd be willing to help run
such a group (note: I don't know anything about putting out a newsletter).