From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 3 11:06:58 2011 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BE1110656AD for ; Mon, 3 Jan 2011 11:06:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 500998FC13 for ; Mon, 3 Jan 2011 11:06:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p03B6wSh046413 for ; Mon, 3 Jan 2011 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p03B6vA7046411 for freebsd-acpi@FreeBSD.org; Mon, 3 Jan 2011 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Jan 2011 11:06:57 GMT Message-Id: <201101031106.p03B6vA7046411@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org 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, 03 Jan 2011 11:06:58 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/152438 acpi [acpi]: patch to acpi_asus(4) to add extra sysctls for o kern/152098 acpi [acpi] Lenovo T61p does not resume o i386/146715 acpi [acpi] Suspend works, resume not on a HP Probook 4510s o kern/145306 acpi [acpi]: Can't change brightness on HP ProBook 4510s o i386/144045 acpi [acpi] [panic] kernel trap with acpi enabled o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142263 acpi [acpi] ACPI regression on Asus K8N7-E deluxe motherboa o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o amd64/140751 acpi [acpi] BIOS resource allocation and FreeBSD ACPI in TO o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o bin/137053 acpi [hang] FreeBSD 8.0 BETA2Compaq Mini 700 locks on boot o kern/137042 acpi [acpi] hp laptop's lcd not wakes up after suspend to r o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o bin/135349 acpi [patch] teach acpidump(8) to disassemble arbitrary mem o kern/135070 acpi [acpi] [patch] BIOS resource allocation and FreeBSD AC o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race? o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D p kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/73823 acpi [request] acpi / power-on by timer support o i386/69750 acpi Boot without ACPI failed on ASUS L5 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 40 problems total. From owner-freebsd-acpi@FreeBSD.ORG Wed Jan 5 21:59:23 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 A0C81106566B for ; Wed, 5 Jan 2011 21:59:23 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 3AEB88FC0A for ; Wed, 5 Jan 2011 21:59:22 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id p05LdYpm072318 ; Wed, 5 Jan 2011 22:39:34 +0100 (CET) X-Ids: 165 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id p05LdOHs056227; Wed, 5 Jan 2011 22:39:25 +0100 (CET) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id p05LdO53056224; Wed, 5 Jan 2011 22:39:24 +0100 (CET) (envelope-from arno) To: acpi@freebsd.org From: "Arno J. Klaassen" Date: Wed, 05 Jan 2011 22:39:24 +0100 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at jchkmail.jussieu.fr with ID 4D24E516.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4D24E516.001/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: mav@freebsd.org Subject: 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: Wed, 05 Jan 2011 21:59:23 -0000 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. Merci, Arno From owner-freebsd-acpi@FreeBSD.ORG Wed Jan 5 22:12:54 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 79B471065670; Wed, 5 Jan 2011 22:12:54 +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 4D4AC8FC13; Wed, 5 Jan 2011 22:12:54 +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 E61C646B2C; Wed, 5 Jan 2011 17:12:53 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 02C458A009; Wed, 5 Jan 2011 17:12:53 -0500 (EST) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Wed, 5 Jan 2011 17:12:40 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101051712.40619.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 05 Jan 2011 17:12:53 -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, mav@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: Wed, 05 Jan 2011 22:12:54 -0000 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. Arno, are there any BIOS options that mention the HPET or have you updated your BIOS since you booted the 7.1 kernel? -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Jan 5 22:12:54 2011 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79B471065670; Wed, 5 Jan 2011 22:12:54 +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 4D4AC8FC13; Wed, 5 Jan 2011 22:12:54 +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 E61C646B2C; Wed, 5 Jan 2011 17:12:53 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 02C458A009; Wed, 5 Jan 2011 17:12:53 -0500 (EST) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Wed, 5 Jan 2011 17:12:40 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101051712.40619.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 05 Jan 2011 17:12:53 -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, mav@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: Wed, 05 Jan 2011 22:12:54 -0000 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. Arno, are there any BIOS options that mention the HPET or have you updated your BIOS since you booted the 7.1 kernel? -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Jan 6 22:32:21 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 4E4231065673; Thu, 6 Jan 2011 22:32:21 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id F3FB08FC0A; Thu, 6 Jan 2011 22:32:20 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id p06MWIXp064853 ; Thu, 6 Jan 2011 23:32:19 +0100 (CET) X-Ids: 165 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id p06MW98p069937; Thu, 6 Jan 2011 23:32:09 +0100 (CET) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id p06MW9B7069934; Thu, 6 Jan 2011 23:32:09 +0100 (CET) (envelope-from arno) To: John Baldwin From: "Arno J. Klaassen" References: <201101051712.40619.jhb@freebsd.org> Date: Thu, 06 Jan 2011 23:32:08 +0100 In-Reply-To: <201101051712.40619.jhb@freebsd.org> (John Baldwin's message of "Wed\, 5 Jan 2011 17\:12\:40 -0500") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at jchkmail.jussieu.fr with ID 4D2642F2.005 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4D2642F2.005/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: acpi@freebsd.org, mav@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: Thu, 06 Jan 2011 22:32:21 -0000 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? Thanx, Arno From owner-freebsd-acpi@FreeBSD.ORG Fri Jan 7 14:46:52 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 2B32610657AC; Fri, 7 Jan 2011 14:46:52 +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 F0A688FC16; Fri, 7 Jan 2011 14:46:51 +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 A706A46B2C; Fri, 7 Jan 2011 09:46:51 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A2CA88A02A; Fri, 7 Jan 2011 09:46:50 -0500 (EST) From: John Baldwin To: "Arno J. Klaassen" Date: Fri, 7 Jan 2011 09:45:57 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <201101051712.40619.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101070945.57800.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 07 Jan 2011 09:46:50 -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, mav@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: Fri, 07 Jan 2011 14:46:52 -0000 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. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Sat Jan 8 16:27:31 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 81F8E10656F6; Sat, 8 Jan 2011 16:27:31 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id E79A08FC08; Sat, 8 Jan 2011 16:27:30 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id p08GRSLQ061224 ; Sat, 8 Jan 2011 17:27:28 +0100 (CET) X-Ids: 168 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id p08GQTud093665; Sat, 8 Jan 2011 17:26:29 +0100 (CET) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id p08GQTTA093662; Sat, 8 Jan 2011 17:26:29 +0100 (CET) (envelope-from arno) To: John Baldwin From: "Arno J. Klaassen" References: <201101051712.40619.jhb@freebsd.org> <201101070945.57800.jhb@freebsd.org> Date: Sat, 08 Jan 2011 17:26:28 +0100 In-Reply-To: <201101070945.57800.jhb@freebsd.org> (John Baldwin's message of "Fri\, 7 Jan 2011 09\:45\:57 -0500") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at jchkmail.jussieu.fr with ID 4D289070.005 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4D289070.005/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: acpi@freebsd.org, mav@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 16:27:31 -0000 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? Thanks, Arno 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