From owner-freebsd-stable@FreeBSD.ORG Wed Jan 24 15:06:21 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 305FD16A40E for ; Wed, 24 Jan 2007 15:06:21 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 894E513C4D9 for ; Wed, 24 Jan 2007 15:06:18 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l0OEkJKd054966; Wed, 24 Jan 2007 15:46:19 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l0OEkBiV042747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jan 2007 15:46:12 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l0OEkBLA040083; Wed, 24 Jan 2007 15:46:11 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l0OEk881040082; Wed, 24 Jan 2007 15:46:08 +0100 (CET) (envelope-from ticso) Date: Wed, 24 Jan 2007 15:46:08 +0100 From: Bernd Walter To: Hans Petter Selasky Message-ID: <20070124144607.GD39608@cicely12.cicely.de> References: <20070124113858.GG64263@hoeg.nl> <200701241254.51900.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701241254.51900.hselasky@c2i.net> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: FreeBSD Hackers , freebsd-stable@freebsd.org, Ed Schouten , Pietro Cerutti Subject: Re: atacontrol kernel crash (atausb?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 15:06:21 -0000 On Wed, Jan 24, 2007 at 12:54:51PM +0100, Hans Petter Selasky wrote: > On Wednesday 24 January 2007 12:38, Ed Schouten wrote: > > Hello, > > > > * Pietro Cerutti wrote: > > > On 1/15/07, Hans Petter Selasky wrote: > > > >No. What happens when you use/load "umass" and unload "atausb" ? > > > > > > Everything works nice with umass. It creates the da0 device node. > > > It just shows up these errors, as it always did... > > > GEOM: new disk da0 > > > da0 at umass-sim0 bus 0 target 0 lun 0 > > > da0: < USB2.0 FlashDisk 1.1b> Removable Direct Access SCSI-0 device > > > da0: Serial Number > > > da0: 40.000MB/s transfers > > > da0: 248MB (507904 512 byte sectors: 64H 32S/T 248C) > > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > > status == 0x0 > > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > > status == 0x0 > > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > > status == 0x0 > > > (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi > > > status == 0x0 > > > > I had these messages with two other devices before, an MP3 player and a > > USB floppy drive. I fixed these errors by adding a quirk to > > /sys/cam/scsi/scsi_da.c. > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=97174 > > http://www.freebsd.org/cgi/query-pr.cgi?pr=107101 > > Instead of having all these quirks, isn't it possible that the SCSI layer can > auto-probe this? No - it is intended to fail on devices not supporting the commands. And the user should know if a drive has not been synced befor unplugging it from power. The SCSI Layer could ask if the device has a cache at least, but I this would likely just relocate the problem. Issuing unsupported commands should be harmless for any sane device, but often bad implemented devices just hang on unknown commands. IIRC umass specification has a way to distinguish reduced command set flash type from generic SCSI devices, by interpreting the subclass. That way umass could safely catch such commands. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de