FAQ: [#6406] failure after resume during standby mode power management test(2010)

Document created by Aaronwu Employee on Sep 11, 2013
Version 1Show Document
  • View in full screen mode

[#6406] failure after resume during standby mode power management test

Submitted By: Bob Liu

Open Date

2010-12-15 04:50:02    

Priority:

Medium     Assignee:

Bob Liu

Status:

Open     Fixed In Release:

N/A

Found In Release:

2010R1-RC5     Release:

Category:

N/A     Board:

N/A

Processor:

BF548     Silicon Revision:

Is this bug repeatable?:

Yes     Resolution:

Fixed

Uboot version or rev.:

    Toolchain version or rev.:

2010r1-rc4

App binary format:

N/A     

Summary: failure after resume during standby mode power management test

Details:

 

Attached the linux kernel config.

The log is:

==================

BusyBox v1.16.2 (2010-11-08 17:44:14 CST) hush - the humble shell

 

root:/>

root:/> rtcwake -s 10 -m standby

wakeup from "standby" at Mon Jan  5 12:14:53 1970

PM: Syncing filesystems ... done.

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

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

Suspending console(s) (use no_console_suspend to debug)

PM: suspend of devices complete after 877.131 msecs

PM: late suspend of devices complete after 0.567 msecs

PM: early resume of devices complete after 0.336 msecs

PM: resume of devices complete after 14.415 msecs

Restarting tasks ...

done.

root:/>

root:/>

root:/> usb 1-1: new high speed USB device using musb_hdrc and address 2

scsi0 : usb-storage 1-1:1.0

scsi 0:0:0:0: Direct-Access     SanDisk  U3 Cruzer Micro  4.05 PQ: 0 ANSI: 2

sd 0:0:0:0: [sda] 3999373 512-byte logical blocks: (2.04 GB/1.90 GiB)

sd 0:0:0:0: [sda] Write Protect is off

sd 0:0:0:0: [sda] Assuming drive cache: write through

sd 0:0:0:0: [sda] Assuming drive cache: write through

sda: sda1

sd 0:0:0:0: [sda] Assuming drive cache: write through

sd 0:0:0:0: [sda] Attached SCSI removable disk

 

root:/>

root:/>

root:/> rtcwake -s 10 -m standby

wakeup from "standby" at Mon Jan  5 12:15:27 1970

PM: Syncing filesystems ... done.

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

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

Suspending console(s) (use no_console_suspend to debug)

PM: suspend of devices complete after 922.975 msecs

PM: late suspend of devices complete after 0.593 msecs

PM: early resume of devices complete after 0.417 msecs

usb 1-1: reset high speed USB device using musb_hdrc and address 2

usb 1-1: device descriptor read/64, error -19

usb 1-1: device descriptor read/64, error -19

usb 1-1: reset high speed USB device using musb_hdrc and address 2

usb 1-1: device descriptor read/64, error -19

usb 1-1: device descriptor read/64, error -19

usb 1-1: reset high speed USB device using musb_hdrc and address 2

usb 1-1: device not accepting address 2, error -19

PM: resume of devices complete after 1672.161 msecs

Restarting tasks ...

done.

usb 1-1: USB disconnect, address 2

root:/> usb 1-1: new high speed USB device using musb_hdrc and address 3

usb 1-1: device descriptor read/64, error -19

usb 1-1: device descriptor read/64, error -19

usb 1-1: new high speed USB device using musb_hdrc and address 4

usb 1-1: device descriptor read/64, error -19

usb 1-1: device descriptor read/64, error -19

usb 1-1: new high speed USB device using musb_hdrc and address 5

usb 1-1: device not accepting address 5, error -19

usb 1-1: new high speed USB device using musb_hdrc and address 6

usb 1-1: device not accepting address 6, error -19

hub 1-0:1.0: unable to enumerate USB device on port 1

 

root:/>

 

Follow-ups

 

--- Bob Liu                                                  2010-12-15 05:53:03

fixed by commit 9528

 

--- Bob Liu                                                  2010-12-15 21:51:21

During suspend to ram test on bf548, if selected CONFIG_PM_BFIN_WAKE_GP in

kernel config, the system will be waked up immediately.

The root cause is the board's hardware problem and bf527 have no such

problem,so my commit -r9047 which seems to fixed this issue is wrong and caused

standby can't work.

After revert it, both standby and suspend to ram mode with musb works fine.

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

linux.config        39791    Bob Liu

Attachments

Outcomes