From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 4 18:34:10 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 1A14716A4CE for ; Mon, 4 Oct 2004 18:34:10 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id D505A43D53 for ; Mon, 4 Oct 2004 18:34:09 +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 i94IY2Hr028285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Oct 2004 11:34:02 -0700 Message-ID: <41619774.8020709@root.org> Date: Mon, 04 Oct 2004 11:33:24 -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: <20041004174914.D64EB5D04@ptavv.es.net> In-Reply-To: <20041004174914.D64EB5D04@ptavv.es.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: 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: Mon, 04 Oct 2004 18:34:10 -0000 Kevin Oberman wrote: >>Date: Mon, 04 Oct 2004 09:54:19 -0700 >>From: Nate Lawson >> >>Kevin Oberman wrote: >> >>>After building some old kernels, it became apparent that the network >>>broke long before the disk problem showed up and was the result of the >>>ACPI black-list implemented back on June 30. Unfortunately, this board >>>seems to require ACPI to run. Without it I get continuous xl0: watchdog >>>timeout messages from the system. >>> >>>I have now re-enabled ACPI in the hints file and the network is >>>fine. (I'm still looking for the source of the disk problem.) Why it >>>fails without ACPI is another issue. This is a rather old board and has >>>run just fine for years on V3 and V4 kernels. >>> >>>The quirk entry is: >>># ASUS P5A 03/12/99 >>>name: ASUS_P5A >>>oem: FADT "ASUS " "P5A " >>>oem_rev: FADT <= 0x58582e31 >>>quirks: ACPI_Q_BROKEN >>> >>>My FADT is: >>> FADT: FACS=0x5fff000, DSDT=0x5ffc100 >>> INT_MODEL=PIC >>> Preferred_PM_Profile=Unspecified (0) >>> SCI_INT=9 >>> SMI_CMD=0xb1, ACPI_ENABLE=0xa1, ACPI_DISABLE=0xa0, S4BIOS_REQ=0x0 >>> PSTATE_CNT=0x0 >>> PM1a_EVT_BLK=0xec00-0xec03 >>> PM1a_CNT_BLK=0xec04-0xec05 >>> PM2_CNT_BLK=0xec30-0xec30 >>> PM_TMR_BLK=0xec08-0xec0b >>> GPE0_BLK=0xec18-0xec1b >>> GPE1_BLK=0xec1c-0xec1f, GPE1_BASE=16 >>> P_LVL2_LAT=90 us, P_LVL3_LAT=900 us >>> FLUSH_SIZE=0, FLUSH_STRIDE=0 >>> DUTY_OFFSET=1, DUTY_WIDTH=0 >>> DAY_ALRM=13, MON_ALRM=0, CENTURY=0 >>> IAPC_BOOT_ARCH= >>> Flags={WBINVD,PROC_C1,SLP_BUTTON,RTC_S4} >> >>I need output from a newer version of acpidump. The output above >>doesn't include the OEM header for the FADT. June 30th was the commit >>that added this output. > > > That does make a bit of a difference. I have 0x58582e31, so it is > black-listed. For the record, please send the full acpidump -t output (with a recent acpidump). > Unfortunately, it does not work without ACPI. The only > ACPI problem is that the clock runs at double speed. That may be why it was blacklisted. I don't know all the rationale for some of the blacklist entries, only that Windows won't install acpi.sys on machines that we blacklist. In your case, it's likely a broken timer. We can refine/fine-tune blacklist entries to only disable the problem parts (if possible). > It looks like interrupts from the Ethernet are not delivered without > ACPI, but that is hardly your problem. I have over-ridden the black-list > and things are back to normal. The reason this system works in Windows without ACPI is that irq routing in Windows uses multiple info sources including _PIR and $PIR. John Baldwin has patches to do this for us too. > Is it possible to only disable the use of the clock but leave the rest > of ACPI running? (Not that using the sysctl to switch to TSC is much of > a problem.) Yes: debug.acpi.disable="timer" -- Nate