You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
(4) |
2005 |
Jan
(10) |
Feb
|
Mar
(14) |
Apr
(8) |
May
(2) |
Jun
|
Jul
(1) |
Aug
(7) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(3) |
Dec
|
2007 |
Jan
(2) |
Feb
(2) |
Mar
(5) |
Apr
(12) |
May
(2) |
Jun
|
Jul
(10) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
(2) |
Dec
(4) |
2008 |
Jan
(2) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
(13) |
Oct
(6) |
Nov
(27) |
Dec
(37) |
2009 |
Jan
(13) |
Feb
(14) |
Mar
(11) |
Apr
(19) |
May
(41) |
Jun
(21) |
Jul
(29) |
Aug
(8) |
Sep
(2) |
Oct
|
Nov
|
Dec
(4) |
2010 |
Jan
(6) |
Feb
(5) |
Mar
(5) |
Apr
|
May
(2) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
From: <bao...@si...> - 2007-08-13 07:12:12
|
Cg0KJm5ic3A7IEFzIHRoZSB0aXRpbGUgLEkgd2FudCB0byBrbm93IGhvdyB0byBjaGFuZ2UgdGhl IHdhaXQgdGltZSBmb3IgdGhlIHdvcmtpbmcgc3RhdGUgdG8gZW50ZXIgRFBNIHF1aWNrYm9vdCBz dGF0ZSAuR2VuZXJhbGx5LHRoZSB0aW1lIGlzIGFib3V0IDYwIHNlY29uZHMuDQombmJzcDtzb21l IG9uZSBoZWxwIG1lID8NCiZuYnNwOw0KQmVzdCB3aXNoZXMgDQombmJzcDsgQWxleC5CYW8mbmJz cDsKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tCk1PVE9SQVpSIM+1wdC137iy1q7X96OsyKvQwlY4s6y088urxsHK1rv6 KCBodHRwOi8vZDEuc2luYS5jb20uY24vc2luYS9saW1lbmczL21haWxfemh1aXl1LzIwMDcvbWFp bF96aHVpeXVfMjAwNzA4MTMuaHRtbCApCgo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CteisuHQwsDLMkfD4rfR08rP5KOo IGh0dHA6Ly9tYWlsLnNpbmEuY29tLmNuL2Nob29zZU1vZGUuaHRtbCCjqQ== |
From: <bao...@si...> - 2007-08-13 06:50:04
|
Jm5ic3A7IEFzIHRoZSB0aXRpbGUgLEkgd2FudCB0byBrbm93IGhvdyB0byBjaGFuZ2UgdGhlIHdh aXQgdGltZSBmb3IgdGhlIHdvcmtpbmcgc3RhdGUgdG8gZW50ZXIgRFBNIHF1aWNrYm9vdCBzdGF0 ZSAuR2VuZXJhbGx5LHRoZSB0aW1lIGlzIGFib3V0IDYwIHNlY29uZHMuDQombmJzcDtzb21lIG9u ZSBoZWxwIG1lID8NCiZuYnNwOw0KQmVzdCB3aXNoZXMgDQombmJzcDsgQWxleC5CYW8mbmJzcDsK Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0KTU9UT1JBWlIgz7XB0LXfuLLWrtf3o6zIq9DCVjizrLTzy6vGwcrWu/ooIGh0 dHA6Ly9kMS5zaW5hLmNvbS5jbi9zaW5hL2xpbWVuZzMvbWFpbF96aHVpeXUvMjAwNy9tYWlsX3po dWl5dV8yMDA3MDgxMy5odG1sICkKCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K16Ky4dDCwMsyR8Pit9HTys/ko6ggaHR0 cDovL21haWwuc2luYS5jb20uY24vY2hvb3NlTW9kZS5odG1sIKOp |
From: Todd P. <tod...@gm...> - 2007-07-24 06:48:15
|
On 7/18/07, Patrick Bellasi <der...@gm...> wrote: > As there been any clever implementation of the OP selection algorithm? The original IBM developers wrote up an interesting usage in a paper, describing an MPEG4 decoder that begins calculation of the next frame at a low operating point but bumping to a high operating point if it appears the realtime deadline is in danger of being missed. http://www.research.ibm.com/arl/publications/papers/DPM%20IEEE%20SOC%2003.pdf -- Todd |
From: Todd P. <tod...@gm...> - 2007-07-20 07:03:21
|
On 7/18/07, Patrick Bellasi <der...@gm...> wrote: >... > 70% on C3 with an avg residency of 239ms, an avg long term residency of 44ms > and only 4 WPS!!!... it seem great... it seem... except for the estimate ACPI > power usage that is now alwasy over 35W... my fan start running fast and > never noising! > > I guess there's some issue related to hardware management. May be is the > graphics card (ATI X1600) power state? Hi, you should send this to the lin...@li... list, there's more folks that deal with Linux PM issues on x86 laptops there. -- Todd |
From: Patrick B. <der...@gm...> - 2007-07-18 22:32:23
|
Hi all! I' experimenting a quite strange behavior with my laptop, maybe someone could give me some clue! I'm running kernel 2.6.22.2 with all stuff enabled to match powertop requirements and satisfy powertop's tips. When KDE is running all is fine: about 90% on C3, 5ms avg residency and 150 wakeups per second (WPS). Laptop mode is running too. If I switch to battery the ACPI estimated consumption is of about 26W... no great but that's what I achieve by default just rebooting with the new kernel. The strange stuff happens when I do that experiment: in order to reduce even mode the WPS and so improve the avg residency on C3 I switch to a console and I stop all services/daemons and applications not needed. The situation is that: 70% on C3 with an avg residency of 239ms, an avg long term residency of 44ms and only 4 WPS!!!... it seem great... it seem... except for the estimate ACPI power usage that is now alwasy over 35W... my fan start running fast and never noising! I guess there's some issue related to hardware management. May be is the graphics card (ATI X1600) power state? When running KDE i slow it down to low voltage... but I suppose that when I switch to console stopping Xorg its configuration should not change: it isn't? Can any body give any clue? Thanks Regards Patrick -- <----------------------------------------------------------------------------------------------------------> DERKLING LRU 338214 (http://counter.li.org) "We have to do this only because Exchange is a moron." Windows 2000 source code (private\shell\ext\ftp\ftpdrop.cpp) <----------------------------------------------------------------------------------------------------------> Patrick Bellasi <derkling at users dot sourceforge dot net> PhD Student on Computer Science at Politecnico di Milano Contacts: - ICQ 344672588 - MSN derkling at yahoo dot it - Skype derkling Personal Sites: - Bookmarks http://del.icio.us/derkling - Bibliography http://www.bibsonomy.org/user/derkling - Music taste http://www.last.fm/user/derkling/ Privacy: - GnuPG 0x72ABC1EE (keyserver.linux.it) pub 1024D/72ABC1EE 2003-12-04 Patrick Bellasi Key fingerprint: 3958 7B5F 36EC D1F8 C752 9589 C3B7 FD49 72AB C1EE <----------------------------------------------------------------------------------------------------------> -- <----------------------------------------------------------------------------------------------------------> DERKLING LRU 338214 (http://counter.li.org) Coltiva Linux che tanto windows si pianta da solo. <----------------------------------------------------------------------------------------------------------> Patrick Bellasi <derkling at users dot sourceforge dot net> PhD Student on Computer Science at Politecnico di Milano Contacts: - Mobile +39 347 3153808 - Phone +39 02 236566942 - ICQ 344672588 - MSN derkling at yahoo dot it - Skype derkling Personal Sites: - Bookmarks http://del.icio.us/derkling - Bibliography http://www.bibsonomy.org/user/derkling - Music taste http://www.last.fm/user/derkling/ Privacy: - GnuPG 0x72ABC1EE (keyserver.linux.it) pub 1024D/72ABC1EE 2003-12-04 Patrick Bellasi Key fingerprint: 3958 7B5F 36EC D1F8 C752 9589 C3B7 FD49 72AB C1EE <----------------------------------------------------------------------------------------------------------> |
From: Patrick B. <der...@gm...> - 2007-07-18 09:02:18
|
The actual implementation of DynamicPower is missing proposal for a clever policy manager and even worst is based on a greedy in-class OP selection algorithm. I understand that both lacks are design choices responding to the principle to "keep policy out and only mechanisms in" wrt the kernel. As there been any proposal in the past about a policy manager implementation? Presently this algorithm simply always select the less energy requiring OP. Of course this is a greedy approach that not always produces better overall results, i.e. it doesn't take into consideration switching overheads and latencies. As there been any clever implementation of the OP selection algorithm? Regards, Patrick -- <----------------------------------------------------------------------------------------------------------> DERKLING LRU 338214 (http://counter.li.org) make linux | more > user-firendly <----------------------------------------------------------------------------------------------------------> Patrick Bellasi <derkling at users dot sourceforge dot net> PhD Student on Computer Science at Politecnico di Milano Contacts: - ICQ 344672588 - MSN derkling at yahoo dot it - Skype derkling Personal Sites: - Bookmarks http://del.icio.us/derkling - Bibliography http://www.bibsonomy.org/user/derkling - Music taste http://www.last.fm/user/derkling/ Privacy: - GnuPG 0x72ABC1EE (keyserver.linux.it) pub 1024D/72ABC1EE 2003-12-04 Patrick Bellasi Key fingerprint: 3958 7B5F 36EC D1F8 C752 9589 C3B7 FD49 72AB C1EE <----------------------------------------------------------------------------------------------------------> |
From: Patrick B. <der...@gm...> - 2007-07-18 08:55:34
|
> Sounds like a good feature: to the extent per-process power states are > useful, it really should be implemented per-thread. Fortunately, since linux implement thread as LWP, the dpmstate info embedded within the task_struct is available for threads too. Threads already inherit dpmstate from their thread leader... anyway the procfs DPM interface doesn't export that param for task but just for processes. The simple patch I've posted previously add that feature so that we find a dpmstate attrib even within proc task subdirs. > From what I've > seen of DPM implementations, the per-process power states haven't been > heavily used for whatever reason, possibly that assigning > power/performance tradeoffs to particular processes is an advanced > topic and most folks are primarily concerned with the basics. Me I'm just investigating on those issues.... and I confirm: it's not trivial. The main issue we are focusing is how to "understand" power/performances threadoff for each process. The idea up-to-now is to try infering that information by looking at how processes "use" OS services... Another issue is related to overhead compensation: how much frequently we could change OP without losing benefits of operating at the best OP for each task. > It would be interesting to see a usage of per-thread power states. Regards, Patrick -- <----------------------------------------------------------------------------------------------------------> DERKLING LRU 338214 (http://counter.li.org) make linux | more > user-firendly <----------------------------------------------------------------------------------------------------------> Patrick Bellasi <derkling at users dot sourceforge dot net> PhD Student on Computer Science at Politecnico di Milano Contacts: - ICQ 344672588 - MSN derkling at yahoo dot it - Skype derkling Personal Sites: - Bookmarks http://del.icio.us/derkling - Bibliography http://www.bibsonomy.org/user/derkling - Music taste http://www.last.fm/user/derkling/ Privacy: - GnuPG 0x72ABC1EE (keyserver.linux.it) pub 1024D/72ABC1EE 2003-12-04 Patrick Bellasi Key fingerprint: 3958 7B5F 36EC D1F8 C752 9589 C3B7 FD49 72AB C1EE <----------------------------------------------------------------------------------------------------------> |
From: Todd P. <tod...@gm...> - 2007-07-17 22:01:00
|
On 7/16/07, derkling ml <der...@gm...> wrote: > While doing some hacks on DynamicPower and I've notices that it miss support > for a thread-related dpmstate definition. > If I look within /proc/PID/task/TID I can't find a "dpmstate" query file, > and thus I'm unable to set this param for a single thread. > We could define only the dpmstate for a thread leader process and than all > spawned threads will inherit that value. > > It should be of interest to have such a feature: this will allow > intra-process optimizations. > Is there any reason for that implementation choice? > Do you think it should be possible and interesting to have a thread-specific > dpmstate definition. Sounds like a good feature: to the extent per-process power states are useful, it really should be implemented per-thread. From what I've seen of DPM implementations, the per-process power states haven't been heavily used for whatever reason, possibly that assigning power/performance tradeoffs to particular processes is an advanced topic and most folks are primarily concerned with the basics. It would be interesting to see a usage of per-thread power states. -- Todd |
From: derkling m. <der...@gm...> - 2007-07-16 10:07:57
|
This is the quite trivial patch to add thread-specific dpmstate setting using procfs Patrick --- linux-2.6.16.2-2.3/fs/proc/base.c 2007-07-06 10:18:14.000000000 +0200 +++ linux-2.6.16.2-derkling/fs/proc/base.c 2007-07-16 11:24: 58.000000000 +0200 @@ -169,6 +169,7 @@ #ifdef CONFIG_DPM PROC_TGID_DPM, + PROC_TID_DPM, #endif /* Add new entries before this */ @@ -270,6 +271,9 @@ #ifdef CONFIG_AUDITSYSCALL E(PROC_TID_LOGINUID, "loginuid", S_IFREG|S_IWUSR|S_IRUGO), #endif +#ifdef CONFIG_DPM + E(PROC_TID_DPM, "dpmstate", S_IFREG|S_IRUGO|S_IWUSR), +#endif {0,0,NULL,0} }; @@ -1845,6 +1849,7 @@ break; #endif #ifdef CONFIG_DPM + case PROC_TID_DPM: case PROC_TGID_DPM: inode->i_op = &proc_fd_inode_operations; inode->i_fop = &proc_dpm_operations; |
From: derkling m. <der...@gm...> - 2007-07-16 08:41:33
|
While doing some hacks on DynamicPower and I've notices that it miss support for a thread-related dpmstate definition. If I look within /proc/PID/task/TID I can't find a "dpmstate" query file, and thus I'm unable to set this param for a single thread. We could define only the dpmstate for a thread leader process and than all spawned threads will inherit that value. It should be of interest to have such a feature: this will allow intra-process optimizations. Is there any reason for that implementation choice? Do you think it should be possible and interesting to have a thread-specific dpmstate definition. Thanks for any clue. Patrick |
From: Todd P. <tod...@gm...> - 2007-07-08 05:45:19
|
On 7/2/07, Saru Addep <sar...@gm...> wrote: > Hi All, > > Does the DPM patch have hooks for DVFS on the ARM platform. Clocking and voltage controls are implemented according to the hardware clocks and voltage regulators present on a particular ARM-based chipset and board based on the chipset; these are not something specified by the ARM processor architecture. DPM patches support a couple of ARM SoCs shown on the patches page. -- Todd |
From: Saru A. <sar...@gm...> - 2007-07-02 18:55:27
|
Hi All, Does the DPM patch have hooks for DVFS on the ARM platform. If so which of the patches do I need to apply, since I have 2.6.14.2 running on my system. Thanks Saru |
From: Todd P. <tod...@gm...> - 2007-05-10 05:24:55
|
On 5/8/07, Manish RATHI <man...@st...> wrote: > Hi, > I am using boot from nfs configuration in .config. > When I goto sleep state (echo -n mem > /sys/power/state) then > Kswapper thread is not suspended hence linux PM framework doesn't goto desired state. > > If use (CONFIG_CMDLINE="root=/dev/ram0 console=ttyAMA1,115200n8 init=linuxrc") in .config then there is no kswapper thread in `ps` and system go into desired state. > > Looks there is requirement of appropriate signal handling in kswapper. > > Can any body give any clue? Questions on standard Linux power management, not on the DPM patches, to lin...@li... . Mention the kernel revision, exact error messages, etc. NFS root is not a common desktop/server configuration, and suspend to RAM often needs some tweaking to work properly. I don't know the most recent status of this. There may be a system thread that needs to handle the freeze signal, or specify the PF_NOFREEZE (or whatever it's called these days) flag. -- Todd |
From: Manish R. <man...@st...> - 2007-05-08 10:48:01
|
Hi, I am using boot from nfs configuration in .config. When I goto sleep state (echo -n mem > /sys/power/state) then=20 Kswapper thread is not suspended hence linux PM framework doesn't goto = desired state. If use (CONFIG_CMDLINE=3D"root=3D/dev/ram0 console=3DttyAMA1,115200n8 = init=3Dlinuxrc") in .config then there is no kswapper thread in `ps` = and system go into desired state. Looks there is requirement of appropriate signal handling in kswapper. Can any body give any clue? Thanks Regards Manish |
From: Todd P. <tod...@gm...> - 2007-04-30 07:22:29
|
On Wednesday 25 April 2007 05:31:35 Manish RATHI wrote: > Is there any plan to merge them in main stream kernel? There have been attempts to discuss the whole of DPM and to split out a piece of it for consideration on its own. Although the IBM research lab that spawned DPM is no longer involved, I imagine at least MontaVista (and maybe WindRiver) and possibly some embedded chipset vendors continue to hope for improvements in Linux support for embedded platforms along the lines of what DPM offers. I've gotten away from it myself as of late, so I'm not sure of the most recent status. Many of the previous objections had to do with the relatively complicated interfaces needed in the kernel to create PM information with multiple subfields, and to select policies by name instead of single-integer-valued CPU speeds, and so forth (meanwhile, support for the ACPI monstrosity continues unabated). There is also cpufreq, which is based on very different interfaces, but can be made to handle many similar situations. The DPM notion of a system "operating point" comprised of a number of power/performance-related hardware register values (or other more abstract values that cause hardware changes) met with some general approval on the lin...@li... list (which is the real place to discuss upstream PM improvements) and at the 2006 Linux PM Summit. But since then some objections were raised, and much of the momentum evaporated for various reasons. I see that Matthew Locke, one of the original DPM guys, is still involved in pushing for an expanded mechanism for general power parameters via his consulting company, NomadGS; there's a presentation at http://www.linuxdevices.com/files/article078/mlocke-elc2007-pm.ppt.pdf . This likely means there's a company in the embedded space funding efforts to improve this. There may be other DPM concepts that could find favor upstream in some form or another. The general ability for processes to express relative power/performance requirements that are evaluted within the absolute context of a "policy" that may be geared toward maximum performance or toward maximum battery life conservation could be one of them someday. Power-policy-aware idle loops could be another. It seems like a whole summit devoted to embedded PM could be in order, in which the focus stays on what chipset vendors feel is important for supporting their new, ever-more-complicated clocking and voltage scaling architectures, and on what makers of battery-powered mobile devices feel is needed to improve battery life. And make sure the desktop-oriented PM in-crowd buys into a reasonably concrete direction for changes that can be made to support these. It's tough work arguing for this stuff and reaching a consensus. -- Todd |
From: Patrick B. <der...@gm...> - 2007-04-26 09:03:43
|
Me also I'm interested on this topic. I'm working on porting DynamicPower to STM's Nomadik platform, it seem a promising framework and I personally think it's eligible to be merged to the main stream kernel. Regards Patrick On Wednesday 25 April 2007 05:31:35 Manish RATHI wrote: > Hi, > Why dpm proposed by montavista and ibm not merged to main stream kernel? > Is there any plan to merge them in main stream kernel? > > > Regards > Manish -- <----------------------------------------------------------------------------------------------------------> DERKLING LRU 338214 (http://counter.li.org) UNIX is an operating system, OS/2 is half an operating system, Windows is a shell, and DOS is a boot partition virus. <----------------------------------------------------------------------------------------------------------> Patrick Bellasi <derkling at users dot sourceforge dot net> PhD Student on Computer Science at Politecnico di Milano Contacts: - ICQ 344672588 - MSN derkling at yahoo dot it - Skype derkling Personal Sites: - Bookmarks http://del.icio.us/derkling - Bibliography http://www.bibsonomy.org/user/derkling - Music taste http://www.last.fm/user/derkling/ Privacy: - GnuPG 0x72ABC1EE (keyserver.linux.it) pub 1024D/72ABC1EE 2003-12-04 Patrick Bellasi Key fingerprint: 3958 7B5F 36EC D1F8 C752 9589 C3B7 FD49 72AB C1EE <----------------------------------------------------------------------------------------------------------> |
From: Manish R. <man...@st...> - 2007-04-25 03:31:52
|
Hi, Why dpm proposed by montavista and ibm not merged to main stream kernel? Is there any plan to merge them in main stream kernel? Regards Manish |
From: Manish R. <man...@st...> - 2007-04-24 05:23:16
|
Hi, Problem is solved now. I'd to use echo -n instad of echo Thanks Regards Manish -----Original Message----- From: dyn...@li... [mailto:dyn...@li...] On Behalf Of dyn...@li... Sent: Tuesday, April 24, 2007 12:50 AM To: dyn...@li... Subject: Dynamicpower-devel Digest, Vol 6, Issue 4 Send Dynamicpower-devel mailing list submissions to dyn...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/dynamicpower-devel or, via email, send a message with subject or body 'help' to dyn...@li... You can reach the person managing the list at dyn...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of Dynamicpower-devel digest..." Today's Topics: 1. Re: Problem in exit from enter_state() (Manish RATHI) ---------------------------------------------------------------------- Message: 1 Date: Mon, 23 Apr 2007 20:24:22 +0530 From: Manish RATHI <man...@st...> Subject: Re: [Dynamicpower-devel] Problem in exit from enter_state() To: <dyn...@li...> Cc: man...@st... Message-ID: <000001c785b7$4b75f700$7b2...@dl...> Content-Type: text/plain; charset="utf-8" Hi, I am not able to take individual device into sleep mode. I am doing Echo 1 > /sys/devices/mb:\c0/power/state Noting happens and prompt come immediately. When I cat wakeup nothing is shown. My device suspend func is not called. Can you give any clue? I am able to take system in sleep and then wakeup by /sys/power. Thanks Regards Manish ------------------------------ ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ------------------------------ _______________________________________________ Dynamicpower-devel mailing list Dyn...@li... https://lists.sourceforge.net/lists/listinfo/dynamicpower-devel End of Dynamicpower-devel Digest, Vol 6, Issue 4 ************************************************ |
From: Manish R. <man...@st...> - 2007-04-23 14:54:54
|
Hi, I am not able to take individual device into sleep mode. I am doing Echo 1 > /sys/devices/mb:\c0/power/state Noting happens and prompt come immediately. When I cat wakeup nothing is shown. My device suspend func is not called. Can you give any clue? I am able to take system in sleep and then wakeup by /sys/power. Thanks Regards Manish |
From: Todd P. <tod...@gm...> - 2007-04-10 18:11:35
|
Rm9yd2FyZGluZyBhIHF1ZXN0aW9uIG9uIFBYQTI3eCBEUE0gcGF0Y2ggdG8gdGhlIGRldmVsb3Bt ZW50IGxpc3Q7IEknbQpubyBsb25nZXIgbWFpbnRhaW5pbmcgdGhlc2UgYW5kIGhhdmUgZ290dGVu IGF3YXkgZnJvbSBYU2NhbGUgYW5kIExpbnV4CmFzIG9mIGxhdGUuLi4KCk9uIDQvMTAvMDcsIL/s vPbDoiA8ZG50bmNrZEBnbWFpbC5jb20+IHdyb3RlOgo+IEkgYW0gdHJ5aW5nIHRvIHVzZSB5b3Vy IFBYQTI3eCBEUE0gcGF0Y2guCj4KPiBPbiB0aGUgdHJpYWwsIG15IHN5c3RlbSBpcyBoYW5naW5n Lgo+Cj4gQWZ0ZXIgZGVidWdnaW5nIHRoYXQsIEkgZm91bmQgdGhhdCBQVkNSW1ZDU0FdIGJpdCBk b2VzIG5vdCBjaGFuZ2UgaW50byAwCj4gYWZ0ZXIgdm1fc2V0dm9sdGFnZSgpIGZ1bmN0aW9uIGV4 ZWN1dGVzLgo+Cj4gTWF5YmUsIGl0IHNlZW1zIHRoYXQgdm9sdGFnZS1jaGFuZ2Ugc2VxdWVuY2Ug ZG9lcyBub3QgY29tcGxldGUuCj4gSW4gcG93ZXJfY2hhbmdlX2NtZCgpLAo+Cj4gICAgICAgICBk YXRhQXJyYXlbMF0gPSAwOyAgICAgICAvKiAgICAgIENvbW1hbmQgMCAgICAgICAqLwo+ICAgICAg ICAgZGF0YUFycmF5WzFdID0gKERBQ1ZhbHVlICYgMHgwMDAwMDBGRik7IC8qICAgICAgZGF0YSBM U0IgICAgICAgICovCj4gICAgICAgICBkYXRhQXJyYXlbMl0gPSAoREFDVmFsdWUgJiAweDAwMDBG RjAwKSA+PiA4OyAgICAvKiAgICAgIGRhdGEgTVNCCj4gICAgKi8KPgo+Cj4gICAgICAgICBQVkNS ID0gMDsKPgo+ICAgICAgICAgUENGUiAmPSB+UENGUl9GVkM7Cj4gICAgICAgICBQVkNSICY9IDB4 RkZGRkYwN0Y7ICAgICAvKiAgICAgIG5vIGRlbGF5IGlzIG5lY2Vzc2FyeSAgICovCj4gICAgICAg ICBQVkNSICY9IDB4RkZGRkZGODA7ICAgICAvKiAgY2xlYXIgc2xhdmUgYWRkcmVzcyAgICAgICAg ICovCj4gICAgICAgICBQVkNSIHw9IDB4MjA7ICAgICAgICAgICAvKiAgICAgIHNldCBzbGF2ZSBh ZGRyZXNzICAgICAgICovCj4KPgo+IHdoYXQncyB0aGUgbWVhbmluZyBvZiAweDIwIChTbGF2ZSBB ZGRyZXNzKSBhbmQgQ29tbWFuZCAwID8KPiAodGhlIFBYQSBtYW51YWwgZG9lcyBub3QgbWVudGlv biBzcGVjaWZpYyBpbmZvcm1hdGlvbiBhYm91dCBhYm92ZSB0d28KPiBmYWN0b3JzKQo+Cj4gSSBo YXZlIHRyaWVkIHRvIGZpbmQgcmVsYXRlZCBpbmZvcm1hdGlvbiBvbiBQWEEyNzAgbWFudWFsLCBh bmQgdGhyb3VnaAo+IGdvb2dsaW5nLCBidXQgZmFpbGVkLgo+Cj4gQ291bGQgeW91IGhlbHAgbWUg cGxlYXNlcz8KPgo+IEJlc3QgcmVnYXJkcywKPiBXb28KClRoaXMgY29kZSBwcm9iYWJseSBvcmln aW5hdGVkIGZyb20gSW50ZWwgYW5kIG1heSBoYXZlIGJlZW4gbW9kaWZpZWQgYnkKTW9udGFWaXN0 YSwgc29tZXRpbWVzIHdpdGggaGVscCBmcm9tIEludGVsIGRldmVsb3BlcnMuICBJdCBkb2Vzbid0 Cmxvb2sgbGlrZSBvbmUgb2YgdGhlIHBhcnRzIEkgd29ya2VkIG9uLCBzbyBJIGRvbid0IGhhdmUg YW55IGZ1cnRoZXIKaW5mbyBvbiB0aGUgcmVnaXN0ZXJzIG90aGVyIHRoYW4gd2hhdCdzIGF2YWls YWJsZSBpbiB0aGUgZG9jcy4gIFRoZQp2b2x0YWdlIGNoYW5nZSBzZXF1ZW5jZSBpcyBvbmUgb2Yg dGhlIG1vcmUgbXlzdGVyaW91cyBhc3BlY3RzIG9mIHRoZQpTb0MsIEknbSBhZnJhaWQuICBUaGVy ZSBtYXkgYmUgZm9sa3Mgb24gdGhlIGxpc3Qgd2hvIGNhbiBwcm92aWRlIG1vcmUKZGV0YWlscy4g IEdvb2QgbHVjaywKCi0tIApUb2RkCg== |
From: Manish R. <man...@st...> - 2007-04-10 13:51:03
|
=20 To add more if I enable few prints at end of enter_state() [ system is = already woken up and console prints are coming there even in shell hang = case ] , then I get shell prompt again. Regards Manish -----Original Message----- From: Manish RATHI [mailto:man...@st...]=20 Sent: Tuesday, April 10, 2007 7:17 PM To: dyn...@li... Cc: man...@st... Subject: Problem in exit from enter_state() Hi, I enter into mem mode (theu /sys/power/state) and on exit enter_state() = end is hit but I don't get back shell prompt i.e. no control Back to = shell. All my uart & timer registers are same as previous. Timer interrupt is = hitting as well. Has anybody faced similar problem? Thanks Regards Manish |
From: Manish R. <man...@st...> - 2007-04-10 13:47:02
|
Hi, I enter into mem mode (theu /sys/power/state) and on exit enter_state() = end is hit but I don't get back shell prompt i.e. no control Back to = shell. All my uart & timer registers are same as previous. Timer interrupt is = hitting as well. Has anybody faced similar problem? Thanks Regards Manish |
From: Manish R. <man...@st...> - 2007-04-09 12:49:06
|
Hi. In my implementing power management, when I wakeup, my busybox thread is not scheduled after Exiting from linux power management framework. Because of that I am not getting any shell prompt. System is inside idle thread. All console prints entered in code after wakeup appears on console. If I add prints for printing each thread Name at end of linux power mgmt code( at end of enter_state() in kernel/power/main.c) then my prompt appears. Adding delay instead of print doesn't work. I entered in memstate thru sysfs (/sys/power/state). Pls note that timer & uart interrupts are behaving as expected. Has anybody faced similar problem of non scheduling? Thanks Regards Manish |
From: <tod...@gm...> - 2007-04-05 18:43:52
|
On Wed, 4 Apr 2007 7:29 am, Manish RATHI wrote: > During power management testing, After waking up from sleep (where I > save restore all mmu register ) , I am getting message "note: > busybox[186] exited with preempt_count 1"... For standard Linux PM questions not related to the DPM patches it's best to use the linux-arm-kernel list for ARM-specific issues or the linux-pm list for general PM issues. --todd |
From: Manish R. <man...@st...> - 2007-04-04 14:26:05
|
=20 Hi, During power management testing, After waking up from sleep (where I = save restore all mmu register ) , I am getting message "note: = busybox[186] exited with preempt_count 1" and there is no print/input on = console. This message comes possibly during execution of thaw_processes = (kernel/power/process.c) Every time wakeup is successful. However system sometimes hang with above message. Many times it passes. Sometimes I also get dump (Printed at end of mail). It looks data abort exception inside Undefine exception.=20 Can you give me any clue? Thanks Regards Manish Bad mode in data abort handler detected: mode UND_32 Internal error: Oops - bad mode: 0 [#1] Modules linked in: CPU: 0 PC is at vector_swi+0x4/0x8c LR is at 0xffff000c pc : [<c0021e64>] lr : [<ffff000c>] Not tainted sp : c93b7d34 ip : 00000000 fp : c93b7da4 r10: 00000000 r9 : c93b6000 r8 : fffffcc0 r7 : 00000000 r6 : 00000000 r5 : 00000001 r4 : 00000000 r3 : 00000000 r2 : c023528c r1 : c0008000 r0 : 00000000 Flags: nZCv IRQs off FIQs on Mode UND_32 Segment user Control: 5317F Table: 09734000 DAC: 00000015 Process busybox (pid: 182, stack limit =3D 0xc93b61a0) Stack: (0xc93b7d34 to 0xc93b8000) 7d20: 00000000 c0008000 = c023528c=20 7d40: 00000000 00000000 00000001 00000000 00000000 fffffcc0 c93b6000 = 00000000=20 7d60: c93b7da4 00000000 c93b7d34 ffff000c c0021e64 6000009b ffffffff = c93b6000=20 7d80: c93b7da4 c93b7d90 c0057eb0 c0056ea8 c93b7f14 000041ed c93b7df4 = c93b7da8=20 7da0: c009a758 c0057e68 c1b44005 00000310 c93b7ebc 0029ab98 00000003 = c1b44001=20 7dc0: c04152a0 c1b6ca58 c006e494 c93b6000 c93b7f14 c04152a0 c93aa418 = c1b44000=20 7de0: c93b6000 00000000 c93b7e64 c93b7df8 c009b704 c009a6b0 00000000 = c93aa418=20 7e00: c04152a0 80000013 00000004 c1b46048 00000310 00000001 00000000 = 00000000=20 7e20: c93b7f6c c93b7f48 c0087c88 c00432d4 c009a320 00000d42 00000180 = c1b4f980=20 7e40: c0418f20 c93b6000 ffffffe9 c93b7f14 00000001 c1b44000 c93b7e94 = c93b7e68=20 7e60: c009bc84 c009b688 c93b7e94 c93b7e78 c008b210 ffffff9c ffffffe9 = 00000210=20 7e80: c93b7f14 00000d42 c93b7eb4 c93b7e98 c009c7a8 c009b9b0 00000d41 = c93b7f14=20 7ea0: ffffff9c 00000004 c93b7f04 c93b7eb8 c009ca10 c009c764 00000d42 = 00000180=20 7ec0: 00000180 0000000a 00000004 c18ab770 c18ab774 c18ab778 c18ab764 = 00000d41=20 7ee0: c93b7f14 ffffff9c 00000004 c1b44000 c93b6000 00000000 c93b7f6c = c93b7f08=20 7f00: c0088030 c009c990 c93b7f14 c02a90c0 00000001 c1b6ca58 c04152a0 = 80000013=20 7f20: 00000004 c1b46048 00000314 00000001 00000000 00000000 c93b7f6c = c93b7f48=20 7f40: c0087c88 c00432d4 c009a320 00000d42 00000180 c1b4f980 00000d41 = 00000180=20 7f60: c93b7f94 c93b7f70 c00880a4 c0088014 00000000 00000d41 00000000 = 00000d41=20 7f80: 00000005 c0021f48 c93b7fa4 c93b7f98 c0088160 c0088060 00000000 = c93b7fa8=20 7fa0: c0021da0 c008814c 00000d41 00000000 000afad4 00000d41 00000180 = 00000001=20 7fc0: 00000d41 00000000 00000d41 00000005 000afad4 000af868 00000003 = bea883c4=20 7fe0: 000c1a40 bea87f08 0008921c 401bb32c 40000010 000afad4 cccccccc = cccccccc=20 Backtrace:=20 [<c0057e58>] (in_group_p+0x0/0x9c) from [<c009a758>] = (__link_path_walk+0xb8/0xfd8) r5 =3D 000041ED r4 =3D C93B7F14=20 [<c009a6a0>] (__link_path_walk+0x0/0xfd8) from [<c009b704>] = (link_path_walk+0x8c/0x164) [<c009b678>] (link_path_walk+0x0/0x164) from [<c009bc84>] = (do_path_lookup+0x2e4/0x330) r8 =3D C1B44000 r7 =3D 00000001 r6 =3D C93B7F14 r5 =3D FFFFFFE9 r4 =3D C93B6000=20 [<c009b9a0>] (do_path_lookup+0x0/0x330) from [<c009c7a8>] = (__path_lookup_intent_open+0x54/0x94) r8 =3D 00000D42 r7 =3D C93B7F14 r6 =3D 00000210 r5 =3D FFFFFFE9 r4 =3D FFFFFF9C=20 [<c009c754>] (__path_lookup_intent_open+0x0/0x94) from [<c009ca10>] = (open_namei+0x90/0x64c) r7 =3D 00000004 r6 =3D FFFFFF9C r5 =3D C93B7F14 r4 =3D 00000D41 [<c009c980>] (open_namei+0x0/0x64c) from [<c0088030>] = (do_filp_open+0x2c/0x4c) [<c0088004>] (do_filp_open+0x0/0x4c) from [<c00880a4>] = (do_sys_open+0x54/0xd8) r5 =3D 00000180 r4 =3D 00000D41=20 [<c0088050>] (do_sys_open+0x0/0xd8) from [<c0088160>] = (sys_open+0x24/0x28) r8 =3D C0021F48 r7 =3D 00000005 r6 =3D 00000D41 r5 =3D 00000000 r4 =3D 00000D41=20 [<c008813c>] (sys_open+0x0/0x28) from [<c0021da0>] = (ret_fast_syscall+0x0/0x2c) |