From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 11 23:27:38 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9566E106566B; Mon, 11 Apr 2011 23:27:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 345538FC1B; Mon, 11 Apr 2011 23:27:38 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p3BNMetI069314 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 11 Apr 2011 17:22:43 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <8CDC697CCCE3652-124C-1B2@web-mmc-m04.sysops.aol.com> Date: Mon, 11 Apr 2011 17:22:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2BD9089E-874C-41BB-80B1-25B0DDE489C4@bsdimp.com> References: <8CDC697CCCE3652-124C-1B2@web-mmc-m04.sysops.aol.com> To: dieterbsd@engineer.com X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 11 Apr 2011 17:22:44 -0600 (MDT) Cc: freebsd-hackers@freebsd.org, freebsd-drivers@freebsd.org Subject: Re: Need an alternative to DELAY() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 23:27:38 -0000 I don't suppose that your driver could cause the hardware to interrupt = after a little time? That would be more resource friendly... = Otherwise, 1ms is long enough that a msleep or tsleep would likely work = quite nicely. Warner On Apr 11, 2011, at 1:43 PM, dieterbsd@engineer.com wrote: >>> FreeBSD 8.2 amd64 uniprocessor >>>=20 >>> 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 >>>=20 >>> Meanwhile, *everything* comes to a screeching halt. Device >>> drivers are locked out, and thus incoming data is lost. >>> Losing incoming data is unacceptable. >>>=20 >>> 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. >=20 > 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. >=20 > 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? >=20 > 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. >=20 > Redesigning the SCSI layer sounds like a job for someone who took > a lot more CS classes than I did. /dev/brain returns ENOCLUE. :-( >=20 >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" >=20 >=20