From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 10 20:11:49 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 93EBE1065670; Mon, 10 Jan 2011 20:11:49 +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 E3BE68FC1A; Mon, 10 Jan 2011 20:11:48 +0000 (UTC) Received: by fxm16 with SMTP id 16so19250560fxm.13 for ; Mon, 10 Jan 2011 12:11:47 -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=o5XhR3yvKWwTZQm3kCFBx7oKB3ohq+X/z9mbGSNWrm8=; b=HL/8W6TawdAH11KW0pvEmtAc00E/uO1Sy+Wl1ffFtQRrWYJ9DMwV8T0GkJfFtKch/g XnQMQTGpOrlOSnyJtfuxWhexJLk6yowyq4M97LfhBU2iPrwq67TBlXFNMZ6Dljhmwa6Y NnIyTbox1MKk3yvPJRiMyCUTkZ9joiWHBycgs= 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=wU+c0yreU35xhkBpEZOiNAkUAOOkPEj8aFsm9ZEf9ou2hue9nkaievA6N1/qaX4MFG exhswBSEqbltYcsC18CeMxM0lNApOk/jHtc5XF6KlxgMX3jctlYaSFYEivZ3dTJmQLCx CiRXwquMLp28GdijbqcdKdC1aHNTGLPv4ohT4= Received: by 10.223.100.15 with SMTP id w15mr3935325fan.121.1294690307725; Mon, 10 Jan 2011 12:11:47 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id a2sm7123785faw.22.2011.01.10.12.11.45 (version=SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 12:11:46 -0800 (PST) Sender: Alexander Motin Message-ID: <4D2B67E4.70907@FreeBSD.org> Date: Mon, 10 Jan 2011 22:11:16 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: John Baldwin References: <4D2894CA.5010004@FreeBSD.org> <201101101500.45783.jhb@freebsd.org> In-Reply-To: <201101101500.45783.jhb@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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:11:49 -0000 John Baldwin wrote: > 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? May be, but then it would be reasonable for BIOS to not report it's presence instead of disabling. -- Alexander Motin