Power Management issues in MPC8313 processor

[Srivatsan Canchivaram]

Hello Scott,

I am using 2.6.27 - I am trying to add Power Management support to an older
product.

Thanks,
Srivatsan

On Fri, Oct 26, 2012 at 8:27 PM, Scott Wood <scottwood at freescale.com> wrote:

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