response 1 of 16:

Jul 31 23:16 UTC 1991

        You might try removing the video card and replacing it with another
kind.  The problem might be with your video card.
        You could also put the video card in an 8 bit slot to see if that
makes a difference.
        How often do you get this problem?

response 3 of 16:

Aug 1 01:04 UTC 1991

Putting the video card in an 8-bit slot would NOT be good for the 
video card.
The problem occurs every once in a while, much like line noise.
sometimes several times in an evening, other times not for a couple of
days or more.
I do not have another video card, except an old CGA, and don't really want
to leave that in for days.

response 5 of 16:

Aug 1 06:59 UTC 1991

Everything is fine after it's done freezing. It freezes most often when
loading a 256-color screen in games like Wing Commander. 
As soon as it thaws, the disk heads do a full-length "seek" and it 
continues where it left off.
This is no big problem, which is why I've never gone crazy trying to figure
out what the deal is. It's just annoying.

response 7 of 16:

Aug 1 22:08 UTC 1991

Nope, the disk light is off.
I haven't looked at the video card in a year, so I may be forgetting, but...
How would it fit in an 8-bit slot? I seem to recall the 8-bit slot
being a mite too short...like by half...

response 9 of 16:

Aug 1 22:14 UTC 1991

        The extra part of the card that fits in the extra length of an
expansion slot would just be loose, unconnected to anything.  VGA cards
often work in 8 bit cards, but are just faster in a 16 bit slot.  (Very
few other 16 bit cards will work in an 8 bit slot, but VGA cards are
often designed to work in an XT as well as an AT or 386 computer.)

response 11 of 16:

Aug 2 08:08 UTC 1991

The full length seek is probably a disk restore/retry.  Could still be
due to a memory or video problem -- it may have caused a disk I/O to
fail.

Definitely reseating the memory is a sensible solution.

Uh, DRAM and VRAM can both come in sips, dips, or simms.  Jep's rule of
thumb may happen to be more or less true for him, but don't rely on it
in the long run.  The difference between VRAM and DRAM is inside the
chip where you can't see -- VRAM is just DRAM with some extra logic on
the chip to get special fast video access -- basically it relies on some
architectural pecularities of DRAM.

You see, in a normal DRAM chip, a memory access actually takes place in
2 steps -- you strobe in a row address, and this causes an entire row to
be fetched out of the memory array in the chip, into a special row
buffer, and then you strobe in a column address to select one bit that
you want to read or write in the row.  When you're through, the entire
row is then written back into the memory array -- you have to do that
because the readout process is destructive -- what's in that row of the
memory array goes away when read.  Even if you don't read it, what's in
memory still goes away in less than a second, so you have to execute
refresh cycles on all of the rows of the memory array to charge it back
up again.  A refresh cycle consists of just strobing in the row address
and then not doing any column strobbing -- a "null" cycle, you might
say.  But any read or write cycle will refresh the entire row, so if you
can arrange for periodic sequential memory cycles, you're set.
Conveniently, this is just what video is good for -- and that's why the
apple ][ came out with 4K of memory when S-100 technology of the time
was hard pressed to provide 1K of relatively trouble free static RAM.  6
years later, the designer of the Sun-1 CPU had an even simplier solution
for dynamic ram refresh -- they just hooked up a periodic interrupt
source to the NMI pin of the 68000, and pointed the NMI service routine
to a list of 127 NOP instructions, followed by an RTS.  That generated
128 sequential memory references on a periodic basis--all that you
needed.

Now, in normal DRAM, you can only read or write one bit at a time.  This
is kind of frustrating since you actually are referencing at least 128
bits, and probably a lot more in today's memory chips.  The bottleneck
is, of course, the # of pins on the chips, and there's a lot of reasons
to keep the pin count down as much as possible.  Now, there's a number
of clever things you can do -- some modern chips, for instance, give you
access to 4 bits at once, instead of just one, but the essential problem
is that you're doing random access to the chip, and so you really can't
get away from having to tell it which row, and then which column.
However, video logic has entirely different constraints on it.  It's
highly sequential, and about the only thing that's really critical about
it is some of the timing -- when it wants its data, it wants it and it
can't be late.  This is a problem with traditional DRAM -- basically,
the faster the video is (like the larger the screen is), or the slower
the memory is, the less time is available for the processor to get at
the memory.  VRAM is a solution to this - basically, inside the chip,
where interconnects are cheap, a video shift register is added in
parallel with the row buffer that already has to be there.  Now, in
addition to doing a normal bit-wise read or write on one bit, you can do
a load of the whole shift register in the same amount of time.  The
shift register is then provided with independent clocks, so it can be
shifted out one bit at a time, and meanwhile, the memory array and row
buffer are absolutely free and available full-time for the processor.
Basically, this only adds about 3 pins to the package, and means the
chip is available to the processor about 99% of the time -- a pretty
good deal for video designers.

response 13 of 16:

Aug 3 14:27 UTC 1991

One more possibility:
 
I had this same problem whenever I loaded a communications program into
my laptop when it was at work.  My computer would hang for 20 or 30 seconds
and then keep going.  So I thought it was my communications card.  I pulled
it, ran an eraser over the connections, and shoved it back in.  The problem
was intermittant and would come and go, and my card passed all diagnostic
tests.
 
Eventually, I figured it out.  I was getting a slew of temporary read i/o
errors loading the software.  Sometimes it would only take 1 or 2 retries,
and would seem to operate close to normal speed.  Other times, it would
take 10 or 15 retries to be successful reading each track, and I'd think
my system crashed, then, poof, it would keep working.
 
I didn't figure it out until the first time it went 16 tries on one sector
and gave up with an I/O error.

response 15 of 16:

Aug 4 05:34 UTC 1991

        I only know what I see.  I haven't seen that much VRAM, and all I've
seen was SIPP style.  Thanks for the correction, Marcus!