Hi, I just updated my 8.0-STABLE/amd64 today around 17h CEST, and it just panics when I unplug my AC. The current process = 11 (idle: cpu1) is this related to the cpufreq and related stuff ? It also says cannot dump. Device not defined or unavailable so I can't give you more infos now. King regards. -- Demelier David
2010/5/3 David DEMELIER <demelier.david@gmail.com>:> Hi, > > I just updated my 8.0-STABLE/amd64 today around 17h CEST, and it just > panics when I unplug my AC. ?The current process = 11 (idle: cpu1) is > this related to the cpufreq and related stuff ? > > It also says cannot dump. Device not defined or unavailable so I can't > give you more infos now. >I can confirm that : #performance_cx_lowest="HIGH" #performance_cpu_freq=${performance_cx_lowest} #economy_cx_lowest="LOW" #economy_cpu_freq=${economy_cx_lowest} in rc.conf was the problem. -- Demelier David
On Tue, May 04, 2010 at 10:32:14AM +0200, David DEMELIER wrote:> Since I added dumpdev="/dev/ad4s1b" in my /boot/loader.conf it does > not panic anymore ... > > I'm not lucky (or ?).1) dumpdev="xxx" should go into /etc/rc.conf, not /boot/loader.conf. Putting in in /boot/loader.conf will change/do nothing. You should probably be using 'dumpdev="auto"' anyway (it then uses whatever you define as swap in /etc/fstab). 2) If you meant to say /etc/rc.conf instead of /boot/loader.conf, setting dumpdev shouldn't fix your problem. I think it's a red herring. 3) You sent the above to me directly; please keep the mailing list CC'd, as others need to know what you've tried/done. Thanks. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Good news ! It worked, check the picture here : http://img63.imageshack.us/img63/4244/dsc00361g.jpg
On Tue, May 04, 2010 at 06:35:52PM +0200, David DEMELIER wrote:> Good news ! It worked, check the picture here : > > http://img63.imageshack.us/img63/4244/dsc00361g.jpgPlease try adding code fragment like this: if (cx_next->p_lvlx == NULL) printf("Going to panic.\n"); to dev/acpi/acpi_cpu.c:acpi_cpu_idle() function, right before CPU_GET_REG(cx_next->p_lvlx, 1); line and see if it prints the message immediately before the panic. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100504/637a9435/attachment.pgp
2010/5/4 Kostik Belousov <kostikbel@gmail.com>:> On Tue, May 04, 2010 at 06:35:52PM +0200, David DEMELIER wrote: >> Good news ! It worked, check the picture here : >> >> http://img63.imageshack.us/img63/4244/dsc00361g.jpg > > Please try adding code fragment like this: > ? ? ? ?if (cx_next->p_lvlx == NULL) > ? ? ? ? ? ? ? ?printf("Going to panic.\n"); > to ?dev/acpi/acpi_cpu.c:acpi_cpu_idle() function, right before > ? ?CPU_GET_REG(cx_next->p_lvlx, 1); > line and see if it prints the message immediately before the panic. >Yes it does at the beginning of the kernel panic. Cheers. -- Demelier David
On Tue, May 04, 2010 at 10:27:23PM +0200, David DEMELIER wrote:> 2010/5/4 Kostik Belousov <kostikbel@gmail.com>: > > On Tue, May 04, 2010 at 06:35:52PM +0200, David DEMELIER wrote: > >> Good news ! It worked, check the picture here : > >> > >> http://img63.imageshack.us/img63/4244/dsc00361g.jpg > > > > Please try adding code fragment like this: > > ? ? ? ?if (cx_next->p_lvlx == NULL) > > ? ? ? ? ? ? ? ?printf("Going to panic.\n"); > > to ?dev/acpi/acpi_cpu.c:acpi_cpu_idle() function, right before > > ? ?CPU_GET_REG(cx_next->p_lvlx, 1); > > line and see if it prints the message immediately before the panic. > > > > Yes it does at the beginning of the kernel panic.Ok, so the point of panic is found, it is NULL cx_next->p_lvlx resource. With the data in hand, I recommend you to ask on acpi@ (added a Cc:) about the cause and possible solution. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100504/2ea15158/attachment.pgp
On Wed, May 05, 2010 at 12:45:46PM +0100, Rui Paulo wrote:> Please try this patch: > > Index: acpi_cpu.c > ==================================================================> --- acpi_cpu.c (revision 207322) > +++ acpi_cpu.c (working copy) > @@ -997,12 +997,12 @@ > if (notify != ACPI_NOTIFY_CX_STATES) > return; > > + ACPI_SERIAL_BEGIN(cpu); > /* Update the list of Cx states. */ > acpi_cpu_cx_cst(sc); > acpi_cpu_cx_list(sc); > > /* Update the new lowest useable Cx state for all CPUs. */ > - ACPI_SERIAL_BEGIN(cpu); > cpu_cx_count = 0; > for (i = 0; i < cpu_ndevices; i++) { > isc = device_get_softc(cpu_devices[i]); >Tested, but exactly same panic an backtrace. Cheers. -- Demelier David
Le Vendredi 07 mai 2010 ? 18:22 +0200, Giovanni Trematerra a ?crit :> On Fri, May 7, 2010 at 2:08 PM, Demelier David <demelier.david@gmail.com> wrote: > > Hi, > > I noticed that pluggin the AC adaptor when I boot without it does not > > panic. It only panic when removing it. > > > > Maybe that could help ? > > > > Good to know. The problem lies somewhere when performance state change. > In your case it happens when you remove AC adaptor. Let's hope someone on > acpi@ ml comes up with a good idea. >Okay so for the moment no change, I'll wait for someone with an idea that could solve my problem. For me because the panic only happens when changing profile from ac plugged -> ac unplugged (and not the reverse) I would think it's a cpu related acpi issue. David.
On Thu, Jun 10, 2010 at 10:58 PM, Giovanni Trematerra <giovanni.trematerra@gmail.com> wrote:> On Tue, May 4, 2010 at 6:35 PM, David DEMELIER <demelier.david@gmail.com> 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_count > 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, ?with a value > 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.cpu.0. If different CPUs may have different Cx-states, the script should use as lowest_value the lowest value between all the CPUs. Please, let me know your comments and possibly commit the patch if you think is good enough. -- Gianni -------------- next part -------------- diff -r ac95a73d358d sys/dev/acpica/acpi_cpu.c --- a/sys/dev/acpica/acpi_cpu.c Tue May 18 08:13:40 2010 -0400 +++ b/sys/dev/acpica/acpi_cpu.c Fri Jun 11 03:10:37 2010 -0400 @@ -1009,6 +1009,8 @@ acpi_cpu_notify(ACPI_HANDLE h, UINT32 no if (isc->cpu_cx_count > cpu_cx_count) cpu_cx_count = isc->cpu_cx_count; } + if (sc->cpu_cx_lowest < cpu_cx_lowest) + acpi_cpu_set_cx_lowest(sc, min(cpu_cx_lowest, sc->cpu_cx_count - 1)); ACPI_SERIAL_END(cpu); } @@ -1204,7 +1206,7 @@ acpi_cpu_global_cx_lowest_sysctl(SYSCTL_ ACPI_SERIAL_BEGIN(cpu); for (i = 0; i < cpu_ndevices; i++) { sc = device_get_softc(cpu_devices[i]); - acpi_cpu_set_cx_lowest(sc, val); + acpi_cpu_set_cx_lowest(sc, min(val, sc->cpu_cx_count - 1)); } ACPI_SERIAL_END(cpu);