Bug 12468 - Crash in acpi_cpufreq_init
Crash in acpi_cpufreq_init
Status: CLOSED DUPLICATE of bug 12495
Product: ACPI
Classification: Unclassified
Component: Power-Processor
All Linux
: P1 normal
Assigned To: Venkatesh Pallipadi
:
Depends on:
Blocks: 12398
  Show dependency treegraph
 
Reported: 2009-01-17 10:47 UTC by Alex Riesen
Modified: 2009-01-20 14:31 UTC (History)
3 users (show)

See Also:
Kernel Version: boot crash @ get_cur_freq_on_cpu
Tree: Mainline
Regression: Yes


Attachments
Screenshot of the crashed computer (142.52 KB, image/jpeg)
2009-01-17 10:48 UTC, Alex Riesen
Details

Description Alex Riesen 2009-01-17 10:47:31 UTC
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!
Comment 1 Alex Riesen 2009-01-17 10:48:37 UTC
Created attachment 19864 [details]
Screenshot of the crashed computer
Comment 2 Alex Riesen 2009-01-17 12:54:54 UTC
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
Comment 3 Alex Riesen 2009-01-17 13:12:34 UTC
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
Comment 4 Rafael J. Wysocki 2009-01-19 12:35:47 UTC
First-Bad-Commit : 50c668d678fd01284799a6e4f1b91829d83cb9ed
Comment 5 Len Brown 2009-01-20 08:20:43 UTC
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)
Comment 6 Len Brown 2009-01-20 08:23:27 UTC
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
Comment 7 Len Brown 2009-01-20 13:13:08 UTC

*** This bug has been marked as a duplicate of bug 12495 ***
Comment 8 Alex Riesen 2009-01-20 14:31:57 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.