From owner-freebsd-bugs Fri May 26 05:23:05 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA24464 for bugs-outgoing; Fri, 26 May 1995 05:23:05 -0700 Received: from hda.com (hda.com [199.232.40.182]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id FAA24458 for ; Fri, 26 May 1995 05:23:01 -0700 Received: (dufault@localhost) by hda.com (8.6.9/8.3) id IAA05683; Fri, 26 May 1995 08:21:34 -0400 From: Peter Dufault Message-Id: <199505261221.IAA05683@hda.com> Subject: Re: MAJOR problem with FreeBSD-2.0-RELEASE To: davidg@Root.COM Date: Fri, 26 May 1995 08:21:33 -0400 (EDT) Cc: hsu@cs.hut.fi, freebsd-bugs@freefall.cdrom.com In-Reply-To: <199505260214.TAA00145@corbin.Root.COM> from "David Greenman" at May 25, 95 07:14:27 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1114 Sender: bugs-owner@FreeBSD.org Precedence: bulk David Greenman writes: > > >all accesses to the disk which first generated an error fail. Everything > >around the disks, including cables have been changed several times, so it > >is either the disks or the software. > > Probably both. One of the drives is hanging the SCSI bus, and FreeBSD > doesn't cope with it correctly. I've seen this happen myself... Properly resetting the SCSI bus, the host adapter, renegotiating sync transfers, waiting for all devices to come ready again and getting their "bus device reset occurred" message, reaping all outstanding I/O transactions, and then retrying those outstanding transactions is an effort that includes modifying all the host adapter drivers (and looking for a common interface to pull up out of them) and so will be a tough job to adequately test. It should also be done in conjunction with better I/O transaction scheduling to cleanly support tag queuing. This is a 2.1 adventure. -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267