Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (6)
to General by Kalatti - 3 days, 7 hrs ago -
Full linux distros on Sailfish OS (253)
to SailfishOS by qoh - 6 days, 1 hr ago - more...
|
2010-07-21
, 02:26
|
|
Posts: 958 |
Thanked: 483 times |
Joined on May 2010
|
#12
|
Originally Posted by myeyegooogles
you could try killing the process.....i've done that a few times but i'm not sure how much of a "restart" that is.
i have the calendar, facebook, and 3 desktop command execution widgets, along with some app shortcuts and bookmarks, the widgets definitely seem like the culprit.
is there way to restart the hildon desktop without rebooting. rebooting every 3 days is annoying.
also, if there is a way to restart the desktop, then make a script and make a cron job out of it?
|
|
2010-07-21
, 02:42
|
|
Posts: 88 |
Thanked: 25 times |
Joined on Jan 2010
|
#13
|
Originally Posted by myeyegooogles
Try the following:
i have the calendar, facebook, and 3 desktop command execution widgets, along with some app shortcuts and bookmarks, the widgets definitely seem like the culprit.
is there way to restart the hildon desktop without rebooting. rebooting every 3 days is annoying.
also, if there is a way to restart the desktop, then make a script and make a cron job out of it?
$ killall hildon-home
I have the same problem and it seems it is a problem of hildon desktop than the whole system (the menu button on top left remains fully responsive for me). However, restarting hildon will remove all your 3rd part widgets and you will have to put them back again
 |
|
2010-07-21
, 03:29
|
|
Posts: 1,559 |
Thanked: 1,786 times |
Joined on Oct 2009
@ Boston
|
#14
|
Originally Posted by Frank Banul
The "possible memory leak" described in the OP is the fragmentation of memory by python widgets. The symptom of that is an unresponsive desktop/task switcher. The hildon-home problem that seems to have surfaced with PR1.2 i still get but it's a bit less disruptive (eats battery and slows things down esp. when task switching) rather than completely freezing UI.
I don't have any python widgets on my desktop yet I still need to reboot every week or so as the lag becomes ridiculous.
There are still a few what I would consider fatal flaws with the N900 at this time, the forced reboots being one of them. My N810 is almost never rebooted. A family member's ipod touch never gets rebooted. But the N900 does. Which one doesn't belong? I don't think my 770 had to be rebooted but it's web browser would randomly die so it might as well have needed reboots.
Frank
There are definitely some kinks to work out but, as i said, going back to an almost empty desktop really helped with the symptoms the OP describes.
__________________
Unofficial PR1.3/Meego 1.1 FAQ
Unofficial PR1.3/Meego 1.1 FAQ
***
Classic example of arbitrary Nokia decision making. Couldn't just fallback to the no brainer of tagging with lat/lon if network isn't accessible, could you Nokia?
|
|
2010-07-21
, 06:53
|
|
Posts: 100 |
Thanked: 24 times |
Joined on May 2010
|
#15
|
Originally Posted by aiyush
I've tried pkill hildon-dektop as root and it seemed to do the trick. the widgets didnt disappear, and the system feels refreshed. ill see how long i can keep this going without rebooting.
Try the following:
$ killall hildon-home
I have the same problem and it seems it is a problem of hildon desktop than the whole system (the menu button on top left remains fully responsive for me). However, restarting hildon will remove all your 3rd part widgets and you will have to put them back again
Right now Im @ 3 days 21:15
|
|
2010-07-21
, 07:25
|
|
Posts: 193 |
Thanked: 92 times |
Joined on May 2010
@ galveston, tx
|
#16
|
IMHO the memory is getting fragmented a lot.
Here's the fragmentation info. There's hardly any segment above 64KB available after 2 days of runtime.
Normal: 1024*4kB 1636*8kB 394*16kB 12*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 23936kB
Here's how I got this info
echo m > /proc/sysrq-trigger
dmesg
Here's the fragmentation info. There's hardly any segment above 64KB available after 2 days of runtime.
Normal: 1024*4kB 1636*8kB 394*16kB 12*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 23936kB
Here's how I got this info
echo m > /proc/sysrq-trigger
dmesg
| The Following User Says Thank You to noipv4 For This Useful Post: | ||
|
|
2010-07-21
, 07:37
|
|
Posts: 1,418 |
Thanked: 1,541 times |
Joined on Feb 2008
|
#17
|
Originally Posted by Flandry
I do not have Python widgets or Python installed. I am still experiencing this problem. In fact, I have been experiencing it long before PR1.2.
The "possible memory leak" described in the OP is the fragmentation of memory by python widgets. The symptom of that is an unresponsive desktop/task switcher. The hildon-home problem that seems to have surfaced with PR1.2 i still get but it's a bit less disruptive (eats battery and slows things down esp. when task switching) rather than completely freezing UI.
|
|
2010-07-21
, 07:41
|
|
Posts: 193 |
Thanked: 92 times |
Joined on May 2010
@ galveston, tx
|
#18
|
Try these steps too.
http://www.linuxinsight.com/proc_sys...op_caches.html
Writing to this will cause the kernel to drop clean caches, dentries and inodes from memory, causing that memory to become free.
To free pagecache:
* echo 1 > /proc/sys/vm/drop_caches
To free dentries and inodes:
* echo 2 > /proc/sys/vm/drop_caches
To free pagecache, dentries and inodes:
* echo 3 > /proc/sys/vm/drop_caches
As this is a non-destructive operation, and dirty objects are not freeable, the user should run "sync" first in order to make sure all cached objects are freed.
http://www.linuxinsight.com/proc_sys...op_caches.html
Writing to this will cause the kernel to drop clean caches, dentries and inodes from memory, causing that memory to become free.
To free pagecache:
* echo 1 > /proc/sys/vm/drop_caches
To free dentries and inodes:
* echo 2 > /proc/sys/vm/drop_caches
To free pagecache, dentries and inodes:
* echo 3 > /proc/sys/vm/drop_caches
As this is a non-destructive operation, and dirty objects are not freeable, the user should run "sync" first in order to make sure all cached objects are freed.
| The Following 3 Users Say Thank You to noipv4 For This Useful Post: | ||
 |
