From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 12 07:21:34 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 48219106566B for ; Tue, 12 Apr 2011 07:21:34 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id CC4578FC0C for ; Tue, 12 Apr 2011 07:21:33 +0000 (UTC) Received: by fxm11 with SMTP id 11so5441410fxm.13 for ; Tue, 12 Apr 2011 00:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7kLmVDk36/ZPZ0rSoEB9fIza6fnxxlUJAtz+hUywQho=; b=gcZRoMeiLsIkxk0iMFPTvggy/PMqjsSmJLK5Ai4IBBn3U5uBVP/ZLnA3gpqd6QN13C Ot0EjZ8XKmT+xz2SNnSD8YMTEVsU9hm9i5aqoD/JEkFY3gx8Vb28mBAugt/0uHXi0rSt mxJlg1j6eBYfB56oI5a9n8zvXaHnKJmZfWkaM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Klh8KWtIzkyTh8urPrijjpGKaNGksECAXnF6IvTV8nyCkp9IZD5QX9H+9YEsy6fGCI 3BsiwCb8IAxPwC7Z54Uf/onDiRcpAFo4V+Ostq+7t52g8tW5eoq+Yo/VPx3ekw7SDm53 bJ5fXIdnqqsjAWjxBD0SaFI04UHNKsKuSWSsk= Received: by 10.223.6.198 with SMTP id a6mr869096faa.126.1302591260419; Mon, 11 Apr 2011 23:54:20 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id n26sm1883597fam.37.2011.04.11.23.54.18 (version=SSLv3 cipher=OTHER); Mon, 11 Apr 2011 23:54:19 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DA3F70F.4010805@FreeBSD.org> Date: Tue, 12 Apr 2011 09:54:07 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Warner Losh References: <8CDC697CCCE3652-124C-1B2@web-mmc-m04.sysops.aol.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, dieterbsd@engineer.com, Hans Petter Selasky 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: Tue, 12 Apr 2011 07:21:34 -0000 Warner Losh wrote: > 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. It's not his driver, it's mine. Actually, unlike AHCI, this hardware even has interrupt for ready transition (second, biggest of sleeps). But it is not used in present situation. > On Apr 11, 2011, at 1:43 PM, dieterbsd@engineer.com wrote: >>>> 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=60ms status=00000123 >>>> kernel: siisch1: SIIS reset done: devices=00000001 >>>> 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=59ms status=00000123 >>>> ... >>>> kernel: siisch0: siis_wait_ready() calling DELAY(1000) >>>> last message repeated 1300 times >>>> kernel: siisch0: port is not ready (timeout 10000ms) status = >> 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. :-( CAM is not completely innocent in this situation indeed. CAM defines XPT_RESET_BUS request as synchronous. It is not queued, and called under the SIM mutex lock. I don't think lock can be safely dropped in the middle there. Now I think that I could try to move readiness waiting out of the siis_reset() to do it asynchronously. I'll think about it. -- Alexander Motin