From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 13 06:48:48 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 3FADB106564A for ; Wed, 13 Apr 2011 06:48:48 +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 C1D028FC0A for ; Wed, 13 Apr 2011 06:48:47 +0000 (UTC) Received: by fxm11 with SMTP id 11so346176fxm.13 for ; Tue, 12 Apr 2011 23:48:46 -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 :x-enigmail-version:content-type:content-transfer-encoding; bh=tPdBS7y4GsEMemEKHXvOg1bWcxBXF9WwzCnGW1gDu1w=; b=ELcxI+0TbBfem4uVp8TdavaC1DHCzT9rOXAlZZdjRCk6DHo2gje9RNq060laCXlPM1 KzsOng5r1/gvtKRgLjgzvyb1JOcCM7IAf3rozQPyoxywS63gqRn7RtbxJIZvSI+u1Xz2 zqUGHQySuy6xdLRIb4rxX8yfVhXvDL7WyJYks= 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:x-enigmail-version:content-type :content-transfer-encoding; b=XHO9AJddozswSW9i1SMdQoe2AZd9h5G70mE21zxvyWBxk0qUNb01oYuCO0oF62yaw7 H7d5TILKu7ncdZjC9i1ShgD9sDLvIbGChUYRt301N1794nRZxEZWbF8Hajn+Q6zFqGGC PO/Q4ANTqmSlM4uuNTpF7yULh5kasG974zMoM= Received: by 10.223.59.146 with SMTP id l18mr926737fah.58.1302677326628; Tue, 12 Apr 2011 23:48:46 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 21sm66294fav.17.2011.04.12.23.48.44 (version=SSLv3 cipher=OTHER); Tue, 12 Apr 2011 23:48:45 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DA5473E.8060208@FreeBSD.org> Date: Wed, 13 Apr 2011 09:48:30 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: dieterbsd@engineer.com References: <8CDC697CCCE3652-124C-1B2@web-mmc-m04.sysops.aol.com> <4DA3F70F.4010805@FreeBSD.org> In-Reply-To: <4DA3F70F.4010805@FreeBSD.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, 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: Wed, 13 Apr 2011 06:48:48 -0000 Alexander Motin wrote: > 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. I've fixed this problem for ahci(4) in HEAD, there should be no sleeps longer then 100ms now (typical 1-2ms). With siis(4) the situation is different. There by default should be no sleeps longer then 100ms (typical 1-2ms). Longer sleep means that either controller is not responding, or it can't establish link to device it sees. I've reduced waiting timeout from 10s to 1s. It should improve situation a bit, but I would look for the original problem cause. Have you done something specific to trigger it? Are your drive/cables OK? -- Alexander Motin