From owner-freebsd-i386@FreeBSD.ORG Fri Nov 17 18:10:10 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 DA0C216A403 for ; Fri, 17 Nov 2006 18:10:10 +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 62ACD43D46 for ; Fri, 17 Nov 2006 18:10:10 +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 kAHIAAjk015907 for ; Fri, 17 Nov 2006 18:10:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAHIAAxP015906; Fri, 17 Nov 2006 18:10:10 GMT (envelope-from gnats) Date: Fri, 17 Nov 2006 18:10:10 GMT Message-Id: <200611171810.kAHIAAxP015906@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Ariff Abdullah 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: Ariff Abdullah 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 18:10:10 -0000 The following reply was made to PR i386/104678; it has been noted by GNATS. From: Ariff Abdullah To: John Baldwin Cc: bug-followup@FreeBSD.org, bde@zeta.org.au, danolson@visi.com, rainer.alves@gmail.com, infofarmer@FreeBSD.org Subject: Re: i386/104678: SMP not working on Turion XP Laptop Date: Sat, 18 Nov 2006 02:05:27 +0800 On Fri, 17 Nov 2006 16:50:14 GMT John Baldwin wrote: > > 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. > Unfortunately, this CPU is a bit special since it support nothing but C1. Perhaps the logic is simmilar that is, if the CPU is at it lowest Cx states (which in this sense, C1) and HLT is issued, interrupt generation within the CPU is simply halted. On Turion64 X2: # sysctl hw.acpi.cpu hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% On single core Turion64: # sysctl hw.acpi.cpu hw.acpi.cpu.cx_supported: C1/0 C2/18 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% 0.00% Surprisingly, if I deliberately set cx_lowest to C2 on single core Turion64 and HLT is issued through idle loop, the simmilar behaviour can be observed. Perhaps the workaround (or fix) best implmented within acpi cpu idle hook itself: acpi_cpu_c1() somewhere within sys/i386/acpica/acpi_machdep.c: if (at_lowest_cx_states && first_cpu && lapic_timer_enabled) { enable intr; } else { issue HLT; } This should fix issues with other cpu as well. Resonable? I guess so.. -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........