-
Notifications
You must be signed in to change notification settings - Fork 3
Sleep of Death 2.6.29 encore issues.
When sleeping, the encore dies. Sometimes it resets, sometimes it just refuses to wake up. (Analias is checking as to whether the USB being plugged in makes a difference in this.)
(This is with any kind of power logging turned on): ###Super-Slo-Mo SOD: this is a SOD
What the kernel crash looks like:
If you remove a driver (in the below example, I removed the "alarm" driver), you still get the error:
Our drivers/base/power/main.c is the same as omapzoom's
Note the final patch on 2009-22-02 --> the watchdog that creates the error that we're seeing. If a device takes longer than 3 seconds to power down it gives the error.
Edits to the Power Management stuff since are here
Change to 10 seconds and see if it goes away?
Analias - 02/13/11 : Done - No apparent change in behavior other than the time it takes for the reboot to occur when USB is plugged in at the time of sleep and the NC attempts to wake up. - Analias
Is it possible we are missing something when the NC resumes? From the command line prompt the system appears to be functional. All the applications that had been frozen are running. The wireless network is up and running (I can ping google.com). I see kernel messages for the sensors. Is there something in the init.rc files we forgot to do? Some write to /sys that we have neglected, or some service we didn't restart?
Analias - 02/13/11 : I noticed a difference in behavior when running the nook_kernel and if the USB is plugged in at the time the NC attempts to sleep. I have confirmed this through several reboots varying only if the USB was plugged in.
If the USB is plugged in at the time of sleep, the NC will panic and reboot when awoken. (see http://pastebin.com/DBBGy2R6)
If the USB is NOT plugged in at the time of sleep, the NC will suspend, but become non-responsive. If the USB is then plugged in, the host will see the NC and ADB will be able to bring up a shell. The logs show a "successful" restart, but there is no apparent physical change in status.
(see http://pastebin.com/PC7tG0u5)
Note that the resume and the network startup happen before the message for android_usb gadget. This suggests to me that pressing the power button or the home button actually caused the NC to resume, and not the plugging in of the USB or starting of a shell with ADB.