SCOUG-HELP Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Wed, 31 Jul 2002 12:33:54 PST7
From:	"J. R. Fox" <jr_fox@pacbell.net >
Reply-To:	scoug-help@scoug.com
To:	scoug-help@scoug.com
Subject:	SCOUG-Help: Re: significance of Trap E

Content Type: text/plain

=====================================================
If you are responding to someone asking for help who
may not be a member of this list, be sure to use the
REPLY TO ALL feature of your email program.
=====================================================

Steven replied:

> As there should be. A trap E is a generic error. Any piece of code that
> incorrectly attempts to access memory it does not own will generate a trap
> E.

One of many details I did not know. Too bad there is no os design (or
at least none available to
us) that can just deflect such fatal requests, telling the requesting
service "No, you cannot go
there," and generate a report for the user that makes identifying and
correcting the error much more
accessible . . . instead of a crash & burn that leaves us none the
wiser and takes 15 minutes to
recover from. I guess that would require some sort of pre-test,
look-ahead, simulation thingie, for
most any instruction (and with a minimal performance penalty) . . .
and that's way more advanced
than anything around today ?

> >theories and suggested fixes, but very possibly irrelevent to my problem.
> >Most of them referred to stack fixes. I haven't been using Injoy or any
>
> Right. IBM shipped the MCP code without integrating the fix for the "trap
> E on redial" defect.

Those news messages, when they offered corrective suggestions, said
that the user needed to apply
ic27649 (which I saw on some past SCOUG cd's), or possibly another
archive called TCPIPUPD.EXE, but
that another one, ic32802 was a pre-requisite for these. I was
unable to locate the latter two.
I was able to find one called ic32290. As usual, this alpha-numeric
soup of TCP & MPTS fixes
confuses me. I don't know what the MCP-2 (which Tony apparently
applied) did or did not update in
this regard. The files I see in the eCS \MPTN\Protocol, for example,
date from early 11/01. The
files in one of the fix archives I did find are dated only a couple
weeks later. Did they fix that
much in two weeks time ? There are also fix archives floating around
called INJOYFIX and TELNETFX.

Why do I bother mentioning this, when it won't be relevent to the
particular Trap E I've been
discussing here ? Because I fully intend to support my V.90 modem in
eCS -- as an emergency
fallback, just as I had in W4. And that means one dialer or another
will be used. Might as well
update anything else known to cause a Trap E, while I'm at it.

> Yep. Eventually you will have to decide if the problem is video related
> or something wrong in the VDM subsystem. Have you tested yet with just
> straight VGA? If so, how?

You know, I was going to do that -- almost did do it while I was
briefly running VGA, before
reverting to the Matrox 2.36 drivers.

Jordan

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-help".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 31 | July | 2002 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.