Weird deadlock when shutting down
in [Kernel]
|
Prev: acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
Next: input/touchscreen: Synaptics Touchscreen Driver
From: Xiaotian Feng on 21 Feb 2010 06:20 On Sun, Feb 21, 2010 at 6:55 PM, Xiaotian Feng <xtfeng(a)gmail.com> wrote: > On Sun, Feb 21, 2010 at 6:43 PM, Johannes Berg > <johannes(a)sipsolutions.net> wrote: >> Incidentally, the machine also freezes hard without any output at all if >> I "echo 0 > /sys/.../cpu1/online". > > It might be nothing related with cpufreq. I think there's something > wrong during the _cpu_down path. > put more debug printks into _cpu_down(), if we can find kernel is > stuck in which place in _cpu_down, it would be helpful. and it looks like this breakage is only seen on powerMac G5, so it might be arch specific. Maybe some commit in powermac breaks G5's cpu_down, just a guess ;-) > >> >> johannes >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Johannes Berg on 21 Feb 2010 06:20 On Sun, 2010-02-21 at 19:12 +0800, Xiaotian Feng wrote: > On Sun, Feb 21, 2010 at 6:55 PM, Xiaotian Feng <xtfeng(a)gmail.com> > wrote: > > On Sun, Feb 21, 2010 at 6:43 PM, Johannes Berg > > <johannes(a)sipsolutions.net> wrote: > >> Incidentally, the machine also freezes hard without any output at > all if > >> I "echo 0 > /sys/.../cpu1/online". > > > > It might be nothing related with cpufreq. I think there's something > > wrong during the _cpu_down path. > > put more debug printks into _cpu_down(), if we can find kernel is > > stuck in which place in _cpu_down, it would be helpful. > > and it looks like this breakage is only seen on powerMac G5, so it > might be arch specific. Maybe some commit in powermac breaks G5's > cpu_down, just a guess ;-) Hmm, not sure ... it seems to be in __stop_machine(), in this code: printk("got cpu\n"); for_each_online_cpu(i) { sm_work = per_cpu_ptr(stop_machine_work, i); INIT_WORK(sm_work, stop_cpu); queue_work_on(i, stop_machine_wq, sm_work); } /* This will release the thread on our CPU. */ put_cpu(); printk("put cpu\n"); which is weird... the "got cpu" printk is the last thing I see. johannes
From: Johannes Berg on 21 Feb 2010 06:30 On Sun, 2010-02-21 at 12:14 +0100, Johannes Berg wrote: > printk("got cpu\n"); > for_each_online_cpu(i) { > sm_work = per_cpu_ptr(stop_machine_work, i); > INIT_WORK(sm_work, stop_cpu); > queue_work_on(i, stop_machine_wq, sm_work); > } > /* This will release the thread on our CPU. */ > put_cpu(); > printk("put cpu\n"); As odd as that may be, it hangs in put_cpu() here. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Américo Wang on 22 Feb 2010 03:20 On Sun, Feb 21, 2010 at 6:17 PM, Johannes Berg <johannes(a)sipsolutions.net> wrote: > On Sun, 2010-02-21 at 17:51 +0800, Américo Wang wrote: >> On Sat, Feb 20, 2010 at 9:57 PM, Johannes Berg >> <johannes(a)sipsolutions.net> wrote: >> > On Sat, 2010-02-20 at 21:44 +0800, Américo Wang wrote: >> > >> >> That message is displayed before shutting down the devices. >> >> >> >> To verify, you can add some printk() in the end of >> >> __cpufreq_remove_dev(), or enable CONFIG_CPU_FREQ_DEBUG. >> > >> > That is already enabled. >> > >> >> Ok, I got it. >> >> Could you test the patch below? Thanks! > > No change, sorry, still hangs right after "Disabling non-boot CPUs ..." > before the machine turns off. > Oh, I see, then this will be another problem. My previous patch is to fix the cpufreq lockdep warning mentioned in Benjamin's report, so this hang should be caused by other problem, not the cpufreq lockdep problem. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Américo Wang on 22 Feb 2010 03:30
On Sun, Feb 21, 2010 at 7:12 PM, Xiaotian Feng <xtfeng(a)gmail.com> wrote: > On Sun, Feb 21, 2010 at 6:55 PM, Xiaotian Feng <xtfeng(a)gmail.com> wrote: >> On Sun, Feb 21, 2010 at 6:43 PM, Johannes Berg >> <johannes(a)sipsolutions.net> wrote: >>> Incidentally, the machine also freezes hard without any output at all if >>> I "echo 0 > /sys/.../cpu1/online". >> >> It might be nothing related with cpufreq. I think there's something >> wrong during the _cpu_down path. >> put more debug printks into _cpu_down(), if we can find kernel is >> stuck in which place in _cpu_down, it would be helpful. > > and it looks like this breakage is only seen on powerMac G5, so it > might be arch specific. Maybe some commit in powermac breaks G5's > cpu_down, just a guess ;-) > Maybe not, there could be some generic code bug that will only be exposed on a specific arch. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |