Date: Mon, 04 Oct 2004 11:33:24 -0700 From: Nate Lawson <nate@root.org> To: Kevin Oberman <oberman@es.net> Cc: acpi@freebsd.org Subject: Re: ASUS P5A broken by ACPI black-list Message-ID: <41619774.8020709@root.org> In-Reply-To: <20041004174914.D64EB5D04@ptavv.es.net> References: <20041004174914.D64EB5D04@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Oberman wrote:
>>Date: Mon, 04 Oct 2004 09:54:19 -0700
>>From: Nate Lawson <nate@root.org>
>>
>>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41619774.8020709>