From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 4 14:27:30 2008 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 47B4A1065683 for ; Fri, 4 Jul 2008 14:27:30 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 9609B8FC13 for ; Fri, 4 Jul 2008 14:27:29 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m635tYgt015886 for ; Thu, 3 Jul 2008 15:55:34 +1000 Received: from c220-239-252-11.carlnfd3.nsw.optusnet.com.au (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m635tSbg032554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2008 15:55:30 +1000 Date: Thu, 3 Jul 2008 15:55:28 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Joerg Wunsch In-Reply-To: <20080702191827.GK1469@uriah.heep.sax.de> Message-ID: <20080703145049.S6189@delplex.bde.org> References: <20080702191827.GK1469@uriah.heep.sax.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org Subject: Re: HP/Compaq nx6325 clock "jumping around" 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, 04 Jul 2008 14:27:30 -0000 On Wed, 2 Jul 2008, Joerg Wunsch wrote: > On a nx6325 running 6-stable (because I couldn't get 7.x to work with > ACPI at all so far), the main clock is frequently "jumping", up to a > level where ntpd eventually gives up: Try 7.x. 6.x never worked right for me on this machine, due to lapic timer bugs which might be fixed now, while 7-CURRENT started working right except for suspend and lid switch once the lapic timer bugs and minor battery bugs were fixed, and 7-CURRENT and 8-CURRENT haven't regressed in compatibility since then. I didn't try amd64 mode until after the bugs were fixed, and it worked immediately with late 7-CURRENT after rcp'ing ~5.2 userland and updating the kernel. > Jul 2 10:44:44 remi ntpd[50885]: time reset +11.885037 s > Jul 2 10:44:44 remi ntpd[50885]: kernel time sync disabled 6041 > Jul 2 10:54:24 remi ntpd[50885]: kernel time sync disabled 2041 > Jul 2 11:07:13 remi ntpd[50885]: kernel time sync enabled 2001 > ... > Jul 2 19:03:17 remi ntpd[50885]: time correction of 1785 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. I know of the following bugs in time on nx6325: - pressing the lid switch to turn the screen off makes the time jump by almost precisely 1 second using any timecounter. The system appears to spend the 1 second in something like SMM mode with all interrupts and all timecounters stopped. More precisely, the jump is: ACPI-fast and TSC: -1.000000 +- 10 uS i8254: -1.043000 +- 1 mS - pressing the lid switch to turn the screen on makes the time jump by 55 +- 1 mS with the i8254 timecounter. The magic 55 is 1 i8254 timer maximum count (65536 / 1193182 = 0.054925. (65536 is with acpi_timer; otherwise at least FreeBSD's max count would be ~11920 giving a magic 10). Apparently, SMM restarts and/or reloads all the timercounter's hardware, but makes a larger mess of it for the i8254. Not making a mess of it is harder than for the other timecounter hardware, since the others have a granularity of 1 cycle while the i8254 has a granularity of 65536 or 11920 cycles unless it is carefully synced with the OS software which SMM can't do. The magic 43 for screen off is presumably the magic 55 reduced a bit by other bugs. - dynamic recalibration of cpu_tick_frequency has never worked. This is a MI bug, and only affects process times. cpu_tick_frequency is never adjusted downwards (except for a full recalibration). Thus any glitches in the cpu_tick clock (TSC on nx6325), e.g., from the SMM bug or entering ddb) cause cpu_tick_frequency to creep or jump upwards and never come down. Maybe you have a dynamic cause of events like the lid switch. I don't see any problems except with time except the above. > Notice the huge time resets of about 900 seconds between. Could this > be related to CPU frequency changes caused by whomever might control > that (ACPI BIOS? powerd is not running, should I?)? The CPU > frequencies listed are: > > dev.cpu.0.freq: 1393 > dev.cpu.0.freq_levels: 1990/100000 1791/81822 1592/65808 1393/57582 1194/49356 995/41130 796/22152 696/19383 597/16614 497/13845 398/11076 298/8307 199/5538 99/2769 I don't use powerd and rarely use batteries. Suspsend stuff doesn't work in FreeBSD, perhaps because I have no acpi support newer than ~5.2 in userland (powerd doesn't exist), and battery life at max CPU is about 30 minutes. makeworld of ~5.2 over nfs takes 13 minutes 40 seconds. nx6325 doesn't run ~5.2 kernels (problems in video, ata and acpi) or early (?) 6.x kernels with lapic timer. dev.cpu.0.freq: 1985 dev.cpu.0.freq_levels: 1985/-1 1736/-1 1488/-1 1240/-1 992/-1 744/-1 496/-1 248/-1 Once I used some performance/power-reduction config and got a list like yours. 1985 actually gives 1995 MHz. Bruce