2009-04-03 11:11:41     Power management can't wakeup

2009-04-03 11:11:41     Power management can't wakeup

Adam Dershowitz (UNITED STATES)

Message: 72123   

I am using the ez-kit 527, and was trying to do some stuff with power management.  I read:

http://docs.blackfin.uclinux.org/doku.php?id=power_management_support

and followed the instructions.  For the EZKit I changed the GPIO number to 16 for the first button.  I can get it to go to sleep.  But if I can't get it to wake up.

I also enabled rtcwake, and after the set time, instead of waking up, the board reboots.  While, if I just enble gpio:

/sys/devices/platform/gpio-keys.0/power> echo enabled > wakeup

and then put it to sleep

echo standby > /sys/power/state I can't get it to wakeup at all.  The only thing I can do that that point is hit the reset button to cause a reboot.

Any suggestions would be appreciated.

Thanks,

--Adam

QuoteReplyEditDelete

2009-04-06 00:37:18     Re: Power management can't wakeup

Mike Frysinger (UNITED STATES)

Message: 72194   

what version of software exactly are you using (u-boot and kernel) ?  suspend support was not in the last (2008R1.5) release.

QuoteReplyEditDelete

2009-04-06 11:35:53     Re: Power management can't wakeup

Adam Dershowitz (UNITED STATES)

Message: 72264   

I am using trunk-svn-7715 version of the kernel.  But I am still using 2008R1.5 of u-boot.  I figured that once u-boot loaded the kernel that the version really didn't matter, so I had not bothered to update it.

It sounds, from your question, like this mismatch could cause a problem.  I will upgrade u-boot and see what happens.

Thanks,

QuoteReplyEditDelete

2009-04-06 13:26:00     Re: Power management can't wakeup

Adam Dershowitz (UNITED STATES)

Message: 72271   

