ESIX File System Selection

[Raymond Nijssen]

kdenning at pcserver2.naitc.com (Karl Denninger) writes:
>In article <3021 at sixhub.UUCP> davidsen at sixhub.UUCP (bill davidsen) writes:
>>In article <1991Jan24.143542.19808 at nstar.rn.com> larry at nstar.rn.com (Larry Snyder) writes:
>>
>>| what type of controller?  I did have this problem on
>>| one of our machines last year (running 386/ix) with
>>| a WD 1006-SRV2 (1:1 16 bit RLL controller) and replacing
>>| the controller (actually returning it as DOA) solved
>>| the problem..
>>
>>  This sometimes happens with two drives on a WD 1006 or 1007 with
>>multiple drives. My understanding is that an i/o is started on one
>>drive while a seek is started on the other. If they both finish at the
>>same time a single interrupt is issued and the driver has to check the
>>controller status to get both conditions.
>
>Turning on the flag "CCAP_NOSEEK" in the HPDD driver config file will fix
>this problem with ISC machines.

More precisely: to turn this feature off, you have to

	1) edit the file /etc/conf/pack.d/dsk/space.c
           change the 'disk_config_tbl' entry for either a primary or
	   secondary AT hard disk, which looks like:
		(CCAP_RETRY | CCAP_ERRCOR), /* capabilities */
           to
	        (CCAP_RETRY | CCAP_ERRCOR | CCAP_NOSEEK), /* capabilities */

	2) rebuild the kernel
        3) reboot

(Thanks to Doug Pintar at ISC)

A better alternative is to replace the controller board with one without
this bug. There is no _documented_ way for you to tell whether a WD1006 
adapter is buggy or not. However, when I encountered this problem some
time ago, I posted an inquiry in this newsgroup in which I asked people
to tell me (a) if they had seen it too, and (b) the text on top of the WD1006
chip. *Everybody* who had seen this problem told me it said 'PROTO' on 
the chip; Everybody who did not have a chip with 'PROTO' on it told
me they had never had any problem.

So have a close look at your adapter, and tell me if the magic word is there.

-Raymond