From owner-freebsd-acpi@FreeBSD.ORG Sat Jan 8 17:13:26 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 0233610656AC for ; Sat, 8 Jan 2011 17:13:26 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 79CEF8FC23 for ; Sat, 8 Jan 2011 17:13:25 +0000 (UTC) Received: by fxm16 with SMTP id 16so17791226fxm.13 for ; Sat, 08 Jan 2011 09:13:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=6IUQyszXpGgdWiqTUj24SO8TN3r0JB59uLkDaf4ixCY=; b=sTesV8v5LlF3GwTi/iSEOYttTyDmrNxvfSw248SeW9H5UYR55gIpaNykS8RI6+8Rxh 6+4bIar+XXaYU0iBvdtMMXRy1BPOS9kwgHcVJ7FP7b+RxWydZcXAx7ad8wE50AM4pBLf 035QIzpH9ynKZqCwgZCej7JsarAn8XfQ50OKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=UcwqFoq8Zyz2MHuwdweQkBgCdHJj45TLRGnj1F2KyQz0M0rcpSMwiCGk/SvZOCpbvf sp/Drq94FeMnj59UdxrpbRsKUHdB2A0+Op2UUUxOdnYkdv90U8PPIeBVzkEqIjx8BKP4 rW1lXVz49BDazBV+DFjqRcCrs6L7///tv21Wo= Received: by 10.223.96.73 with SMTP id g9mr2667587fan.24.1294505188585; Sat, 08 Jan 2011 08:46:28 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id n15sm6462566fam.12.2011.01.08.08.46.25 (version=SSLv3 cipher=RC4-MD5); Sat, 08 Jan 2011 08:46:27 -0800 (PST) Sender: Alexander Motin Message-ID: <4D2894CA.5010004@FreeBSD.org> Date: Sat, 08 Jan 2011 18:46:02 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: "Arno J. Klaassen" References: <201101051712.40619.jhb@freebsd.org> <201101070945.57800.jhb@freebsd.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org 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: Sat, 08 Jan 2011 17:13:26 -0000 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. -- Alexander Motin