From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 21:17:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCEEA16A4CE for ; Thu, 6 Jan 2005 21:17:35 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7673F43D5F for ; Thu, 6 Jan 2005 21:17:35 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j06LHWGV007682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Jan 2005 13:17:33 -0800 Message-ID: <41DDAADE.8010501@root.org> Date: Thu, 06 Jan 2005 13:17:18 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Warner Losh References: <41DD0849.9010006@root.org> <20050106.122338.41631737.imp@harmony.village.org> In-Reply-To: <20050106.122338.41631737.imp@harmony.village.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@FreeBSD.org Subject: Re: Extra long time resuming -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Thu, 06 Jan 2005 21:17:36 -0000 Warner Losh wrote: >>When I updated to a recent -current, my laptop takes a very long time to >>resume (20 seconds) whereas before it took about 2 seconds. I suspect >>the PCI device probe delay capability you added triggered this. Perhaps >>the PCI resume code queries the register, gets all ones since the bus is >>not active yet, and takes the maximum delay for each device access? > > > You mean enforcing the system software minimum access time delay? At > most I'm waiting 10ms (D3->D0 transition). So you must have 2000 > devices if that results in a 20s delay. There's an implication that I > could halve that value. > > Alternatively, it could be that DELAY doesn't work quite right at this > stage of the resume, so we're sleeping a lot longer than 10ms... > > Warner I think phk's response that it's ATA timeouts may be more correct then. I'll try to do more debugging, I guess. -- Nate