<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/acpi/processor_idle.c, branch v2.6.26-rc7</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>cpuidle acpi driver: fix oops on AC&lt;-&gt;DC</title>
<updated>2008-06-11T23:13:45+00:00</updated>
<author>
<name>Venkatesh Pallipadi</name>
<email>venkatesh.pallipadi@intel.com</email>
</author>
<published>2008-05-19T23:09:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=dcb84f335bee9c9a7781cfc5d74492dccaf066d2'/>
<id>dcb84f335bee9c9a7781cfc5d74492dccaf066d2</id>
<content type='text'>
cpuidle and acpi driver interaction bug with the way cpuidle_register_driver()
is called. Due to this bug, there will be oops on
AC&lt;-&gt;DC on some systems, where they support C-states in one DC and not in AC.

The current code does
ON BOOT:
	Look at CST and other C-state info to see whether more than C1 is
	supported. If it is, then acpi processor_idle does a
	cpuidle_register_driver() call, which internally enables the device.

ON CST change notification (AC&lt;-&gt;DC) and on suspend-resume:
	acpi driver temporarily disables device, updates the device with
	any new C-states, and reenables the device.

The problem is is on boot, there are no C2, C3 states supported and we skip
the register. Later on AC&lt;-&gt;DC, we may get a CST notification and we try
to reevaluate CST and enabled the device, without actually registering it.
This causes breakage as we try to create /sys fs sub directory, without the
parent directory which is created at register time.

Thanks to Sanjeev for reporting the problem here.
http://bugzilla.kernel.org/show_bug.cgi?id=10394

Signed-off-by: Venkatesh Pallipadi &lt;venkatesh.pallipadi@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
cpuidle and acpi driver interaction bug with the way cpuidle_register_driver()
is called. Due to this bug, there will be oops on
AC&lt;-&gt;DC on some systems, where they support C-states in one DC and not in AC.

The current code does
ON BOOT:
	Look at CST and other C-state info to see whether more than C1 is
	supported. If it is, then acpi processor_idle does a
	cpuidle_register_driver() call, which internally enables the device.

ON CST change notification (AC&lt;-&gt;DC) and on suspend-resume:
	acpi driver temporarily disables device, updates the device with
	any new C-states, and reenables the device.

The problem is is on boot, there are no C2, C3 states supported and we skip
the register. Later on AC&lt;-&gt;DC, we may get a CST notification and we try
to reevaluate CST and enabled the device, without actually registering it.
This causes breakage as we try to create /sys fs sub directory, without the
parent directory which is created at register time.

Thanks to Sanjeev for reporting the problem here.
http://bugzilla.kernel.org/show_bug.cgi?id=10394

Signed-off-by: Venkatesh Pallipadi &lt;venkatesh.pallipadi@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6</title>
<updated>2008-04-30T18:52:52+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2008-04-30T18:52:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=08acd4f8af42affd8cbed81cc1b69fa12ddb213f'/>
<id>08acd4f8af42affd8cbed81cc1b69fa12ddb213f</id>
<content type='text'>
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (179 commits)
  ACPI: Fix acpi_processor_idle and idle= boot parameters interaction
  acpi: fix section mismatch warning in pnpacpi
  intel_menlo: fix build warning
  ACPI: Cleanup: Remove unneeded, multiple local dummy variables
  ACPI: video - fix permissions on some proc entries
  ACPI: video - properly handle errors when registering proc elements
  ACPI: video - do not store invalid entries in attached_array list
  ACPI: re-name acpi_pm_ops to acpi_suspend_ops
  ACER_WMI/ASUS_LAPTOP: fix build bug
  thinkpad_acpi: fix possible NULL pointer dereference if kstrdup failed
  ACPI: check a return value correctly in acpi_power_get_context()
  #if 0 acpi/bay.c:eject_removable_drive()
  eeepc-laptop: add hwmon fan control
  eeepc-laptop: add backlight
  eeepc-laptop: add base driver
  ACPI: thinkpad-acpi: bump up version to 0.20
  ACPI: thinkpad-acpi: fix selects in Kconfig
  ACPI: thinkpad-acpi: use a private workqueue
  ACPI: thinkpad-acpi: fluff really minor fix
  ACPI: thinkpad-acpi: use uppercase for "LED" on user documentation
  ...

