From owner-freebsd-stable@FreeBSD.ORG Sat Jun 12 17:19:44 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 293F5106566B; Sat, 12 Jun 2010 17:19:44 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B1F9E8FC12; Sat, 12 Jun 2010 17:19:42 +0000 (UTC) Received: by bwz2 with SMTP id 2so1441600bwz.13 for ; Sat, 12 Jun 2010 10:19:41 -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=xq8uzJux/wjPY/bIURMp7DESND+ETUfy3S39274zpm0=; b=hSjT6KaLvzrFGHtzgaBQ52NZQLEijqlRSZjbsoE2nwzw2XTi+MvQ6oM9geaI9yVmQm CLktfDzzqb7nrU3sx3NzO+CbTN0MjTJ/ge4cujLL4sZJjs7IWsg+SSs0sSvD1RJLS7dw 1dBDbFfOe5roBxrg0SqyEpqpnKL2sTib//U7M= 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=U62T36bXRpx+pcEK+SDSjbsq33kq+5BUdOz1voqkjsM6OUf020wgM+Imh3wjjmsb1x I9Ok39xkS0B0F5sHTndt81035bx6DyKuw4Lb7DHP8LKmOjSDRabvcwMEy3XWST3ru44W 7nUjxQQYex9W/gMjZhjqvNPXi0NqpJGFzef3k= MIME-Version: 1.0 Received: by 10.204.2.71 with SMTP id 7mr2491027bki.213.1276363181245; Sat, 12 Jun 2010 10:19:41 -0700 (PDT) Received: by 10.204.123.202 with HTTP; Sat, 12 Jun 2010 10:19:41 -0700 (PDT) In-Reply-To: <201006110818.27366.jhb@freebsd.org> References: <201006110818.27366.jhb@freebsd.org> Date: Sat, 12 Jun 2010 19:19:41 +0200 Message-ID: From: David DEMELIER To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable , Brandon Gooch , 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:19:44 -0000 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_cou= nt >> > 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, =C2=A0with a va= lue >> > 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.cp= u.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. --=20 Demelier David