From owner-freebsd-current@FreeBSD.ORG Wed Feb 3 21:40:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD86A106566C for ; Wed, 3 Feb 2010 21:40:28 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by mx1.freebsd.org (Postfix) with ESMTP id 5266C8FC0C for ; Wed, 3 Feb 2010 21:40:28 +0000 (UTC) Received: by fxm25 with SMTP id 25so468956fxm.14 for ; Wed, 03 Feb 2010 13:40:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type; bh=La1Q8AXIbOL+2s+0Jans1/+yMxAwUYXH3NwVAQwmkfA=; b=e73qp1Ssko4CDY1yX/iYp51rsjYfdhXBABTUnBchbXqLzcs46Lefr+Err4rh9NYq+v Z+N47B6M1Au64tRuYEyqx8hak+Zyy7zJ9QDuxDJ4l+ZaRSNf4rmQa8tldc3ROsYiAjvG 1S0NJIaoF3wP6BvhAe13LYTSVorPq8YxMD4mo= 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; b=BBbYMNHuQNP84YYtFddWxRKEzOER/+xgc3vIRT8IZfB6uGEHJyQ762Kk3ywS587hja moN4W95FkG1JtJ/sTfqSJgc88QZTtSJNiIg/q7P9bkjBpINzVn9O0y5/cTGQy4DornMT 70Epo0l+UfJZxpUkSwtY64RYeR64WrnLB7Ox8= Received: by 10.223.16.216 with SMTP id p24mr145955faa.66.1265233227084; Wed, 03 Feb 2010 13:40:27 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm3432771fxm.10.2010.02.03.13.40.26 (version=SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 13:40:26 -0800 (PST) Sender: Alexander Motin Message-ID: <4B69ED46.7030400@FreeBSD.org> Date: Wed, 03 Feb 2010 23:40:22 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: David Wolfskill References: <20100203144037.GA32250@bunrab.catwhisker.org> <4B69B4F6.1090608@FreeBSD.org> <20100203180508.GD32250@bunrab.catwhisker.org> In-Reply-To: <20100203180508.GD32250@bunrab.catwhisker.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------040202040601010206060600" Cc: FreeBSD-Current Subject: Re: "shutdown -p": (noperiph:aacp0:0:6:0): Device power down failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 21:40:29 -0000 This is a multi-part message in MIME format. --------------040202040601010206060600 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit David Wolfskill wrote: > On Wed, Feb 03, 2010 at 07:40:06PM +0200, Alexander Motin wrote: >> David Wolfskill wrote: >>> On Wed, Feb 03, 2010 at 06:40:37AM -0800, David Wolfskill wrote: >>>> Just updated my build machine from r203376 to r203425, which seeme dto >>>> go well, but after I issued "shutdown -p now" (as I leave the machine >>>> off when it's not in use), I saw the following on the serial console: >>>> >>>> Uptime: 1m45s >>>> (noperiph:aacp0:0:0:0): Device power down failed >>>> (noperiph:aacp0:0:1:0): Device power down failed >>>> ... >> That was my change r203420. `sysctl kern.cam.power_down=0` should >> disable new behavior. It can be a bug of aac driver. Is it repeatable >> each time at the same place? > > Well, I just tried it a second time, and the failure mode appears > identical, yes. I won't (quite) claim that it's "repeatable each time > at the same place" yet, but the evidence certainly tends toward that > direction. > >>> Tried the same experiment with the laptop; didn't get the above failure, >>> but am seeing many (as in "hundreds") of >>> >>> atapi_poll called! >>> atapi_poll called! >> This looks like atapicam misfeature. I'll look on it. >> ... > > Cool; thanks! > > I'm quite willing to test patches &c. Attached patch implements poll method for atapicam. It is probably not good from the locking point of view. But it is better then nothing and seems enough for now, especially because atapicam is going to die. As there can be other controllers with poll problems, I've disabled this feature by default for now. -- Alexander Motin --------------040202040601010206060600 Content-Type: text/plain; name="atapicam.poll.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="atapicam.poll.patch" diff -ruNp ata.prev/atapi-cam.c ata/atapi-cam.c --- ata.prev/atapi-cam.c 2010-02-03 23:30:12.000000000 +0200 +++ ata/atapi-cam.c 2010-02-03 23:29:37.000000000 +0200 @@ -682,8 +682,12 @@ action_invalid: static void atapi_poll(struct cam_sim *sim) { - /* do nothing - we do not actually service any interrupts */ - printf("atapi_poll called!\n"); + struct atapi_xpt_softc *softc = + (struct atapi_xpt_softc*)cam_sim_softc(sim); + + mtx_unlock(&softc->state_lock); + ata_interrupt(softc->ata_ch); + mtx_lock(&softc->state_lock); } static void --------------040202040601010206060600--