Fixed conflicts in drivers/acpi/video.c and drivers/misc/intel_menlow.c
manually.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (179 commits)
  ACPI: Fix acpi_processor_idle and idle= boot parameters interaction
  acpi: fix section mismatch warning in pnpacpi
  intel_menlo: fix build warning
  ACPI: Cleanup: Remove unneeded, multiple local dummy variables
  ACPI: video - fix permissions on some proc entries
  ACPI: video - properly handle errors when registering proc elements
  ACPI: video - do not store invalid entries in attached_array list
  ACPI: re-name acpi_pm_ops to acpi_suspend_ops
  ACER_WMI/ASUS_LAPTOP: fix build bug
  thinkpad_acpi: fix possible NULL pointer dereference if kstrdup failed
  ACPI: check a return value correctly in acpi_power_get_context()
  #if 0 acpi/bay.c:eject_removable_drive()
  eeepc-laptop: add hwmon fan control
  eeepc-laptop: add backlight
  eeepc-laptop: add base driver
  ACPI: thinkpad-acpi: bump up version to 0.20
  ACPI: thinkpad-acpi: fix selects in Kconfig
  ACPI: thinkpad-acpi: use a private workqueue
  ACPI: thinkpad-acpi: fluff really minor fix
  ACPI: thinkpad-acpi: use uppercase for "LED" on user documentation
  ...

Fixed conflicts in drivers/acpi/video.c and drivers/misc/intel_menlow.c
manually.
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branches 'release', 'acpica', 'bugzilla-10224', 'bugzilla-9772', 'bugzilla-9916', 'ec', 'eeepc', 'idle', 'misc', 'pm-legacy', 'sysfs-links-2.6.26', 'thermal', 'thinkpad' and 'video' into release</title>
<updated>2008-04-30T17:58:00+00:00</updated>
<author>
<name>Len Brown</name>
<email>len.brown@intel.com</email>
</author>
<published>2008-04-30T17:58:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=96916090f488986a4ebb8e9ffa6a3b50881d5ccd'/>
<id>96916090f488986a4ebb8e9ffa6a3b50881d5ccd</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI: Fix acpi_processor_idle and idle= boot parameters interaction</title>
<updated>2008-04-30T17:57:15+00:00</updated>
<author>
<name>Venkatesh Pallipadi</name>
<email>venkatesh.pallipadi@intel.com</email>
</author>
<published>2008-04-30T17:57:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=36a913586597cab1cd565e9bf348d037f0df955b'/>
<id>36a913586597cab1cd565e9bf348d037f0df955b</id>
<content type='text'>
acpi_processor_idle and "idle=" boot parameter interaction is broken.
The problem is that, at boot time acpi driver is checking for "idle=" boot
option and not registering the acpi idle handler. But, when there is a CST
changed callback (typically when switching AC &lt;-&gt; battery or suspend-resume)
there are no checks for boot_option_idle_override and acpi idle handler tries
to get installed with nasty side effects.

With CPU_IDLE configured this issue causes results in a nasty oops on CST
change callback and without CPU_IDLE there is no oops, but boot option
of "idle=" gets ignored and acpi idle handler gets installed.

Change the behavior to not do anything in acpi idle handler when there is a
"idle=" boot option.

Note that the problem is only there when "idle=" boot option is used.

Signed-off-by: Venkatesh Pallipadi &lt;venkatesh.pallipadi@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
acpi_processor_idle and "idle=" boot parameter interaction is broken.
The problem is that, at boot time acpi driver is checking for "idle=" boot
option and not registering the acpi idle handler. But, when there is a CST
changed callback (typically when switching AC &lt;-&gt; battery or suspend-resume)
there are no checks for boot_option_idle_override and acpi idle handler tries
to get installed with nasty side effects.

