Page 1 of 2 12 LastLast
Results 1 to 20 of 23
  1.    #1  
    My Sprint Pre(-) meta-doctored to webOS 2.1 is sporadically using all available memory and swap, as shown in Govnah. I'm using Uber-Kernel with 16 MB compcache enabled. Memory progresses up to 236 MB, and the swap steadily increases to 103 MB. This usually occurs within just a few minutes after a complete device restart. That's when the device becomes completely unresponsive. The touchscreen no longer responds and even the keyboard backlight dims and shuts off. I do have Mode Switcher running in the background and some patches via Preware, but nothing else at the time of the hangups. The JSTop application does not show anything unusual.

    I usually have to restart the whole device via battery pull anywhere between 3 and 6, with the same problem happening every time, until it decides to boot properly. When it does decide to boot properly, the same problem does happen, but for apparently no reason both memory values in Govnah will drop drastically and then the device will continue to operate normally. Quite strange.

    I can connect it to USB and get a terminal started for command line access during the memory increase. So, I'm wondering what the best way is to determine which application or service is chewing up all the memory so I can get rid of it. What would be the best Linux commands to run to figure that out?
    Last edited by SilvrDrgn; 08/22/2011 at 05:02 AM. Reason: Updated description
  2.    #2  
    (bump) Anyone?
  3.    #3  
    Never mind. I finally had some time to do some digging. Wrote up two scripts and put them directly on my Palm Pre to run in Terminus. First script uses the "pmap -x" command, some text massaging commands like sed and awk, and prints out the top five processes using the most memory along with their memory kilobyte amounts. Second script uses the first script to print out the actual top five process lines from the "ps" list. These should help me track down the issue.
  4. #4  
    Please keep us posted with your findings.
  5.    #5  
    This morning the issue was happening again, but I was still able to connect my Pre to my PC via USB and get a terminal going with novaterm. Surprisingly, the terminal is very responsive to commands while the webOS screen UI is very laggy or not responsive at all.

    The scripts I wrote provided information that two LunaSysMgr processes were using a combined total of over 300 MB of memory (RAM + compcache swap). A third process, called WebAppMgr, was not using nearly as much memory, but it was using 85+% of the CPU according to the "top" utility. There were some other processes popping in and out of the top position in the top utility list. I restarted Luna from the command line using these commands:

    initctl stop LunaSysMgr
    initctl start LunaSysMgr

    After Luna restarted, my entire Pre including the screen UI was back to normal. As I look at the process list in my Pre now, there is no WebAppMgr process running at all.

    Does anyone know what the WebAppMgr process is for, or what it's supposed to be doing? Why does it not run all the time, and/or why does it start up at all? With the above in mind, any ideas as to what's going haywire with my Pre?
    Last edited by SilvrDrgn; 08/23/2011 at 07:57 AM.
  6.    #6  
    I just had to restart my Sprint Pre, and the same issue happened again. WebAppMgr was in there again, but an unusually high CPU usage suspect in the process list is:

    com.palm.service.backup.jsjsjs /$usr$/$share$/$ls2$

    It seems to jive with the fact that this issue usually happens overnight and I notice it when I wake up in the morning. Usually the standard Palm Profile backup is happening overnight.

    Again, I did the stop and start of LunaSysMgr as in my previous post, and the Pre is back to normal again and fully functional. Wish I could figure out what's going on with this crazy thing.
  7.    #7  
    Well, locked up completely this morning. Could not get anything to respond, not even a novaterm session. Ended up pulling the battery. Put it back in and restarted. While restarting, the memory issue started happening again (seen in Govnah), and I started a novaterm session at the same time. This time around, the "top" command displayed "rvice.backup.jsjsjs&$quot$; $as$ $the$ $top$ $process$.

    Prior to the device locking up again, I just went ahead and restarted LunaSysMgr with the commands above. It took quite a bit longer than normal, but after it did I opened up the standard "Backup" application. It displayed that the last backup was 5:12 AM this morning, which is right after I did the battery pull and reinsert. Whether the backup was actually successful or not, I do not know. It sure seems like this issue is related to when the backup automatically runs. I have not had a problem running it manually via the "Backup Now" button in the application.

    So, I decided to take a small risk and shut off the standard Backup application via setting its slider to "Off" and tapping the "Shut off and erase backup data" button when that popped up. Will wait and see what happens overnight and report back tomorrow.
  8. #8  
    Hi there,

    I have the same issue since 1-2 weeks (Palm Pre(-) meta-doctored to webOS 2.1, o2 germany with UberKernel (every profile) as well as the standard kernel and currently the Starfighter 104a testing feed kernel (which is, according to some posts in the forums better than UberKernel (i.e. relating battery life)).

    And it's getting worse: The phone is only usable in a window of 3-5 minutes after right after reboot. Then, I have to take out the battery in order to reboot the phone.

    Now i disabled, as proposed above, the backup functionality: And it seems to work for now. I'll observe it.
  9.    #9  
    @ttgweizen, yes, I concur with your 3-5 minutes of operation after a reboot window assessment. I get that same type of symptom here.

    Got up this morning and checked my Pre(-). All is well. With the Backup application in a turned OFF state overnight, no lockup occurred and my device is functioning normally. Also, I was mistaken in thinking that the backup would run fine manually. I tested this by turning it back on this morning, and then tapping the "Backup Now" button. Govnah immediately started showing steadily increasing memory usage up to 236 MB RAM, and then the swap started increasing as well. The device was very sluggish to operate while it was doing this. Then, as before, when the swap hit 103 MB, the device UI and keyboard became completely unusable, and this time around I could not even get a reliable novaterm session to start up. I ended up pulling the battery.

    Upon battery replacement and restart, the same symptoms start happening again as before. During the period while the memory usage was increasing, I started up a novaterm session. The "top" utility appears to cut off the beginning and/or the end of various processes in the list, but it was again showing "rvice.backup.jsjsjs&$quot$; $on$ $the$ $top$ $of$ $the$ $list$ $for$ $both$ $CPU$ $and$ $memory$ $usage$. $Quitting$ $out$ $of$ $the$ $top$ $utility$ $and$ $doing$ $a$ $grep$ $of$ $the$ $process$ $list$ $for$ &$quot$;$back$&$quot$; $produced$ &$quot$;$com$.$palm$.$service$.$backup$.$js$ /$usr$/$share$/$ls2$&$quot$; $as$ $in$ $one$ $of$ $my$ $previous$ $posts$ $above$.

    I decided to try something different. I did a kill on the PID of the "com.palm.service.backup.jsjsjs /$usr$/$share$/$ls2$&$quot$; $process$ $in$ $novaterm$. $Immediately$ $after$ $I$ $did$ $that$, $the$ $process$ $disappeared$ $and$ $the$ $RAM$ $usage$ $in$ $Govnah$ $went$ $from$ $236$ $MB$ $down$ $to$ $181$ $MB$. $The$ $swap$ $usage$ $stayed$ $the$ $same$, $which$ $I$ $thought$ $was$ $a$ $bit$ $unusual$. $After$ $the$ $backup$ $process$ $kill$, $my$ $Pre$(-) $remained$ $completely$ $usable$ $and$ $normal$.

    So, this issue is definitely related to the procedures of the standard "Backup" application. I have a feeling that it's related to this article on the webOSroundup site -

    HP Cracks Down on Devices with Unofficially Supported webOS Versions

    With that, is there a homebrew workaround or another way to fix this issue with the backups that @ttgweizen and I are having??
  10.    #10  
    (bump) Anyone? Suggestions? Thanks!
  11. #11  
    You guys are a couple months late to the game.

    WebOS 2 Upgrade Pre Minus - WebOS Internals

    Bottom Line: WebOS 2.1 was optimized for 512mb of ram.

    These tweaks detailed in the wiki will help ease the lockups.
  12.    #12  
    I've been running webOS 2.1 on my Sprint Pre(-) for months. Only recently did my backup problems start happening. I probably crossed space usage threshold of some sort, and am now simply running out of space for the backup to be able to run. Most likely the 100 MB swap space mentioned at link you provided is my main issue. I'm going to do the Kernel, System Control patch for RAM, and the USB drive operations to increase the swap space to 512MB and disable compcache, but leave everything else I have the same and give that a try first. If I need to do anything else, then I'll look at implementing the other stuff. My main purpose is to get the backups working again because I'm going to need that for getting my configuration over to a Verizon Pre 2. Thanks for the link!
    Last edited by SilvrDrgn; 08/27/2011 at 08:19 AM.
  13.    #13  
    OK, had a chance to get this done. Good news - it worked! I'm sure the disabling of compcache and the increase of /dev/store swap to 512MB was the key. Backup procedure works fine now! (Swap was between 160 and 185 MB while backup was running. It did go back down quite a bit when finished.) Thanks a lot for the help!!!
  14. #14  
    np, glad everything is better now.

    I am in the middle of creating a script that runs in Mode Switcher and completely flushes the swap every 20 minutes.

    Ill keep up posted.
  15.    #15  
    How's that script working for you?
  16. #16  
    Great so far...just getting it ready for public use.
  17.    #17  
    @rmausser, good to hear!! Is there a webOS Internals wiki page similar to the "WebOS 2 Upgrade Pre Minus - WebOS Internals", but for the Verizon Pre 2? Or doesn't it need any help like that?
  18.    #18  
    I went ahead and increased the /dev/store swap space on my Verizon Pre 2 to avoid any potential issues. Suppose I need anything else other than that?
  19.    #19  
    Since no one has said anything else, I assume nothing else is needed for my Pre 2. Please chime in if you have an opinion. Thanks!
  20. #20  
    You guys are not alone! I've been experiencing this on my Pre 2 which has 512 mb physical memory. Technically it's a Verizon Pre 2 moved on to Sprint. I don't know what it is about the backup process that is causing MAJOR memory usage.

    There's another thread for this but actually on HP's forums. HP has responded and are asking someone with UNMODIFIED software to send them logs (they've posted instructions)!

    Backup causing Memory Critical error - Support Community

    Is there anyone out there with unmodified software that can help? Or have you guys found anything further to fix this yourselves?
Page 1 of 2 12 LastLast

Posting Permissions