From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 8 17:46:54 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A32C16A4CE for ; Fri, 8 Oct 2004 17:46:54 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3407343D2F for ; Fri, 8 Oct 2004 17:46:54 +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 i98Hki1d022604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Oct 2004 10:46:45 -0700 Message-ID: <4166D27C.1080005@root.org> Date: Fri, 08 Oct 2004 10:46:36 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Oberman References: <20041008152659.2C81F5D04@ptavv.es.net> In-Reply-To: <20041008152659.2C81F5D04@ptavv.es.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@FreeBSD.org Subject: Re: ASUS P5A broken by ACPI black-list X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2004 17:46:54 -0000 Kevin Oberman wrote: >>Date: Wed, 06 Oct 2004 21:27:03 -0700 >>From: Nate Lawson >>Try the attached patch. If it works, please submit your system info >>including dmesg and acpidump -t as a PR (i386/???) and I'll commit it. > > > It worked perfectly. I'll add it to the PR in a few minutes. > > If you are doing this, will you add quirks for the other ACPI modules? > I know I've seen reports that various of them are not working on some > BIOS or another and putting in the quirks (even if there are no current > references to most of them in the acpi_quirks file) will make it easier > for people to make appropriate customizations of their kernels. Not to begin with. It's likely many modules will never need to be disabled by default or can't be disabled without breaking the rest of ACPI (i.e., the EC) so I'll deal with those as they come up. So it doesn't make sense to define an automatic mapping between quirks and the debug.acpi.disabled tunable. Also, I intend for the quirks system to work around bogus behavior also and want to save bits for that vs. just making it an outright blacklist. -- Nate