On Thu, Feb 14, 2008 at 3:48 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Yinghai Lu <[EMAIL PROTECTED]> wrote: > > > after disable cpufreq, i got > > > > ACPI: Preparing to enter system sleep state S5 > > Disabling non-boot CPUs ... > > kvm: disabling virtualization on CPU1 > > CPU 1 is now offline > > CPU1 is down > > kvm: disabling virtualization on CPU2 > > CPU 2 is now offline > > ================> hang here. > > > > but x86.git/mm could go through down all the cpus.... > > > > interesting... > > i suspect some kobject related race, and i have the feeling this all is > timing dependent. > > Andrew started seeing reboot hangs roughly around the time when the > kobject changes went upstream. Given that x86.git had flux in that > timeframe too i couldnt be sure what caused them. > > i have the fixlet below in x86.git but it didnt solve Andrew's problem > so it's parking now at the end of the queue, with no clear purpose in > life :-) If it would solve someone's problem it might be revitalized. > > Note: this does not fix any particular bug i know about, it's just a > hack. > > Ingo > > ------------------------------> > Subject: x86: highprio shutdown hack > From: Ingo Molnar <[EMAIL PROTECTED]> > > Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> > Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]> > --- > arch/x86/kernel/reboot.c | 16 ++++++++++++++-- > 1 file changed, 14 insertions(+), 2 deletions(-) > > Index: linux-x86.q/arch/x86/kernel/reboot.c > =================================================================== > --- linux-x86.q.orig/arch/x86/kernel/reboot.c > +++ linux-x86.q/arch/x86/kernel/reboot.c > @@ -396,8 +396,20 @@ static void native_machine_shutdown(void > if (!cpu_isset(reboot_cpu_id, cpu_online_map)) > reboot_cpu_id = smp_processor_id(); > > - /* Make certain I only run on the appropriate processor */ > - set_cpus_allowed(current, cpumask_of_cpu(reboot_cpu_id)); > + /* > + * Make certain we only run on the appropriate processor, > + * and with sufficient priority: > + */ > + { > + struct sched_param schedparm; > + int ret; > + > + schedparm.sched_priority = 99; > + ret = sched_setscheduler(current, SCHED_RR, &schedparm); > + WARN_ON_ONCE(1);
so I got ------------[ cut here ]------------ WARNING: at arch/x86/kernel/reboot.c:409 native_machine_shutdown+0x5f/0xb4() Modules linked in: Pid: 7173, comm: reboot Not tainted 2.6.25-rc1-smp-00168-g458504f-dirty #33 Call Trace: [<ffffffff802521d8>] warn_on_slowpath+0x64/0x8e [<ffffffff802464c8>] enqueue_task+0x5c/0x7e [<ffffffff8027765c>] rt_mutex_adjust_pi+0x28/0x94 [<ffffffff8024c075>] sched_setscheduler+0x304/0x33c [<ffffffff80237feb>] native_machine_shutdown+0x5f/0xb4 [<ffffffff80237f6e>] native_machine_restart+0x2e/0x4c [<ffffffff8026234b>] sys_reboot+0x140/0x1b2 [<ffffffff8029bbd2>] handle_mm_fault+0x380/0x705 [<ffffffff802cc311>] d_kill+0x50/0x7c [<ffffffff8097d000>] do_page_fault+0x3bd/0x7c9 [<ffffffff804d58ae>] __up_read+0x27/0xb5 [<ffffffff8022432b>] system_call_after_swapgs+0x7b/0x80 ---[ end trace eb0e49090acb42b5 ]--- - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html