Page 35 of 36 FirstFirst ... 2530313233343536 LastLast
Results 681 to 700 of 703
  1. #681  
    I noticed that it hangs whne signing on to AIM (after a fresh restart...)

    So let your AIM fully sign on, then the patch should be okay after that

    **basically dont do anything for the first 3-5 minutes after a fresh reboot

    edit: looks like smart reflex is freezing the phone. I went ahead and made a 600mhz ONLY patch with no Smartreflex, working fine for 30 min now -no freezing
    Last edited by trim81; 12/29/2009 at 01:14 AM.
  2. as4life's Avatar
    Posts
    577 Posts
    Global Posts
    733 Global Posts
    #682  
    just installed vitvipers cpuscaling (Saved the most battery life). I will let you know how it works out
    My first theme - Mac OSX Theme Gallery or Pre Themer

    Learn how to run your pre at 800mhz Here!
  3. #683  
    Method from the OP still going strong in 1.3.5 for me.
  4. #684  
    Is anyone having trouble with the Smartflex 500 Powersave since the switch to 1.3.5?

    I wanted to add that I am not somebody who understands linux at all, but I really appreciate all the help that folks on these boards and site give to people like me. You guys make the experience of owning and using a Pre much better.
  5. as4life's Avatar
    Posts
    577 Posts
    Global Posts
    733 Global Posts
    #685  
    Just to update, vitvipers script still locks up my phone.
    My first theme - Mac OSX Theme Gallery or Pre Themer

    Learn how to run your pre at 800mhz Here!
  6. #686  
    I am currently running 1.3.5.1
    Vitvipers original script and cpuspeed mods lock up my phone. I have been playing with different -i values and -p values and processor maximum speeds in order to try and save battery life but still be stable.
    I am currently running this script line with his cpuspeed and it seems I've finally found something that works for my phone! yea! lol I've spent quite a bit of time trying to find a happy medium here...
    exec /opt/sbin/cpuspeed -i 5 -C -p 45 80 -m 125000 -M 550000 -a /sys/devices/platform/lcd.0/panel_state -A 10 -D -r
    When the screen is off it spends about 12% of the time in 250, and the rest in 125.
    no BSOD's, as was the problem before.
    no other problems either. I've gotten texts with the screen off as well. Going to run it for a day or so to see how stable it really is and let you guys know.
    WOOT!
  7. #687  
    scratch that... stable on ac power but crashes at boot screen on battery power.
    back to the drawing board... this is so frustrating.
  8. #688  
    hm. wierd. seems if I let it boot on ac power and then unplug it, it's stable...
    buggy freaking software!
    [edit] not stable after running for a few hours. trying bumping up the lower p value to 55, and maybe an i value of 2, but im thinking that's going to be too aggressive. wonder if anyone's still following this thread... haha
    Last edited by sublimexistence; 01/11/2010 at 01:47 AM.
  9. #689  
    Quote Originally Posted by trim81 View Post
    I definitely recommend the overclock file....it make the Pre lovable!
    what file is this exactly? where can i find a link to download? thx
    -------------------------------------------------
    Long time Palmer: Original Palm Pilot > Pilot III > Pilot V > Treo 300 > Treo 600 > Treo 755p > Pre
  10. #690  
    I have found (On my pre at least) anything over 500mhz works great on 1.3.5 but crashes the whole OS in 1.3.5.1. Which is a bummer, Running at 600mhz is so much nicer. I may doctor back down to 1.3.5 so I can run smartreflex and 600mhz again.
  11. #691  
    mmk. the original cpuspeed app from carl works wonderfully on my phone. no stuttering with a low i value, -p 45 90 does exactly what it's supposed to. goes to 600000 and runs fine when playing quake or doom and when sitting idle runs at 125000 with occasional jumps up to 250000. so i'm assuming my phone just doesnt like smartreflex.

    Thank you clipcarl!!!!!
    this is an ingenious workaround for the crappy kernel implementation!
    Last edited by sublimexistence; 01/12/2010 at 10:21 PM.
  12.    #692  
    Quote Originally Posted by sublimexistence View Post
    mmk. the original cpuspeed app from carl works wonderfully on my phone. no stuttering with a low i value, -p 45 90 does exactly what it's supposed to. goes to 600000 and runs fine when playing quake or doom and when sitting idle runs at 125000 with occasional jumps up to 250000. so i'm assuming my phone just doesnt like smartreflex.

    Thank you clipcarl!!!!!
    this is an ingenious workaround for the crappy kernel implementation!
    I'm glad it's working for you.

    I don't think there's anything wrong with the kernel implementation of scaling. I think the problem is the hardware.
  13. #693  
    Thanks for making this script Carl. Before I go ahead and install it, I have a few questions. I'm a Linux noob so please bare with me.

    So this is the default code in the cet-cpuspeed script:
    Code:
    exec /opt/sbin/cpuspeed -i 10 -p 60 80 -M 500000 -a /sys/devices/platform/lcd.0/panel_state -A 10 -C -D -r
    exec /opt/sbin/cpuspeed -m 250000 -M 500000 -a /sys/devices/platform/lcd.0/panel_state -A 10 -C -r
    I want to change the script so that when the screen's off, the CPU runs at 125Mhz, and when it's on, the CPU runs at 600Mhz. Nothing more; not even scaling during the off phase. Here are the questions I have so far:

    1. Why are there two execs that are slightly different?
    2. What does "-p 60 80" do?
    3. Will deleting the "-D" command keep the CPU at the min freq when off?
    4. I'm able to edit the script with Notepad on my desktop, but if I need to do some editing on the run, how do I do that using the Terminal app?

    Thanks everyone, this is a wonderful community!
    Sprint FrankenPre 2
    webOS 2.2.4
    Verizon donor
  14.    #694  
    Quote Originally Posted by Assimilator87 View Post
    Thanks for making this script Carl. Before I go ahead and install it, I have a few questions. I'm a Linux noob so please bare with me.

    ...
    If you are a Linux noob I do not recommend that you install this program. In fact, because many Pres can't run this without problems and because the battery savings are only marginal at best, I don't recommend that anyone run this. I myself don't even run it anymore. If you understand the risks and you really want to try this despite what I've said post again and I will answer your questions.
  15. #695  
    I actually went ahead and installed the script the day I posted, but I'd still like your feedback. I took out -D, changed -m to 125000, and changed both -M to 600000. The only issue I've run into is that the CPU sometimes runs at 500Mhz. This definitely crops up when the phone boots up while on AC power, but goes back to normal operation, as per the script, if I turn the screen off and on once. I think it might be running at 500Mhz in other situations as well, but I can't figure out when and using cat time_in_state is really tedious in Terminal cuz there's no copy/paste support.
    Sprint FrankenPre 2
    webOS 2.2.4
    Verizon donor
  16. #696  
    just tried it, it is running faster i can notice that, i will post results after testing my pre for about a week if it runs smooth if not i will post any problems peace out...
  17. #697  
    Does this work with the new 800MHz patch?
    16 Candles, The Breakfast Club SB, Friday SB, App Catalog Fix, Palm Pre/Pixi - USB Modem, TMC Workaround, SCRIM Changing OTF

    The fastest way to install Preware on your WebOS device.
    Put your device in Developer mode.
    From your PC download the Preware installer from http://get.preware.org
    Run the Preware installer while the WebOS device is connected with the USB cable to your PC.
    Vualla Preware is installed.]
  18. #698  
    uh,, If you read the instructions with the 800mhz patch then, No.
  19. #699  
    Quote Originally Posted by fr4nk1yn View Post
    uh,, If you read the instructions with the 800mhz patch then, No.
    Hey there, let me point you to this post I made. I was running the 800Mhz script when WebOS was at 1.4.0. I was using clipcarls script and it did work.

    http://forums.precentral.net/2345040-post1701.html

    Here are all the nice statistics that I compiled whilst using the 800Mhz kernel along with Clipcarls' ondemand cpu scaling script.
    Palm Pilot m100 --> Alltel Razr V3c --> Alltel HTC PPC6800(Mogul) --> Alltel HTC Touch Pro --> Alltel Rokr Z6M --> Alltel Palm Pre

    Speed at 70Mph using MyTether using Alltel Hybrid Rev A
    http://i30.tinypic.com/2iu733d.jpg
  20. #700  
    Quote Originally Posted by clipcarl View Post
    My solution is to use a carefully tuned CPU scaling userspace application and to tell it to only scale the CPU when the screen is off.
    Nice idea. I ran it on my 800MHz test kernel based off 1.4.1 from /bin/sh with:

    ./cpuspeed -m 250000 -M 800000 -a /sys/devices/platform/lcd.0/panel_state -A 10 -C -r

    And it does what it says on the tin. You might want to put a check in for ondemand scaling and set it to userspace if so. Alternatively, perhaps have an option to check if ondemand is enabled and if so, use scaling_min_freq and scaling_max_freq and have an option to have different values for the minimum depending on whether the screen is on or off? I suspect that would save more battery power than running at a fixed speed constantly.

    The -m1250000 problem is, I think, due to the udelay problem mentioned in prcm_pwr.c in the TI errata notes. Ramping up the udelay from 10 to 40 (and adding udelay(1) between each step powering up each device) has allowed me to run ondemand with PREEMPT on the 1.4.1 kernel stably without (as many) hangs when resuming from suspend. Running with your code has the amusing side effect that resuming from suspend is very fast, but powering down to suspend fades extremely slowly - on the order of 2-3 seconds.

    Cheers, Steve

Posting Permissions