With CPU_IDLE configured this issue causes results in a nasty oops on CST
change callback and without CPU_IDLE there is no oops, but boot option
of "idle=" gets ignored and acpi idle handler gets installed.

Change the behavior to not do anything in acpi idle handler when there is a
"idle=" boot option.

Note that the problem is only there when "idle=" boot option is used.

Signed-off-by: Venkatesh Pallipadi &lt;venkatesh.pallipadi@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>acpi: use non-racy method for proc entries creation</title>
<updated>2008-04-29T15:06:22+00:00</updated>
<author>
<name>Denis V. Lunev</name>
<email>den@openvz.org</email>
</author>
<published>2008-04-29T08:02:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=cf7acfab032ff262f42954328cdfd20a5d9aaaac'/>
<id>cf7acfab032ff262f42954328cdfd20a5d9aaaac</id>
<content type='text'>
Use proc_create()/proc_create_data() to make sure that -&gt;proc_fops and -&gt;data
be setup before gluing PDE to main tree.

Add correct -&gt;owner to proc_fops to fix reading/module unloading race.

Signed-off-by: Denis V. Lunev &lt;den@openvz.org&gt;
Cc: Len Brown &lt;lenb@kernel.org&gt;
Cc: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Cc: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use proc_create()/proc_create_data() to make sure that -&gt;proc_fops and -&gt;data
be setup before gluing PDE to main tree.

Add correct -&gt;owner to proc_fops to fix reading/module unloading race.

Signed-off-by: Denis V. Lunev &lt;den@openvz.org&gt;
Cc: Len Brown &lt;lenb@kernel.org&gt;
Cc: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Cc: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fix idle (arch, acpi and apm) and lockdep</title>
<updated>2008-04-26T22:01:45+00:00</updated>
<author>
<name>Peter Zijlstra</name>
<email>peterz@infradead.org</email>
</author>
<published>2008-04-25T15:39:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=7f424a8b08c26dc14ac5c17164014539ac9a5c65'/>
<id>7f424a8b08c26dc14ac5c17164014539ac9a5c65</id>
<content type='text'>
OK, so 25-mm1 gave a lockdep error which made me look into this.

The first thing that I noticed was the horrible mess; the second thing I
saw was hacks like: 71e93d15612c61c2e26a169567becf088e71b8ff

The problem is that arch idle routines are somewhat inconsitent with
their IRQ state handling and instead of fixing _that_, we go paper over
the problem.

So the thing I've tried to do is set a standard for idle routines and
fix them all up to adhere to that. So the rules are:

  idle routines are entered with IRQs disabled
  idle routines will exit with IRQs enabled

Nearly all already did this in one form or another.

Merge the 32 and 64 bit bits so they no longer have different bugs.

As for the actual lockdep warning; __sti_mwait() did a plainly un-annotated
irq-enable.

Signed-off-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Tested-by: Bob Copeland &lt;me@bobcopeland.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
OK, so 25-mm1 gave a lockdep error which made me look into this.

The first thing that I noticed was the horrible mess; the second thing I
saw was hacks like: 71e93d15612c61c2e26a169567becf088e71b8ff

The problem is that arch idle routines are somewhat inconsitent with
their IRQ state handling and instead of fixing _that_, we go paper over
the problem.

So the thing I've tried to do is set a standard for idle routines and
fix them all up to adhere to that. So the rules are:

  idle routines are entered with IRQs disabled
  idle routines will exit with IRQs enabled

Nearly all already did this in one form or another.

Merge the 32 and 64 bit bits so they no longer have different bugs.

As for the actual lockdep warning; __sti_mwait() did a plainly un-annotated
irq-enable.

