From owner-freebsd-acpi@FreeBSD.ORG Wed Sep 28 19:34:17 2005 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95B5616A41F for ; Wed, 28 Sep 2005 19:34:17 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from portpc-design.spb.ru (portpc-design.spb.ru [81.176.64.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0C6543D49 for ; Wed, 28 Sep 2005 19:34:16 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from [85.140.138.12] (ppp85-140-138-12.pppoe.mtu-net.ru [85.140.138.12]) (authenticated bits=0) by portpc-design.spb.ru (8.13.5/8.13.5) with ESMTP id j8SJYDJg027353; Wed, 28 Sep 2005 23:34:13 +0400 (MSD) (envelope-from mcsi@mcsi.pp.ru) Message-ID: <433AF02F.2060902@mcsi.pp.ru> Date: Wed, 28 Sep 2005 23:34:07 +0400 From: Maxim Maximov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050911 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Nate Lawson References: <4330020C.5030302@mcsi.pp.ru> <20050920135958.GA1616@poupinou.org> <433016F8.903@mcsi.pp.ru> <20050920145932.GB1616@poupinou.org> <4332505A.5050201@mcsi.pp.ru> <4339EB56.2040503@root.org> In-Reply-To: <4339EB56.2040503@root.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on 81.176.64.226 X-Virus-Status: Clean Cc: acpi@freebsd.org Subject: Re: Hard hang with powerd 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: Wed, 28 Sep 2005 19:34:17 -0000 Nate Lawson wrote: > Maxim Maximov wrote: > >> Bruno Ducrot wrote: >> >>> On Tue, Sep 20, 2005 at 06:04:40PM +0400, Maxim Maximov wrote: >>> >>>> Bruno Ducrot wrote: >>>> >>>>> The 2 logical CPUs need to set the same MSRs at the same time, >>>>> but if the second one is forced to be idle, I'm not sure if p4tcc will >>>>> work fine. >>>>> >>>>> Therefore, I'm wondering if this hard hang happens with a SMP kernel >>>>> and hyperthreading is enabled, or if this happens with a UP kernel. >>>> >>>> >>>> Yes, kernel is SMP one. >>>> >>>> # sysctl machdep.hyperthreading_allowed >>>> machdep.hyperthreading_allowed: 1 >>>> >>> >>> It's weird. Could you please try with a kernel without SMP for >>> testing purpose? >>> >> >> It's fine. Now I'm running UP kernel with 'powerd -v' > > > Maxim, can you try some debugging things to figure out where the hang is > happening? First, add printfs of 1, 2, 3, 4, etc. throughout > sys/i386/cpufreq/p4tcc.c in p4tcc_set(). Then recompile the SMP kernel > and boot single user (to save an fsck) and change some settings via > sysctl dev.cpu.0.freq=xxx until you can get a hang. See what numbers > were printed and where it hung. It should go through all the numbers > twice when there is no hang since we set a value on cpu0 and cpu1. I did that. I seeded printfs from 1 to 7 throughout the function. OS dies when making these steps: 1. 751 -> 375 2. 748 -> 374 (from boot to boot, freq numbers always differ on my notebook) In the first case numbers printed were: 1234567. However, in the second hang the numbers printed were: 12345671234567. > > Also, see if you can break to the debugger (ctrl-alt-esc) from console > when it is hung. I'm guessing no. You're right. -- Maxim Maximov