farhad@Tehran.Stanford.EDU (Farhad Shakeri) (04/10/90)
I have questions about how the disk driver handles the Memory dump
after the crash, if Memory is slightly greater that the
first chunk (ra0b) of swap.
Our system is a 64MEG (67.07 MB total on boot time) and I use to have
two 65MEG chunks for swaping. We upgraded from 32MEG to 64MEG and
we forgot to make first swap bigger (I know we goofed).
Anyway we had two major crashes Due to Bad CPU, Bad Memory and
Bad Controller. On each case the memory dump destroyed the next
partition (/usr and /var two cases here).
The problem is fixed now. I made swap 0 bigger than the total memory.
Is this a bug? Shouldn't the driver stop the memory dump to prevent
this kind of destruction? I did not get any satisfactory answers
from DEC. Does Ultrix 4.0 or 3.1D prevent this?
Thanks is advance.
+----------------------------------------------------+
/ Farhad Shakeri E-Mail: /
/ Stanford University farhad@Tehran.Stanford.EDU /
/ Computer Science Dept. /
+----------------------------------------------------+chris@mimsy.umd.edu (Chris Torek) (04/14/90)
In article <1990Apr9.183344.28958@Neon.Stanford.EDU> farhad@Tehran.Stanford.EDU (Farhad Shakeri) writes: >Our system is a 64MEG (67.07 MB total on boot time) and I use to have >two 65MEG chunks for swaping. ... we had two major crashes .... On >each case the memory dump destroyed the next partition .... >The problem is fixed now. I made swap 0 bigger than the total memory. >Is this a bug? Certainly. >Shouldn't the driver stop the memory dump to prevent >this kind of destruction? 4BSD used to have the same bug. The fix was to dump only as much as fits. Presumably DEC will pick up this fix once enough customers complain. (It would be nice if DEC would pick up fixes *before* the bugs cause trouble.... It is very annoying to discover that a bug fixed not long after the 4.2BSD release is still present in a late release of Ultrix. 4.3BSD-tahoe has been out for quite a while now, and DEC should have applied some effort towards fixing their software wherever Berkeley CSRG fixed theirs.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris