At 10:45 Uhr 07.09.1996, Scott Reynolds wrote:

>I hope someone can explain how the driver is managing
>to do this, actually.  Perhaps a "reset at an embarassing moment" is
>really what's happening here.


Hi Scott,

After digging deep into my manuals, I think I can.

>I think I must repeat that I don't recommend the sbc driver except in
>specific circumstances.  Namely, that (a) you're running on a "hard" disk,
>and (b) you're experiencing random filesystem corruption with the ncrscsi
>driver.  This driver is a work in progress, and while I hope to make it
>the primary SCSI driver for 5380-based Macs, I cannot support that move
>right now.

After some interrupt-related code changes in MacBSD around mid-May, the
ncrscsi driver reported media damage on a Quantum LPS 105 root partition
(my mail to you and Allen on 22 Jun). The disk had been running reliably
for more than four years and has continued to do so ever after. That's why
_I_  had to switch...

>I can assure you that I am not ignoring the sbc driver, but as it is not a
>critical cog in the 1.2 release effort, it is certainly getting a little
>less attention than I would like.

I can well imagine that driver development for a hardware that you have
never even seen from afar is a hell of a job; and I *do* appreciate that
people like you, like Allen and Michael Zucca put their *spare* time into
that. My hint to MacBSD's "good, old" tradition of non-operative major
releases was not meant to be a flaming of those who actively contribute.

>SO anyway, is there anybody with an MO drive that they're not using (or
>not much) that is willing to loan it to me for the purpose of making the
>sbc driver work?

Unfortunately, I can't send my only MO drive over the ocean, but I can
provide some interesting information.

Look at what I found in the Fujitsu M2512 "SCSI Logical Specifications" manual:
---------------------------------------------------------------------------
> (1.6.6 Reset processing)
>
> The INIT [initiator, hf] can execute the following reset processing
> methods on the SCSI bus:
> o  RESET condition
> o  BUS DEVICE RESET message
> o  ABORT message.

[...]

> Command type: WRITE, WRITE AND VERIFY, WRITELONG
>
> Stop processing of command execution:
> The date block where data is being written is not always successfully
> processed, including the ECC field. Not all data items transferred
> from the INIT to ODD [optical disk drive, hf] may be
> written to the disk.
---------------------------------------------------------------------------

That is: Send a hard reset to your drive in case of an error -- and if
you're fast enough, you are likely to generate what shows up as a media
defect on the next access but is rather an incompletely written block.

The tech manual of my Quantum Empire 1080 says nothing on the issue.

>From looking at the sources, I can't make out what exactly leads to

  root:/usr # sbc0: can not transfer more data
  sbc0: aborting, but phase=DATA_OUT (reset)
  sbc0: reset SCSI bus for TID=2 LUN=0
  panic: ncr5380_scsi_cmd: polled request, abort failed

-- but I assume that initiator and target have gotten out of sync and you
try to get the target back into line by a hard reset. (Should I send-pr
this?)

I see two alternatives:

a)  try a 'TERMINATE I/O PROCESS (11h)' first, as it is guaranteed to
maintain data integrity on the target, or

b)  wait a sufficiently long time (say, half a second) to let the target
complete whatever it's doing *before* you issue a reset.

BTW, there was a related issue with the sleep/wakeup of an MO drive and the
ncrscsi driver. The driver wouldn't give the target enough time to spin up
and respond, but instead hit it with a hard reset again and again, causing
it to spin down and up, and...

[I am sending this to Allen, too, as it may well be relevant to the ncrscsi
driver. Also, I've sent a query to <scsi-wizzards@solutions.apple.com>.]

Comments?


	hauke

---
"It's never straight up and down"     (DEVO)