ISC 3.2/harddisk & floppy problems

[Raymond Nijssen]

marzusch at odiehh.hanse.de (Ralph-Diether Marzusch) writes:
>   This is a summary of a discussion regarding certain floppy and harddisk 
>   problems under ISC UNIX (2.0.2 and 2.2.1). 
>
>[...] I found two problems
>with ISC's harddisk and floppy drivers (possibly not related to each other):
>1st problem:
>     When using certain motherboards and ET4000 VGA controllers together
>     write accesses to the floppy disk(s) may fail, however these failures
>     are not reported at all (invalid data will be written without notice).

You omitted detailed info about your floppy controller, the I/O bus speed, 
wait-states, motherboards etc. If you want detailed answers, you'll have to 
supply all the details.....

>2nd problem:
>     If you connect two (!) hard disk drives to one (ore even two) `standard'
>     AT type hard disk controller (i.e. MFM, RLL or ESDI drives) you may

This statement is *very* inaccurate!!  see below.

>     experience a `hanging' disk controller (making any further disk accesses
>     impossible which possibly destroys one or more file systems) when both 
>     disks are accessed concurrently 
>
>There seem to be no solutions to these problems, just some workarounds:

This statement is even more inaccurate!!  see below.

>workarounds for 2nd problem:
>   a) connect only *one* disk to your system

You gotta be kiddin'....

>   b) throw away your `standard' disk controller (and the disks connected to
>      it) and get a SCSI controller and SCSI disk [a good decision anyway, but
>      quite expensive if you already have two other disks ...]

Please don't advise people to do something silly like this ....

>   c) try another motherboard ...

That does it! Oh Connor, if you're reading this, please add this issue to the 
FAQ list!!

Here we go again:

The second problem, the one with the HD controller locking up under ISC
is known to occur in combination with Western Digital's WD1006Vsr2 RLL
controller; it contains a bug which only occurs if 2 drives are
attached to it and if the HD device driver has the 'overlapped-seeks' 
feature enabled, like the one in ISC/ix has by default. It does not
happen with ESDI.

>Anybody at ISC listening?

Yes they are, but I recon they got kind of fed up with people blaming ISC
time and time again because of a bug in a product which is not theirs. 
However, some time ago, they repeatedly took effort to help people out
in this one, see below:

:Article 7943 of comp.unix.i386:
:Path: al.ele.tue.nl!svin02!hp4nl!mcsun!uunet!isis!ico!dougp
:>From: dougp at ico.isc.com (Doug Pintar)
:Newsgroups: comp.unix.i386
:Subject: Re: ISC 2.0.2: "PANIC athd_recvdata: LOGIC ERROR missing MEMBREAK"
:Message-ID: <1990Aug27.161420.11723 at ico.isc.com>
:Date: 27 Aug 90 16:14:20 GMT
:References: <9008171007.aa06635 at PARIS.ICS.UCI.EDU> <483 at comcon.UUCP>
:Reply-To: dougp at ico.ISC.COM (Doug Pintar)
:Organization: Interactive Systems Corp., Boulder CO
:Lines: 27
:
:In article <483 at comcon.UUCP> tim at comcon.UUCP (Tim Brown) writes:
:>The WD1006SVR2 has a known history of locking up with ISC.  Something
:>to do with the card being unable to recover from errored seek aheads.
:>As I understand it the 1006 does multiple seeks and if one fails it
:>*should* go back and do single seeks, which it doesn't do correctly
:>thus it locks up.  BTW, ISC *said* they would have a work around in
:>the 2.2 kernel.  They don't.  I have seen the same thing with 2.2.
:>THe only fix I know of is to get another controller.
:
:Well, this is kinda sorta true.  The HPDD, by default, WILL do overlapped
:seeks on multi-drive AT-controller systems.  To pull this stunt off, it counts
:on the controller doing retries if a data transfer request gets a 'drive busy'
:error when it's still performing a previously-requested seek operation.  The
:WD series of controllers had been able to do this since the 1001, 'way back
:when.  Somehow it got broken in some revs of the 1006.  The fix, which has
:been around as long as the HPDD and *requires* no change in the product, is
:to change the file /etc/conf/pack.d/dsk/space.c AFTER configuring the HPDD
:for your system.  In the 'disk_config_tbl' entry for either a primary or
:secondary AT hard disk is a line that looks like:
:	(CCAP_RETRY | CCAP_ERRCOR), /* capabilities */
:change this to be:
:	(CCAP_RETRY | CCAP_ERRCOR | CCAP_NOSEEK), /* capabilities */
:to cripple the overlapped seek stuff.  This should fix the problem if it's
:really a multi-drive seek condition that's doing you in.
:
:Good luck,
:DLP

>Is there anybody out there who is or was stuck with the same problems 
>(and possibly knows how to solve them other than buying new hardware)?

Hey, of course! Have faith in the net!
The patch mentioned above _does_ circumvene the bug in your hardware. It
worked for me. Have a look at your HD controller. If it says 'PROTO' on
one of the big chips, it's very likely that you have a buggy version, this
was at least the case when I gathered lots of reactions about this topic:
All systems which had such a controller suffered from lockups; All people
who had a controller without 'PROTO' stated that they had never noticed
any problem like that.

-Raymond
-- 
| Raymond X.T. Nijssen  | Eindhoven Univ. of Technology                       |
| raymond at es.ele.tue.nl | EH 7.13, PO 513, 5600 MB Eindhoven, The Netherlands |
| "Don't put that on the wall in a tax-payer supported museum!"  Pat Buchanan |