Page 60 of 74 FirstFirst ... 1050555657585960616263646570 ... LastLast
Results 1,181 to 1,200 of 1472
Like Tree4Likes
  1. #1181  
    I've got some useful information now. Sconix checked my messages log right after my phone's screen was off and he discovered that the following code was repeating every 2 seconds.
    Code:
    {LunaSysMgrJS}: com.palm.systemui: UpdateClockEveryMinute Tue Apr 26 2011 21:48:53 GMT-0700 (PDT), almInitFramew$
    WLAN device IP address is 0xc0a80105
    Syncing filesystems ... skipped for target platform ... done.
    Freezing user space processes ... (elapsed 0.02 seconds) done.
    Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
    Suspending console(s)
    PWR_SleepDSP() returned 32768
    Suspending... WakeupReq=N Conn=Y PS_Mode=0 PS_State=0
    WLAN: Forcing FW into extended PS mode
    WLAN device IP address is 0xc0a80105
    WLAN: Driver received HS Config/Activate/Awake Confirm Resp from firmware - set bHostSleepConfigured $
    WLAN: Driver sending host HS_ACTIVATED - set HS_Activated (TRUE)
    WLAN: Host sleep activated
    Enabling WLAN as wakeup interrupt, PSState 3 bWakeupDevRequired 1 WakeupTries 0
    suspend_device(): -16
    Could not suspend device 3-0038: error -16
    Resuming... WakeupReq=Y Conn=Y PS_Mode=1 PS_State=3
    WLAN: Driver sending host HS_DEACTIVATED - set HS_Activated (FALSE)
    WLAN: Host sleep deactivated
    Invalid VDD1 OPP requested
    WLAN: Driver received HS Config Cancel Resp from firmware - set bHostSleepConfigured (FALSE)
    Some devices failed to suspend
    Restarting tasks ... done.
    Quote Originally Posted by Sconix
    ...you see log lines that keep repeating every 2 seconds. Your wifi is failing to go to sleep mode which causes the whole system to wakeup again and it even wakes up MS [Mode Switcher] to check wifi state since it sends the wifi connected trigger. So there is something preventing the wifi to go to sleep which keeps whole system wake.
    I have already checked that no apps are using the internet in the background. Could there be a problem with the Wi-Fi driver in F105 Harrier kernel?

    I'm using a Sprint Pre- with webOS 2.1 using Screenstate2 500/1005 and stock voltages.
  2. #1182  
    WiFi failure has been a common symptom of devices being clocked past their limit.

    -- Rod
  3. #1183  
    Quote Originally Posted by rwhitby View Post
    WiFi failure has been a common symptom of devices being clocked past their limit.

    -- Rod
    This helps explain why using mode switcher to turn off wifi when my screen is locked solves the load averages issue for me. Thanks, Rod.
  4. #1184  
    Quote Originally Posted by rwhitby View Post
    WiFi failure has been a common symptom of devices being clocked past their limit.

    -- Rod
    Thanks for your response Rod. I'll run my phone at 900MHz and report back if it fixes anything.
  5.    #1185  
    Turning off WiFi is not the end-all solution to load averages being high. I posted and have always gotten high load averages even with the stock kernel, also, may I add, i noticed this with my 1st Pre before even coming out with overclocking code?

    The WiFi driver is proprietary and we don't have source code for it. So all bugs should be sent to Palm or Marvell.

    Devices may fail to suspend if they are in use. WiFi failure is least due to the speed of the overclock, but the temp of the chipset. Check the F14 (or SR71 Pre2) threads for proof. The SDIO/MMC bus speeds are not overclocked, nor voltage increased.

    Simply checking for battery level and closing old TCP sockets wakes up the device from suspend (check BATTERY_FASTPATH and TCP_FASTPATH).

    So you may think nothing is running in the background, but there is plenty running in the background.
    Live free or DIE!
  6. #1186  
    Thanks for the info Unixpsycho. I apologize for pointing the finger so quickly at your kernels.
  7. #1187  
    Quote Originally Posted by gollyzila View Post
    I've got some useful information now. Sconix checked my messages log right after my phone's screen was off and he discovered that the following code was repeating every 2 seconds.
    Code:
    {LunaSysMgrJS}: com.palm.systemui: UpdateClockEveryMinute Tue Apr 26 2011 21:48:53 GMT-0700 (PDT), almInitFramew$
    WLAN device IP address is 0xc0a80105
    Syncing filesystems ... skipped for target platform ... done.
    Freezing user space processes ... (elapsed 0.02 seconds) done.
    Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
    Suspending console(s)
    PWR_SleepDSP() returned 32768
    Suspending... WakeupReq=N Conn=Y PS_Mode=0 PS_State=0
    WLAN: Forcing FW into extended PS mode
    WLAN device IP address is 0xc0a80105
    WLAN: Driver received HS Config/Activate/Awake Confirm Resp from firmware - set bHostSleepConfigured $
    WLAN: Driver sending host HS_ACTIVATED - set HS_Activated (TRUE)
    WLAN: Host sleep activated
    Enabling WLAN as wakeup interrupt, PSState 3 bWakeupDevRequired 1 WakeupTries 0
    suspend_device(): -16
    Could not suspend device 3-0038: error -16
    Resuming... WakeupReq=Y Conn=Y PS_Mode=1 PS_State=3
    WLAN: Driver sending host HS_DEACTIVATED - set HS_Activated (FALSE)
    WLAN: Host sleep deactivated
    Invalid VDD1 OPP requested
    WLAN: Driver received HS Config Cancel Resp from firmware - set bHostSleepConfigured (FALSE)
    Some devices failed to suspend
    Restarting tasks ... done.
    I have already checked that no apps are using the internet in the background. Could there be a problem with the Wi-Fi driver in F105 Harrier kernel?

    I'm using a Sprint Pre- with webOS 2.1 using Screenstate2 500/1005 and stock voltages.
    Sorry to interrupt... Could this just be because you have wifi enabled while sleeping? (you know, wifi preferences), have you checked this with a stock kernel? It says: "WLAN: Host sleep deactivated"
    Just remember: If I helped you, press the thanks button!

    Owner of: Pre Sprint, Pre Telcel, Pre Plus AT&T, Pre 2 Unlocked, Pixi Plus AT&T, and 2 TouchPads (my Pre3 was stolen so it won't appear again here).
    Needs: Veer (anyone?)
    Apps: Subnet Calculator, FreeCam, PhotoFun, NuttyPad (work in progress)
    HomeBrew: meta-doctor and Messaging Plugins collaborator
    Twitter: @cesarneg
  8. #1188  
    I do have it set to keep Wi-Fi on while the screen is off. I think there is a difference between turning Wi-Fi off and Wi-Fi going to sleep.
    I haven't checked this with a stock kernel.
  9.    #1189  
    If WiFi is left on for screen off then it will never go into suspend. It goes into low-power state and uses WOL to wake up. In fact, the kernel sets the wifi device as always ON during suspend activation:
    Code:
    twl_write(TWL4030_VIO_DEV_GRP,     TWL_DEV_GROUP_P3);
    twl_write(TWL4030_VIO_REMAP,       TWL_RES_SLEEP);
    Whereas most everything else gets:
    Code:
    twl_write(TWL4030_REGEN_DEV_GRP,    TWL_DEV_GROUP_P3);
    twl_write(TWL4030_REGEN_REMAP,      TWL_RES_OFF);
    Live free or DIE!
  10. #1190  
    Quote Originally Posted by unixpsycho View Post
    It should be in the feeds now.

    You can go back to older versions but it is a manual process.
    Index of /feeds/webos-kernels/testing/1.4.5/
    Quick Update. Before I applied this latest update to F102B I was humming along with the grunged VDEMAND version and it restarted without warning - it acted like a voltage too low situation the email app hung, there was a little color flash and then it started going dark. On that grunged version there was no way to spec LOW/MED/HIGH/OMG for the amount of demand so I'm not sure what level of lunacy it may have attempted.

    After the update to the latest F102B (1.4.5-175) I was able to replicate the camera lockup using MEDIUM VDEMAND - no other apps have given me any issue so far. I have lowered VDEMAND to LOW to see if I can determine if this is sufficient to stop the problem. Previous F102B uses worked with VDEMAND off but the testing was insufficient to prove to me conclusively that this eliminated the problems.

    Other observations: This release seems "snappier" than the past ones - when I open the phone the responsiveness is much faster - past versions seems a little sluggish when the first resumed from sleeping.

    Lastly - with VDEMAND set to LOW this seems to be burning through the battery faster than F102A did. I'm seeing an burn rate of nearly 10% per hour with Virtually Zero use (sitting idle unused with WiFi set to Sleep).

    EDIT - Is there a good way to verify what is running in the background via logs?
    Last edited by Unclevanya; 04/28/2011 at 12:34 PM.
  11.    #1191  
    Quote Originally Posted by Unclevanya View Post
    Quick Update. Before I applied this latest update to F102B I was humming along with the grunged VDEMAND version and it restarted without warning - it acted like a voltage too low situation the email app hung, there was a little color flash and then it started going dark. On that grunged version there was no way to spec LOW/MED/HIGH/OMG for the amount of demand so I'm not sure what level of lunacy it may have attempted.

    After the update to the latest F102B (1.4.5-175) I was able to replicate the camera lockup using MEDIUM VDEMAND - no other apps have given me any issue so far. I have lowered VDEMAND to LOW to see if I can determine if this is sufficient to stop the problem. Previous F102B uses worked with VDEMAND off but the testing was insufficient to prove to me conclusively that this eliminated the problems.

    Other observations: This release is "snappier" than the past ones - when I open the phone the responsiveness is much faster - past versions seems a little sluggish when the first resumed from sleeping.

    Lastly - with VDEMAND set to LOW this seems to be burning through the battery faster than F102A did. I'm seeing an burn rate of nearly 10% per hour with Virtually Zero use (sitting idle unused with WiFi set to Sleep).
    Try a battery pull, then test again. There's not much that changed from 1.4.5 build to 2.1. F102A is SSv1 so it doesnt do any voltage scaling. odd that you can get a repeated camera lockup. I might have to Doctor back to 1.4.5 to see this as a 1.4.5 kernel doesnt work well in 2.1.
    Live free or DIE!
  12. #1192  
    Quote Originally Posted by unixpsycho View Post
    Try a battery pull, then test again. There's not much that changed from 1.4.5 build to 2.1. F102A is SSv1 so it doesnt do any voltage scaling. odd that you can get a repeated camera lockup. I might have to Doctor back to 1.4.5 to see this as a 1.4.5 kernel doesnt work well in 2.1.
    Actually I have already done the battery pull - I had to change batteries due to the high drain. But I can't recall if I have tested since then. I'll keep testing with LOW and then if nothing happens I'll move back to MEDIUM and test again.

    I have a number of patches on my phone and one of these is the Improved Photo Naming one - but it hasn't seemed to cause problems before. I'm going to have to doctor today or tomorrow anyway (replacement device due to bad keyboard mojo) so maybe I can try with a more pristine device and see if it continues to give problems.

    The phone lockup is not immediate or certain; it takes a little while - basically I keep the camera app open take a few pics, then sleep the device and open and take some more pics and keep doing this at random intervals. SO far it has only stayed grayed out happend with VDEMAND On and set to MEDIUM or HIGH.

    Thanks again for looking at this. I know 1.4.5 isn't a priority these days.
  13. #1193  
    Quote Originally Posted by Unclevanya View Post
    Actually I have already done the battery pull - I had to change batteries due to the high drain. But I can't recall if I have tested since then. I'll keep testing with LOW and then if nothing happens I'll move back to MEDIUM and test again.

    I have a number of patches on my phone and one of these is the Improved Photo Naming one - but it hasn't seemed to cause problems before. I'm going to have to doctor today or tomorrow anyway (replacement device due to bad keyboard mojo) so maybe I can try with a more pristine device and see if it continues to give problems.

    The phone lockup is not immediate or certain; it takes a little while - basically I keep the camera app open take a few pics, then sleep the device and open and take some more pics and keep doing this at random intervals. SO far it has only stayed grayed out happend with VDEMAND On and set to MEDIUM or HIGH.

    Thanks again for looking at this. I know 1.4.5 isn't a priority these days.
    I've seen a similar lockup issue with the camera app when i had the GPS radio on...
  14.    #1194  
    I've heard of Geo tagging causing problems with the camera.
    Live free or DIE!
  15. #1195  
    Apologies if this has been stated somewhere already, but i haven't been able to find it.

    Does F104a bump the system frequency to 200mhz?

    What are the symptoms of a system frequency voltage that is too low? too high? (I presume the benefits are the same as cpu voltage: lower means less battery draw...)
  16. #1196  
    I just noticed there is a new F104A kernel in the feeds.
  17. #1197  
    Quote Originally Posted by unixpsycho View Post
    I've heard of Geo tagging causing problems with the camera.
    Geo tagging is turned off. But I have to tell you guys that I couldn't replicate this while sitting around the house the past couple of days. This was after doing a 2nd battery pull. I think conditions were slightly different in that the phone was not in active use in the same ways and wasn't spending any time in my pocket where it would obviously get hotter than sitting on my desk.

    So for now - let's call this one - unconfirmed. I was able to replicate it previously but that doesn't mean that something else wasn't a factor.
  18. #1198  
    Quote Originally Posted by NickVTPre View Post
    Apologies if this has been stated somewhere already, but i haven't been able to find it.

    Does F104a bump the system frequency to 200mhz?

    What are the symptoms of a system frequency voltage that is too low? too high? (I presume the benefits are the same as cpu voltage: lower means less battery draw...)
    OK. The latest F104A, or maybe just reinstalling the kernel, seems to have fixed my Govnah issue that showed my system voltage frequency as like 2GHZ (yes, GHZ). I see it is 166MHz. Any chance that F104a could get the 200MHZ bump?
  19.    #1199  
    Quote Originally Posted by NickVTPre View Post
    OK. The latest F104A, or maybe just reinstalling the kernel, seems to have fixed my Govnah issue that showed my system voltage frequency as like 2GHZ (yes, GHZ). I see it is 166MHz. Any chance that F104a could get the 200MHZ bump?
    Nope. F104 is the stepping stone to Uberkernel. Also the 200Mhz testing is inconclusive. Some phones cant run the full patchset, while others did.
    Live free or DIE!
  20. #1200  
    I was fiddling with voltages last night and experienced something odd.

    This is a Pre+ with 2.1 and F104a-35, Govnah 7.27.

    I had been using the Govnah SSv2 500/1100 profile and it was stable. I wanted to try and optimize my voltages a bit, and still use the "medium" vdemand scaling. So i turned off vdemand and started turning down the voltages to find out the crash spot. I was able to drop my voltages to 60 for 1100mhz and 30 for 500mhz with stable results.

    My understanding was a "medium" vdemand setting would scale the vsel down by 4 (from this post) during low loads, and by 2 during medium loads, and not at all at high loads.

    So, i set my 1100mhz voltage to 65 (knowing 60 was stable), and 500mhz voltage to 35 (with 30 being stable), then enabled vdemand and <crash> phone rebooted.

    What am i missing?

Tags for this Thread

Posting Permissions