Page 61 of 74 FirstFirst ... 1151565758596061626364656671 ... LastLast
Results 1,201 to 1,220 of 1472
Like Tree4Likes
  1.    #1201  
    Quote Originally Posted by NickVTPre View Post
    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?
    Only report problems with the latest version. -35 is old.

    Glorious day! HOOAH!
    Live free or DIE!
  2. #1202  
    I doctored my phone and erased all traces of homebrew including this kernel and swapped devices. My old device had keyboard problems so bad it was almost unbearable. After doctoring the problems were much less but not totally gone. As an experiment I put F102B back on and found more keyboard errors than without it. These could obviously be due to the clock rate, or there could be some tuning that is different between this Kernel and the stock one (UnixPsycho can comment on that).

    In any case, while this was available for test I used the OMG? setting for F102B on my phone with the camera and could not replicate my earlier problems. I think something other than just F102B with Medium VDEMAND was responsible - but again given the intermittent nature I didn't have a lot of time to test and validate fully - but preliminary info says - it worked fine on "OMG?" so I suspect the earlier problems are not repeatable.

    The other point I want to make is that the keyboard problems were progressive and worse before the doc than after - even with the F102B kernel. At one time I had the Virtual Keyboard installed and Keyboss etc. I wonder if a specific patch or patch removal interacted with the higher speed and/or Kernel files negatively.

    Oh and my drain using OMG? overnight was around 0.7% of battery per hour which is fantastic. With Medium I think it was running about double this and reporting close to 2% at times.
  3.    #1203  
    Quote Originally Posted by Unclevanya View Post
    I doctored my phone and erased all traces of homebrew including this kernel and swapped devices. My old device had keyboard problems so bad it was almost unbearable. After doctoring the problems were much less but not totally gone. As an experiment I put F102B back on and found more keyboard errors than without it. These could obviously be due to the clock rate, or there could be some tuning that is different between this Kernel and the stock one (UnixPsycho can comment on that).

    In any case, while this was available for test I used the OMG? setting for F102B on my phone with the camera and could not replicate my earlier problems. I think something other than just F102B with Medium VDEMAND was responsible - but again given the intermittent nature I didn't have a lot of time to test and validate fully - but preliminary info says - it worked fine on "OMG?" so I suspect the earlier problems are not repeatable.

    The other point I want to make is that the keyboard problems were progressive and worse before the doc than after - even with the F102B kernel. At one time I had the Virtual Keyboard installed and Keyboss etc. I wonder if a specific patch or patch removal interacted with the higher speed and/or Kernel files negatively.

    Oh and my drain using OMG? overnight was around 0.7% of battery per hour which is fantastic. With Medium I think it was running about double this and reporting close to 2% at times.
    So you had a flaky Pre? Did you get a new one?
    Live free or DIE!
  4. #1204  
    verizon pre plus webos 2.1 105 thunderchief runs great no problems I feel like the 500/1.005 gets better battery then uber kernel 250/1000!!!
  5. #1205  
    Quote Originally Posted by unixpsycho View Post
    So you had a flaky Pre? Did you get a new one?
    I think i may have flaky pre-(or aleast weak pre cause the blackbird wont work w/ 1.4.5) will randomly reboot when preware is trying to download feed updates, it stutters all the time overclocked(uberkernel) or not.

    currently running 2.1.0 on a sprint pre-

    ----------------
    Now playing: St. Germain - Pont des Arts
    via FoxyTunes
  6. #1206  
    Quote Originally Posted by unixpsycho View Post
    So you had a flaky Pre? Did you get a new one?
    A "like new" refurb. But to be clear - after doctoring I was able to use the F102B in the OMG? Vdemand setting without problems in the camera app. The problems I had were strictly keyboard as far as I can tell.
  7. #1207  
    Quote Originally Posted by retroblu View Post
    will randomly reboot when preware is trying to download feed updates, it stutters all the time overclocked(uberkernel) or not.
    Your voltages are too low. Bump them up at least two notches.


    M.
  8. #1208  
    Regarding the high load averages while screen is off, I found the problem for my phone at least. Remembering what unixpsycho said that checking the battery level can wake up the system, I deactivated the battery percentage patch from Tweaks. After a few tests with the screen off there was no high load.
  9. #1209  
    Quote Originally Posted by NickVTPre View Post
    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?
    Still having this issue with -41. What do you need from me to debug this?
  10.    #1210  
    Quote Originally Posted by NickVTPre View Post
    Still having this issue with -41. What do you need from me to debug this?
    I'm not seeing this using your voltages. I've tried every which way... disable vdemand, not disable vdemand before changing voltages.

    Can you try to change voltages by not disabling/enabling vdemand in the process?
    Live free or DIE!
  11. #1211  
    Thought I would throw this out here. I've been doing some testing related to memory consumption. My goal is to minimize freezing due to lack of memory since I've doctored to 2.1. What I've found is my memory consumption stays much lower if I use the performance governor instead of the screenstate-v2 governor.

    Some of you might want to test this. I have a VZW Pre+, compcache disabled, F105 perf governor set to 1ghz. Also, battery consumption doesn't seem any worse running a constant 1ghz vs screenstate.
  12.    #1212  
    Quote Originally Posted by peterlemonjello View Post
    Thought I would throw this out here. I've been doing some testing related to memory consumption. My goal is to minimize freezing due to lack of memory since I've doctored to 2.1. What I've found is my memory consumption stays much lower if I use the performance governor instead of the screenstate-v2 governor.

    Some of you might want to test this. I have a VZW Pre+, compcache disabled, F105 perf governor set to 1ghz. Also, battery consumption doesn't seem any worse running a constant 1ghz vs screenstate.
    Not being a smartass, but I'm dying to know how you can see this? Because there is no kmalloc being used in screenstate and the lower protected mode of memory reserved for drivers and such isnt much bigger than the "userspace" governor. Also to point out webOS 2.1.0 reserves more lower reserved memory for the kernel than 1.x in their attempt to resolve TMC and random reboots.
    Live free or DIE!
  13. #1213  
    Quote Originally Posted by peterlemonjello View Post
    Thought I would throw this out here. I've been doing some testing related to memory consumption. My goal is to minimize freezing due to lack of memory since I've doctored to 2.1. What I've found is my memory consumption stays much lower if I use the performance governor instead of the screenstate-v2 governor.

    Some of you might want to test this. I have a VZW Pre+, compcache disabled, F105 perf governor set to 1ghz. Also, battery consumption doesn't seem any worse running a constant 1ghz vs screenstate.
    I have the same, been running that way for a while now, a while as in at least a couple months. Been running performance 24/7, 1ghz w/ 700mhz battery scaleback freq, VDD1 @ 59, 54, 50, 42, & 36, VDD2 @ 40. Hasn't crashed as far as I can remember, except this one time I was listening to music and streaming internet radio for (literally) 7 hours straight. Battery consumption at idle with apps open can dip as low to -10mA, averages with screen off is around -70mA (apps open), compressed swap off, memory ~400-480.. F105..
    Neo Enyo 2.0 Twitter App: NOW AVAILABLE | WON REVIEW
    clearview - clear card app for HP TOUCHPAD
    Wild'n Video Poker - AVAILABLE FOR ALL WEBOS DEVICES! | follow for latest updates - @fxspec06

  14. #1214  
    Quote Originally Posted by unixpsycho View Post
    Not being a smartass, but I'm dying to know how you can see this? Because there is no kmalloc being used in screenstate and the lower protected mode of memory reserved for drivers and such isnt much bigger than the "userspace" governor. Also to point out webOS 2.1.0 reserves more lower reserved memory for the kernel than 1.x in their attempt to resolve TMC and random reboots.
    No problem, don't get me wrong I'm not saying this is a kernel or governor issue. I just wanted to share my experience to get more insight on what may or may not be happening and why.

    My approach isn't very scientific. The way I noticed this is by monitoring memory usage using Govnah. What I found was after normal usage over a period of time my memory consumption in Govnah was consistently lower when I was using the perf gov. I also noticed the memory consumption reached much lower levels with the perf gov. For instance I've never seen my memory consumption below 420 with screenstate enabled. Several times I've noticed my memory below 400 with the perf gov. The 10-15 second freezes which usually occur when reclaiming memory are less frequent too. I've been watching this for almost a week and I'm confident the difference is there. I'm just not sure why or if this is unique to me.
  15.    #1215  
    Hmm... Not sure what to make of the memory anomaly. Screenstate is a static module and always there, whether you have it selected or not, every time you push the power button it calls the screenstate function; it chooses to ignore it if it's not the running governor (except for AV8B kernel which has no screenstate driver). Also there is nothing in code to ask for memory, everything is static.

    This is one of those cases where your workload is a good candidate for the Race-to-Idle theory. That's why there is a slew of choices for governors.
    Live free or DIE!
  16. #1216  
    I installed F104a in my Pre 2. Seems pretty good and a little faster. A couple of questions though. When I first look in Govnah after the install, the profile is unknown. No big deal, but just wondered.

    There are a couple of screenstate profiles and the F104A Default. I select F104A default with no problem. After restart, the F104A Default is in profile. Under Advanced Settings, it is showing 500000 and 1100000 under Frequency Selection. However, the frequency graph on the main Govnah screen goes from 300 to 1.1, which is the default for the Pre 2. Not that big of a deal for me, just an observation.

    Also, the Compressed Swap is disabled under this Default F104A profile, which again, is okay for me, but I thought it was supposed to be enabled by default.
  17. #1217  
    @gapost

    The Pre 2 default profile is 1.0, not 1.1. The scaling is because of ondemandctl, which scales the frequency when max workload is not needed. F104a has other speed improvements to go along with the (relatively) small bump. I guess this is because (sort of like the SR71 for pre/pre+) there are stability issues and not every Pre 2 can run at 1.2 or 1.4.

    I might give it a test later on today to see how it is. How much of an improvent is it in your opinion?
    Last edited by fxspec06; 05/07/2011 at 07:19 AM. Reason: it's early
    Neo Enyo 2.0 Twitter App: NOW AVAILABLE | WON REVIEW
    clearview - clear card app for HP TOUCHPAD
    Wild'n Video Poker - AVAILABLE FOR ALL WEBOS DEVICES! | follow for latest updates - @fxspec06

  18. #1218  
    Quote Originally Posted by gapost View Post
    I installed F104a in my Pre 2. Seems pretty good and a little faster. A couple of questions though. When I first look in Govnah after the install, the profile is unknown. No big deal, but just wondered.

    There are a couple of screenstate profiles and the F104A Default. I select F104A default with no problem. After restart, the F104A Default is in profile. Under Advanced Settings, it is showing 500000 and 1100000 under Frequency Selection. However, the frequency graph on the main Govnah screen goes from 300 to 1.1, which is the default for the Pre 2. Not that big of a deal for me, just an observation.

    Also, the Compressed Swap is disabled under this Default F104A profile, which again, is okay for me, but I thought it was supposed to be enabled by default.
    Before you upgraded to F104a did you delete your old Govnah profiles? If not this may be the culprit. Try deleting all but the default F104a one and then disable it and restart the phone. Hopefully then you will see Compressed Swap and all the other stuff working as anticipated.

    NOTE: I'm on 1.4.5 on a Pre Plus I am extrapolating this solution from other posts I have read and from issues I saw switching kernels on 1.4.5 which were similar to what you describe.
  19. #1219  
    Thanks, fxspec06. Yeah, I know the default is the 1.0 with ..ctl. However, I was talking about he F104A Default profile which shows up when you install it. It also has two Screenstate profiles. It just seemed weird that the F104A Default profile, which says the minimum speed is 500000, is going down to 300000, which is the default setting for the Pre 2 ondemandctl governor. And also, the Default F104A profile did not enable compache, which I thought it would. If I want it, I guess I can enable it.

    And I think I do see a slight speed increase, but too early to tell about battery life.
  20. #1220  
    Quote Originally Posted by Unclevanya View Post
    Before you upgraded to F104a did you delete your old Govnah profiles? If not this may be the culprit. Try deleting all but the default F104a one and then disable it and restart the phone. Hopefully then you will see Compressed Swap and all the other stuff working as anticipated.

    NOTE: I'm on 1.4.5 on a Pre Plus I am extrapolating this solution from other posts I have read and from issues I saw switching kernels on 1.4.5 which were similar to what you describe.
    I had not installed any kernels before this one and I just installed Govnah before installing F104A, because I just got my Pre 2 this week. And yes, I restarted it. Btw, the speed IS showing at 1.1 at the top end.

Tags for this Thread

Posting Permissions