From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 10 09: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 E167F106566B for ; Mon, 10 Jan 2011 09:12:54 +0000 (UTC) (envelope-from nirnroot.freebsd@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id AAF018FC0A for ; Mon, 10 Jan 2011 09:12:54 +0000 (UTC) Received: by iwn39 with SMTP id 39so19326951iwn.13 for ; Mon, 10 Jan 2011 01:12:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=ZlBQEPV88pdKWMhpAmJxJ5MPychTfR9WM7A9NIQlbTc=; b=wr/6f1aWb5TAGepUaBIf9me12uO0LJBWAAbRbGmJRwGKtQezDyPclGFPIaoXxlFgxn WRa3E/ug3wHfb/pVTznlUx6Ra6w80M9ANe91lJVy6IkaDgJZBuiFQeLV8rjfb7QLVSdx 4M4pNcSQOW+zotYax29k/24+siXHDwfhTVhiQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=Ezv+umazhAA/HwnqMVvx2UDOoqfm79STjzOhnX8xL77Gg5IQwMWyEV17FkD4ohmHIb 7YhbZUKkMpe1rozLf3cv9tTTojEFsAtY5ZCJRO8smuJucb3i0j/VDwa4GeUM3C3z+5Bw s3wiwKQPB0F7viU/6RzWFrpmDue/bJR4Wy/Bk= Received: by 10.42.227.68 with SMTP id iz4mr3974662icb.426.1294649083493; Mon, 10 Jan 2011 00:44:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.164.66 with HTTP; Mon, 10 Jan 2011 00:44:23 -0800 (PST) From: Alexey Golodov Date: Mon, 10 Jan 2011 18:44:23 +1000 Message-ID: To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Need help to improve asus_acpi module 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 09:12:55 -0000 Hello, I have Asus EEE PC 1215N netbook with Nvidia ION2 (switchable graphics). Tried to install PCBSD, but graph installer does not start. I'm not a programmer and ask for help in the improvement of driver asus_acpi and wiki page. In driver needs to add detect of Asus 1215N and sysctl to enable/disable ION2 GPU. Lunux already have initial support for hybrid graphics with acpi_call kernel module. Regarding support 1215N - http://linux-hybrid-graphics.blogspo...arameters.html I don't know C but can test driver in weekends . System - fresh install of CURRENT-201011 snap. On demand give any logs. -- Regards, Alexey Golodov From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 10 11:06:56 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 634CD10656A5 for ; Mon, 10 Jan 2011 11:06:56 +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 374E58FC0A for ; Mon, 10 Jan 2011 11:06:56 +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 p0AB6uUR001682 for ; Mon, 10 Jan 2011 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0AB6tNr001680 for freebsd-acpi@FreeBSD.org; Mon, 10 Jan 2011 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Jan 2011 11:06:55 GMT Message-Id: <201101101106.p0AB6tNr001680@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, 10 Jan 2011 11:06:56 -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 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 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 From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 10 20:16:01 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 16A8F106564A; Mon, 10 Jan 2011 20:16:01 +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 B7A6D8FC17; Mon, 10 Jan 2011 20:16:00 +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 5609C46B0D; Mon, 10 Jan 2011 15:16:00 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4A0F08A009; Mon, 10 Jan 2011 15:15:59 -0500 (EST) From: John Baldwin To: Alexander Motin Date: Mon, 10 Jan 2011 15:15:47 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <201101101500.45783.jhb@freebsd.org> <4D2B67E4.70907@FreeBSD.org> In-Reply-To: <4D2B67E4.70907@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101101515.47127.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:15:59 -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:16:01 -0000 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. :) -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 10 21:18:33 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 F2C11106566C; Mon, 10 Jan 2011 21:18:32 +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 702168FC14; Mon, 10 Jan 2011 21:18:32 +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 p0ALIUdj061118 ; Mon, 10 Jan 2011 22:18:30 +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 p0ALI8vF021769; Mon, 10 Jan 2011 22:18:08 +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 p0ALI8Z0021766; Mon, 10 Jan 2011 22:18:08 +0100 (CET) (envelope-from arno) To: Alexander Motin From: "Arno J. Klaassen" References: <201101051712.40619.jhb@freebsd.org> <201101070945.57800.jhb@freebsd.org> <4D2894CA.5010004@FreeBSD.org> Date: Mon, 10 Jan 2011 22:18:08 +0100 In-Reply-To: <4D2894CA.5010004@FreeBSD.org> (Alexander Motin's message of "Sat\, 08 Jan 2011 18\:46\:02 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Miltered: at jchkmail.jussieu.fr with ID 4D2B77A6.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4D2B77A6.001/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: acpi@FreeBSD.org, John Baldwin 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:18:33 -0000 Alexander Motin writes: > Arno J. Klaassen wrote: >> John Baldwin writes: >>=20 >>> 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-0xfed003= ff >>>>>> on acpi0 >>>>>> Timecounter "HPET" frequency 25000000 Hz quality 900 >>>>>> >>>>>> now it says (debug.acpi.hpet_test=3D"1", debug.acpi.layer=3D"ACPI_TI= MER", >>>>>> debug.acpi.level=3D"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 =3D 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 (=3D=3D 0xffffffff)' as w= ell >>>>>> 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=20 >>>> >>>> [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 up= dated=20 >>>>> 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 agai= n? >>> Changing the length wouldn't make a difference as we would still read t= he same=20 >>> registers since the start address is identical. I think the length is= =20 >>> symptomatic of the BIOS doing something differently that has disabled t= he=20 >>> HPET. >>=20 >> 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. >>=20 >> 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. [forgive my ignorance, long time since I didn't do any of these hardware architectural things ] I googled around a little bit and found some issues with similar chipsets, e.g. for xen 'enabl[ing] direct device assignment (PCI passthru) on AMD IOMMU platforms.' : http://www.mailinglistarchive.com/html/xen-devel@lists.xensource.com/2008= -07/msg00282.html Two remarks on that (quotes from the above thread) : "Due to some BIOS issues, this patch has a workaround to enable ht1100 ^^^^^^^^^^^ iommu." (patch supposedly for ht1100 chipset, but the guy responding has ht2000/ht1000, as I do) [ from his linux dmesg (under xen I suppose=E0 ] : [ 57.300688] PCI-DMA: Disabling AGP. [ 57.303516] PCI-DMA: aperture base @ c0000000 size 131072 KB [ 57.303656] PCI-DMA: using GART IOMMU. [ 57.303738] PCI-DMA: Reserving 128MB of IOMMU area in the AGP aperture These indeed are BIOS options : "Set GART size" with choice "AGP Present/Disabled, 32MB, 64MB, 128MB [default], ... . (I tried all, no luck) I have "device agp" in my kernel, but no trace of it in dmesg. [ 57.307831] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 ^^^^^^^^^^^^^^^^^^ Might this imply that it is not the same address-space as where FreeBSD looks for it? again, my $0.01 ... For completenes, the two patches mentioned in the above thread can be found at : http://lists.xensource.com/archives/html/xen-devel/2007-11/txtJD2SnCs5Li.= txt http://lists.xensource.com/archives/html/xen-devel/2007-11/txtYFdQBW9AZT.= txt and both look rather 'hacky' ;-) Thanx, Arno 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 From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 10 22:34:13 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 D7543106564A; Mon, 10 Jan 2011 22:34:13 +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 3D1348FC0A; Mon, 10 Jan 2011 22:34:12 +0000 (UTC) Received: by fxm16 with SMTP id 16so19383197fxm.13 for ; Mon, 10 Jan 2011 14:34:12 -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=SMXQ68D5G9mA5X+CSAK6ia0oI079puEPyzr5EKjUUGo=; b=Xf5DFDLRHm2HSG+Zis+1RbHJ1+vd71Wdebu2GfKHfEte2johgBHNO63p+Nz9GB/CD7 9MHSCbrb/teC4G1XT7BNjcIFwaverB3KJdb+j/dOOnxDZmmeM6THjgeeujV6FhsA4hE9 Bj+zCBE3b0ARSEeD3uEBo5RQBEZUwKo2DD7U4= 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=YH/Wx2u1wUDdH0xnPp5KDapsiJFO1ReEJLvJ99sAsiItcRP54teiz7L9Oqr9NzrV/t SBFoofTcQfGVDmuvXcDX1OlcsvqDtBrSqAaB+uI63cjpzkICIhb54x/MkgLcgxsqneqQ A8l1KE73lO+XTxiFBBNHA+qWlc66vw1qAiYKE= Received: by 10.223.72.9 with SMTP id k9mr230521faj.93.1294698852089; Mon, 10 Jan 2011 14:34:12 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id f24sm7176711fak.24.2011.01.10.14.34.09 (version=SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 14:34:10 -0800 (PST) Sender: Alexander Motin Message-ID: <4D2B8944.6030200@FreeBSD.org> Date: Tue, 11 Jan 2011 00:33:40 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: "Arno J. Klaassen" References: <201101101500.45783.jhb@freebsd.org> <4D2B67E4.70907@FreeBSD.org> <201101101515.47127.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: Mon, 10 Jan 2011 22:34:13 -0000 Arno J. Klaassen wrote: > 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? So what here seems not funny to you? Lower timer interrupt rate is not a bug but feature of 9-CURRENT. -- Alexander Motin From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 10 22:41:57 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 86DAB106566B; Mon, 10 Jan 2011 22:41:57 +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 024688FC15; Mon, 10 Jan 2011 22:41:56 +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 p0AMfsJh073433 ; Mon, 10 Jan 2011 23:41:55 +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 p0AMdGZ9022458; Mon, 10 Jan 2011 23:39:16 +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 p0AMdGLX022455; Mon, 10 Jan 2011 23:39:16 +0100 (CET) (envelope-from arno) To: Alexander Motin From: "Arno J. Klaassen" References: <201101101500.45783.jhb@freebsd.org> <4D2B67E4.70907@FreeBSD.org> <201101101515.47127.jhb@freebsd.org> <4D2B8944.6030200@FreeBSD.org> Date: Mon, 10 Jan 2011 23:39:16 +0100 In-Reply-To: <4D2B8944.6030200@FreeBSD.org> (Alexander Motin's message of "Tue\, 11 Jan 2011 00\:33\:40 +0200") 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 4D2B8B33.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4D2B8B33.001/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: acpi@FreeBSD.org, John Baldwin 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 22:41:57 -0000 Alexander Motin writes: > Arno J. Klaassen wrote: >> 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? > > So what here seems not funny to you? Lower timer interrupt rate is not a > bug but feature of 9-CURRENT. the standard deviation in the values; I don't have another 8-way by hand, but a 4-way 6-STABLE gives : cpu0: timer 3299774936 2000 cpu2: timer 3299757640 2000 cpu3: timer 3299757640 2000 cpu1: timer 3299757640 2000 and my 8-STABLE notebook (with kern.hz=100) : cpu0: timer 323161363 400 cpu1: timer 323161114 400 A range from 9 to 199 is 'funny', maybe I choose the wrong word, but I didn't see such discrepancies before. Sorry Best, Arno From owner-freebsd-acpi@FreeBSD.ORG Mon Jan 10 23:12:40 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 0EEC9106564A; Mon, 10 Jan 2011 23:12:40 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 911928FC13; Mon, 10 Jan 2011 23:12:39 +0000 (UTC) Received: by iwn39 with SMTP id 39so20000397iwn.13 for ; Mon, 10 Jan 2011 15:12:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=LB/wbzLMdMfWIoqVrvgpTw/0jyNwr0aW4HLQovaqlEc=; b=QOerBg+hUGfLDmAOD8lviPzsLwxGkQGVQZbOjQSICOY6iFncpvM4XpKCJ+6wGR55Q9 Bak3b/MICs55og3tZxOr3mCZDpGfwRXyo0OSPlXnb4KD1iMKmriPIVXEWWJc/CCz58tC dKjR/m4MoaworTBCAxx6YZ0KcPuZXLQuNfMrM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=MZSWzyevzNE6ER8/qOU6pfpyNc9t9ZKLd1yYfJCcLBbHsMfNiq1ZsJOZCihRUKw+W/ x9W02UTB8Ir9qtaJ7Uej4Vv0Nl7bpmkJcbWwb7CX/BcF0Zn5ThOxQrgkSVRvKoXEXgHR kirkGw3GGSoL1FS5oqa+eXpl28nBnB/uobCLA= MIME-Version: 1.0 Received: by 10.231.17.77 with SMTP id r13mr13309766iba.38.1294701158933; Mon, 10 Jan 2011 15:12:38 -0800 (PST) Sender: mavbsd@gmail.com Received: by 10.231.24.104 with HTTP; Mon, 10 Jan 2011 15:12:38 -0800 (PST) Received: by 10.231.24.104 with HTTP; Mon, 10 Jan 2011 15:12:38 -0800 (PST) In-Reply-To: References: <201101101500.45783.jhb@freebsd.org> <4D2B67E4.70907@FreeBSD.org> <201101101515.47127.jhb@freebsd.org> <4D2B8944.6030200@FreeBSD.org> Date: Tue, 11 Jan 2011 01:12:38 +0200 X-Google-Sender-Auth: 5iaQLu2q26WlqjdwmLdRdeqQgLs Message-ID: From: Alexander Motin To: "Arno J. Klaassen" Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 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 23:12:40 -0000 Ah, that's fine and indeed just funny. When CPUs are idle now, they receive minimal amount of interrupts to allow reduced power consumption. Your numbers just tells that load is not equal. You may see in systat how rates changing depending on load. --=20 Alexander Motin 11.01.2011 0:42 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 "Arno J. Klaassen" =CE=C1=D0=C9=D3=C1=CC: > Alexander Motin writes: > >> Arno J. Klaassen wrote: >>> 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? >> >> So what here seems not funny to you? Lower timer interrupt rate is not a >> bug but feature of 9-CURRENT. > > the standard deviation in the values; I don't have another 8-way by > hand, but a 4-way 6-STABLE gives : > > cpu0: timer 3299774936 2000 > cpu2: timer 3299757640 2000 > cpu3: timer 3299757640 2000 > cpu1: timer 3299757640 2000 > > and my 8-STABLE notebook (with kern.hz=3D100) : > > cpu0: timer 323161363 400 > cpu1: timer 323161114 400 > > A range from 9 to 199 is 'funny', maybe I choose the wrong word, but > I didn't see such discrepancies before. Sorry > > Best, Arno > From owner-freebsd-acpi@FreeBSD.ORG Tue Jan 11 07:51:05 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 63EAD106566B for ; Tue, 11 Jan 2011 07:51:05 +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 E27568FC14 for ; Tue, 11 Jan 2011 07:51:04 +0000 (UTC) Received: by fxm16 with SMTP id 16so19686571fxm.13 for ; Mon, 10 Jan 2011 23:51:03 -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=C5K6+THIFCpeir/GKjnyUCcLdqQxfWXW/bJSUvpH0xI=; b=AhSSx1bTIjylM4NUp59Rr4vIoEdezdYL95ZfwQ4PAukef0yVMKs77bpf9xoGDHJ+os ABeoLDKyysxcX5YPn5Qh3wL+H5RnLqxBhQoe+XwvD91b9h2b3xblL5VaGKlYwACpx3lB BVHo+HXjmBeE7LGV1L5uhLQ7gNN2LlueFjPwc= 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=qYb6Y1vOY2s6fFewbGuex7zwTgLgUO0n29/1LdjxJ6aEqtiheu5QvAa0wnlZwvyF44 1U14rDvgWURPPXKeJpEmxSTk8rsYBe+byiMooep1SpgfYZZgEsiUyHsp9Ptvd7+cGPLF PJC7mXR1CNbxVdA7HXxzgvgOiFZj6FDu1J4e4= Received: by 10.223.79.68 with SMTP id o4mr4243843fak.0.1294732263763; Mon, 10 Jan 2011 23:51:03 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id n26sm7256620fam.13.2011.01.10.23.51.01 (version=SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 23:51:02 -0800 (PST) Sender: Alexander Motin Message-ID: <4D2C0BC7.4090103@FreeBSD.org> Date: Tue, 11 Jan 2011 09:50:31 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Bruce Evans References: <201101101500.45783.jhb@freebsd.org> <4D2B67E4.70907@FreeBSD.org> <201101101515.47127.jhb@freebsd.org> <4D2B8944.6030200@FreeBSD.org> <20110111160606.H2006@besplex.bde.org> In-Reply-To: <20110111160606.H2006@besplex.bde.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: Tue, 11 Jan 2011 07:51:05 -0000 Bruce Evans wrote: > On Tue, 11 Jan 2011, Alexander Motin wrote: > >> Arno J. Klaassen wrote: >>> 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? >> >> So what here seems not funny to you? Lower timer interrupt rate is not a >> bug but feature of 9-CURRENT. > > They (cpu*:timer) also aren't timecounters :-). Sure. They've never been timecounters. > Hmm, with hpet on FreeBSD cluster machines, there is now only hpet. How > is statclock distributed with hpet? If there are enough timers for each CPU and their IRQs are not shareable -- they are assigned to each CPU, one to one. The rest logic is same for all drivers: if timer is not per-CPU - it is used for all CPUs and events redistributed via IPI by MI code. Plus of one-shot mode - we don't need separate timer hardware for statclock. > I never properly reviewed the latest "irqN"-printing changes in systat, > and just noticed that they break printing of "irq" the usual case where > the interrupt name starts with "irqN:" (then systat removes "irqN:" and > never puts back "irq"). > > Not-so-quick fix: > > % Index: vmstat.c > % =================================================================== > % RCS file: /home/ncvs/src/usr.bin/systat/vmstat.c,v > % retrieving revision 1.93 > % diff -u -2 -r1.93 vmstat.c > % --- vmstat.c 11 Dec 2010 08:32:16 -0000 1.93 > % +++ vmstat.c 11 Jan 2011 06:20:01 -0000 > % @@ -244,5 +244,10 @@ > % *--cp1 = '\0'; > % % - /* Convert "irqN: name" to "name irqN". */ > % + /* > % + * Convert "irqN: name" to "name irqN", "name N" or > % + * "name". First reduce to "name"; then append > % + * " irqN" if that fits, else " N" if that fits, > % + * else drop all of "N". > % + */ > % if (strncmp(cp, "irq", 3) == 0) { > % cp1 = cp + 3; > % @@ -256,5 +261,8 @@ > % cp2 = strdup(cp); > % bcopy(cp1, cp, sz - (cp1 - cp) + 1); > % - if (sz <= 10 + 4) { > % + if (sz <= 10 + 1) { > % + strcat(cp, " "); > % + strcat(cp, cp2); > % + } else if (sz <= 10 + 4) { > % strcat(cp, " "); > % strcat(cp, cp2 + 3); > % @@ -266,5 +274,9 @@ > % /* > % * Convert "name irqN" to "name N" if the former is > % - * longer than the field width. > % + * longer than the field width. This handles some > % + * cases where the original name did not start with > % + * "irqN". We don't bother dropping partial "N"s in > % + * this case. The "name" part may be too long in > % + * either case; then we blindly truncate it. > % */ > % if ((cp1 = strstr(cp, "irq")) != NULL && > > This restores part of rev.1.90, updates the first comment to match the code > changes in rev.1.90, and expands the last comment. Heh. If I haven't forgot some prehistory, you may be right. -- Alexander Motin From owner-freebsd-acpi@FreeBSD.ORG Tue Jan 11 08:54:10 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 2F0C71065674 for ; Tue, 11 Jan 2011 08:54:10 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 539828FC1B for ; Tue, 11 Jan 2011 08:54:08 +0000 (UTC) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0B6R6WB010619 for ; Tue, 11 Jan 2011 17:27:06 +1100 Received: from c122-106-165-206.carlnfd1.nsw.optusnet.com.au (c122-106-165-206.carlnfd1.nsw.optusnet.com.au [122.106.165.206]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p0B6QxsZ031995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jan 2011 17:27:01 +1100 Date: Tue, 11 Jan 2011 17:26:59 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alexander Motin In-Reply-To: <4D2B8944.6030200@FreeBSD.org> Message-ID: <20110111160606.H2006@besplex.bde.org> References: <201101101500.45783.jhb@freebsd.org> <4D2B67E4.70907@FreeBSD.org> <201101101515.47127.jhb@freebsd.org> <4D2B8944.6030200@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Tue, 11 Jan 2011 08:54:10 -0000 On Tue, 11 Jan 2011, Alexander Motin wrote: > Arno J. Klaassen wrote: >> 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? > > So what here seems not funny to you? Lower timer interrupt rate is not a > bug but feature of 9-CURRENT. They (cpu*:timer) also aren't timecounters :-). Hmm, with hpet on FreeBSD cluster machines, there is now only hpet. How is statclock distributed with hpet? I never properly reviewed the latest "irqN"-printing changes in systat, and just noticed that they break printing of "irq" the usual case where the interrupt name starts with "irqN:" (then systat removes "irqN:" and never puts back "irq"). Not-so-quick fix: % Index: vmstat.c % =================================================================== % RCS file: /home/ncvs/src/usr.bin/systat/vmstat.c,v % retrieving revision 1.93 % diff -u -2 -r1.93 vmstat.c % --- vmstat.c 11 Dec 2010 08:32:16 -0000 1.93 % +++ vmstat.c 11 Jan 2011 06:20:01 -0000 % @@ -244,5 +244,10 @@ % *--cp1 = '\0'; % % - /* Convert "irqN: name" to "name irqN". */ % + /* % + * Convert "irqN: name" to "name irqN", "name N" or % + * "name". First reduce to "name"; then append % + * " irqN" if that fits, else " N" if that fits, % + * else drop all of "N". % + */ % if (strncmp(cp, "irq", 3) == 0) { % cp1 = cp + 3; % @@ -256,5 +261,8 @@ % cp2 = strdup(cp); % bcopy(cp1, cp, sz - (cp1 - cp) + 1); % - if (sz <= 10 + 4) { % + if (sz <= 10 + 1) { % + strcat(cp, " "); % + strcat(cp, cp2); % + } else if (sz <= 10 + 4) { % strcat(cp, " "); % strcat(cp, cp2 + 3); % @@ -266,5 +274,9 @@ % /* % * Convert "name irqN" to "name N" if the former is % - * longer than the field width. % + * longer than the field width. This handles some % + * cases where the original name did not start with % + * "irqN". We don't bother dropping partial "N"s in % + * this case. The "name" part may be too long in % + * either case; then we blindly truncate it. % */ % if ((cp1 = strstr(cp, "irq")) != NULL && This restores part of rev.1.90, updates the first comment to match the code changes in rev.1.90, and expands the last comment. Bruce From owner-freebsd-acpi@FreeBSD.ORG Thu Jan 13 16:25:55 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 D5521106564A for ; Thu, 13 Jan 2011 16:25:55 +0000 (UTC) (envelope-from menkovich@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8BF118FC0A for ; Thu, 13 Jan 2011 16:25:55 +0000 (UTC) Received: by qyk36 with SMTP id 36so1872494qyk.13 for ; Thu, 13 Jan 2011 08:25:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=kEL+bnvw3npdjgtI4195dseBENv1Zr8e/lKGUtYkL08=; b=wW3nIJkeMtRA1LCw7uA/djPDzDGN4KCRtZdOdCcp3vyJE7QuCo4PZDiUMplfIDdUrj ydArj//lWLgPZndlgjCBl9rxCGhCmpXH+pNqDog3FvOAr9rWE1Y97Yf/aXm6Jkfhqr/0 KN1YodKQHA25p803pmCbXmhukjrsb+TbYucQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=vXNtTEvJWfcZML7yBykmTSwkBFBeA1AcyrzEeMryNX4tk1c0u6wztYLzHumxprddbD YgpqCqzMHooppYDBxkcHnuqICUZDygIZf/vUh0sWYagZHjUD9mWM5rIsiXjXuZsyp0Wj +F460WymTC9UPwH2tSpnLWiVGQwZXgssKGnVY= Received: by 10.229.75.21 with SMTP id w21mr2063842qcj.228.1294934594861; Thu, 13 Jan 2011 08:03:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.23.19 with HTTP; Thu, 13 Jan 2011 08:02:34 -0800 (PST) In-Reply-To: References: From: Nikita A Menkovich Date: Thu, 13 Jan 2011 19:02:34 +0300 Message-ID: To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Problem with FreeBSD graceful shutdown 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, 13 Jan 2011 16:25:55 -0000 Hello, I have FreeBSD guest running with KVM+libvirt, when I send shutdown through virsh for ex. $ virsh shutdown freebsd There is not any reaction from FreeBSD. Linux guests works together with acpid daemon well. devd in freebsd is running, and should work correct. Is there any way to fix this dumpxml config http://pastebin.com/UGGgG894 devd config is out of box. Is there any way to understand does devd receive any acpi events? -- Nikita A Menkovich JID: menkovich@gmail.com From owner-freebsd-acpi@FreeBSD.ORG Fri Jan 14 15:36:28 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 5266E10656A4 for ; Fri, 14 Jan 2011 15:36:28 +0000 (UTC) (envelope-from timon@timon.net.nz) Received: from frost.plasmahost.ru (plasmahost.ru [178.63.60.242]) by mx1.freebsd.org (Postfix) with ESMTP id 8847C8FC1A for ; Fri, 14 Jan 2011 15:36:27 +0000 (UTC) Received: from pc209.office.masterhost.ru ([87.242.97.5]) (AUTH: PLAIN timon@timon.net.nz, TLS: TLSv1/SSLv3, 256bits, CAMELLIA256-SHA) by frost.plasmahost.ru with esmtp; Fri, 14 Jan 2011 15:28:12 +0000 id 0000E392.000000004D306B8E.00007D24 Message-ID: <4D306B28.1030001@timon.net.nz> Date: Fri, 14 Jan 2011 18:26:32 +0300 From: Alexandr Matveev User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.9) Gecko/20100927 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Thinkpad suspend/resume problem 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, 14 Jan 2011 15:36:28 -0000 Hello I have IBM/Lenovo T61p laptop. Everything works fine except one thing - suspend/resume. I know that at present moment there a lots of work that need to be done before it will be reliable, but I want to help to improve it. My system: OS: FreeBSD-CURRENT ( cvsup at 14 Jan 2011 ) Usual dmesg output ( with all drivers loaded ): http://timon.net.nz/freebsd/acpi/dmesg.txt dmesg output after "boot -v" ( with all drivers loaded ): http://timon.net.nz/freebsd/acpi/dmesg.verbose.txt dmesg output after "boot -v" on generic kernel ( no additional drivers loaded ): http://timon.net.nz/freebsd/acpi/dmesg.verbose.generic.txt 'sysctl hw.acpi' output: http://timon.net.nz/freebsd/acpi/hw.acpi.txt ASL: http://timon.net.nz/freebsd/acpi/lenovo-t61p.asl.txt Main problem: Suspend seems to work fine ( after 'acpiconf -s 3' sleep indicator start flashing for a second, then everything power off and indicator stand on ), but system doesn't resume after suspend: after pressing power button hard drive spin-up and DVD-drive powered up, Num Lock and Caps Lock indicator light up for a moment, hard drive led light up for a 2 seconds, then led turns off and nothing happens next. Sleep indicator stays turned on all this time. What I already tried and discover: 0) Suspend and resume don't work both on i386 and amd64 kernels; 1) Simple test sysctl debug.bootverbose=1 sysctl debug.acpi.suspend_bounce=1 acpiconf -s 3 works fine: system successfuly emulates switching to S3 and back to S0 modes; 2) Mini-kernel ( config http://timon.net.nz/freebsd/acpi/mini.txt ) don't resume after sleep too. Even if APIC is disabled. 3) I can't test that system wake up ( and so go sleep ) correctly by setting sysctl debug.acpi.resume_beep=1 because my laptop don't have separate speaker on main board and speaker output connected to Intel HDA mixer, therefore, speaker don't work immedeatly after system startup; 4) Replace resume_beep in wakeup code with code that light on Num Lock and Caps Lock keyboard indicators don't have effect; 5) BIOS have switch "Power Control Beep" turned on. Description of this switch says: "Enable this option to have a beep sound when: the system enters suspend mode; the system resumes from suspend mode; the system enters hibernation mode; the system resumes from hibernation mode: the AC adapter is connected or disconnected". Laptop produce a sound when I disconnect and connect AC adapter, but don't produce any sound on suspend and resume; My conclusions: Because system don't flash on lights (4) and don't produce any sound on resume (5) I think that system don't propertly go to sleep. What I want to try next: 0) Try to output something to COM-port on wakeup code; 1) Try to get POST-code from laptop when it resume from sleep; 2) Try to use null-modem cable to record all possible debug information from console when laptop goes to suspend mode. Questions to community: 0) In what direction to look for a bug? 1) How can I test that system suspend itself correctly? -- Alexandr Matveev