|
2010-07-21
, 07:58
|
|
Posts: 579 |
Thanked: 286 times |
Joined on Oct 2009
@ Australia
|
#19
|
OMG
this was the reason why PR1.2 was delayed
i logged a bug about this a long time ago
https://bugs.maemo.org/show_bug.cgi?id=8723
thanks for not fixing it nokia.
i have no widgets running anymore and i have to do this every few days
sudo gainroot
killall hildon-desktop
killall hildon-home
this was the reason why PR1.2 was delayed
i logged a bug about this a long time ago
https://bugs.maemo.org/show_bug.cgi?id=8723
thanks for not fixing it nokia.
i have no widgets running anymore and i have to do this every few days
sudo gainroot
killall hildon-desktop
killall hildon-home
|
|
2010-07-21
, 08:05
|
|
Posts: 579 |
Thanked: 286 times |
Joined on Oct 2009
@ Australia
|
#20
|
Originally Posted by noipv4
Try these steps too.
http://www.linuxinsight.com/proc_sys...op_caches.html
Writing to this will cause the kernel to drop clean caches, dentries and inodes from memory, causing that memory to become free.
To free pagecache:
* echo 1 > /proc/sys/vm/drop_caches
To free dentries and inodes:
* echo 2 > /proc/sys/vm/drop_caches
To free pagecache, dentries and inodes:
* echo 3 > /proc/sys/vm/drop_caches
As this is a non-destructive operation, and dirty objects are not freeable, the user should run "sync" first in order to make sure all cached objects are freed.
continuously flush the cache:
#!/bin/bash
for ((i = 1; i < 1000000; i++)); do
echo 1 > /proc/sys/vm/drop_caches
sleep 1
done
There are still a few what I would consider fatal flaws with the N900 at this time, the forced reboots being one of them. My N810 is almost never rebooted. A family member's ipod touch never gets rebooted. But the N900 does. Which one doesn't belong? I don't think my 770 had to be rebooted but it's web browser would randomly die so it might as well have needed reboots.
Frank