From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 10 20:03:30 2011 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EE6010657C0; Mon, 10 Jan 2011 20:03:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0FD058FC19; Mon, 10 Jan 2011 20:03:30 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id AED5746B4C; Mon, 10 Jan 2011 15:03:29 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A14428A01D; Mon, 10 Jan 2011 15:03:28 -0500 (EST) From: John Baldwin To: Alexander Motin Date: Mon, 10 Jan 2011 15:00:45 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <4D2894CA.5010004@FreeBSD.org> In-Reply-To: <4D2894CA.5010004@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101101500.45783.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 10 Jan 2011 15:03:28 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: acpi@freebsd.org, "Arno J. Klaassen" Subject: Re: Tyan S3992-E: hpet no longer working X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 20:03:30 -0000 On Saturday, January 08, 2011 11:46:02 am Alexander Motin wrote: > Arno J. Klaassen wrote: > > John Baldwin writes: > > > >> On Thursday, January 06, 2011 5:32:08 pm Arno J. Klaassen wrote: > >>> John Baldwin writes: > >>> > >>>> On Wednesday, January 05, 2011 4:39:24 pm Arno J. Klaassen wrote: > >>>>> Hello, > >>>>> > >>>>> I have (a long-lasting) problem to get hpet attached to a Tyan S3992-E > >>>>> MB. My last known working kernel is 7.1-PRERELEASE Sep 2 2008" , I > >>>>> rarely cared about this board for a while... > >>>>> > >>>>> At that time the dmesg said : > >>>>> > >>>>> > >>>>> acpi_hpet0: iomem 0xfed00000-0xfed003ff > >>>>> on acpi0 > >>>>> Timecounter "HPET" frequency 25000000 Hz quality 900 > >>>>> > >>>>> now it says (debug.acpi.hpet_test="1", debug.acpi.layer="ACPI_TIMER", > >>>>> debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" enabled) : > >>>>> > >>>>> hpet0: iomem 0xfed00000-0xfed03fff on > >>>>> acpi0 > >>>>> hpet0: vendor 0xffff, rev 0xff, 232831Hz 64bit, 32 timers, legacy route > >>>>> hpet0: t0: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t1: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t2: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t3: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t4: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t5: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t6: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t7: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t8: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t9: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t10: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t11: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t12: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t13: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t14: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t15: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t16: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t17: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t18: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t19: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t20: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t21: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t22: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t23: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t24: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t25: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t26: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t27: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t28: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t29: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t30: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: t31: irqs 0xffffffff (31), MSI, 64bit, periodic > >>>>> hpet0: 0.000000000: 4294967295 ... 4294967295 = 0 > >>>>> hpet0: time per call: 0 ns > >>>>> hpet0: HPET never increments, disabling > >>>>> device_attach: hpet0 attach returned 6 > >>>>> > >>>>> > >>>>> Some things strike me : > >>>>> > >>>>> 'vendor 0xffff, rev 0xf' and '4294967295 (== 0xffffffff)' as well > >>>>> as 232831Hz > >>>>> > >>>>> the change in iomem range : > >>>>> > >>>>> OK : iomem 0xfed00000-0xfed003ff > >>>>> KO : iomem 0xfed00000-0xfed03fff > >>>>> ^^^^ > >>>>> > >>>>> I can provide full dmesg and/or other extra needed info. > >>>> Arno sent me his acpidump which includes this: > >>>> > >>>> Device (HPET) > >>>> { > >>>> Name (_HID, EisaId ("PNP0103")) > >>>> Name (_UID, 0x34) > >>>> Method (_STA, 0, NotSerialized) > >>>> { > >>>> Return (0x0F) > >>>> } > >>>> > >>>> Method (_CRS, 0, NotSerialized) > >>>> { > >>>> Return (ResourceTemplate () > >>>> { > >>>> Memory32Fixed (ReadWrite, > >>>> 0xFED00000, // Address Base > >>>> 0x00004000, // Address Length > >>>> ) > >>>> }) > >>>> } > >>>> } > >>>> > >>>> So it does look like we are doing what the DSDT tells us in terms > >>>> of the memory address. > >>> yop. That said, I made yet another copy-paste error: the last known > >>> working kernel is 8.0-CURRENT Mar 1 2009 and the hpet says : > >>> > >>> acpi_hpet0: iomem 0xfed00000-0xfed003ff > >>> on acpi0 > >>> Timecounter "HPET" frequency 14318180 Hz quality 900 > >>> > >>> [only the frequency differs, the memory range indeed then was reported as > >>> 0x400 and not 0x4000 ] > >>> > >>>> Arno, are there any BIOS options that mention the HPET or have you updated > >>>> your BIOS since you booted the 7.1 kernel? > >>> yes .. I now use BIOS 1.06 released 06/09/09. > >>> Can I somehow 'overide' the bios and force the driver to use 0X400 as > >>> 'Address Length' in order to test if that makes the driver attach again? > >> Changing the length wouldn't make a difference as we would still read the same > >> registers since the start address is identical. I think the length is > >> symptomatic of the BIOS doing something differently that has disabled the > >> HPET. > > > > good point : this failure probably is not related to the FreeBSD-driver > > : in the current BIOS under the submenu 'South Bridge Chipset > > Configuration', the option to enable the HPET has disappeared (no > > mention of that in the release-notes), whilst it was present in the > > original BIOS, *and* disabled by default. > > > > Is it possible to write to some register during hpet_enable() and force > > the timer to tick, regardless of the BIOS? > > Problem seems not about ticking, but about HPET registers working at > all. Returning ffh values for everything more probably tells that HPET > is just not in place where we look for it. Or that the BIOS has disabled it. Maybe it is buggy on this motherboard and newer BIOS revisions always disable it as a result? -- John Baldwin