From owner-freebsd-current@FreeBSD.ORG Thu Jan 6 23:11:50 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 217E716A4CE; Thu, 6 Jan 2005 23:11:50 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE1D343D45; Thu, 6 Jan 2005 23:11:49 +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 j06NAUpl007608; Thu, 6 Jan 2005 16:10:30 -0700 (MST) (envelope-from imp@harmony.village.org) Date: Thu, 06 Jan 2005 16:10:30 -0700 (MST) Message-Id: <20050106.161030.112618882.imp@harmony.village.org> To: scottl@FreeBSD.org From: Warner Losh In-Reply-To: <41DDC29F.9000002@freebsd.org> References: <20050106131327.GE801@zaphod.nitro.dk> <20050106.134852.41638084.imp@harmony.village.org> <41DDC29F.9000002@freebsd.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 Subject: Re: pci powerstate related: aac(4) broken on Perc 3/Di on -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 23:11:50 -0000 > This type of thing is why I've always been very nervous about the > automatic power management control that was committed to the tree. The > above example is completely in spec, but we are taking the liberty of > assuming that all unattached devices should be powered down (modulo the > exception that was made for video devices). I don't know of a generic > way to fix this; you'll have to either add an exception to the PM code > for these specific SCSI devices, or write a do-nothing driver to attach > to it so it doesn't get spammed by the PM code. Either way it's just an > exception for this paarticular case, and who knows how many other cases > with similar needs will be broken when 6.0 is released? I understand your nervousness. However, the automatic pm code is a huge win for most people, a very huge win for some poeple, so I'm going to be pushing very hard to have it be on by default. I didn't turn it on by default for 5.x, and the understanding at the time was that it would be turned on for 6.0 by default unless there was some compelling reason to not do so. So far, the exception list is tiny, and easy to manage. We'll see how things go as we get experience with these things. I'm committed to making it work, and have shown a willingness to do what is necessary to make it work. Until that changes, I'd appreciate the benefit of the doubt. I'll be committing the appropriate driver to the tree for the system device class. I'm hoping to do it in a way that makes it trivial to override for other things (eg, you just write a probe function, and nothing else). Warner