From owner-freebsd-drivers@FreeBSD.ORG Mon Apr 11 19:43:30 2011 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11A3B106564A; Mon, 11 Apr 2011 19:43:30 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from imr-ma03.mx.aol.com (imr-ma03.mx.aol.com [64.12.206.41]) by mx1.freebsd.org (Postfix) with ESMTP id C731E8FC0A; Mon, 11 Apr 2011 19:43:29 +0000 (UTC) Received: from imo-ma01.mx.aol.com (imo-ma01.mx.aol.com [64.12.78.136]) by imr-ma03.mx.aol.com (8.14.1/8.14.1) with ESMTP id p3BJhFus002034; Mon, 11 Apr 2011 15:43:15 -0400 Received: from dieterbsd@engineer.com by imo-ma01.mx.aol.com (mail_out_v42.9.) id n.1048.4a7d781 (55739); Mon, 11 Apr 2011 15:43:13 -0400 (EDT) Received: from smtprly-md01.mx.aol.com (smtprly-md01.mx.aol.com [64.12.143.154]) by cia-md04.mx.aol.com (v129.9) with ESMTP id MAILCIAMD046-d4154da359c5ff; Mon, 11 Apr 2011 15:43:13 -0400 Received: from web-mmc-m04 (web-mmc-m04.sim.aol.com [64.12.224.137]) by smtprly-md01.mx.aol.com (v129.9) with ESMTP id MAILSMTPRLYMD013-d4154da359c5ff; Mon, 11 Apr 2011 15:43:01 -0400 To: freebsd-hackers@freebsd.org, freebsd-drivers@freebsd.org Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Apr 2011 15:43:00 -0400 X-MB-Message-Source: WebUI X-AOL-IP: 67.206.164.34 X-MB-Message-Type: User MIME-Version: 1.0 From: dieterbsd@engineer.com Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailer: Mail.com Webmail 33490-STANDARD Received: from 67.206.164.34 by web-mmc-m04.sysops.aol.com (64.12.224.137) with HTTP (WebMailUI); Mon, 11 Apr 2011 15:43:00 -0400 Message-Id: <8CDC697CCCE3652-124C-1B2@web-mmc-m04.sysops.aol.com> X-Spam-Flag: NO X-AOL-SENDER: dieterbsd@engineer.com Cc: Subject: Re: Need an alternative to DELAY() X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 19:43:30 -0000 >> FreeBSD 8.2 amd64 uniprocessor >> >> kernel: siisch1: DISCONNECT requested >> kernel: siisch1: SIIS reset... >> kernel: siisch1: siis_sata_connect() calling DELAY(1000) >> last message repeated 59 times >> kernel: siisch1: SATA connect time=3D60ms status=3D00000123 >> kernel: siisch1: SIIS reset done: devices=3D00000001 >> kernel: siisch1: DISCONNECT requested >> kernel: siisch1: SIIS reset... >> kernel: siisch1: siis_sata_connect() calling DELAY(1000) >> last message repeated 58 times >> kernel: siisch1: SATA connect time=3D59ms status=3D00000123 >> ... >> kernel: siisch0: siis_wait_ready() calling DELAY(1000) >> last message repeated 1300 times >> kernel: siisch0: port is not ready (timeout 10000ms) status =3D=20 001f2000 >> >> Meanwhile, *everything* comes to a screeching halt. Device >> drivers are locked out, and thus incoming data is lost. >> Losing incoming data is unacceptable. >> >> Need an alternative to DELAY() that does not lock out >> other device drivers. There must be a way to reset one >> bit of hardware without locking down the entire machine. Hans Petter Selasky writes: > An alternative to DELAY() is the simplest solution. You probably need > to do some redesign in the SCSI layer to find a better solution. I keep coming back to the idea that a device driver for one controller should not have to lock out *all* the hardware. RS-232 locks out Ethernet. Disk drivers lock out Ethernet. And so on. Why? Is there some fundamental reason that this *has* to be? I thought the conversion from spl() to mutex() was supposed to fix this? I'm making progress on my project converting printf(9) calls to log(9), and fixing some bugs along the way. Eventually I'll have patches to submit. But this is really a workaround, not a fix to the underlying problem. Redesigning the SCSI layer sounds like a job for someone who took a lot more CS classes than I did. /dev/brain returns ENOCLUE. :-(