Release Hotfix 5 - Rc2. Last One Before Going Final

[skeezix]

klop -- can you run each one independantly, and see if one of those is a problem?

ie: Terminal is not a pnd is it?

Can you run Deedbeef and quit it, then run it again and quit it, repeat 10 times? --> watch ram to see if its being used up (ram+cached is fine), and see if you run out of loopbacks.

Repeat for each.

-- one or more of those could be bad, staying around forever.

(some music player apps were guilty.. they'd launch and stay open forever, but let the pnd exit.. thus causing loopback leak etc. But if they stay open forever, thats still a loopback usage.)

It might just be that Chromium is using up too much memory; remember, browsers like that generalyl assumg you've got a 2GB memory pool or more

jeff

edit; is the swap being used just to keep somethign ready, or is it actually used? I forget if linux weill leave stuff cached in swap or not. ie: some OSes will leave swap all full (just like cached memory), but its not 'full cache' just 'ready to be used cache' Oh, that looks like actually used swap, which is funny

 

[kloplop321]

sebt3: No, the menu is not slow

skeezix: I'll gladly run these tests soon.

sebt3/skeezix
I'll do that when I'm in class after work(ETA: 4 hours from this post time)
sebt3: the current pndrun is overwritten with the current running program, which has not crashed yet over 2 hours, so I need to wait until I have time to do swapoff -a

 

[goldenegg]

If there is a problem (may well be, who knows), then shoudl check if its also in HF4 (which probably is), and if so, HF5 can still go out and then can work on the issue for HF6. ie: No point in holding back everything for one (newly identified) issue. Better to ship, get all the patches and such out, and then work on it, imho.

However, if it is new in HF5, thats something.

I can confirm that the loop device problem doesn't happen in HF4, at least not to the degree it does with HF5.

I also seem to have another problem with battery life in HF5. If I put my Pandora in low power mode in the morning (with about 80% battery), the unit will be completely dead in the evening. Also, if I shutdown the Pandora (in the minimenu options) in the morning (same 80% battery), I'll be down to 40% - 50% battery by the evening and dead within a couple of days. This is much worse than in HF4.

 

[kloplop321]

deadbeef: start, free, end, free, repeat; No leaks, only minor varying values, which will don't increase or decrease on average
chrome: start, free, end, free, repeat; it looks like a leak...half way
Before I start, I have 140M free,
I start, I have like 3M
I end, I have 80M

I repeat:
Start: same
End: 10MB less free each time

Until, I do about 4 times, and it stays at 65M free, I've gone 3 past 4, and the results are the same.

But, pidgin...? Well, it just dies without me having to do run anything else, I send about 14 messages, and WOOHOO,
pndrun_pidgin.out
all sorts of memory errors, although I blame sebt3

 

[skeezix]

OKay, so soiunds like Chromium problem of some sort; I wonder if its leaving something resident .. or if runscript ids exiting prior to chromium itself (thus leaving the aufs open forever.)

pidgin .. if it crashes out, that should clean up You didn't see if that one is leaking or not.

goldenegg -- your usage pattern may have changed; what apps? can you try the test outlined above .. pick one simple pnd and run it over and over, and see if okay; then try your regular apps .. I bet one of them is being bad

jeff

OKay, so toggle wifi might be turding up .. seems like its using up a lo maybe. I tried a couple others, no problem but toggle wifi is eating up a slot.
-- yep, confirmed.. toggle wifi script is exiting before the script is finished, and so does not unmount properly.

 

[kloplop321]

Regarding the op_wifi.sh toggle exiting uncleanly
Solution:
http://bugs.openpand...ils&task_id=214
Appending " &" to the line which calls this init script, solves the problem.
and I refer to editing the script located in /usr/pandora/scripts/op_wifi.sh
It now properly unmounts, and the pndrun_op_wifi.out does not report any issues like before.