Bug 12468
| Summary: | Crash in acpi_cpufreq_init | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Alex Riesen (raa.lkml) |
| Component: | Power-Processor | Assignee: | Venkatesh Pallipadi (venki) |
| Status: | CLOSED DUPLICATE | ||
| Severity: | normal | CC: | acpi-bugzilla, mingo, rjw |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | boot crash @ get_cur_freq_on_cpu | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 12398 | ||
| Attachments: | Screenshot of the crashed computer | ||
Created attachment 19864 [details]
Screenshot of the crashed computer
And the first bad commit seem to be: :HEAD ~/v2.6; git bisect good 50c668d678fd01284799a6e4f1b91829d83cb9ed is first bad commit commit 50c668d678fd01284799a6e4f1b91829d83cb9ed Author: Ingo Molnar <mingo@elte.hu> Date: Mon Jan 12 10:49:53 2009 +0100 Revert "cpumask: use work_on_cpu in acpi-cpufreq.c for drv_read and drv_writ e" This reverts commit 7503bfbae89eba07b46441a5d1594647f6b8ab7d. Dieter Ries reported bootup soft-hangs and bisected it back to this commit, and reverting this commit gave him a working system. The commit introduces work_on_cpu() use into the cpufreq code, but that is subtly problematic from a lock hierarchy POV: the hotplug-cpu lock is an highlevel lock that is taken before lowlevel locks, and in this codepath we are called with the policy lock taken. Dieter did not have lockdep enabled so we dont have a nice stack trace proof for this, but using work_on_cpu() in such a lowlevel place certainly looks wrong, so we revert the patch. work_on_cpu() needs to be reworked to be more generally usable. Reported-by: Dieter Ries <clip2@gmx.de> Tested-by: Dieter Ries <clip2@gmx.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> M arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c Reverting the commit helped. I can boot: $ uname -a Linux blimp 2.6.29-rc2-t #171 SMP PREEMPT Sat Jan 17 22:05:48 CET 2009 x86_64 GNU/Linux First-Bad-Commit : 50c668d678fd01284799a6e4f1b91829d83cb9ed Alex, Can you confirm that when you "git revert 50c668d678fd01284799a6e4f1b91829d83cb9ed" (which reverts the revert and restores the original commit) that this crash goes away? (alternatively, you could git cherry-pick 7503bfbae89eba07b46441a5d1594647f6b8ab7d which would give you the same result) Date: Tue, 20 Jan 2009 15:23:12 +0100 From: Ingo Molnar <mingo@elte.hu> To: Alex Riesen <raa.lkml@gmail.com> Subject: Re: [Bug #12468] Crash in acpi_cpufreq_init should be fixed by the pending x86 fixes: git pull git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-fixes-for-linus does it work fine if you pull that tree? Ingo *** This bug has been marked as a duplicate of bug 12495 *** (In reply to comment #5) > Alex, > Can you confirm that when you > "git revert 50c668d678fd01284799a6e4f1b91829d83cb9ed" > (which reverts the revert and restores the original commit) > that this crash goes away? Eh? That's what I did. And it "helped". No crash. |
Latest working kernel version: v2.6.29-rc1 Earliest failing kernel version:v2.6.29-rc2 Distribution: Ubuntu Hardware Environment: Dell XPS M1330 Problem Description: Crashed before entering init. The little transcripted from the referenced screenshot: Process swapper (pid: 1, threadinfo ... Stack: ffff88007f0db9a0 ... ff... ff... Call trace: [<ffffffff80260372] ? trace_hardirqs_on_caller+0x114/0x138 ? trace_hardirqs_on+0xd/0xf get_cur_freq_on_cpu+0x63/0x8f acpi_cpufreq_cpu_init+0x366/0x418 cpufreq_add_dev+0x1fd/0x668 ? get_lock_stats ? mark_held_locks ? mutex_lock_nested ? trace_hardirqs_on_caller ? mutex_lock_nested ? sysdev_driver_register ? sysdev_driver_register ? _spin_unlock_irqrestore sysdev_driver_register cpufreq_register_driver acpi_freq_init ? acpi_freq_init _stext ? get_lock_stats ? native_sched_clock ? kmem_cache_free ? get_lock_stats ? put_lock_stats ? lock_release_holdtime ? _spin_unlock ? proc_register ? create_proc_entry ? register_irq_proc ? proc_fd_info kernel_init child_rip ? finish_task_switch ? restore_args ? kernel_init ? child_rip Code: 48 ... <f3> ... RIP [<ffffffff8021b0ac>] get_cur_val+0xc8/0xe5 RSP <ffff88007f0db980> CR2: 00000000000000d0 ---[ end trace ... ]--- Kernel panic - not syncing: Attempted to kill init!