From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 10 21:32:15 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 2793210656A3; Mon, 10 Jan 2011 21:32:15 +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 23E208FC12; Mon, 10 Jan 2011 21:32:13 +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 p0ALWC8Y062966 ; Mon, 10 Jan 2011 22:32:12 +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 p0ALVXR5021881; Mon, 10 Jan 2011 22:31:33 +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 p0ALVWqv021878; Mon, 10 Jan 2011 22:31:32 +0100 (CET) (envelope-from arno) To: John Baldwin From: "Arno J. Klaassen" References: <201101101500.45783.jhb@freebsd.org> <4D2B67E4.70907@FreeBSD.org> <201101101515.47127.jhb@freebsd.org> Date: Mon, 10 Jan 2011 22:31:32 +0100 In-Reply-To: <201101101515.47127.jhb@freebsd.org> (John Baldwin's message of "Mon\, 10 Jan 2011 15\:15\:47 -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 4D2B7ADC.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4D2B7ADC.001/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: acpi@freebsd.org, Alexander Motin 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 21:32:15 -0000 John Baldwin writes: > On Monday, January 10, 2011 3:11:16 pm Alexander Motin wrote: >> 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. > > I'm a bit too cynical to depend on BIOS writers being reasonable. :) Sure .. that said, the BIOS I use is the last official release for this board (Sept 2009) and not even a more recent beta-release is available. I would expect reporting a disabled device which cannot be enabled via de BIOS a bug deserving a newer release. Anyway, this bug isn't very harmful for me, but the non-hpet timecounters don't seem that fun either : # uptime 10:27PM up 2 days, 5:44 # sysctl kern.timecounter.hardware kern.timecounter.choice kern.timecounter.hardware: ACPI-safe kern.timecounter.choice: TSC(-100) i8254(0) ACPI-safe(850) dummy(-1000000) # vmstat -i | fgrep cpu: cpu0:timer 38599321 199 cpu6:timer 2151003 11 cpu1:timer 7121075 36 cpu3:timer 1808269 9 cpu5:timer 3832463 19 cpu2:timer 2399988 12 cpu7:timer 2013444 10 cpu4:timer 21630368 111 (default HZ ....) Maybe I should try downgrading the BIOS? Best, Arno