Signed-off-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Tested-by: Bob Copeland &lt;me@bobcopeland.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>2.6.25 regression: powertop says 120K wakeups/sec</title>
<updated>2008-04-25T00:05:01+00:00</updated>
<author>
<name>Venkatesh Pallipadi</name>
<email>venkatesh.pallipadi@intel.com</email>
</author>
<published>2008-04-10T01:31:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=0fda6b403f0eca66ad8a7c946b3996e359100443'/>
<id>0fda6b403f0eca66ad8a7c946b3996e359100443</id>
<content type='text'>
Patch to fix huge number of wakeups reported due to recent changes in
processor_idle.c. The problem was that the entry_method determination was
broken due to one of the recent commits (bc71bec91f987) causing
C1 entry to not to go to halt.

http://lkml.org/lkml/2008/3/22/124

Signed-off-by: Venkatesh Pallipadi &lt;venkatesh.pallipadi@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Patch to fix huge number of wakeups reported due to recent changes in
processor_idle.c. The problem was that the entry_method determination was
broken due to one of the recent commits (bc71bec91f987) causing
C1 entry to not to go to halt.

http://lkml.org/lkml/2008/3/22/124

Signed-off-by: Venkatesh Pallipadi &lt;venkatesh.pallipadi@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cpuidle: fix 100% C0 statistics regression</title>
<updated>2008-03-26T04:58:19+00:00</updated>
<author>
<name>Venki Pallipadi</name>
<email>venkatesh.pallipadi@intel.com</email>
</author>
<published>2008-02-29T18:24:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=8e92b6605da989c0aa8ff7e33306f36f0efd957c'/>
<id>8e92b6605da989c0aa8ff7e33306f36f0efd957c</id>
<content type='text'>
commit 9b12e18cdc1553de62d931e73443c806347cd974
'ACPI: cpuidle: Support C1 idle time accounting'
was implicated in a 100% C0 idle regression.
http://bugzilla.kernel.org/show_bug.cgi?id=10076

It pointed out a potential problem where the menu governor
may get confused by the C-state residency time from poll
idle or C1 idle, where this timing info is not accurate.
This inaccuracy is due to interrupts being handled
before we account for C-state exit.

Do not mark TIME_VALID for CO poll state.
Mark C1 time as valid only with the MWAIT (CSTATE_FFH) entry method.

This makes governors use the timing information only when it is correct and
eliminates any wrong policy decisions that may result from invalid timing
information.

Signed-off-by: Venkatesh Pallipadi &lt;venkatesh.pallipadi@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9b12e18cdc1553de62d931e73443c806347cd974
'ACPI: cpuidle: Support C1 idle time accounting'
was implicated in a 100% C0 idle regression.
http://bugzilla.kernel.org/show_bug.cgi?id=10076

It pointed out a potential problem where the menu governor
may get confused by the C-state residency time from poll
idle or C1 idle, where this timing info is not accurate.
This inaccuracy is due to interrupts being handled
before we account for C-state exit.

Do not mark TIME_VALID for CO poll state.
Mark C1 time as valid only with the MWAIT (CSTATE_FFH) entry method.

This makes governors use the timing information only when it is correct and
eliminates any wrong policy decisions that may result from invalid timing
information.

Signed-off-by: Venkatesh Pallipadi &lt;venkatesh.pallipadi@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI: fix mis-merge -- invoke acpi_unlazy_tlb() only on C3 entry</title>
<updated>2008-03-26T04:40:41+00:00</updated>
<author>
<name>Venki Pallipadi</name>
<email>venkatesh.pallipadi@intel.com</email>
</author>
<published>2008-03-24T21:24:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=996520c1fdd2948addb629be56c9febf2967e02b'/>
<id>996520c1fdd2948addb629be56c9febf2967e02b</id>
<content type='text'>
This original patch
http://ussg.iu.edu/hypermail/linux/kernel/0712.2/1451.html
was intending to add acpi_unlazy_tlb() to acpi_idle_enter_bm(),
which is used for C3 entry.

But it was merged incorrectly as commmit

bde6f5f59c2b2b48a7a849c129d5b48838fe77ee
'x86: voluntary leave_mm before entering ACPI C3'

