Page 3 of 3 FirstFirst 123
Results 41 to 47 of 47
  1. #41  
    how ya doing today Jeff ? good i hope !!
    Here is a direct link to webOS Doc for all carriers
    P.S. if i have helped you and you are thankful please hit the thanks button to the right---->
  2. #42  
    Quote Originally Posted by crucian4 View Post
    Wish I saw this before updating to 1.4. I am seriously considering doctoring my phone back to 1.35.1 to request being a tester. Any plans for 1.4? Would love to be a tester if you plan to. The more people willing to test, that understand the risks, and won't complain the more progressive this effort would be. Caj would you consider me for testing?
    I have been enjoying 1.4 for a few days, but my *** is going back to 1.3.5 so I can finish the testing of the 720 and 800 probably tomorrow.

    So go for it!
    "I'm sorry your phone is smarter than you"
  3.    #43  
    Quote Originally Posted by caj2008 View Post
    550 and 600 thoughts

    I have known done hundreds of tests on OS1.4 and OS1.3.5.1 using the 600 MHz patch using two different Pre's. I installed the 600 MHz patch too soon after the OS1.4 update (needs 1-2 days to stabilize) and after I ran extreme extensive cpu tests. The combination of the two did in my Pre. I can assure you the 550 and 600 MHz patches are safe on all OS's if you allow your OS install to stabilize first (1-2 days without patch). Two other people bricked there Pre's but one installed the LunaSysMgr from the old update over the new (didnt uninstall patch before update) and the other also put his system under stress (nonequilibrium conditions). In my opinion, under equilibrium conditions (equilibrate for 1-2 days and make sure uninstall before update), the worst thing that can happen is a frozen screen which can be undone by my Pre Unbrick Procedure (signature thread 1)-if it has poor cpu build. To actually damage the cpu in my opinion requires more extreme measures which I have intentionally done. Hence, in my final opinion over time I have determined that these patches are not dangerous. I have now put 3 Pre's to its limits and only damaged one cpu (my fault). My current Pre has been running at 800 MHz for all programs for well over a week now with no visible signs of damage (passes all tests). Will report more on long term stability at 800 MHz in due course...
    thanks for the thoughts, and experience. I think the 600 is probably fine like you say (although palm's consistency with their hardware is lacking making it far from absolute) but I think the 800 can't really be declared safe until it's been running a whole year. I mean if a bunch of people run it fine for 3 months but then at 6 months their phones all die, was it safe? I think overclocking's real issue is the possibility of an early "death" and that's tough to test for when a year would be an "early" death.
  4. #44  
    Are you running the 800 patch on the 1.4 or 1.3.5? Only asking for curiosity, not to replicate
    "I'm sorry your phone is smarter than you"
  5.    #45  
    Quote Originally Posted by caj2008 View Post

    Today at 500 MHz, I loaded intentionally OS 1.4 the same way which produced the same launcher/freezing symptoms. The first symptom after installation of the apps is the launcher bar freezes and the page number can get truncated from >4 to 4 pages (one unintentional intermittent restart, semibricked state). I monitored the temp directly after installation (62C), cooled down the casing, turned on airplane mode, and the system went back to normal. I then installed the patch without issue. Unsurprisingly, it is heat doing the damage and in the initial 600 MHz patch, I didnt cool it down prior to installation of the 600 MHz patch (ran 1.4 doing cpu intensive functions after install) which is where my equilibrium theory comes from.
    This actually makes me think the 600mhz patch is NOT safe and here's why:

    If temp is the key factor here, you have to remember that the Pre, more than any other smart phone I've ever used, tends to run pretty hot under a lot of conditions. For one, when you charge it (especially on a touchstone) it gets quite hot. Would that mean every time you charge it, you'd better not use it with 600mhz? Also, I've had the pre get hot (to the touch) running on battery when doing some intensive stuff.

    I just think there's too much risk (given how hot it runs), UNLESS the patch could be modified to monitor for temp. and turn off the 600mhz (or at least alert the user) when it's too hot.

    (BTW, how do you monitor its temp?)
  6.    #46  
    Quote Originally Posted by caj2008 View Post
    I actually use the battery monitor app. Today I was a loaned a Pre (from a Sprint store manger ironically) which he claimed he froze (I reversed it via Dr) with cpu scaling app. We then loaded 1 Gb of apps upon fresh OS1.4 install but went slightly above protocol specs but not allowing the temp to go beyond 35-36C. He ran a few games (30-35C) and other apps for a few hours (I should have monitored exact time) and this did not freeze after install (was equilibrated on OS first). He is currently smoothly running at 600 MHz. I undertstated temperature for a be cautious. Performance is remarkably smooth. I have done enough tests now to know that if these conditions are followed, the worst thing that can happen is a reversible frozen screen (probably ~1% cases guestimate). If the Pre has been running a really long time and really feels warm (relatively), I would just allow it to cool for 10 min before proceeding with cpu intensive apps. This is the only additonal safeguard that should be monitored. I have done too many is ready. I am reopening my thread with new data soon...

    BTW-In soon to be release data from the 800 MHz script using the nonoptimized and optimized kernels (OS1.3.5.1), temperatures were generally below this range under diverse sets of conditions.
    Thanks. Is this the app you use?

    I don't see anything listed about temp. Where is it in the app (or is it a diff app)?
  7. #47  
    Not sure if you seen my extensive pre modding threads in the development section but got a quick question....has anyone actually checked the processor temps? ie actual temperature of the core directly? I have 8 Palm pre motherboards sitting here left that have no home yet except as backups for my main DIY UMPC. I have no problems running any specific testing requirements or ND agreement if you would like my help to run a test for simple raw data via a IR temp monitor fed into the serial port. I could setup a small confined enclosure jig(motherboard installed as normal but no backplate) to get it to actual real world conditions since the phone must be mostly apart. Can let a board run its full course un-interupted say running some sort of demo app or a game while the PC datalogs the temps from the core. The only issue of my test would be slight variation due to the stacked POP. I would be aiming at both the RAM and CPU.

    I figure at least we can know for certain what is failing. it could be something simple like onboard thermo fuses to prevent these things from happening.

    If theirs one thing I seem to be good at its killing boards left and right for fun and my own research.
Page 3 of 3 FirstFirst 123

Posting Permissions