Krypton
Tue Feb 06 18:51:00 CST 2007
Thank you once again for your reply.
I am actually developing, not trying to kill my own PDA ha.
Will look up the link you provided.
"voidcoder" wrote:
>
> Interesting, I thought IPSM is no longer used on
> PPC/WM devices. Here you can find some advanced
> registry flushing options:
>
>
http://msdn2.microsoft.com/en-us/library/ms885238.aspx
>
> Actually it doesn't matter what method you will
> use. The problem will popup anyway as far as your
> flash is slow. If not during the power down then
> at some point during the normal operation.
>
> Btw what are you doing exactly? Are you developing
> a WM design or just killing your own WM5 PDA?
> In the first case you can get much better answer
> through your WM support channel. I'm sure you don't
> have enough freedom choosing methods and components
> when developing WM5 design ...
>
>
>
> Krypton wrote:
> > Thank you for the info.
> >
> > Is there any way to ask the PM not to flush registry upon suspend?
> >
> > I removed the call by the PM (by commenting it out) and things still
> > seems to work. Hopefully the OS does flush frequently enough so that
> > only some registry changes are not registered in flash?
> >
> > "voidcoder" wrote:
> >
> >> P30 is too slow itself. For example, depending on the block
> >> size / parameter, block erase time may vary from 0.4 up to 4.0
> >> seconds ...
> >>
> >>
> >> Krypton wrote:
> >>> Hi,
> >>>
> >>> I found that the time is spent doing read, write and flush to flash.
> >>> I am using P30 with Intel IPSM.
> >>> Is this an inherent problem, the slowness of write and flush to flash
> >>> for this combination?
> >>>
> >>> Thanks.
> >>>
> >>> "voidcoder" wrote:
> >>>
> >>>> Normally you can track such a situation using kernel profiler,
> >>>> this may shed some light on where exactly it spends the time.
> >>>> However suspension is quite specific situation, not sure
> >>>> profiling may help you here.
> >>>>
> >>>> To the flash driver. I think flushing registry changes to the
> >>>> flash while suspending is one of the possible reasons for the
> >>>> slowness. You can try to track WriteSector() and EraseSector()
> >>>> callbacks in your flash driver. Just insert some debug output
> >>>> to see how often they are called and how long does it take to
> >>>> program/erase flash while suspending.
> >>>>
> >>>>
> >>>> Krypton wrote:
> >>>>> I am sorry I am not too sure what you meant by hard activity.
> >>>>> I am not clear abt which function calls will follow FileSystemPowerFunction.
> >>>>> This seems to be in coredll and I do not know eventually what flash driver
> >>>>> calls
> >>>>> are made. Do you know where I can get more information on this?
> >>>>>
> >>>>> Thanks.
> >>>>>
> >>>>> "voidcoder" wrote:
> >>>>>
> >>>>>> Perhaps it is flushing registry. Is there any hard
> >>>>>> activity in your flash driver during the call?
> >>>>>>
> >>>>>>
> >>>>>> Krypton wrote:
> >>>>>>> I am working on a slow suspend problem on my pda running WM5.0 on Intel
> >>>>>>> PXA270.
> >>>>>>> I noticed that the function call in the power manager
> >>>>>>> FileSystemPowerFunction(FSNOTIFY_POWER_OFF);
> >>>>>>> is taking very long to return.
> >>>>>>>
> >>>>>>> Does anyone has experience with this?
> >>>>>>>
> >>>>>>> Thanks.
>