Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!think!mintaka!mit-eddie!uw-beaver!ubc-cs!alberta!gordon
From: gordon@cs.UAlberta.CA (Gordon Atwood)
Newsgroups: comp.sys.mips
Subject: Dump program causes system crash
Message-ID: <1990Jan16.220024.2485@alberta.uucp>
Date: 16 Jan 90 22:00:24 GMT
Sender: news@alberta.uucp (News Administrator)
Organization: University of Alberta, Edmonton, Alberta, Canada
Lines: 41

I have encountered an interesting problem on the mips machine.  I would be
most interested if anyone out there can provide an explanation and/or
solution.  We have two machines in our department, an m1000 and a recently
installed m120-5.  The former was converted to RISC/os 4.0 (Sys V mode)
several months ago while the latter (the m120-5) was simply brought up with
RISC/os 4.0 (Sys V mode).

Both machines experience what appears to be an identical problem.  They both
crash when a filesystem is dumped using the raw device name.

As you will recall the disks can be referenced in either block device or
character (raw) device form.  The latter allows for uninterrupted I/O and
bypasses the filesystem software.  

I noticed that the new Sys V flavor didn't provide raw device names
for the filesystems and that the supplied dump program (/etc/dump.ffs) used
the block device.  There is, however, no reason that I can think of for not
using the raw device, so I tried the dump program with a raw device
filesystem name.  The machine promptly crashed (an orderly shutdown and
reboot).  This happens on both the m1000 and the m120-5.

Even more interesting is that when the m1000 was running the BSD 4.3 OS
the corresponding dump program was quite happy with both the block and the
raw device filesystems.

The only other clue that I can provide is the error message which appears
on the console just prior to the crash.  The messages was
     "assertion failed !pg_ismod(pd), file:  fault.c line 284"

I have two suspicions:  1)  Since the filesystem is active, perhaps the os
is detecting that a disk block has been read which is already been modified
in the real memory (ie flagged as modified).

2) The raw device I/O has a bug.

Any thoughts would be gratefully received.

Gordon Atwood
Programmer/Analyst
Department of Computing Science
University of Alberta