On Thu, Feb 14, 2008 at 3:48 PM, Ingo Molnar <mingo@xxxxxxx> wrote:
>
> * Yinghai Lu <yhlu.kernel@xxxxxxxxx> 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 <mingo@xxxxxxx>
>
> Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
> Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> ---
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
