New system completely locks up every few minutes; also, TRAP E
Alex Taylor
could really use some help on these, if anyone can give it... TIA.
PROBLEM 1
Newly-installed system (eCS GA) on my existing system, replacing
an old Warp 4 FP8 system.
I'm having a very serious problem. Every few minutes, seemingly
at random (but generally when working in an application), the
entire system locks up. Completely. Windows stop painting halfway
through, the mouse can do nothing, and not even NumLock turns on/off.
This lasts for anywhere between six and thirty seconds, before the
system comes back to life.
This is NOT the INI-writing slowdown. That just makes the system
rather unresponsive for a couple of seconds. THIS problem is a
complete lockout.
I think this started a couple of days ago, but I'm not sure exactly
when. (About the time I installed Sibyl FixPak 3, I think.) At some
times it's less frequent than at others, so I suppose it's possible
that it was happening for a short while before I noticed it. At any
rate, I'm 99% certain this did NOT happen during the first few days
after I installed the new system.
However, I've removed or disabled pretty much all of the system-level
changes I made since then!
Things I've tried to fix it:
- Installed the INI-file writing fix (newcalls). No effect, so I
removed it again.
- Removed HPFS386 (which I'm using on this system) and reverted to
the normal HPFS drivers. No effect.
- Disabled MPTS startup. No effect.
- Disabled Desktop On-Call daemons. No effect.
- Removed VAC++ 3, the Toolkit 4.5 directories, and Sibyl, from the
system LIBPATH, DPATH, and PATH. No effect.
- Disabled the IOMega OAD driver (for my PP Zip drive). No effect.
- Replaced the DANIS506 and DANIATAPI drivers with the IBM ones.
No effect.
- Ran CheckIni /C. Twice. No effect.
- Disabled the FAT32 driver. No effect.
Can somebody PLEASE help me? I can't use the system like this!
PROBLEM 2
This may have started at the same time another problem began. A
few days ago, I was accessing the system through Desktop On-Call,
and tried to run ProNews. The system TRAPped E (as I found when
I got home).
When I tried to reboot, I got the same TRAP E just as the desktop
tried to come up. I eventually got back into the system by
REMming out the MPTSTART.CMD line in CONFIG.SYS and rebooting.
After the system came up again, I re-enabled MPTSTART and rebooted,
and it worked this time.
However, a couple of times since then, I've gotten TRAP E: "Exception
in Device Driver: <empty>" at various stages during bootup. This
only occasionally occurs. Sometimes just after drivers load and
before the desktop appears, and sometimes almost immediately after
the boot logo comes up following Boot Manager.
Several of these occurred during my abortive attempts to install
WatchCat and Process Commander (both of which I gave up on and have
removed). I removed them and they stopped, at least for a couple
of days. But it's happened at least once since then, and the first
few were before I started trying.
I don't know what's going on, and it's driving me mad.
--
-----------------------------------------------------------------
Alex Taylor BA - CIS - University of Guelph
al...@eddie.cis.uoguelph.ca http://eddie.cis.uoguelph.ca/~alex
-----------------------------------------------------------------
William L. Hartzell
Both problem may be related to the problem that the eCS MPTS installer
has in correctly installing all the protocols part to the stack. Since
you did an install over, you are having parts of two stacks failing to
communicate completely with in its self. I would suggest running the
MPTS install again after you've deleted the entire TCPIP stack and
applications. Save the user modified files elsewhere so you can put
back, like the firewall.cfg and the B4TCP.CMD and TCPEXIT.CMD files.
--
Bill
<Okay, you win>
Alex Taylor
>> PROBLEM 1
>>
>> I'm having a very serious problem. Every few minutes, seemingly
>> at random (but generally when working in an application), the
>> entire system locks up. Completely. Windows stop painting halfway
>> through, the mouse can do nothing, and not even NumLock turns on/off.
>> This lasts for anywhere between six and thirty seconds, before the
>> system comes back to life.
>>
>> Things I've tried to fix it:
>> --snip--
I forgot to add: installed the latest IC**** MPTS stack fix.
I've also now installed the 508 kernel.
More update below.
>> PROBLEM 2
>>
>> This may have started at the same time another problem began. A
>> few days ago, I was accessing the system through Desktop On-Call,
>> and tried to run ProNews. The system TRAPped E (as I found when
>> I got home).
>>
>> When I tried to reboot, I got the same TRAP E just as the desktop
>> tried to come up. I eventually got back into the system by
>> REMming out the MPTSTART.CMD line in CONFIG.SYS and rebooting.
>> After the system came up again, I re-enabled MPTSTART and rebooted,
>> and it worked this time.
>>
>> However, a couple of times since then, I've gotten TRAP E: "Exception
>> in Device Driver: <empty>" at various stages during bootup. This
>> only occasionally occurs. Sometimes just after drivers load and
>> before the desktop appears, and sometimes almost immediately after
>> the boot logo comes up following Boot Manager.
>
>Both problem may be related to the problem that the eCS MPTS installer
>has in correctly installing all the protocols part to the stack. Since
>you did an install over, you are having parts of two stacks failing to
>communicate completely with in its self. I would suggest running the
>MPTS install again after you've deleted the entire TCPIP stack and
>applications. Save the user modified files elsewhere so you can put
>back, like the firewall.cfg and the B4TCP.CMD and TCPEXIT.CMD files.
Thanks, but actually, I didn't do an install-over. I wiped my Warp 4
drive clean and did a long format before installing eCS.
However, there's been a major new development.
Over the weekend, the TRAPs E got more and more frequent, until by
Sunday evening, the system wouldn't boot at all.
Acting on a hunch (after all, the first time this happened, REMming
out the MPTSTART allowed the system back up), I disabled the driver
for my NIC.
And the system came back up.
So, this morning I swapped out the NIC in this machine (D-Link
DFE-530TX, about three years old by now) with one from my firewall
box: a DFE-500TX which uses a Digital 21141 chipset.
My system is now running again. I've yet to see if the "mystery hang"
has gone, and of course maybe another TRAP is just around the corner,
but at least I can boot the machine again. I'll watch and wait.
--
--------------------------
Alex Taylor
al...@eddie.cis.uoguelph.ca
--------------------------
Al Savage
wrote:
> So, this morning I swapped out the NIC in this machine (D-Link
> DFE-530TX, about three years old by now) with one from my firewall
> box: a DFE-500TX which uses a Digital 21141 chipset.
>
> My system is now running again. I've yet to see if the "mystery hang"
> has gone,
AHAHAHAHA!
D-Link has claimed another victim.
This is why I only run Intel EtherExpress Pro100 and 3Com 3C905x: they
very rarely break, and when they do I have no problem exercising the
warranty. For an extra $20, it's worth it.
--
Regards,
Al S.
* Hillman & Rootes Group manuals online: http://asavage.fdns.net/Hillman
* Ford Falcon manuals online: http://FalconFAQ.fdns.net
This OS/2 system ("Tori", W4 FP15) uptime is 6 days 00:29 hours
Alex Taylor
it with a different one.
I guess that NIC had just reached the end of its life...
You know, every now and then, when the system booted, it would just
'freeze' right after the last drivers loaded (before the desktop came
up). This was random but would happen maybe once in ten bootups.
That was going on for at least a year and a half. But it became much
more pronounced at the time this problem was occurring, and I suddenly
realize that that is the exact point in the boot sequence where MPTS
initializes.
Maybe that was a buggy NIC card all along... Well, I'll wait and see
if that problem has gone as well.
On Mon, 20 Aug 2001 19:18:03, al...@eddie.cis.uoguelph.ca (Alex Taylor) wrote:
> >> I'm having a very serious problem. Every few minutes, seemingly
> >> at random (but generally when working in an application), the
> >> entire system locks up. Completely. Windows stop painting halfway
> >> through, the mouse can do nothing, and not even NumLock turns on/off.
> >> This lasts for anywhere between six and thirty seconds, before the
> >> system comes back to life.
> >> [Also, periodic TRAPs E on boot.]
>
> Over the weekend, the TRAPs E got more and more frequent, until by
> Sunday evening, the system wouldn't boot at all.
>
> Acting on a hunch (after all, the first time this happened, REMming
> out the MPTSTART allowed the system back up), I disabled the driver
> for my NIC. And the system came back up.
>
> So, this morning I swapped out the NIC in this machine (D-Link
> DFE-530TX, about three years old by now) with one from my firewall
> box: a DFE-500TX which uses a Digital 21141 chipset.
Al Savage
wrote:
> Okay, the problem has vanished since I took out my NIC and replaced
> it with a different one.
>
> I guess that NIC had just reached the end of its life...
Hey, you got several years of (sometimes not very good) service from
that D-Link, and that's a lot better than some people get.
> You know, every now and then, when the system booted, it would just
> 'freeze' right after the last drivers loaded (before the desktop came
> up). This was random but would happen maybe once in ten bootups.
>
> That was going on for at least a year and a half.
Go Intel or 3Com and never look back. One less variable to worry about.
I used to make a tidy sum, going to client offices and yanking low-end
hardware (such as D-Link NICs) to fix 'mystery' problems such as yours.
> > So, this morning I swapped out the NIC in this machine (D-Link
> > DFE-530TX, about three years old by now) with one from my firewall
> > box: a DFE-500TX which uses a Digital 21141 chipset.
That's the same chipset as the Kinston KNE series uses. It's "OK" if
not stellar. I don't know about the driver you're using, but the
Kingston-supplied driver will NOT accept the "/v" parameter, and in fact
refuses to load if you specify it!
--
Regards,
Al S.
* Hillman & Rootes Group manuals online: http://asavage.fdns.net/Hillman
* Ford Falcon manuals online: http://FalconFAQ.fdns.net
This OS/2 system ("Tori", W4 FP15) uptime is 2 days 07:25 hours
John Poltorak
> Okay, the problem has vanished since I took out my NIC and replaced
> it with a different one.
>
> I guess that NIC had just reached the end of its life...
How does a NIC reach its end of life?
Does it have any moving parts which are subject to wear? Is it programed to fail
after so many bytes have passed through it?
>
> --
> -----------------------------------------------------------------
> Alex Taylor BA - CIS - University of Guelph
> al...@eddie.cis.uoguelph.ca http://eddie.cis.uoguelph.ca/~alex
> -----------------------------------------------------------------
--
John
Steven Hunter
> How does a NIC reach its end of life?
>
> Does it have any moving parts which are subject to wear? Is it
> programed to fail after so many bytes have passed through it?
Most solid-state devices have the potential to function perfectly
forever. The problems come from poor manufacturing conditions, bad or
damaged power regulators, heat, and sudden voltage fluxuations. A
mediocre power supply may cost less than a good one, but your power
will be far dirtier. Also, the dirtier your AC power is the more
problems you'll have. I've fixed problems with crashing computers
mearly by adding a surge protector with very basic noise filtering to
the mix.
--
Steven Hunter | shu...@NOSPAMbilbo.bio.purdue.edu
"HEY! Check out these cresent fresh skulls in my salad!" - Sifl & Olly
Al Savage
<shu...@NOSPAMbilbo.bio.purdue.edu> wrote:
> Most solid-state devices have the potential to function perfectly
> forever.
AHAHAHAHA!
Nope, this stuff definitely isn't designed to last more than a few
years. I especially like it when (SMT or not) electrolytic capacitors
are used in a high-heat environment, where a tantalum or equivalent
would last "forever" but the electrolytic "dries out" and goes high ESR
within a couple of years.
I did full-time monitor & terminal repair for a few years, and about 60%
of my repairs were replacing failed electrolytic capacitors (another 25%
was faulty solder joints). Sorry, Steven, but monitors are solid state
and most of the crappy ones die or are have a picture that are too
horrible to look at anymore, after only a couple thousand hours of use.
And NICs and such use surface-mount electrolytics too. This is just one
good example; there are others.
And the cleanest power possible supplied to them won't stretch an
overheated electolytic another hour.
--
Regards,
Al S.
* Hillman & Rootes Group manuals online: http://asavage.fdns.net/Hillman
* Ford Falcon manuals online: http://FalconFAQ.fdns.net
This OS/2 system ("Tori", W4 FP15) uptime is 2 days 20:53 hours
Sergey I. Yevtushenko
AS> Go Intel or 3Com and never look back. One less variable to worry about.
AS> I used to make a tidy sum, going to client offices and yanking low-end
AS> hardware (such as D-Link NICs) to fix 'mystery' problems such as yours.
I had almost as bad experience with 3Com hardware as yours with D-Link.
Moreover, for last 8 years dealing with network equipment I only once
saw broken equipment taken rigth from the box. And it was 3Com hub.
Low-end hardware often built on same components as "high-end" and
often "high-end" equipment is just same "low-end" with other label.
Just come to mind: six years ago I had experience installing EISA NIC
in Compaq server. Delivering of original Compaq's NIC took longer that
I expected and meanwhile I decided to install some other NIC. I have
purchased D-Link's one and installed in server. When Compaq's NIC
was delivered I took both NIC's and compared. There were no visible
difference except label. After all, all hardware produced in Taiwan
and China regardless from the brand :-)
As for D-Link NIC's, in paricular recent ones, I can tell that many
of them are built on Realtek chipset (or derived from it by D-Link)
and this is real source of the problems. Same problems can be seen
with NIC's with Realtek chipset produced with any other manufacturer.
Older D-Link NIC's buit on Digital Semiconductors' DC21x4x as well
as even older ISA NIC's warks flawlessly for many years. So do other
NIC's built on these chips.
Regards,
Sergey.
*--------------------------------------
ES@Home
http://www.naverex.kiev.ua/~evsi/
Steven Hunter
> AHAHAHAHA!
> Nope, this stuff definitely isn't designed to last more than a few
> years. I especially like it when (SMT or not) electrolytic capacitors
> are used in a high-heat environment, where a tantalum or equivalent
> would last "forever" but the electrolytic "dries out" and goes high ESR
> within a couple of years.
First of all I said they have the *potential* to last forever.
A lump of coal has the *potential* to become a diamond. And just
because something isn't _likely_ doesn't mean it can't or won't happen.
Second, I did ackowledge that heat is a contributing factor to failure.
Besides, you really can't disagree with me. If conditions are right
there is no reason why most well made solid state electronics won't
last a very very very long time.
> I did full-time monitor & terminal repair for a few years, and about 60%
> of my repairs were replacing failed electrolytic capacitors (another 25%
> was faulty solder joints). Sorry, Steven, but monitors are solid state
> and most of the crappy ones die or are have a picture that are too
> horrible to look at anymore, after only a couple thousand hours of use.
Monitors are NOT completely solid state. Sure they have many solid
state components but the one thing that fails the most on monitors is
the phosphor coating on the glass. (ie: burn-in)
> And NICs and such use surface-mount electrolytics too. This is just one
> good example; there are others.
>
> And the cleanest power possible supplied to them won't stretch an
> overheated electolytic another hour.
--
Al Savage
it won't work in four . . . "
On Thu, 30 Aug 2001 16:39:45, Steven Hunter
<shu...@NOSPAMbilbo.bio.purdue.edu> wrote:
> > Nope, this stuff definitely isn't designed to last more than a few
> > years.
>
> Besides, you really can't disagree with me. If conditions are right
> there is no reason why most well made solid state electronics won't
> last a very very very long time.
Yes, sure. What percentage of consumer electronics do you think are
"well made"? Ask around in sci.electronics.repair, where many full-time
repair professionals hang out, and they'll tell you: not very damned
much!
If you have well-made coal, it'll last a very long time (as a diamond),
but too much of today's consumer electronics is just sand, left out in
the rain.
> > I did full-time monitor & terminal repair for a few years, and about 60%
> > of my repairs were replacing failed electrolytic capacitors . . .
>
> Monitors are NOT completely solid state. Sure they have many solid
> state components but the one thing that fails the most on monitors is
> the phosphor coating on the glass. (ie: burn-in)
A lot of non-repairs were bad CRTs, but not for the reason you think.
Most _repairs_ were failed electrolytics, with failed solder joints a
close second.
Repairs: The first as the result of bad design (using an electrolytic in
a circuit that should have used a capacitor with different construction,
or at the very least an electrolytic with higher capacity, but both of
those cost more money); the second resulting often from the modern mass
wave-soldering assy. technique, which often leaves too little
mechanical strength in a soft metal joint subjected to repeated thermal
cycling.
Next up: dim CRTs or CRTs with poor color balance (usually, the green
drops off, leaving a purplish display) is NOT a result of worn phosphor
coating on the CRT, it's reduced emission from the three color guns.
This is easily indicated by any CRT tester/rejuver (like my Sencore
CR-70a). This isn't wear in the normal sense, it's a set of guns
(cathodes) which do not emit nearly as many electrons after being run
2000 hours as they did when new, and this wasn't really a problem in PC
monitors until about a decade ago when the market demanded cheaper CRTs.
Cheap cathodes = fast wear.
In general, anything with a Sony tube, the CRT will last "forever"
(beyond either usefulness, or non-repairability of the chassis, because
you can't source replacement "hybrid" ICs or custom ASICs); anything
with a Samsung or Philips tube will be scrap in well under a decade,
with the majority of the Samsung being "dim & purple" within 2000 hours,
if my experience counts. I've scrapped dozens of them.
Note that none of the above discussion of CRTs pertains to monochrome
tubes, which use a completely different phosphor setup (no "color dots"
in triads) and also don't use a shadow mask; those designs usually *do*
lose the phosphor over time, and have the burn-in problem about which
anyone who's used an old ATM knows.
--
Regards,
Al S.
* Hillman & Rootes Group manuals online: http://asavage.fdns.net/Hillman
* Ford Falcon manuals online: http://FalconFAQ.fdns.net
This OS/2 system ("Tori", W4 FP15) uptime is 4 days 23:38 hours
Thomas Hoffmann
> John Poltorak wrote:
>
> > How does a NIC reach its end of life?
> >
> > Does it have any moving parts which are subject to wear? Is it
> > programed to fail after so many bytes have passed through it?
>
> Most solid-state devices have the potential to function perfectly
> forever. The problems come from poor manufacturing conditions, bad or
A bit OT, but anyway:
Have you guys considered that not just immaterial bytes are moving in your
computer but electrons? This is macroscopically measured as current and
in modern (small and not necessarily poor manufactured) devices reaches
levels that lets degrade your devices over the years: There is really
"electronic wear": look for "accelerated testing" and "reliability" and
such terms an you will see what I mean.
--
Thomas Hoffmann Telephone: 49-351-4598831
thof...@zappa.sax.de Dresden, Germany
.sig under construction ...
Paul Floyd
>If you have well-made coal, it'll last a very long time (as a diamond),
>but too much of today's consumer electronics is just sand, left out in
>the rain.
Not the best of examples. Carbon has two allotropes (I think that's the
right term), diamond and graphite. Diamond is the unstable form, and
graphite stable. So though it's true that a diamond will last a very
long time, it'll end up as a lump of graphite in the end.
A bientot
Paul
--
Paul Floyd http://paulf.free.fr (for what it's worth)
Mail as URL, replace 1st . with @
If more is better, are double standards better than single ones?
swe...@kickapoo.com
> > > about 60%
> > > of my repairs were replacing failed electrolytic capacitors . . .
> >
>
> Most _repairs_ were failed electrolytics, with failed solder joints a
> close second.
>
> Repairs: The first as the result of bad design (using an electrolytic in
> a circuit that should have used a capacitor with different construction,
> or at the very least an electrolytic with higher capacity, but both of
> those cost more money)
Capacitor failures often have no particular rhyme or reason. One brand
will fail after x years and another will last indefinitely. Invest in
an in-circuit capacitor tester and your life will be immensely
simplified. For example, a typical satellite receiver, say 12 years
old, will have from 6 to a dozen bad capacitors. When these are
replaced the set will be good as new. Old HiFi's, too. It is not
always a power component or even a solid-state device that fails.
--
sp
Al Savage
> > > > about 60%
> > > > of my repairs were replacing failed electrolytic capacitors . . .
> Capacitor failures often have no particular rhyme or reason. One brand
> will fail after x years and another will last indefinitely. Invest in
> an in-circuit capacitor tester and your life will be immensely
> simplified.
Oh, I've owned a Bob Parker/Dick Smith ESR tester for years. It's
literally (that is, without exagerration), saved me thousands of dollars
in diagnostic time. And the kit was something like $50. All you add is
about an hour to assemble it, plus a decent set of probes (about $20).
I can't recommend it highly enough.
--
Regards,
Al S.
* Hillman & Rootes Group manuals online: http://asavage.fdns.net/Hillman
* Ford Falcon manuals online: http://FalconFAQ.fdns.net
This OS/2 system ("Tori", W4 FP15) uptime is 0 days 00:22 hours
Brian {Hamilton Kelly}
asa...@iname.com "Al Savage" writes:
> Most _repairs_ were failed electrolytics, with failed solder joints a
> close second.
>
> Repairs: The first as the result of bad design (using an electrolytic in
> a circuit that should have used a capacitor with different construction,
> or at the very least an electrolytic with higher capacity, but both of
> those cost more money); the second resulting often from the modern mass
> wave-soldering assy. technique, which often leaves too little
> mechanical strength in a soft metal joint subjected to repeated thermal
> cycling.
Back in the early 1980s, at work we bought a few dozen VDUs (Visual 550s)
which emulated both a DEC VT102 and also a Tektronix 4014. Brilliant
little alpha+graphic terminal, for its day. They gave sterling service
for many years except in ONE respect --- they'd develop a fault in the
vertical scanning. Always the cause was the same: a connection to a
transistor in the circuit would "go dry". Just took a few seconds work
with a solder sucker and a nice clean-up and it would work again.
The video & scan drivers were all on a separate PCB, supplied to Visual
by Hitachi. I think the reason why the joints would go dry was that the
transistors had been encapsulated in some resin (it was somewhat akin to
Araldite) for electrical insulation purposes and the residual chemicals
caused migration of the solder away from the board on the legs of that
transistor (which presumably go hot in operation).
The weird thing was that even after manual resoldering like this, the
fault would recur about 3--4 years later; oh, and some of the batch never
needed the repair at all.
--
Brian {Hamilton Kelly} b...@dsl.co.uk
"We have gone from a world of concentrated knowledge and wisdom to one of
distributed ignorance. And we know and understand less while being incr-
easingly capable." Prof. Peter Cochrane, formerly of BT Labs
Brian {Hamilton Kelly}
pa...@see.sig "Paul Floyd" writes:
> On 30 Aug 2001 19:20:35 GMT, Al Savage <asa...@iname.com> wrote:
>
> >If you have well-made coal, it'll last a very long time (as a diamond),
> >but too much of today's consumer electronics is just sand, left out in
> >the rain.
>
> Not the best of examples. Carbon has two allotropes (I think that's the
> right term), diamond and graphite. Diamond is the unstable form, and
> graphite stable. So though it's true that a diamond will last a very
> long time, it'll end up as a lump of graphite in the end.
How about Buckminster-Fullerene? Isn't that acknowledged to be a *third*
form of carbon. And I understood that all three allotropes were stable.
Paul Floyd
> How about Buckminster-Fullerene? Isn't that acknowledged to be a *third*
Yes, and there are many forms. I didn't study them in school as they
hadn't been discovered then.
> form of carbon. And I understood that all three allotropes were stable.
Diamond is metastable, but with a half life of ~10^6 years; "Diamonds
are Forever" is simply not true.
A bientot
Paul
Wolf Kirchmeir
=>Diamond is metastable, but with a half life of ~10^6 years; "Diamonds
=>are Forever" is simply not true.
10^6 years is close enough to forever to satisfy me. Or bore even sillier
than I already am. :-)
--
Wolf Kirchmeir >>wol...@onlink.net<<
If you didn't want to go to Chicago, why did you get on the train?
(Garrison Keillor)
Alex Taylor
>> Okay, the problem has vanished since I took out my NIC and replaced
>> it with a different one.
>>
>> I guess that NIC had just reached the end of its life...
>
>How does a NIC reach its end of life?
>
>Does it have any moving parts which are subject to wear? Is it programed to fail
>after so many bytes have passed through it?
The same way RAM can go bad, I suppose. I'm not an EE, although I
suppose I could ask my friends who are.
Alex Taylor
>Okay, the problem has vanished since I took out my NIC and replaced
>it with a different one.
>
>'freeze' right after the last drivers loaded (before the desktop came
>up). This was random but would happen maybe once in ten bootups.
>
>That was going on for at least a year and a half. But it became much
>more pronounced at the time this problem was occurring, and I suddenly
>realize that that is the exact point in the boot sequence where MPTS
>initializes.
>
>Maybe that was a buggy NIC card all along... Well, I'll wait and see
>if that problem has gone as well.
Well, maybe it's not _totally_ fixed after all...
The mysterious "freezes" while the system is up have vanished since I
replaced the NIC. And the system isn't trapping E on every 2nd-3rd boot
anymore.
I did get a TRAP E on bootup at the same point this week, however. And
one 'mystery bootup freeze' as well.
Also, the WPS seems significantly more prone to locking up and hanging
the system these days (although you may recall I installed OS/2 v4.51
a few days before all these problems exploded in my face... I can't rule
that out as a factor).
I wonder if flaky RAM could be a problem as well... might it have
exacerbated the problem with the dying NIC, only now to become more
subdued now that the new NIC is in place?
Sergey I. Yevtushenko
AT> I wonder if flaky RAM could be a problem as well... might it have
AT> exacerbated the problem with the dying NIC, only now to become more
AT> subdued now that the new NIC is in place?
Which amount of RAM do you have? Also, do you have that amount installed
as one RAM module?
Alex Taylor
> AT> I wonder if flaky RAM could be a problem as well... might it have
> AT> exacerbated the problem with the dying NIC, only now to become more
> AT> subdued now that the new NIC is in place?
>
>Which amount of RAM do you have? Also, do you have that amount installed
>as one RAM module?
I have 128 MB of 100-MHz SDRAM in a single PC100 DIMM.
I'm strongly considering buying another, as RAM prices are so cheap
right now.
Sergey I. Yevtushenko
>> Which amount of RAM do you have? Also, do you have that amount installed
>> as one RAM module?
AT> I have 128 MB of 100-MHz SDRAM in a single PC100 DIMM.
AT> I'm strongly considering buying another, as RAM prices are so cheap
AT> right now.
Well, then this is not what I thought. I had some experience when
RAM consisting of two modules caused problems. Each module being used
alone worked rock solid, but two modules caused spontaneous trap's 0E/0D.