Page 2 of 2 FirstFirst 12
Results 21 to 28 of 28
  1. #21  
    Quote Originally Posted by jhoff80 View Post
    Honestly, I think the people who are comparing the different kernels are doing so because they genuinely don't understand the differences.

    To many, they don't get a single bit of how it works, but 800MHz is 800MHz to them. The rest is all gibberish.

    Now, a reasonable person might say if you don't understand the difference, you probably shouldn't be continuing past the first few lines anyway, but like that's ever stopped anyone before.
    Agreed. We're moving on from just the 800MHz top frequency (which every kernel can do, because they all use the same underlying OPP extension patch that unixPsycho back-ported from the TI omap 3440 mailing list over two month ago), and adding more functionality like the internal CPU temperature sensor, and perhaps in the future adding the capability to automatically decrease the speed of the kernel based on the readings from that sensor ...

    -- Rod
    WebOS Internals and Preware Founder and Developer
    You may wish to donate by Paypal to donations @ webos-internals.org if you find our work useful.
    All donations go back into development.
    www.webos-internals.org twitter.com/webosinternals facebook.com/webosinternals
  2.    #22  
    Quote Originally Posted by NuttyBunny View Post
    It's the app maybe... but it crashed again (took the Pre down)


    Locked on at 800000
    While on the loading screen, it kept jumping again and flickering.
    [ 403.960000] ##### DISPC_IRQSTATUS_GFXFIFOUNDERFLOW
    [ 403.960000] DISPLAY: ***** Sync Lost LCD (DISPC_IRQSTATUS 30e2)
    That suggests the developer may be doing something silly like delay loops based on CPU timing. It's a new one on me, I'll have to dig into this one. Same with other 3D apps?

    Quote Originally Posted by NuttyBunny View Post
    And just after it crashed:
    [ 537.410000] BUG: scheduling while atomic: swapper/0/0x40000105
    [ 537.410000]
    [ 537.410000] Pid: 0, comm: swapper
    That helps a lot. Something either ran out of memory or tried to interrupt the swapper process. I have a suspicion the game is coded to some specific hardware that I'm changing. Let me know what happens with other kernels!

    Thanks for the (very) useful bug reports.

    Cheers, Steve
  3.    #23  
    Quote Originally Posted by rwhitby View Post
    If Steve linked to the source patch, then that would be obvious

    Actually, I think it's all in the config, so just diff that against the stock palm config to see what is different.

    -- Rod
    The vast majority of the changes I've made are in the .config. I also hacked in the -mcpu/-mtune/-march into the Makefile, and patched the two prcm files I have mentioned (which *will* make it upstream, once I'm sure I'm fixing the right problem...!)

    Cheers, Steve
  4.    #24  
    Quote Originally Posted by caj2008 View Post
    Well see and please all stop comparing Steves kernels to me. This seems too personal. Its a phone.
    I would like to reiterate this point. Caj has done sterling work getting the initial 800MHz patches working, and has gone above and beyond offering the level of support he does; my place of work pays hundreds of thousands of dollars annually for the type of support that Caj has offered to the community for free.

    I would also like to reiterate that Caj is not involved in anything I am doing apart from making peripheral comments and recommendations so please do not hassle Caj about any of my kernels. I was utterly astounded that someone had the temerity to call Caj directly on his personal phone at 4:30am complaining about my kernel. That is, quite simply, beyond the pale, and whoever that was should be ashamed of themselves for being so inconsiderate and thoughtless.

    Quote Originally Posted by caj2008 View Post
    Lets focus on Steves development and when serious alpha testing starts (N=50 or more people) perhaps a spread sheet showing significant statistical differences between kernels doing identical tasks may be useful to help everyone. Lets let the data do the talking and not engage in speculation.
    My kernels are all experimental in nature and I seriously doubt will ever approach mainline. As all my changes are to GPL code anything worthwhile (I'm thinking of the fix for hang on resume from suspend in particular) will be punted up the tree into (I assume) the uber tree, and then if the code passes muster there it may be adopted as a patch for the stable kernel. That, however, would be Rod's call. I am extremely happy to no longer have to worry about userspace apps and interaction, development cycles, etc as I have effectively retired from that life and moved on to a new phase in my career.

    On a side note regarding that, having run code testing for a large modem company what you are referring to is beta testing rather than alpha testing; the sequence (at least for me writing the code) went like this, put simplistically:

    * Write code, flash the modem, check if it works as expected
    * Pass code for alpha testing in the lab to make sure it passes all test cases
    * Pass code to beta team for testing in the field
    * Release code to general public

    If the code fails at any point it goes back to step one. In the open source world, things operate rather differently; there is a philosophy of "release early, release often" which speeds up development time dramatically. As I do not have a lab for full testing I have a suite of test cases to make sure basic functionality is working for me, and then I put it out for alpha testing for anyone who can pass the IQ test to get the kernel to boot. I then take the feedback from that and use that to rework. Any fixes that genuinely work will get punted upstream for inclusion as kernel patches (and Rod has seen my repeated Makefile commits in my playing around with git - there is a reason I'm now at over 300 battery pulls on my phone). My kernels also deliberately make their very best effort to break every single rule of Rod's requirements for stable kernels; there is a reason for the warnings about fluffy pink unicorns et al!

    Quote Originally Posted by caj2008 View Post
    To be honest in 6 months all new phones will be 1Ghz or more and perhaps will have many powersaving and scaling functions built in. Perhaps there is alot we can learn much from this.
    Exactly. What makes the Pre different for me is how open it is as a phone; in comparison to other manufacturers it is almost totally transparent, and I can reconfigure the phone to work how *I* want it to work, not how some designer thinks I want it. It is my hope that other manufacturers will see the advantage of opening up their development process in a similar fashion, and open source / homebrew will become the norm, rather than the relative novelty it is now. I am also hoping that Palm can pull the Lazarus trick one more time and once again become the leader in the arena.

    Cheers, Steve
  5. #25  
    Just to report:

    I disabled logging altogether in the phone, stuck it with ondemand governor, 800Mhz min and max, and fired Asphalt 5. This time it worked great!

    Seems that PmLog is somewhat grabbing cpu cycles and moving the processor speed around.

    After I set the min freq to 125000 and tried to run the game again, it crashed (The game and took the Pre down with it)
  6. #26  
    Quote Originally Posted by NuttyBunny View Post
    Just to report:

    I disabled logging altogether in the phone, stuck it with ondemand governor, 800Mhz min and max, and fired Asphalt 5. This time it worked great!

    Seems that PmLog is somewhat grabbing cpu cycles and moving the processor speed around.

    After I set the min freq to 125000 and tried to run the game again, it crashed (The game and took the Pre down with it)
    I noticed when I applied the java mod disabled logging and patched the Pmlog file my Pre has been running great. Steve has helped me learn so much about my phone.
  7.    #27  
    Quote Originally Posted by mamouton View Post
    I noticed when I applied the java mod disabled logging and patched the Pmlog file my Pre has been running great.
    Feel free to generate a patch for the PmLog mod as well, if you like. I don't think people realise how much the logging slows down the system.

    Quote Originally Posted by mamouton View Post
    Steve has helped me learn so much about my phone.
    Knowledge is useless when kept to oneself

    Cheers, Steve
  8. #28  
    Any Update on the 06-May - kernels.sbromwich-kernel-pre_1.4.1-19 ?
Page 2 of 2 FirstFirst 12

Posting Permissions