Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!mcsun!hp4nl!tuegate.tue.nl!rc6.urc.tue.nl!rwc.urc.tue.nl!rcbarn From: rcbarn@rwc.urc.tue.nl (Raymond Nijssen) Newsgroups: comp.unix.sysv386 Subject: Re: ISC 3.2/harddisk & floppy problems Message-ID: Date: 17 Jun 91 15:21:40 GMT References: <111@odiehh.UUCP> <0DRRHOB@geminix.in-berlin.de> <1991Jun10.214243.7594@abqhh.hanse.de> <113@odiehh.hanse.de> Sender: news@rc6.urc.tue.nl Reply-To: rcbarn@urc.tue.nl Lines: 118 marzusch@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@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@ico.isc.com> :Date: 27 Aug 90 16:14:20 GMT :References: <9008171007.aa06635@PARIS.ICS.UCI.EDU> <483@comcon.UUCP> :Reply-To: dougp@ico.ISC.COM (Doug Pintar) :Organization: Interactive Systems Corp., Boulder CO :Lines: 27 : :In article <483@comcon.UUCP> tim@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@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 |