so the call was instead added to acpi_idle_enter_simple()
(which is C2 entry routine), probably due to identical
context in that function.

Move the call back to acpi_idle_enter_bm().

Signed-off-by: Venkatesh Pallipadi &lt;venkatesh.pallipadi@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This original patch
http://ussg.iu.edu/hypermail/linux/kernel/0712.2/1451.html
was intending to add acpi_unlazy_tlb() to acpi_idle_enter_bm(),
which is used for C3 entry.

But it was merged incorrectly as commmit

bde6f5f59c2b2b48a7a849c129d5b48838fe77ee
'x86: voluntary leave_mm before entering ACPI C3'

so the call was instead added to acpi_idle_enter_simple()
(which is C2 entry routine), probably due to identical
context in that function.

Move the call back to acpi_idle_enter_bm().

Signed-off-by: Venkatesh Pallipadi &lt;venkatesh.pallipadi@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI: lockdep warning on boot, 2.6.25-rc5</title>
<updated>2008-03-14T04:05:48+00:00</updated>
<author>
<name>Venki Pallipadi</name>
<email>venkatesh.pallipadi@intel.com</email>
</author>
<published>2008-03-14T00:18:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=71e93d15612c61c2e26a169567becf088e71b8ff'/>
<id>71e93d15612c61c2e26a169567becf088e71b8ff</id>
<content type='text'>
This avoids the harmless WARNING by lockdep in acpi_processor_idle().

The reason for WARNING is because at the depth of idle handling code,
some of the idle handlers disable interrupts, some times, while returning from
the idle handler. After return, acpi_processor_idle and few other routines
in the file did an unconditional local_irq_enable(). With LOCKDEP, enabling
irq when it is already enabled generates the below WARNING.

&gt; &gt; [    0.593038] ------------[ cut here ]------------
&gt; &gt; [    0.593267] WARNING: at kernel/lockdep.c:2035 trace_hardirqs_on+0xa0/0x115()
&gt; &gt; [    0.593596] Modules linked in:
&gt; &gt; [    0.593756] Pid: 0, comm: swapper Not tainted 2.6.25-rc5 #8
&gt; &gt; [    0.594017]
&gt; &gt; [    0.594017] Call Trace:
&gt; &gt; [    0.594216]  [&lt;ffffffff80231663&gt;] warn_on_slowpath+0x58/0x6b
&gt; &gt; [    0.594495]  [&lt;ffffffff80495966&gt;] ? _spin_unlock_irqrestore+0x38/0x47
&gt; &gt; [    0.594809]  [&lt;ffffffff80329a86&gt;] ? acpi_os_release_lock+0x9/0xb
&gt; &gt; [    0.595103]  [&lt;ffffffff80337840&gt;] ? acpi_set_register+0x161/0x173
&gt; &gt; [    0.595401]  [&lt;ffffffff8034c8d4&gt;] ? acpi_processor_idle+0x1de/0x546
&gt; &gt; [    0.595706]  [&lt;ffffffff8020a23b&gt;] ? default_idle+0x0/0x73
&gt; &gt; [    0.595970]  [&lt;ffffffff8024fc0e&gt;] trace_hardirqs_on+0xa0/0x115
&gt; &gt; [    0.596049]  [&lt;ffffffff8034c6f6&gt;] ? acpi_processor_idle+0x0/0x546
&gt; &gt; [    0.596346]  [&lt;ffffffff8034c8d4&gt;] acpi_processor_idle+0x1de/0x546
&gt; &gt; [    0.596642]  [&lt;ffffffff8020a23b&gt;] ? default_idle+0x0/0x73
&gt; &gt; [    0.596912]  [&lt;ffffffff8034c6f6&gt;] ? acpi_processor_idle+0x0/0x546
&gt; &gt; [    0.597209]  [&lt;ffffffff8020a23b&gt;] ? default_idle+0x0/0x73
&gt; &gt; [    0.597472]  [&lt;ffffffff8020a355&gt;] cpu_idle+0xa7/0xd1
&gt; &gt; [    0.597717]  [&lt;ffffffff80485fa1&gt;] rest_init+0x55/0x57
&gt; &gt; [    0.597957]  [&lt;ffffffff8062fb49&gt;] start_kernel+0x29d/0x2a8
&gt; &gt; [    0.598215]  [&lt;ffffffff8062f1da&gt;] _sinittext+0x1da/0x1e1
&gt; &gt; [    0.598464]
&gt; &gt; [    0.598546] ---[ end trace 778e504de7e3b1e3 ]---

