From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 4 17:49:15 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 9A76116A4CE for ; Mon, 4 Oct 2004 17:49:15 +0000 (GMT) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F09F43D2F for ; Mon, 4 Oct 2004 17:49:15 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id IBA74465; Mon, 04 Oct 2004 10:49:15 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id D64EB5D04; Mon, 4 Oct 2004 10:49:14 -0700 (PDT) To: Nate Lawson In-reply-to: Your message of "Mon, 04 Oct 2004 09:54:19 PDT." <4161803B.205@root.org> Date: Mon, 04 Oct 2004 10:49:14 -0700 From: "Kevin Oberman" Message-Id: <20041004174914.D64EB5D04@ptavv.es.net> 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 17:49:15 -0000 > 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. Unfortunately, it does not work without ACPI. The only ACPI problem is that the clock runs at double speed. 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. 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.) Sorry for the noise! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634