From owner-freebsd-stable@FreeBSD.ORG Sat Jun 12 17:30:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2243106566C; Sat, 12 Jun 2010 17:30:32 +0000 (UTC) (envelope-from jamesbrandongooch@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 45DFD8FC13; Sat, 12 Jun 2010 17:30:31 +0000 (UTC) Received: by iwn7 with SMTP id 7so3042904iwn.13 for ; Sat, 12 Jun 2010 10:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1xtirC9tuyOQAe11M2qs98mVsw0zi+GU3MnEeBbfvOg=; b=JKQ/kdiUJCzugkSUAglnGKzgVEtxfyWeZJFVwwwezq03U9lQDIDZ6QyXkQFHYL02Xt Tsf2FLHjeacdJ+xTp00t5FXZ2wF1yV5geK2s4QjyxJkzbQ3F97FvuIvR5ThOfi3sXKaU BzA6vhNNwsXLRBFig3LhbXCOXZNW7sx7FZbI8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ryGVS6B+N0zcGVv8qXQ6kyj4pSNNrEKyUFBFLifNm9aqHHgqQdW40PZYjbtQTejCf9 HfJWNaSU1PG6pyLKEhfdSvp4Ly+G37YVbR9kHwr45Eh5JCA5kb86NQrr5hBwPhRF6Z2n geYiSn7oZCip0Nv9w6hK0C2ElvuhMRZClc1vs= MIME-Version: 1.0 Received: by 10.231.157.17 with SMTP id z17mr3585348ibw.124.1276363831372; Sat, 12 Jun 2010 10:30:31 -0700 (PDT) Received: by 10.231.182.196 with HTTP; Sat, 12 Jun 2010 10:30:31 -0700 (PDT) In-Reply-To: References: <201006110818.27366.jhb@freebsd.org> Date: Sat, 12 Jun 2010 12:30:31 -0500 Message-ID: From: Brandon Gooch To: David DEMELIER Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable , John Baldwin , Giovanni Trematerra , avg@freebsd.org, Attilio Rao , kib@freebsd.org, Rui Paulo , jkim@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 17:30:33 -0000 On Sat, Jun 12, 2010 at 12:19 PM, David DEMELIER wrote: > 2010/6/11 John Baldwin : >> On Friday 11 June 2010 6:27:48 am Giovanni Trematerra wrote: >>> On Thu, Jun 10, 2010 at 10:58 PM, Giovanni Trematerra >>> wrote: >>> > On Tue, May 4, 2010 at 6:35 PM, David DEMELIER >> wrote: >>> >> Good news ! It worked, check the picture here : >>> >> >>> >> http://img63.imageshack.us/img63/4244/dsc00361g.jpg >>> >> >>> > >>> > Into the file sys/dev/acpica/acpi_cpu.c at the end of acpi_cpu_notify >>> > (a per cpu notification handler), called when _CST objects changing, >>> > global cpu_cx_count is set to the greatest value of all sc->cpu_cx_co= unt >>> > per-cpu variables. That could result in a panic as David reported, >>> > because that lets to invoke acpi_cpu_global_cx_lowest_sysctl from >>> > /etc/rc.d/power_profile, when AC adapter is unplugged, =A0with a valu= e >>> > that not all the CPUs could handle in the acpi_cpu_idle. >>> > The patch also change global cpu_cx_lowest according to new value of >>> > global cpu_cx_count if needed. >>> > >>> > David Demelier made a great work to test every patch I sent him >>> > to identify the source of the problem. >>> > >>> > Please, let me know your comments and possibly commit the patch >>> > if you think is good enough. >>> >>> As jhb@ pointed me out in private with the previous patch a CPU could >>> never enter in the >>> lowest Cx-state even if it gained. >>> So I'd like to propose this new solution. >>> When hw.acpi.cpu.cx_lowest sysctl is set, the global handler in >>> sys/dev/acpi_cpu.c >>> will set the greatest sc->cpu_cx_lowest value supported by the CPU and >>> not the same >>> value for all CPUs. >>> Later, when CPU, possibly gain new Cx-states, the acpi_cpu_notify >>> handler will set >>> sc->cpu_cx_lowest accordingly with global cx_lowest and the Cx-states >>> supported by >>> the CPU. >>> >>> Now I think that /etc/rc.d/power_profile script has a problem but that >>> is a different story. >>> The script select the lowest_value only querying cx-states of the dev.c= pu.0. >>> If different CPUs may have different Cx-states, the script should use >>> as lowest_value the >>> lowest value between all the CPUs. >> >> Yes. >> >>> Please, let me know your comments and possibly commit the patch >>> if you think is good enough. >> >> I think this is a good compromise for now. >> >> -- >> John Baldwin >> > > Thanks for Giovanni's patience and work, he made a lot of research to > solve this little problem :-). > > Is there a chance that this patch appears in 8.1-RELEASE ? > > Kind regards. > > -- > Demelier David > Someone would have to discuss with the Release Engineering team, but it would be cool :) -Brandon