Power Management issues in MPC8313 processor

Power Management issues in MPC8313 processor

[Srivatsan Canchivaram]

[-- Attachment #1: Type: text/plain, Size: 7359 bytes --]

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

Call Trace:

[cd087de0] [c0167e6c] pm_dev_dbg+0x70/0x18c (unreliable)

[cd087df0] [c0167cb4] pm_noirq_op+0x58/0xc8

[cd087e00] [c0168e08] device_power_down+0x78/0x1c4

[cd087e40] [c00471bc] suspend_devices_and_enter+0x1ec/0x258

[cd087e70] [c00473ac] enter_state+0x13c/0x198

[cd087e90] [c00474bc] state_store+0xb4/0xf8

[cd087eb0] [c013af68] kobj_attr_store+0x24/0x3c

[cd087ec0] [c00bf734] sysfs_write_file+0xe8/0x1e8

[cd087ef0] [c0078bbc] vfs_write+0xb4/0x16c

[cd087f10] [c0078d7c] sys_write+0x4c/0xa4

[cd087f40] [c000fa88] ret_from_syscall+0x0/0x38

--- Exception: c01 at 0x4802679c

    LR = 0x4803f0e8

Instruction dump:

XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX

XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX

---[ end trace b6a2457eea68b760 ]---

done.

<7>PM: Preparing system for standby sleep

<1>Freezing user space processes ... <7>PM: Entering standby sleep

<7>platform mpc83xx_wdt.0: preparing suspend

<7>fsl-gianfar fsl-gianfar.0: preparing suspend

<7>fsl-gianfar fsl-gianfar.1: preparing suspend

<7>fsl-gianfar_mdio fsl-gianfar_mdio.14: preparing suspend

<7>serial8250 serial8250.0: preparing suspend

<7>serial8250 serial8250: preparing suspend

<7>platform Fixed MDIO bus.0: preparing suspend

<7>lm92 0-0049: legacy suspend

<7>lm92 0-0048: legacy suspend

<7>platform Fixed MDIO bus.0: suspend

<7>mdio_bus 24520:1f: legacy suspend

<7>Generic PHY 24520:01: legacy suspend

<7>Generic PHY 24520:00: legacy suspend

<7>serial8250 serial8250: suspend

<7>of_platform ee000600.timer: legacy suspend

<7>of_platform ee000500.timer: legacy suspend

<7>mpc83xx-pmc ee000b00.power: legacy suspend

<7>of_platform ee000700.pic: legacy suspend

<7>of_platform ee030000.crypto: legacy suspend

<7>of_platform ee004600.serial: legacy suspend

<7>of_platform ee004500.serial: legacy suspend

<7>of_platform ee025000.ethernet: legacy suspend

<7>of_platform ee024000.ethernet: legacy suspend

<7>of_platform ee024520.mdio: legacy suspend

<7>of_platform ee024e00.ptimer: legacy suspend

<7>of_platform ee0082a8.dma: legacy suspend

<7>mpc-i2c ee003100.i2c: legacy suspend

<7>mpc-i2c ee003000.i2c: legacy suspend

<7>of_platform ee000200.wdt: legacy suspend

<7>of_platform ee000000.soc8313: legacy suspend

<7>of-flash fc000000.flash: legacy suspend

<7>of_platform ee005000.localbus: legacy suspend

<7>serial8250 serial8250.0: suspend

<7>fsl-gianfar_mdio fsl-gianfar_mdio.14: suspend

<7>fsl-gianfar fsl-gianfar.1: suspend

<7>fsl-gianfar fsl-gianfar.0: suspend

<7>platform mpc83xx_wdt.0: suspend

<6>PM: suspend devices took 0.000 seconds

<7>platform Fixed MDIO bus.0: LATE suspend

<7>serial8250 serial8250: LATE suspend

<7>serial8250 serial8250.0: LATE suspend

<7>fsl-gianfar_mdio fsl-gianfar_mdio.14: LATE suspend

<1>Unable to handle kernel paging request for instruction fetch

<1>Faulting instruction address: 0x616d6570

<1>Oops: Kernel access of bad area, sig: 11 [#1]

<1>MPC831x RDB

<1>Modules linked in: dsp rcspi modem i2c_mpc thermal_sys lm92 hwmon [last
unloaded: modem]

<1>NIP: 616d6570 LR: c0165224 CTR: 616d6573

<1>REGS: cd087d30 TRAP: 0400   Not tainted  (2.6.27)

<1>MSR: 20001032 <ME,IR,DR>  CR: 28002024  XER: 20000000

<1>TASK = cc312400[1196] 'echo' THREAD: cd086000

<6>GPR00: 00000002 cd087de0 cc312400 cf821800 cd087de8 00000002 c06e0000
c06da4a0

<6>GPR08: c06da948 616d6573 00003fff c06c6308 28002022 10091248 0fffc000
100050b8

<6>GPR16: 1008a270 10068810 100687c8 10068814 00000000 1008c284 1008c294
c0246180

<6>GPR24: c02ab9e4 c02ab9dc c06cc4f4 00000006 cd087e08 00000002 c06c595c
cf821808

<1>NIP [616d6570] 0x616d6570

<1>LR [c0165224] platform_pm_suspend_noirq+0x84/0x88

<1>Call Trace:

<1>[cd087de0] [c0167e6c] pm_dev_dbg+0x70/0x18c (unreliable)

<1>[cd087df0] [c0167cb4] pm_noirq_op+0x58/0xc8

<1>[cd087e00] [c0168e08] device_power_down+0x78/0x1c4

<1>[cd087e40] [c00471bc] suspend_devices_and_enter+0x1ec/0x258

<1>[cd087e70] [c00473ac] enter_state+0x13c/0x198

<1>[cd087e90] [c00474bc] state_store+0xb4/0xf8

<1>[cd087eb0] [c013af68] kobj_attr_store+0x24/0x3c

<1>[cd087ec0] [c00bf734] sysfs_write_file+0xe8/0x1e8

<1>[cd087ef0] [c0078bbc] vfs_write+0xb4/0x16c

<1>[cd087f10] [c0078d7c] sys_write+0x4c/0xa4

<1>[cd087f40] [c000fa88] ret_from_syscall+0x0/0x38

<1>--- Exception: c01 at 0x4802679c

<1>    LR = 0x4803f0e8

<1>Instruction dump:

<1>XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX

<1>XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX

<4>---[ end trace b6a2457eea68b760 ]---

Segmentation fault




I tried commenting out the kernel code in drivers/base/platform.c ->
platform_legacy_suspend_late() function:

/*     if (dev->driver && drv->suspend_late)

       { } */


This prevents the segmentation fault but it causes the resume functions for
all the peripherals to be called as soon as the suspend operations are
complete i.e. the processor goes into standby and then immediately goes
back to normal operation.


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

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.


Any advice or suggestions are most welcome.


Thanks,

Srivatsan

[-- Attachment #2: Type: text/html, Size: 11569 bytes --]

Re: Power Management issues in MPC8313 processor

[Scott Wood]

On 10/25/2012 05:07:01 PM, Srivatsan Canchivaram wrote:
> Hi,
>=20
>=20
> I have a modem with a Freescale MPC8313E processor. I am trying to =20
> enable
> power savings in the processor by placing it in Standby mode and =20
> resume
> normal operation with a Wake-On-LAN magic packet.
>=20
>=20
> Following the directions in the Freescale Power Management app note, I
> enabled Power Management Support in the Linux kernel and device tree
> configurations.
>=20
>=20
> I ran the following command on the board:
>=20
> echo standby > /sys/power/state
>=20
>=20
> This caused the console to hang and there was no further response to
> keyboard inputs. I enabled =E2=80=98no_console_suspend=E2=80=99 in the ke=
rnel and =20
> when I
> loaded the new build and enabled standby mode, I observed an Oops =20
> trace:
>=20
>=20
>=20
> RASCOM_QCU.7.0.0013 $ echo standby > /sys/power/state
>=20
> <6>PM: Syncing fFreezing user space processes ... ilesystems ... =20
> <7>PM:
> Entering standby sleep
>=20
> Unable to handle kernel paging request for instruction fetch
>=20
> Faulting instruction address: 0x616d6570
>=20
> Oops: Kernel access of bad area, sig: 11 [#1]
>=20
> MPC831x RDB
>=20
> Modules linked in: dsp rcspi modem i2c_mpc thermal_sys lm92 hwmon =20
> [last
> unloaded: modem]
>=20
> NIP: 616d6570 LR: c0165224 CTR: 616d6573
>=20
> REGS: cd087d30 TRAP: 0400   Not tainted  (2.6.27)
>=20
> MSR: 20001032 <ME,IR,DR>  CR: 28002024  XER: 20000000
>=20
> TASK =3D cc312400[1196] 'echo' THREAD: cd086000
>=20
> GPR00: 00000002 cd087de0 cc312400 cf821800 cd087de8 00000002 c06e0000
> c06da4a0
>=20
> GPR08: c06da948 616d6573 00003fff c06c6308 28002022 10091248 0fffc000
> 100050b8
>=20
> GPR16: 1008a270 10068810 100687c8 10068814 00000000 1008c284 1008c294
> c0246180
>=20
> GPR24: c02ab9e4 c02ab9dc c06cc4f4 00000006 cd087e08 00000002 c06c595c
> cf821808
>=20
> NIP [616d6570] 0x616d6570
>=20
> LR [c0165224] platform_pm_suspend_noirq+0x84/0x88

What kernel are you using?  platform_pm_suspend_noirq was removed by =20
this commit:

commit 9b39e73d0c2b265a7f8748b0e9a9f09be84079a8
Author: Rafael J. Wysocki <rjw@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 =20
callbacks
     when the corresponding subsystem callbacks are not present, so drop
     them.

     Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

It seems that a driver's pm ops are getting corrupted -- maybe used =20
after freeing?  Have you tried enabling slab/slub debug?

Can you instrument the code to see if there are any fields in the =20
device struct that aren't corrupt, that could point out which device =20
this is?

> I found another thread that dealt with Power Management issues on the
> Freescale MPC8313 processor:
>=20
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-January/095240.html
>=20
> The resolution of this issue seems to be related to the JTAG TRST pin =20
> 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=

Re: Power Management issues in MPC8313 processor

[Srivatsan Canchivaram]

[-- Attachment #1: Type: text/plain, Size: 3596 bytes --]

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@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@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@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
>

[-- Attachment #2: Type: text/html, Size: 4590 bytes --]