From owner-freebsd-acpi@FreeBSD.ORG Thu Dec 24 19:38:18 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E643A1065670; Thu, 24 Dec 2009 19:38:18 +0000 (UTC) (envelope-from nate@root.org) Received: from nlpi129.prodigy.net (nlpi129.sbcis.sbc.com [207.115.36.143]) by mx1.freebsd.org (Postfix) with ESMTP id A93988FC16; Thu, 24 Dec 2009 19:38:18 +0000 (UTC) Received: from [10.0.5.41] (ppp-71-139-5-80.dsl.snfc21.pacbell.net [71.139.5.80]) (authenticated bits=0) by nlpi129.prodigy.net (8.13.8 smtpauth/dk/map_regex/8.13.8) with ESMTP id nBOJcCZq020273; Thu, 24 Dec 2009 13:38:14 -0600 Message-ID: <4B33C325.9030202@root.org> Date: Thu, 24 Dec 2009 11:38:13 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ian Smith References: <20091213204201.A12012@sola.nimnet.asn.au> <4B284A1A.4090909@root.org> <20091219014856.H12012@sola.nimnet.asn.au> In-Reply-To: <20091219014856.H12012@sola.nimnet.asn.au> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: Thinkpad T23 60 second stall on resuming 8.0-RELEASE/i386 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 19:38:19 -0000 Ian Smith wrote: > On Tue, 15 Dec 2009, Nate Lawson wrote: > > Ian Smith wrote: > > > -wakeup from sleeping state (slept 00:00:07) > > > +t_delta 15.f9ad99f01204edd8 too short <<<<<<< > > > +t_delta 16.07bb5b66ef900000 too long <<<<<<< > > > +t_delta 15.f9ad90918acc0000 too short <<<<<<< > > > +ct_to_ts([2009-12-13 17:10:39]) = 1260724239.000000000 > > > +wakeup from sleeping state (slept 00:01:07) > > > ata0: reiniting channel .. > > > ata0: reset tp1 mask=03 ostat0=50 ostat1=00 > > > ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 > > > ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 > > > -ata0: reset tp2 stat0=50 stat1=00 devices=0x1 > > > +ata0: reset tp2 stat0=50 stat1=00 devices=0x1 > > > ad0: setting PIO4 on ICH3 chip > > > ad0: setting UDMA100 on ICH3 chip > > > ata0: reinit done .. > > > @@ -36,7 +37,7 @@ > > > ata1: reset tp1 mask=03 ostat0=00 ostat1=00 > > > ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb > > > ata1: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 > > > -ata1: reset tp2 stat0=00 stat1=00 devices=0x4 > > > +ata1: reset tp2 stat0=00 stat1=00 devices=0x10000 > > > > I think it's ATA timing out for some reason. > > Thanks Nate. I nearly clipped that part of the diff, figuring only the > <*_MASTER> messages had changed, but I now see ata1 devices differ too. > > Have similar regressions re ATA been turning up elsewere, do you know? > > I've been digging, still on the trail of those t_delta messages, but now > figure these might be spurious, some timecounter missing/gaining a tick > or something, if ATA is maybe what's hanging meanwhile? > > There's no HD light activity at all from resume button/switch through > that 60 second wait, when 15? seconds after the third t_delta line is > written to console, the HD light flashes while apparently simultaneously > writing the rest of the resume messages, and it comes alive. > > Guess I should next upgrade the 7.0-R slice to 7.2-STABLE to find out if > this problem has been mfc'd :) I'd try to revert or move ATA forward some to see if that fixes things. Usually that can be done without too many other changes to the kernel. -- Nate