I built uboot 2009-01, and booted that (i didn't flash, just booted from memory) and then if I boot linux (trunk-SVN-7715) all seems fine....but no luck with power management.

Again, if I use rtcwake, it seems to go to sleep, and then wakeup, but reboots soon after the wakeup:

root:/> rtcwake -s 5

wakeup from "standby" at Wed Aug 18 20:34:16 2032

PM: Syncing filesystems ... done.

Freezing user space processes ... (elapsed 0.00 seconds) done.

Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.

Suspending console(s) (use no_console_suspend to debug)

PHY: 0:03 - Link is Down

Restarting tasks ... done.

rto/: >PHY: 0:03 - Link is Up - 100/Full

(5-10 second delay then boots to U-boot)

And if I do it instead to enable gpio wakup, it again seems to go to sleep, but when I push a button to wakeup, I get a kernel panic on wakeup:

root:/> cd /sys/devices/platform/gpio-keys.0/power

root:/sys/devices/platform/gpio-keys.0/power> echo enabled > wakeup

root:/sys/devices/platform/gpio-keys.0/power> echo standby > /sys/power/state

PM: Syncing filesystems ... done.

Freezing user space processes ... (elapsed 0.00 seconds) done.

Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.

Suspending console(s) (use no_console_suspend to debug)

Restarting tasks ... done.

oo:ts/syd/vecisep/alftro/mpgoik-ye.s/0opew>rNULL pointer access

Kernel OOPS in progress

Deferred Exception context

No Valid process in current context

return address: [0x000d0aec]; contents of:

0x000d0ac0:  001e  1803  9138  0040  0c02  102a  0c03  326b

0x000d0ad0:  1821  0000  0000  0000  af2a  aeec  acab  b32f

0x000d0ae0:  0c42  1b9d  0000  0000  0000  0031 [a050] 67f8

0x000d0af0:  b050  60f8  0801  a052  1803  9138  0040  0c02

SEQUENCER STATUS:        Not tainted

SEQSTAT: 00060027  IPEND: c030  SYSCFG: 0006

  EXCAUSE   : 0x27

  interrupts disabled

  physical IVG5 asserted : <0xffa00acc> { _evt_ivhw + 0x0 }

  physical IVG14 asserted : <0xffa008dc> { _evt14_softirq + 0x0 }

  physical IVG15 asserted : <0xffa00c1c> { _evt_system_call + 0x0 }

  logical irq   6 mapped  : <0xffa00308> { _timer_interrupt + 0x0 }

  logical irq  21 mapped  : <0x000bb668> { _bfin_rtc_interrupt + 0x0 }

  logical irq  31 mapped  : <0x000a572c> { _bfin_serial_dma_rx_int + 0x0 }

  logical irq  32 mapped  : <0x000a5a2c> { _bfin_serial_dma_tx_int + 0x0 }

  logical irq  35 mapped  : <0x000ae5b8> { _bfin_mac_interrupt + 0x0 }

  logical irq  87 mapped  : <0x000b9ad0> { _gpio_keys_isr + 0x0 }

RETE: <0x00000000> { _do_one_initcall + 0xfffff000 }

RETN: <0x00191e10> /* kernel dynamic memory */

RETX: <0x00000480> /* Maybe fixed code section */

RETS: <0x000dc95e> { _dst_rcu_free + 0x2a }

PC  : <0x000d0aec> { _dst_destroy + 0xe4 }

DCPLB_FAULT_ADDR: <0x00000004> /* Maybe null pointer? */

ICPLB_FAULT_ADDR: <0x000d0aec> { _dst_destroy + 0xe4 }

PROCESSOR STATE:

R0 : 03eeec60    R1 : 0000ffff    R2 : 0000000a    R3 : 001767c8

R4 : 0000000a    R5 : 00000100    R6 : 00000008    R7 : 00000000

P0 : 00d37c00    P1 : 03eeec60    P2 : 00000001    P3 : 00000000

P4 : 00000000    P5 : 03eeec60    FP : 0017e910    SP : 00191d34

LB0: 0009b9fc    LT0: 0009b9a4    LC0: 00000000

LB1: 0000de2e    LT1: 0000de18    LC1: 00000000

B0 : 00000000    L0 : 00000000    M0 : 00000020    I0 : ffffffff

B1 : 00000000    L1 : 00000000    M1 : 00000000    I1 : ffffffff

B2 : 03eebdcc    L2 : 00000000    M2 : 00000000    I2 : ffffffff

B3 : 00000000    L3 : 00000000    M3 : 00000000    I3 : ffffffff

A0.w: 003d08c9   A0.x: 00000000   A1.w: 00000906   A1.x: 00000000

USP : 00192000  ASTAT: 02003005

Hardware Trace:

   0 Target : <0x00004a40> { _trap_c + 0x0 }

     Source : <0xffa0058a> { _exception_to_level5 + 0x9e } CALL pcrel

   1 Target : <0xffa004ec> { _exception_to_level5 + 0x0 }

     Source : <0xffa003be> { _bfin_return_from_exception + 0x6 } RTX

   2 Target : <0xffa003b8> { _bfin_return_from_exception + 0x0 }

     Source : <0xffa00446> { _ex_trap_c + 0x66 } JUMP.S

   3 Target : <0xffa003e0> { _ex_trap_c + 0x0 }

     Source : <0xffa00616> { _trap + 0x2a } JUMP (P4)

   4 Target : <0xffa005ec> { _trap + 0x0 }

     Source : <0x000d0aea> { _dst_destroy + 0xe2 } 0x0031

   5 Target : <0x000d0ad8> { _dst_destroy + 0xd0 }

     Source : <0x000d0a1a> { _dst_destroy + 0x12 } JUMP.S

   6 Target : <0x000d0a08> { _dst_destroy + 0x0 }

     Source : <0x000dc95a> { _dst_rcu_free + 0x26 } CALL pcrel

   7 Target : <0x000dc958> { _dst_rcu_free + 0x24 }

     Source : <0x000dc94c> { _dst_rcu_free + 0x18 } IF CC JUMP

   8 Target : <0x000dc946> { _dst_rcu_free + 0x12 }

     Source : <0x000dc93e> { _dst_rcu_free + 0xa } IF !CC JUMP

   9 Target : <0x000dc934> { _dst_rcu_free + 0x0 }

     Source : <0x0002e760> { ___rcu_process_callbacks + 0xd0 } CALL (P2)

  10 Target : <0x0002e74e> { ___rcu_process_callbacks + 0xbe }

     Source : <0x0002e766> { ___rcu_process_callbacks + 0xd6 } IF CC JUMP

  11 Target : <0x0002e762> { ___rcu_process_callbacks + 0xd2 }

     Source : <0x000dc944> { _dst_rcu_free + 0x10 } RTS

  12 Target : <0x000dc940> { _dst_rcu_free + 0xc }

     Source : <0x000dc962> { _dst_rcu_free + 0x2e } IF !CC JUMP

  13 Target : <0x000dc95e> { _dst_rcu_free + 0x2a }

     Source : <0x000d0b1c> { _dst_destroy + 0x114 } RTS

  14 Target : <0x000d0b12> { _dst_destroy + 0x10a }

     Source : <0x000d0aa6> { _dst_destroy + 0x9e } IF !CC JUMP

  15 Target : <0x000d0aa4> { _dst_destroy + 0x9c }

     Source : <0x0003c262> { _kmem_cache_free + 0x36 } RTS

Kernel Stack

Stack info:

SP: [0x00191f54] <0x00191f54> /* kernel dynamic memory */

Memory from 0x00191f50 to 00192000

00191f50: 00000020 [03eebe18] 00186cec  00000040  00000300  00192000  0017e910  ffa00248

00191f70: 00190000  0016d5b4  0017e910  00190000  ffa00810  0016cd14  00000000  00000000

00191f90: 00000000  00000001  00000002  0000ffff  0000ffff  0000ffff  ffa00810  00000006

00191fb0: 0016cd14  00000000  00000000  001926c6  00176adc  001aa4e4  0016cd20  0016cd14

00191fd0: 00000000  001aa4e4  0016ca64  00000022  00192098  001acf34  00192000  0019f5d4

00191ff0: 00000000  00000000  00000000  ffb00000  b9b8b934

Return addresses in stack:

Modules linked in:

Kernel panic - not syncing: Kernel exception

QuoteReplyEditDelete

2009-04-06 18:38:41     Re: Power management can't wakeup

Mike Frysinger (UNITED STATES)

Message: 72280   

you should use 2008.10 as that is the next version we plan on using in our next release, but that shouldnt cause a problem here.  2008R1.5 certainly would not support waking up.

in your rtcwake test, if u-boot starts up rather than the kernel, run `md.b 0` and post the output.

i seem to recall there being some problems with the bf527-ezkit board in that the memory pins were not wired perfectly and so it could lead to random memory corruption during suspend/resume.  not anything software can do about that ...

QuoteReplyEditDelete

2009-04-06 19:27:02     Re: Power management can't wakeup

Adam Dershowitz (UNITED STATES)

Message: 72282   

This is strange, but I just tried it again, and now I can't recreate the problem.  Now it seems to be working fine.

Perhaps it needed a full reset, which happened in after the old test.  But all seems good now.

QuoteReplyEditDelete

2009-04-14 10:45:28     Re: Power management can't wakeup

Michael Hennerich (GERMANY)

Message: 72641    Are you still having problems with suspend standby?

-Michael

QuoteReplyEditDelete

2009-04-14 13:24:34     Re: Power management can't wakeup

Adam Dershowitz (UNITED STATES)

Message: 72645   

No.

Now it seems to be working fine.  I did upgrade to a newer u-boot.  At first it didn't work, but now it is working fine.  I don't understand why I continued to have problems after the initial upgrade, but for now it is fine.  It might be that it needed a full hardware reset after I went to the newer u-boot?

Anyway, problem solved.

Thanks for the help.

--Adam