Re: [SHR] Suspend / Resume speed
On Fri, 2009-02-27 at 17:20 +0900, W.Kenworthy wrote: > On Thu, 2009-02-26 at 22:31 +0100, Florian Hackenberger wrote: > > On Thursday 26 February 2009 18:08:54 Marco Trevisan (Treviño) wrote: > > > Check your uboot commandline loglevel value... It highly impacts on the > > > suspend/resume time. I've set it to 3 (but some time ago was set by the > > > system to 8, and I had to wait more than 6-7 seconds to wake the phone, > > > while it generally takes just 1-2 secs). > > > > Thanks, that solved it! I documented this fact in the FAQ: > > http://wiki.openmoko.org/wiki/FAQ#Why_is_resuming_from_suspend_so_slow > > > > Cheers, > > Florian > > > This does make a huge difference! - wow! - I used to fail to answer > calls because they had almost rang out by the FR resumed. > > The test I just did had the ring almost coincident with the ring tone in > the calling phones hand piece! > > But ... how can I make it permanent? - I issue "saveenv" and it seems to > do so, but if I power off and reboot its gone :( > > BillK > eh - the last part was operator error - cant save to "nor"! BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Suspend / Resume speed
On Thu, 2009-02-26 at 22:31 +0100, Florian Hackenberger wrote: > On Thursday 26 February 2009 18:08:54 Marco Trevisan (Treviño) wrote: > > Check your uboot commandline loglevel value... It highly impacts on the > > suspend/resume time. I've set it to 3 (but some time ago was set by the > > system to 8, and I had to wait more than 6-7 seconds to wake the phone, > > while it generally takes just 1-2 secs). > > Thanks, that solved it! I documented this fact in the FAQ: > http://wiki.openmoko.org/wiki/FAQ#Why_is_resuming_from_suspend_so_slow > > Cheers, > Florian > This does make a huge difference! - wow! - I used to fail to answer calls because they had almost rang out by the FR resumed. The test I just did had the ring almost coincident with the ring tone in the calling phones hand piece! But ... how can I make it permanent? - I issue "saveenv" and it seems to do so, but if I power off and reboot its gone :( BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Suspend / Resume speed
Only part of the problem :( There is also firmware upgrade - since moko11 (tried ~1 week) I did not lose any calls/sms. I then moved to shr-unstable and its finally working almost like a phone BillK On Thu, 2009-02-26 at 17:50 -0500, Warren Baird wrote: > Interesting! > > Would this impact resume from suspend on an incoming phone call? The > reason I abandoned the 2008.X family was that I was missing 3/4 of my > incoming calls because by the time the phone unsuspended I had missed > the call... If this will fix it, maybe I can finally move off QtE... > > Warren > > > On Thu, Feb 26, 2009 at 4:31 PM, Florian Hackenberger > wrote: > On Thursday 26 February 2009 18:08:54 Marco Trevisan (Treviño) > wrote: > > Check your uboot commandline loglevel value... It highly > impacts on the > > suspend/resume time. I've set it to 3 (but some time ago was > set by the > > system to 8, and I had to wait more than 6-7 seconds to wake > the phone, > > while it generally takes just 1-2 secs). > > > Thanks, that solved it! I documented this fact in the FAQ: > http://wiki.openmoko.org/wiki/FAQ#Why_is_resuming_from_suspend_so_slow > > Cheers, >Florian > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Suspend / Resume speed
Interesting! Would this impact resume from suspend on an incoming phone call? The reason I abandoned the 2008.X family was that I was missing 3/4 of my incoming calls because by the time the phone unsuspended I had missed the call... If this will fix it, maybe I can finally move off QtE... Warren On Thu, Feb 26, 2009 at 4:31 PM, Florian Hackenberger < f.hackenber...@chello.at> wrote: > On Thursday 26 February 2009 18:08:54 Marco Trevisan (Treviño) wrote: > > Check your uboot commandline loglevel value... It highly impacts on the > > suspend/resume time. I've set it to 3 (but some time ago was set by the > > system to 8, and I had to wait more than 6-7 seconds to wake the phone, > > while it generally takes just 1-2 secs). > > Thanks, that solved it! I documented this fact in the FAQ: > http://wiki.openmoko.org/wiki/FAQ#Why_is_resuming_from_suspend_so_slow > > Cheers, > Florian > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Suspend / Resume speed
On Thursday 26 February 2009 18:08:54 Marco Trevisan (Treviño) wrote: > Check your uboot commandline loglevel value... It highly impacts on the > suspend/resume time. I've set it to 3 (but some time ago was set by the > system to 8, and I had to wait more than 6-7 seconds to wake the phone, > while it generally takes just 1-2 secs). Thanks, that solved it! I documented this fact in the FAQ: http://wiki.openmoko.org/wiki/FAQ#Why_is_resuming_from_suspend_so_slow Cheers, Florian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Suspend / Resume speed
On Thu, Feb 26, 2009 at 12:08 PM, "Marco Trevisan (Treviño)" wrote: > Florian Hackenberger wrote: >> I noticed that suspending / resuming on 2008.12 is quite fast compared >> to SHR. The difference which is most noticeable is that SHR switches to >> a virtual terminal before and right after suspending, as opposed to >> 2008.12 which resumes right into X. Is there a way to replicate this >> behaviour on SHR? I suspect that we could save at least a second of >> resume time, because printing and scrolling a few hundred lines of >> kernel log in addition to the mode switches takes a bit of time. > > Check your uboot commandline loglevel value... It highly impacts on the > suspend/resume time. I've set it to 3 (but some time ago was set by the > system to 8, and I had to wait more than 6-7 seconds to wake the phone, > while it generally takes just 1-2 secs). > > Those commands in the uBoot shell should do the work: > setenv bootargs roofstype=ext2 root=/dev/mmcblk0p2 console=tty0 > console=ttySAC2,115200 loglevel=3 > setenv bootargs_base rootfstype=jffs2 root=/dev/mtdblock6 > console=ttySAC2,115200 console=tty0 loglevel=3 Marco, I tried what you have above and it seems to work quite well. There is a small spelling mistake in the first command though: "roofstype" should be "rootfstype", correct? Also just to clarify, I almost missed it myself (caught it whilst doing a typo check), the first command is for a SD card bootloader, whereas the second command is for the internal flash? Wicked fast resume though, I like it. Regards, Cameron ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Suspend / Resume speed
Florian Hackenberger wrote: > I noticed that suspending / resuming on 2008.12 is quite fast compared > to SHR. The difference which is most noticeable is that SHR switches to > a virtual terminal before and right after suspending, as opposed to > 2008.12 which resumes right into X. Is there a way to replicate this > behaviour on SHR? I suspect that we could save at least a second of > resume time, because printing and scrolling a few hundred lines of > kernel log in addition to the mode switches takes a bit of time. Check your uboot commandline loglevel value... It highly impacts on the suspend/resume time. I've set it to 3 (but some time ago was set by the system to 8, and I had to wait more than 6-7 seconds to wake the phone, while it generally takes just 1-2 secs). Those commands in the uBoot shell should do the work: setenv bootargs roofstype=ext2 root=/dev/mmcblk0p2 console=tty0 console=ttySAC2,115200 loglevel=3 setenv bootargs_base rootfstype=jffs2 root=/dev/mtdblock6 console=ttySAC2,115200 console=tty0 loglevel=3 -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Suspend / Resume speed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Michael 'Mickey' Lauer wrote: | |>> I don't think that they simply disable the backlight. Resuming from SHR |>> unstable takes about 5-6 seconds (no incoming call), while 2008.12 resumes |>> under 3 seconds. While this is not a scientific measurement, 2008.12 surely |>> is a lot faster. Any other ideas what they do differently? |> No idea, sorry. I have never seen 2008.12. It's definitely not a problem |> in the base system, since FSO ms5.1 resolves in 1 second (admittedly, |> with Qi, with U-Boot it might be 2 seconds). |> | My SHR resumed in about 4s. (Running from internal flash, not SDcard.) | First, nothing happens. Then the console shows itself for a little | while. finally, graphichs take over and the screen is redrawn. | | 1s would surely be an improvement. If your kernel has the printk timestamping enabled, maybe the dmesg during suspend / resume has a hint if it's something on the kernel side. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmmlxoACgkQOjLpvpq7dMptXwCdH85IfZksSKJyDQ6u5Akk4T7p 3a0AnRwU+LRs9p2d2syTWBT88wZbvibq =GWNa -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Suspend / Resume speed
Michael 'Mickey' Lauer wrote: >> I don't think that they simply disable the backlight. Resuming from SHR >> unstable takes about 5-6 seconds (no incoming call), while 2008.12 resumes >> under 3 seconds. While this is not a scientific measurement, 2008.12 surely >> is a lot faster. Any other ideas what they do differently? > > No idea, sorry. I have never seen 2008.12. It's definitely not a problem > in the base system, since FSO ms5.1 resolves in 1 second (admittedly, > with Qi, with U-Boot it might be 2 seconds). > My SHR resumed in about 4s. (Running from internal flash, not SDcard.) First, nothing happens. Then the console shows itself for a little while. finally, graphichs take over and the screen is redrawn. 1s would surely be an improvement. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Suspend / Resume speed
> It'll just be different loglevel= or console= on kernel commandline > depending on which bootloader and where you're booting from. which for which and where to find information on the parameters? and btw: is there a way to do that to an already running system, sysfs or so? i never had any luck with changing uboot's cmd line. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Suspend / Resume speed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Are you booting from NAND or NOR flash? I know when I boot from NAND | flash I see a bunch of text scroll by on resume. I don't see that | when booted from NOR. I don't know why... Have you tried that? It'll just be different loglevel= or console= on kernel commandline depending on which bootloader and where you're booting from. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmmBSkACgkQOjLpvpq7dMoQAwCaAj4gYunzAQGaAT4mc2R7DmfO SPYAn1o0cBKB55DyKYYrUXIBM5qdwbWc =1n1k -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Suspend / Resume speed
Are you booting from NAND or NOR flash? I know when I boot from NAND flash I see a bunch of text scroll by on resume. I don't see that when booted from NOR. I don't know why... Have you tried that? -Steven On Mon, Feb 23, 2009 at 2:32 AM, Florian Hackenberger wrote: > I suspect that we could save at least a second of > resume time, because printing and scrolling a few hundred lines of > kernel log in addition to the mode switches takes a bit of time. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Suspend / Resume speed
Am Mittwoch, den 25.02.2009, 19:05 +0100 schrieb Florian Hackenberger: > On Monday 23 February 2009 12:08:10 Michael 'Mickey' Lauer wrote: > > Am Montag, den 23.02.2009, 09:32 +0100 schrieb Florian Hackenberger: > > > I noticed that suspending / resuming on 2008.12 is quite fast compared > > > to SHR. The difference which is most noticeable is that SHR switches to > > > a virtual terminal before and right after suspending, as opposed to > > > 2008.12 which resumes right into X. > > Chances are they just cover up by turning backlight off prior to doing > > real suspend and then wait until resume has happened before turning it > > on again. We're not doing this yet, since we had our share with > > suspend/resume problems in the past and only will do that once it proves > > 100% solid. > > I don't think that they simply disable the backlight. Resuming from SHR > unstable takes about 5-6 seconds (no incoming call), while 2008.12 resumes > under 3 seconds. While this is not a scientific measurement, 2008.12 surely > is a lot faster. Any other ideas what they do differently? No idea, sorry. I have never seen 2008.12. It's definitely not a problem in the base system, since FSO ms5.1 resolves in 1 second (admittedly, with Qi, with U-Boot it might be 2 seconds). > > > > Is there a way to replicate this > > > behaviour on SHR? I suspect that we could save at least a second > of > > > resume time, because printing and scrolling a few hundred lines of > > > kernel log in addition to the mode switches takes a bit of time. > > IIRC Garmin had a patch in their Navi sources that removes switching > the > > VT on suspend/resume, which gave a) a better user experience and b) > a > > small speedup. We should pick that up IMO. > > It should be easier to copy from 2008.12 shouldn't it? No, 2008.12 certainly has no kernel patches like that. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Suspend / Resume speed
On Monday 23 February 2009 12:08:10 Michael 'Mickey' Lauer wrote: > Am Montag, den 23.02.2009, 09:32 +0100 schrieb Florian Hackenberger: > > I noticed that suspending / resuming on 2008.12 is quite fast compared > > to SHR. The difference which is most noticeable is that SHR switches to > > a virtual terminal before and right after suspending, as opposed to > > 2008.12 which resumes right into X. > Chances are they just cover up by turning backlight off prior to doing > real suspend and then wait until resume has happened before turning it > on again. We're not doing this yet, since we had our share with > suspend/resume problems in the past and only will do that once it proves > 100% solid. I don't think that they simply disable the backlight. Resuming from SHR unstable takes about 5-6 seconds (no incoming call), while 2008.12 resumes under 3 seconds. While this is not a scientific measurement, 2008.12 surely is a lot faster. Any other ideas what they do differently? > > Is there a way to replicate this > > behaviour on SHR? I suspect that we could save at least a second of > > resume time, because printing and scrolling a few hundred lines of > > kernel log in addition to the mode switches takes a bit of time. > IIRC Garmin had a patch in their Navi sources that removes switching the > VT on suspend/resume, which gave a) a better user experience and b) a > small speedup. We should pick that up IMO. It should be easier to copy from 2008.12 shouldn't it? Cheers, Florian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Suspend / Resume speed
Am Montag, den 23.02.2009, 09:32 +0100 schrieb Florian Hackenberger: > I noticed that suspending / resuming on 2008.12 is quite fast compared > to SHR. The difference which is most noticeable is that SHR switches to > a virtual terminal before and right after suspending, as opposed to > 2008.12 which resumes right into X. Chances are they just cover up by turning backlight off prior to doing real suspend and then wait until resume has happened before turning it on again. We're not doing this yet, since we had our share with suspend/resume problems in the past and only will do that once it proves 100% solid. > Is there a way to replicate this > behaviour on SHR? I suspect that we could save at least a second of > resume time, because printing and scrolling a few hundred lines of > kernel log in addition to the mode switches takes a bit of time. IIRC Garmin had a patch in their Navi sources that removes switching the VT on suspend/resume, which gave a) a better user experience and b) a small speedup. We should pick that up IMO. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Suspend / Resume speed
Florian Hackenberger writes: > behaviour on SHR? I suspect that we could save at least a second of Are you sure? To me it seemed that 2008.12 just turned the backlight on only when you were already in X? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[SHR] Suspend / Resume speed
Hi! I noticed that suspending / resuming on 2008.12 is quite fast compared to SHR. The difference which is most noticeable is that SHR switches to a virtual terminal before and right after suspending, as opposed to 2008.12 which resumes right into X. Is there a way to replicate this behaviour on SHR? I suspect that we could save at least a second of resume time, because printing and scrolling a few hundred lines of kernel log in addition to the mode switches takes a bit of time. Cheers, Florian -- DI Florian Hackenberger flor...@hackenberger.at www.hackenberger.at ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community