Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!ncar!boulder!stan!taylor
From: taylor@Solbourne.COM (Dick Taylor)
Newsgroups: comp.periphs.scsi
Subject: Re: Handling errors with 33C93
Summary: WD design at its best
Message-ID: <1990Dec24.184704.3376@Solbourne.COM>
Date: 24 Dec 90 18:47:04 GMT
References: <1866@atlas.tegra.COM>
Organization: Solbourne Computer, Inc.
Lines: 70

In article <1866@atlas.tegra.COM> vail@tegra.COM (Johnathan Vail) writes:
>
>Is anyone familiar with handling errors with the WD/AMD 33C93?
>
>More particularly:  given a bad block on the disk, how to handle the
>0x4b, 41, 4f interrupts that are generated?
>
>The data sheet isn't too clear and I don't have any AP-notes.
>
>Thanks, jv

Hoo boy.  Can you say "can of worms"?  Let's start with your last sentence.
Of COURSE you don't have any applications notes.  App notes are never sent
unless the customer asks for them, and since there's no publically-available
list of them, you never know what to ask for.  I think this is WD's way
of encouraging self-help among its customers.

The note you really need is one written by John Spongr on January 30, 1987,
which contains a detailed flowchart of the operation of the chip.  I have it
in a March 1987 packet of applications notes that we got from Western Digital
after reasonably strident requests.  This one will show you how the various
states are supposed to work.

The 0x4b, 41, and 4f interrupts are all variations on the same theme -- a
SCSI bus sequence was initiated that the chip didn't expect.  Since it
doesn't expect very many sequences, these aren't uncommon interrupts.  The
general rule for dealing with these is to initiate programmed I/O transfers
to get the SCSI bus information (like the unexpected messages) until you
get into a state that matches the expected sequence, and then use a
select-and-transfer with the command phase register set appropriately to
restart the state machine.

Unfortunately, there are a number of problems with this, most notably that
the state machine doesn't restart gracefully in a variety of circumstances
(mostly having to do with recovery after parity or sequence errors at
awkward parts of the process).  So you end up having, worst-case, to
build a sort of a state machine around the chip, just to get its state
machine to work properly.

If you don't have any app notes, you probably also don't have the current
bug lists for the part you're using (and EVERY version of the part has
a slightly different bug list).  You need these if you're going to get
into programming the part at all.

For bug lists and application notes, call WD support directly, and ask
for their applications engineering folks.  I've had mixed results with
error debugging with these people, but I've never gotten anything but
good cooperation at getting information, _once_I_knew_what_to_ask_for_.

If you want to continue this discussion into the bits and bytes of the
chip, feel free to email.

DISCLAIMER:  Although I get sarcastic about Western Digital and the
33C9{2|3}[A|B] family of chips, it comes from years of working more
or less successfully with them.  WD is far from the worst company in
the business, and their chips have some real advantages over any of
their competition.

>
>
>"They, that can give up essential liberty, to obtain a little temporary
> safety, deserve neither liberty nor safety." -- Benjamin Franklin 1759
> _____
>|     | Johnathan Vail | n1dxg@tegra.com
>|Tegra| (508) 663-7435 | N1DXG@448.625-(WorldNet)
> -----  jv@n1dxg.ampr.org {...sun!sunne ..uunet}!tegra!vail


			-- Dick Taylor
			   Solbourne Computer, Inc.