Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!psuvax1!brutus.cs.uiuc.edu!uakari.primate.wisc.edu!aplcen!haven!decuac!shlump.nac.dec.com!shodha.dec.com!alan
From: alan@shodha.dec.com ( Alan's Home for Wayward Notes File.)
Newsgroups: comp.unix.ultrix
Subject: Re: Problems with a uVAX II/gpx
Summary: Another word for BAD BLOCK
Keywords: Microvax II/gpx, DECwindows, X, disks
Message-ID: <449@shodha.dec.com>
Date: 16 Oct 89 07:44:02 GMT
References: <12923@s.ms.uky.edu>
Distribution: comp
Organization: Digital Equipment Corp. - Colorado Springs, CO.
Lines: 65

In article <12923@s.ms.uky.edu>, jeff@ms.uky.edu (Jeff Anderson) writes:
> 
> "                              ....  I get the "Force Error Modifier Set:
> LBN xxxxx" message occasionally, where xxxxx is some number which changes.
> I also get message "pid xxx was killed on swap error".  

	I forget the exact name, but in the system management
	doc set is a guide or a section on disk errors.  A
	Forced Error happens when a bad block is replaced 
	and the data isn't correct.  This should only happens
	on reads, since a write should always be able to find
	a good block to write to.
	
> 
> These messages are appearing on the console.  I believe that he uses both
> DECwindows and a few X windows programs at the same time.  Could these
> problems be related to that?  

	Could be.  Since disk errors are a hardware problem, get
	the disk fixed and see if the other problems persist.

> 
> So, has anybody seen something like this before?  Is the problem software
> or hardware?  
>
	Hardware. 

	If you can't find your system management docs, here is
	basically what is happening.

	Per a request by a host, a DSA disk controller tries to
	read a block and gets a data error.  What happens next
	depends on the disk controller.

	RQDX*, HSC* and RF disks - The controller invokes it's
	bad block replacement procedure.  Generally it will try
	many times to get correct data.  Eventually it will get
	a good copy of the data or give up.  Then it will pick
	a replacement block and write the data there.  If the
	data was good it will return the data to the host and
	(probably independently) tell the host there was an error
	it fixed.  If the data was bad, it returns the incorrect
	data and includes a bit that tells the host the data is
	wrong.  In the header for this block is a copy of that bit
	so that future accesses will know the data is wrong even
	though the new block is ok.

	UDA50, KDA50 and KDB50 - The controller tells the host that
	there was an I/O error and lets the host deal with it.  The
	host will probably want to follow a similar procedure that
	the previous set of controllers do.  In V2.0 and later this
	procedure was added to the driver.  Before V2.0 there was
	a standalone utility to do the correct replacement procedure.
	I don't think BSD had the utility.

	The ways to fix a "forced error" are to rewrite the block
	(preferably) with correct data, if it's available or clear
	the bit with the radisk(8) program.
> 
> -- 
> Jeff Anderson				Internet: jeff@engr.uky.edu  


-- 
Alan Rollow				alan@nabeth.enet.dec.com