Signed-off-by: Venkatesh Pallipadi &lt;venkatesh.pallipadi@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This avoids the harmless WARNING by lockdep in acpi_processor_idle().

The reason for WARNING is because at the depth of idle handling code,
some of the idle handlers disable interrupts, some times, while returning from
the idle handler. After return, acpi_processor_idle and few other routines
in the file did an unconditional local_irq_enable(). With LOCKDEP, enabling
irq when it is already enabled generates the below WARNING.

&gt; &gt; [    0.593038] ------------[ cut here ]------------
&gt; &gt; [    0.593267] WARNING: at kernel/lockdep.c:2035 trace_hardirqs_on+0xa0/0x115()
&gt; &gt; [    0.593596] Modules linked in:
&gt; &gt; [    0.593756] Pid: 0, comm: swapper Not tainted 2.6.25-rc5 #8
&gt; &gt; [    0.594017]
&gt; &gt; [    0.594017] Call Trace:
&gt; &gt; [    0.594216]  [&lt;ffffffff80231663&gt;] warn_on_slowpath+0x58/0x6b
&gt; &gt; [    0.594495]  [&lt;ffffffff80495966&gt;] ? _spin_unlock_irqrestore+0x38/0x47
&gt; &gt; [    0.594809]  [&lt;ffffffff80329a86&gt;] ? acpi_os_release_lock+0x9/0xb
&gt; &gt; [    0.595103]  [&lt;ffffffff80337840&gt;] ? acpi_set_register+0x161/0x173
&gt; &gt; [    0.595401]  [&lt;ffffffff8034c8d4&gt;] ? acpi_processor_idle+0x1de/0x546
&gt; &gt; [    0.595706]  [&lt;ffffffff8020a23b&gt;] ? default_idle+0x0/0x73
&gt; &gt; [    0.595970]  [&lt;ffffffff8024fc0e&gt;] trace_hardirqs_on+0xa0/0x115
&gt; &gt; [    0.596049]  [&lt;ffffffff8034c6f6&gt;] ? acpi_processor_idle+0x0/0x546
&gt; &gt; [    0.596346]  [&lt;ffffffff8034c8d4&gt;] acpi_processor_idle+0x1de/0x546
&gt; &gt; [    0.596642]  [&lt;ffffffff8020a23b&gt;] ? default_idle+0x0/0x73
&gt; &gt; [    0.596912]  [&lt;ffffffff8034c6f6&gt;] ? acpi_processor_idle+0x0/0x546
&gt; &gt; [    0.597209]  [&lt;ffffffff8020a23b&gt;] ? default_idle+0x0/0x73
&gt; &gt; [    0.597472]  [&lt;ffffffff8020a355&gt;] cpu_idle+0xa7/0xd1
&gt; &gt; [    0.597717]  [&lt;ffffffff80485fa1&gt;] rest_init+0x55/0x57
&gt; &gt; [    0.597957]  [&lt;ffffffff8062fb49&gt;] start_kernel+0x29d/0x2a8
&gt; &gt; [    0.598215]  [&lt;ffffffff8062f1da&gt;] _sinittext+0x1da/0x1e1
&gt; &gt; [    0.598464]
&gt; &gt; [    0.598546] ---[ end trace 778e504de7e3b1e3 ]---

Signed-off-by: Venkatesh Pallipadi &lt;venkatesh.pallipadi@intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
