From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 20:46:37 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 B8C1E16A4D4 for ; Thu, 6 Jan 2005 20:46:37 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5589C43D5D for ; Thu, 6 Jan 2005 20:46:37 +0000 (GMT) (envelope-from imp@harmony.village.org) Received: from localhost (localhost [IPv6:::1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j06JNdVk000798; Thu, 6 Jan 2005 12:23:39 -0700 (MST) (envelope-from imp@harmony.village.org) Date: Thu, 06 Jan 2005 12:23:38 -0700 (MST) Message-Id: <20050106.122338.41631737.imp@harmony.village.org> To: nate@root.org From: Warner Losh In-Reply-To: <41DD0849.9010006@root.org> References: <41DD0849.9010006@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 07 Jan 2005 13:10:38 +0000 cc: freebsd-current@FreeBSD.org cc: imp@bsdimp.com 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 20:46:37 -0000 > 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