From owner-freebsd-i386@FreeBSD.ORG Fri Nov 17 16:50:18 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33B7516A4AB for ; Fri, 17 Nov 2006 16:50:18 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D055643D73 for ; Fri, 17 Nov 2006 16:50:14 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAHGoE7Z009260 for ; Fri, 17 Nov 2006 16:50:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAHGoEXQ009259; Fri, 17 Nov 2006 16:50:14 GMT (envelope-from gnats) Date: Fri, 17 Nov 2006 16:50:14 GMT Message-Id: <200611171650.kAHGoEXQ009259@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: John Baldwin Cc: Subject: Re: i386/104678: SMP not working on Turion XP Laptop X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John Baldwin List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 16:50:18 -0000 The following reply was made to PR i386/104678; it has been noted by GNATS. From: John Baldwin To: Ariff Abdullah Cc: Bruce Evans , bug-followup@freebsd.org, danolson@visi.com, rainer.alves@gmail.com, infofarmer@freebsd.org Subject: Re: i386/104678: SMP not working on Turion XP Laptop Date: Fri, 17 Nov 2006 11:21:29 -0500 On Friday 17 November 2006 09:50, Ariff Abdullah wrote: > On Fri, 17 Nov 2006 23:36:49 +1100 (EST) > Bruce Evans wrote: > > On Fri, 17 Nov 2006, Ariff Abdullah wrote: > > > > > It seems the workaround is rather simple: > > > > > > machdep.cpu_idle_hlt=0 > > > > This sort of works on an HP nx6325 too. It fixes booting. > > > > > Unfortunately, the only place where you can set that is after the > > > system comes alive. This patch deals with that so that you can set > > > it as early as possible during boot procedure through loader.conf. > > > > After booting I had no problems that matter much to me > > (sleep/suspend don't work; closing the lid only turns off the screen > > and drops 1 second from the timecounter), but with cpu_idle_hlt=0 > > (set manually in ddb after booting with -d), the system runs very > > hot, and turning cpu_idle_hlt back on works strangely (it cools an > > idle system, but stops clock interrupts working), and turning it > > back off works as expected (it reheats an idle system and restarts > > clock interrupts). Apparently the SMP hook into cpu_idle() doesn't > > work right if the flag is changed after booting. > > > > > Summary: > > > Basically the cpu enter deep sleep mode whenever it receives HLT > > > call within idle loop, and that only if APIC + Local APIC timer is > > > enabled. I can't tell whether it is because of APIC misseting, CPU > > > bug or else, but one thing for sure, FreeBSD 5.x/SMP boots happily > > > on this (well, that's because it doesn't use local APIC timer). > > > > The boot problem also caused clock interrupts to stop working *until > > I toggled AC power), so the problem is apparently related to using > > the local APIC timer. > > > > The power penalty seems to be more than slight. On my nx6325, > > tz0.temperature is now 50C with cpu_idle_hlt=1 and 75C with > > cpu_idle_hlt=0, the latter even when on battery power. I've also > > noticed this system getting hot while in ddb, and wondered if it > > would help to use pause() in the spinloops in console i/o routines. > > > > Apparently executing HLT on other cores seems fine, as long as we > _exclude_ at least a single core from doing so. That way, we still > have manageable timer interrupt while letting the other cores doing > power management stuffs. Currently, this is my crude crack on > machdep.c (both for i386 and amd64): > > ## BEGIN ## > void > cpu_idle(void) > { > > #ifdef SMP > if (mp_grab_cpu_hlt()) > return; > #endif > > if (cpu_idle_hlt) { > disable_intr(); > if (sched_runnable()) > enable_intr(); > else if (PCPU_GET(cpuid) == 0) <<<<< > enable_intr(); <<<<< > else > (*cpu_idle_hook)(); > } > } > ## END ## > > > Again, this only concern where local apic timer is in action for this > cpu. Are you using ACPI with Cx hlt states? It's known that on many Intel chips at least, entering C2 or C3 powers off the local APIC timer. I know of one possible workaround that we can use, but haven't had any time to look at it. Specifically, we could use another interrupt source (such as the HPET counters) and schedule them to wake us up when the next clock tick should fire when we enter C2 or higher sleep state. You can test this theory by setting the sysctl for ACPI to use only C1. -- John Baldwin