Hello Scott,<div><br></div><div>I am using 2.6.27 - I am trying to add Power Management support to an older product.</div><div><br></div><div>Thanks,</div><div>Srivatsan<br><br><div class="gmail_quote">On Fri, Oct 26, 2012 at 8:27 PM, Scott Wood <span dir="ltr"><<a href="mailto:scottwood@freescale.com" target="_blank">scottwood@freescale.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 10/25/2012 05:07:01 PM, Srivatsan Canchivaram wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
<br>
I have a modem with a Freescale MPC8313E processor. I am trying to enable<br>
power savings in the processor by placing it in Standby mode and resume<br>
normal operation with a Wake-On-LAN magic packet.<br>
<br>
<br>
Following the directions in the Freescale Power Management app note, I<br>
enabled Power Management Support in the Linux kernel and device tree<br>
configurations.<br>
<br>
<br>
I ran the following command on the board:<br>
<br>
echo standby > /sys/power/state<br>
<br>
<br>
This caused the console to hang and there was no further response to<br>
keyboard inputs. I enabled ‘no_console_suspend’ in the kernel and when I<br>
loaded the new build and enabled standby mode, I observed an Oops trace:<br>
<br>
<br>
<br>
RASCOM_QCU.7.0.0013 $ echo standby > /sys/power/state<br>
<br>
<6>PM: Syncing fFreezing user space processes ... ilesystems ... <7>PM:<br>
Entering standby sleep<br>
<br>
Unable to handle kernel paging request for instruction fetch<br>
<br>
Faulting instruction address: 0x616d6570<br>
<br>
Oops: Kernel access of bad area, sig: 11 [#1]<br>
<br>
MPC831x RDB<br>
<br>
Modules linked in: dsp rcspi modem i2c_mpc thermal_sys lm92 hwmon [last<br>
unloaded: modem]<br>
<br>
NIP: 616d6570 LR: c0165224 CTR: 616d6573<br>
<br>
REGS: cd087d30 TRAP: 0400   Not tainted  (2.6.27)<br>
<br>
MSR: 20001032 <ME,IR,DR>  CR: 28002024  XER: 20000000<br>
<br>
TASK = cc312400[1196] 'echo' THREAD: cd086000<br>
<br>
GPR00: 00000002 cd087de0 cc312400 cf821800 cd087de8 00000002 c06e0000<br>
c06da4a0<br>
<br>
GPR08: c06da948 616d6573 00003fff c06c6308 28002022 10091248 0fffc000<br>
100050b8<br>
<br>
GPR16: 1008a270 10068810 100687c8 10068814 00000000 1008c284 1008c294<br>
c0246180<br>
<br>
GPR24: c02ab9e4 c02ab9dc c06cc4f4 00000006 cd087e08 00000002 c06c595c<br>
cf821808<br>
<br>
NIP [616d6570] 0x616d6570<br>
<br>
LR [c0165224] platform_pm_suspend_noirq+<u></u>0x84/0x88<br>
</blockquote>
<br></div></div>
What kernel are you using?  platform_pm_suspend_noirq was removed by this commit:<br>
<br>
commit 9b39e73d0c2b265a7f8748b0e9a9f0<u></u>9be84079a8<br>
Author: Rafael J. Wysocki <<a href="mailto:rjw@sisk.pl" target="_blank">rjw@sisk.pl</a>><br>
Date:   Sun Dec 18 00:34:24 2011 +0100<br>
<br>
    PM / Sleep: Remove forward-only callbacks from platform bus type<br>
<br>
    The forward-only PM callbacks provided by the platform bus type are<br>
    not necessary any more, because the PM core executes driver callbacks<br>
    when the corresponding subsystem callbacks are not present, so drop<br>
    them.<br>
<br>
    Signed-off-by: Rafael J. Wysocki <<a href="mailto:rjw@sisk.pl" target="_blank">rjw@sisk.pl</a>><br>
<br>
It seems that a driver's pm ops are getting corrupted -- maybe used after freeing?  Have you tried enabling slab/slub debug?<br>
<br>
Can you instrument the code to see if there are any fields in the device struct that aren't corrupt, that could point out which device this is?<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I found another thread that dealt with Power Management issues on the<br>
Freescale MPC8313 processor:<br>
<br>
<a href="https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-January/095240.html" target="_blank">https://lists.ozlabs.org/<u></u>pipermail/linuxppc-dev/2012-<u></u>January/095240.html</a><br>
<br>
The resolution of this issue seems to be related to the JTAG TRST pin being<br>
disabled. This is not relevant in my case as the TRST on my board is<br>
already inactive.<br>
</blockquote>
<br></div>
If you were seeing that, you'd see a hang rather than an oops.<span class="HOEnZb"><font color="#888888"><br>
<br>
-Scott<br>
</font></span></blockquote></div><br></div>