From owner-freebsd-hackers  Mon Aug 28 20:03:33 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.FreeBSD.org (8.6.11/8.6.6) id UAA07726
          for hackers-outgoing; Mon, 28 Aug 1995 20:03:33 -0700
Received: from ref.tfs.com (ref.tfs.com [140.145.254.251])
          by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id UAA07720
          for <freebsd-hackers@freefall.FreeBSD.org>; Mon, 28 Aug 1995 20:03:31 -0700
Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id UAA15622; Mon, 28 Aug 1995 20:02:10 -0700
From: Julian Elischer <julian@ref.tfs.com>
Message-Id: <199508290302.UAA15622@ref.tfs.com>
Subject: Re: S.O.S -2.1Stable and ASUSP54TP4
To: hsu@cs.hut.fi (Heikki Suonsivu)
Date: Mon, 28 Aug 1995 20:02:09 -0700 (PDT)
Cc: rashid@haven.ios.com, freebsd-hackers@freefall.FreeBSD.org
In-Reply-To: <199508290120.EAA08982@shadows.cs.hut.fi> from "Heikki Suonsivu" at Aug 29, 95 04:20:02 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Content-Length: 1388      
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

> 
> One of the SCSI disks becomes unreachable: IBM 0662's say "Disk dribe is
> becoming ready", often survies, Seagates lock up.  Usually we get IO
> errors, panic, and the system gets stuck in SCSI BIOS probes (probably, it
> says WAIT and sits there until reset, sometimes requiring several resets or
> a power cycle).
> 
[...]
> hang in BIOS probes (assuming that Buslogic & NCR did their code right).
> This has been around since spring, at least.

I've seen  SCSI devices hang the scsi bus so solidly that they freeze the 
SCSI adapter just as solid half way through a DMA....
EVERYTHING stops..

I figure the mechanism is:

DMA from SCSI to shared memory buffer on board freezes.
DMA to motherboard cannot get Data ACK, and also freezes,
holding an outsanding cycle on the EISA/VESA/Whatever bus
which freezes the CPU :(


> 

> that certain sequences of disk accesses kill the SCSI.

certain patterns of data allowed the SCSI block agregation code to produce
a really big DMA request.. Other Operating systems often don't do this
so there are certainly several drive models out there that fail on this..

> Maybe seagate did something wrong in their disks?  Tagged queuing?  When it
> came around? 
> 
have you tried en/dis abling this?

> -- 
> Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND,
> hsu@cs.hut.fi  home +358-0-8031121 work -4513377 fax -4555276  riippu SN
>