New joyride build 2405
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2405 Changes in build 2405 from build: 2404 Size delta: 0.00M -bootfw q2e15-1.olpc2.unsigned +bootfw q2e16-1.olpc2.unsigned --- Changes for bootfw q2e16-1.olpc2.unsigned from q2e15-1.olpc2.unsigned --- + Fixup ext3 write support + Add 2 column display to the mfg-data dump -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
On Tue, Sep 9, 2008 at 6:10 AM, Michael Stone [EMAIL PROTECTED] wrote: * We need to find out why the oom-killer is not killing things fast enough. Based on our results, we might consider configuring /proc/$pid/oom_adj to preferentially kill some processes (e.g., the foreground [or background?] activities.) Any reason why killing first activities' processes wouldn't solve the stability issue? AFAIK, we haven't seen OOM conditions without any activity open. Just in case, I'm not saying that isn't worth to do any of the other things on your list. Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[Server-devel] Feature work for xs-0.5: Moodle stage 1
While working to wrap up the F9 port, I cannot avoid itching for some feature work -- the XS has been without a face so far for end users; it's high time we change that. So I've put together some notes on the work I want to do with Moodle for the XS. See http://wiki.laptop.org/go/XS_Moodle_plan - I am hoping to tackle most or all of 'stage 1' for xs-0.5 Are there any Moodle programmers in this list? ;-) cheers, martin -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/server-devel
Re: analyzing memory usage of python code
On Sun, Aug 24, 2008 at 10:09 AM, Polychronis Ypodimatopoulos [EMAIL PROTECTED] wrote: Polychronis Ypodimatopoulos wrote: I filed #8128 to address the memory usage that seems excessive. I have also disabled cerebro from start-up while this is being investigated and the issue with blocking shutdown process (#8108). Should be picked up at the next version of joyride. Any suggestions on how to isolate the parts of some python code that take the most memory? It's rather impossible to start commenting out modules because of dependency issues. It's impossible because of dependency cycles, but aside of that you can execute python with -v, and from the output make a list of module imports that reduce implicit imports to the most. Hope that helps, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Patch fixing a problem with --kickstart-include
On Tue, Sep 9, 2008 at 10:55 PM, Jeroen van Meeuwen [EMAIL PROTECTED] wrote: I know it wasn't doing this before, and I'm not sure it's supposed to now. I've not seen any changes related to kickstart loading other then for the kickstart located on an NFS share... but then again I may have subconsciously ignored the commit. I'll try and figure out how it's supposed to work and how it actually works. When I crafted the patch I was reading the Anaconda/Kickstart wikipage, specifically the http://fedoraproject.org/wiki/Anaconda/Kickstart#Creating_a_Kickstart_Boot_CD-ROM section. Re-reading it now, I notice that you have to complement that with http://fedoraproject.org/wiki/Anaconda/Kickstart#Boot_CD-ROM - Hmmm. Unless a `git grep ks.cfg` of anaconda turns up a smoking gun, the patch I posted may be a misfire :-/ cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/server-devel
Re: Stability and Memory Pressure in 8.2
On Tue, Sep 09, 2008 at 12:10:53AM -0400, Michael Stone wrote: Dear devel@, Kim, Greg, and I have concluded that the instability we experience under memory-pressure in 8.2-759 and similar is the single hard issue that we wish to _attempt_ to address before releasing 8.2 on current timeframes. [...] * We ought to ponder whether there are any additional dirty hacks we can experiment with in order to reduce memory consumption; for example, running the Shell and Journal (and DS?) in one process or making use of the compressed-caching code published on this list some months ago. Compcache has been working well enough for me for the last six months to suggest that wider testing wouldn't be a disaster. -bash-3.2# cat /boot/olpc_build joyride 2399 -bash-3.2# free total used free sharedbufferscached Mem:235716 230356 5360 0 162865448 -/+ buffers/cache: 163280 72436 Swap:58924 2736 56188 -bash-3.2# swapon -s FilenameTypeSizeUsed Priority /dev/ramzswap0 partition 58924 2736 100 The trac ticket is http://dev.laptop.org/ticket/28 Regards, Michael Martin pgpTfTp0tmNft.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
There are four classes of things we can/should/could do: 1) understand where our memory is being used. Individual bugs can have a large effect. Something stupid could be hurting us badly, and we won't know unless we look. What is more, we need to invest in tools that allow us to monitor this. 2) there are some band-aids that have been discussed, such as rlimits, which we can experiment with, and that *might* improve the situation without the real solutions the next two items go into. 3) the oom killer's default algorithms are pretty terrible, taking little into account in the choice of what gets killed. Between Sugar/Rainbow, and knowledge that the window manager has, one could do much better. 4) we provide no end user feedback on memory usage, either. We should investigate whether revisiting our previous attempt to give such feedback, now that Linux can provide much better information than it could when we abandoned our previous donut attempt. The users could really help, if only we let them know a bit about what was going on... In terms of priority: immediately examining what is going on with memory usage in case we have a bad leak is clearly worthwhile (1). We need to budget for tool-building to monitor the situation going forward immediately. 2) and *possibly* (a beginning on) 3 may be 8.2.1 fodder, but without feedback from more users, we won't know if this isn't just keys under the lamppost (e.g. our multiple bug reports about browse ooming because of our amazingly stupid hardware wiki page, which is one of the most egregious pages I've seen in recent memory. Doing 3) pretty well I suspect is 9.1 fodder, but only if we start very soon. My gut tells me its some man-months of work. We might get lucky and should investigate if any of the embedded folks have something we can use. Unfortunately, the Nokia folks I had thought might have something didn't, when I last checked a year ago. But we can/should check a bit first before diving in; it's a year later. http://dev.laptop.org/ticket/1995 I urge we investigate quickly whether 4) is, in fact, feasible, so that it can go on the Sugar roadmap in time to be done for 9.1. - Jim On Tue, 2008-09-09 at 13:02 +0200, Tomeu Vizoso wrote: On Tue, Sep 9, 2008 at 6:10 AM, Michael Stone [EMAIL PROTECTED] wrote: * We need to find out why the oom-killer is not killing things fast enough. Based on our results, we might consider configuring /proc/$pid/oom_adj to preferentially kill some processes (e.g., the foreground [or background?] activities.) Any reason why killing first activities' processes wouldn't solve the stability issue? AFAIK, we haven't seen OOM conditions without any activity open. Just in case, I'm not saying that isn't worth to do any of the other things on your list. Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
On Tue, 2008-09-09 at 00:10 -0400, Michael Stone wrote: Dear devel@, Kim, Greg, and I have concluded that the instability we experience under memory-pressure in 8.2-759 and similar is the single hard issue that we wish to _attempt_ to address before releasing 8.2 on current timeframes. (We recognize that there are several other issues marked as blocking the release but we are confident that they will be resolved satisfactorily or are, in a few cases, beyond help.) Since most other aspects of the release seem to be running smoothly, Kim asked me to take a more direct role in organizing our efforts produce a release which avoids memory pressure when possible and which is better-behaved when it strikes. To that end, I would like to ask for your assistance with the following questions and tasks: * We need to determine why we encounter low-memory and out-of-memory situations more frequently than in previous releases. - This means that we need to measure how our memory consumption profile has changed since our previous releases. (cscott observes that we were unable to attack the F-9 image size issues until we were able to quantify the effect of changes we had made or were considering making. Consequently, he suggests that we will be unable to attack our current space consumption problems until we are able to generate good numbers (and displays).) - We need to think carefully about (or measure) whether our memory-consumption patterns have changed. I am particularly skeptical of our widespread use of tmpfsen since the pages consumed by files stored on tmpfsen are permanently dirty (and are perhaps accounted for differently than pages mapped into process' address spaces?) - We need to check the configuration of applications like Browse which have configurable caching behavior. (Search for cache or capacity in about:config; check for important compile-time configuration flags.) - We need to test in a variety of different network configurations in order to determine to what extent the network/presence environment affects memory consumption. * We need to check carefully for memory-leaks. Three mechanisms which occur to me include: 1) running the system for a period of time, then scanning for anomalies either manually or in some automated fashion from userland, kernel-land, or OFW (via SysRq or SMM). 2) setting rlimits various processes and noting what dies 3) using debugging tools like the python garbage collection module, guppy/heapy, gdb+macros, valgrind, efence, purify, etc. looking for trouble. * We need to find out why the oom-killer is not killing things fast enough. Based on our results, we might consider configuring /proc/$pid/oom_adj to preferentially kill some processes (e.g., the foreground [or background?] activities.) * We need to determine whether the oom-killer is killing the right processes. (sysctl's vm.oom_dump_tasks can be set to 1 in order to get more verbosity from the oom-killer when it fires). * We ought to ponder whether there are any additional dirty hacks we can experiment with in order to reduce memory consumption; for example, running the Shell and Journal (and DS?) in one process or making use of the compressed-caching code published on this list some months ago. * Random other stuff to think about: - rlimits, cgroups, and the memory resource controller - the warnings in the ramfs and tmpfs code about the deadlocks that tmpfsen can generate under low- or no-memory conditions. - whether our kernel overcommits when allocation requests are made? - whether we can get Browse to behave intelligently when it receives BadAlloc errors from X? - how to run bootchart on the XO - how to generate decent statistics and graphics (preferably in an automated fashion) concerning memory usage as part of our test suite - system-tap's kmalloc2.stp example In conclusion, more to come once I have some actual data; _please_ feel free to assist in collecting it! (though be aware that I may 'volunteer' you if I need your help. (That means you, Tomeu, Riccardo, Deepak, ...)). Regards, Michael There are some (trivial) tools (you may be interested in) I've written and used besides others to attack/study this issues: * picker [1] For me it was handier to use then bootchart; will also show per process mem usage. * imports timings and alloc statistics [2] Patch to python that prints timings and mem usage diffs for every imported module. Original timings patch is from Tomeu. * python-allocstatsmodule [3] Inspired by [2] but can be used inside python scripts to collect stats on heap
Re: Stability and Memory Pressure in 8.2
On Tue, 2008-09-09 at 00:10 -0400, Michael Stone wrote: - This means that we need to measure how our memory consumption profile has changed since our previous releases. (cscott observes that we were unable to attack the F-9 image size issues until we were able to quantify the effect of changes we had made or were considering making. Consequently, he suggests that we will be unable to attack our current space consumption problems until we are able to generate good numbers (and displays).) what's the baseline previous release for this comparison? paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Current 8.2 and joyride ext3 builds unusable
Filed trac ticket 8369 about this issue. Here is the text: == All 8.2 devel-ext3 builds are unusable in qemu with the lone exception of 8.2-751. Joyride shows a similar picture. 2346 was OK. 2347-2362 were not complete due to the gstreamer issue. 2363-2365 are OK. Every devel-ext3 build 2366-2405 is incomplete. Problem on both 8.2 and joyride is the missing grub stage1 loader. See the errormessage at the bottom of the build logs, e.g. from build 2405: --- cp: cannot stat `/home/cscott/public_html/xo-1/streams/joyride/build2405-20080909_0222/devel_ext3/install_root/usr/share/grub/i386-redhat/stage1': No such file or directory * Unmounting special file systems from install root * Detaching disk and partition 1 (/dev/loop5 and /dev/loop6) --- Please fix asap so I can test 8.2 issues also in qemu (privately compiled version with 3dNow emulation enabled) === I have not tried, but almost certainly these images will not work when trying to boot from USB or SD on a real XO-1. Ton van Overbeek ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] F9 XS - Take it for a spin...
Martin Langhoff wrote: with some caveats... this is a developer preview, lots of things are b0rken, but still... - download all 759MB of iso here http://xs-dev.laptop.org/xs/other/Fedora-0.5.dev2-i386.iso - Burn it to a DVD (see notes below on using USB sticks) - Install it on a new machine - use the kickstart-driven default menu option - After install 1 - login as root 2 - cd /etc make -f xs-config.make earlyset reboot - If you have 2 NICs and F9 got them the wrong way around, just invoke xs-swapnics and reboot Other installation notes... - Upgrades... for some reason, Anaconda isn't realising that it is supposed to be upgrading... working on that... - From a USB device! Ah, well, mildly annoying - - grab mkusbinstall from here http://dev.laptop.org/git?p=projects/xs-livecd;a=tree;f=util;h=202b31c7ef280036e3edd99ef68871e3d0815295;hb=HEAD - use it like you'd use livecd-iso-to-disk - Anaconda will fail to kind the ks file - fix the path to be 'hd:sdb1:/ks.cfg' - assuming your USB disk is mounted as sdb1. It may require waiting a few seconds until sdb1 is mounted. That is an anaconda re-compile time, think I can fix it. - Anaconda will need to be told where the ISO is. Pick Hard Drive install, sdb1, and the path is 'iso' add to the kickstart file after interactive: harddrive --partition=sdb1 --dir=iso Jerry ___ Server-devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/server-devel
Re: Stability and Memory Pressure in 8.2 ([EMAIL PROTECTED])
Hi All, I recommend build 708 as the baseline. Thanks, Greg S ** Date: Tue, 09 Sep 2008 11:34:50 -0400 From: [EMAIL PROTECTED] Subject: Re: Stability and Memory Pressure in 8.2 To: devel@lists.laptop.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii On Tue, 2008-09-09 at 00:10 -0400, Michael Stone wrote: - This means that we need to measure how our memory consumption profile has changed since our previous releases. (cscott observes that we were unable to attack the F-9 image size issues until we were able to quantify the effect of changes we had made or were considering making. Consequently, he suggests that we will be unable to attack our current space consumption problems until we are able to generate good numbers (and displays).) what's the baseline previous release for this comparison? paul =- paul fox, [EMAIL PROTECTED] -- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel End of Devel Digest, Vol 31, Issue 30 * ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] A few F9 upgrade things I need help with...
Martin Langhoff wrote: As part of the XS upgrade, I've ended up caught with a number of F9 oddities -- none of them a complete blocker, but definitely rought edges... - Cannot include beecrypt in Pungi/Revisor build - this is probably a bug worthy of filing in BZ but needs a bit of diagnosys. http://dev.laptop.org/ticket/8363 - Anaconda conflicts with xs-config - Filed as BZ 461550 http://dev.laptop.org/ticket/8366 - Anaconda crash during install with USB-disk-based ks.cfg BZ 461453 - this probably affects all USB-disk based installs. - Anaconda: Install from USB disk: only ISO picked up BZ 461548 Good Luck I tried, check the anaconda ML archives. Some where I have a working anaconda rpm that fixes that. If its OK to use a re-rolled version anaconda with XS I might be able to overcome that. Jerry ___ Server-devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/server-devel
Re: [Activities] Combined Sugar/XO manual outline
What would a concise and accurate definition of the wireless lights (for 8.2) be? This information seems to suggest the lights aren't working how they ideally would http://wiki.laptop.org/go/Power_Management#Wireless_Lights Brian On Tue, Sep 9, 2008 at 12:55 PM, [EMAIL PROTECTED] wrote: brian wrote: Hi all, See these diagrams: http://dev.laptop.org/~bjordan/screenshots/Picture%2083.png http://dev.laptop.org/~bjordan/screenshots/Picture%2084.png should the wireless lights be labeled? paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
* We need to find out why the oom-killer is not killing things fast enough. Based on our results, we might consider configuring /proc/$pid/oom_adj to preferentially kill some processes (e.g., the foreground [or background?] activities.) In the cases I've been playing with, browse is the only activity that is running. Will try bumping its oom_adj to see if this improves OOM kill latency. * We need to determine whether the oom-killer is killing the right processes. (sysctl's vm.oom_dump_tasks can be set to 1 in order to get more verbosity from the oom-killer when it fires). From watching top, it appears that we're killing the correct process. For example, when running the test case from #8316, OOM killer does not kill browse, but just kills the gnash instance which is chewing up RAM. - the warnings in the ramfs and tmpfs code about the deadlocks that tmpfsen can generate under low- or no-memory conditions. I have yet to see an actual deadlock. What I saw when trying to reproduce #3816 is that the OOM killer just takes a very very long time to kick in. - whether our kernel overcommits when allocation requests are made? By default vm.overcommit_memory is set to 0 which will refuse Obvious overcommits of address space. I will try setting this to 3 along with vm.overcommit_ratio to 0 to force no overcommit at all and see how the system reacts. ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
On Tue, 2008-09-09 at 00:10 -0400, Michael Stone wrote: - whether we can get Browse to behave intelligently when it receives BadAlloc errors from X? I have no doubt that Browse/xulrunner has room for improvement with memory usage but this is not where you should be looking. These BadAlloc messages are true errors generated when the application requests pixmaps outside of the coordinate range accepted by X (this is well documented). This is a real bug in the code, not a memory pressure issue. Such requests should never be generated, and the application crashing is probably the behaviour we want. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
On Tue, Sep 9, 2008 at 11:34 AM, [EMAIL PROTECTED] wrote: On Tue, 2008-09-09 at 00:10 -0400, Michael Stone wrote: - This means that we need to measure how our memory consumption profile has changed since our previous releases. (cscott observes that we were unable to attack the F-9 image size issues until we were able to quantify the effect of changes we had made or were considering making. Consequently, he suggests that we will be unable to attack our current space consumption problems until we are able to generate good numbers (and displays).) what's the baseline previous release for this comparison? update.1 (703, 708, 713 or your choice) You could also try using the pre-F-9 merge joyrides for comparison, but that presupposes that our memory problems are a side-effect of the F-9 merge, and I don't think that we have any evidence of this yet. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
On Tue, Sep 9, 2008 at 7:02 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Tue, Sep 9, 2008 at 6:10 AM, Michael Stone [EMAIL PROTECTED] wrote: * We need to find out why the oom-killer is not killing things fast enough. Based on our results, we might consider configuring /proc/$pid/oom_adj to preferentially kill some processes (e.g., the foreground [or background?] activities.) Any reason why killing first activities' processes wouldn't solve the stability issue? AFAIK, we haven't seen OOM conditions without any activity open. Yes, we have. In particular, if you update your system and then leave it for a while, and later click the software update control panel, you end up OOMing in the control panel. Sugar restarts and reports are that software update works fine the second time. So this might well be a sugar leak; killing 'sugar' is not good for stability. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Current 8.2 and joyride ext3 builds unusable
On Tue, Sep 9, 2008 at 12:21 PM, Ton van Overbeek [EMAIL PROTECTED] wrote: Filed trac ticket 8369 about this issue. Here is the text: == All 8.2 devel-ext3 builds are unusable in qemu with the lone exception of 8.2-751. Joyride shows a similar picture. 2346 was OK. 2347-2362 were not complete due to the gstreamer issue. 2363-2365 are OK. Every devel-ext3 build 2366-2405 is incomplete. Problem on both 8.2 and joyride is the missing grub stage1 loader. See the errormessage at the bottom of the build logs, e.g. from build 2405: --- cp: cannot stat `/home/cscott/public_html/xo-1/streams/joyride/build2405-20080909_0222/devel_ext3/install_root/usr/share/grub/i386-redhat/stage1': No such file or directory * Unmounting special file systems from install root * Detaching disk and partition 1 (/dev/loop5 and /dev/loop6) --- Please fix asap so I can test 8.2 issues also in qemu (privately compiled version with 3dNow emulation enabled) === I have not tried, but almost certainly these images will not work when trying to boot from USB or SD on a real XO-1. working on it. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
On Tue, Sep 9, 2008 at 7:39 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Tue, Sep 9, 2008 at 7:02 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Tue, Sep 9, 2008 at 6:10 AM, Michael Stone [EMAIL PROTECTED] wrote: * We need to find out why the oom-killer is not killing things fast enough. Based on our results, we might consider configuring /proc/$pid/oom_adj to preferentially kill some processes (e.g., the foreground [or background?] activities.) Any reason why killing first activities' processes wouldn't solve the stability issue? AFAIK, we haven't seen OOM conditions without any activity open. Yes, we have. In particular, if you update your system and then leave it for a while, and later click the software update control panel, you end up OOMing in the control panel. Sugar restarts and reports are that software update works fine the second time. So this might well be a sugar leak; killing 'sugar' is not good for stability. That sounds pretty awful, do we have a ticket with precise instructions about how to reproduce? How much time approx. need to wait after updating sugar? Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
On Tue, 2008-09-09 at 13:10 -0400, Daniel Drake wrote: On Tue, 2008-09-09 at 00:10 -0400, Michael Stone wrote: - whether we can get Browse to behave intelligently when it receives BadAlloc errors from X? I have no doubt that Browse/xulrunner has room for improvement with memory usage but this is not where you should be looking. These BadAlloc messages are true errors generated when the application requests pixmaps outside of the coordinate range accepted by X (this is well documented). This is a real bug in the code, not a memory pressure issue. Such requests should never be generated, and the application crashing is probably the behaviour we want. For the specific BadAlloc of the page in our wiki, it is not coordinate out of range, but that the images on that page are so huge as to cause X to get a allocation failure from the OS, and that gets reflected back to the client. Otherwise we'd have gotten a BadValue error. At one point, X11 was pretty carefully checked to work in the face of failures to allocate memory (dunno how true that is today). Whether Firefox should be so silly as to even be asking (the images are huge) and asking the X server to rescale them (also very questionable) is something that can/should be taken up with the Firefox folks, but not something we're going to (be able) to fix on our own. The embedded mozilla folks (there are such people at long last) are the logical people to own this headache. - Jim -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
On Tue, Sep 09, 2008 at 01:10:57PM -0400, Daniel Drake wrote: On Tue, 2008-09-09 at 00:10 -0400, Michael Stone wrote: - whether we can get Browse to behave intelligently when it receives BadAlloc errors from X? I have no doubt that Browse/xulrunner has room for improvement with memory usage but this is not where you should be looking. These BadAlloc messages are true errors generated when the application requests pixmaps outside of the coordinate range accepted by X (this is well documented). This is a real bug in the code, not a memory pressure issue. Fine. How does the X server report failures to allocate memory on behalf of clients? How does Browse respond? Such requests should never be generated, and the application crashing is probably the behaviour we want. I'll grant that it may be helpful for finding the issue in the first place, but I would much rather that we ship a Browse which displayed what it can display without crashing. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
c. scott ananian wrote: On Tue, Sep 9, 2008 at 7:02 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: stability issue? AFAIK, we haven't seen OOM conditions without any activity open. Yes, we have. In particular, if you update your system and then leave it for a while, and later click the software update control panel, you end up OOMing in the control panel. Sugar restarts and reports are that software update works fine the second time. So this might well be a sugar leak; killing 'sugar' is not good for stability. i think there's definitely a sugar shell leak. here's some partial data, gathered from a few machines on my desk right now. (be careful with the column headings -- i rearranged partway through to get separate CODE and DATA columns.) (also, don't do an absolute compare between the 708 build and the 759 build -- the latter is chock full of activites, the former has none at all.) build 708: top - 17:45:17 up 59 min, 3 users, load average: 0.03, 0.05, 0.01 PID USER PR NI VIRT RES SHR CODE DATA %MEM COMMAND 1741 olpc 15 0 53128 27m 13m4 14m 12.2 python same build 708, roughly twenty minutes later: top - 18:03:16 up 1:17, 3 users, load average: 0.01, 0.01, 0.00 PID USER PR NI VIRT RES SHR CODE DATA %MEM COMMAND 1741 olpc 15 0 53308 28m 13m4 14m 12.3 python build 759: top - 12:20:00 up 39 min, 4 users, load average: 0.00, 0.06, 0.11 PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 1461 olpc 20 0 60576 33m 14m S 0.3 14.5 0:48.38 python same build 759, almost two hours later: top - 14:04:11 up 2:23, 3 users, load average: 0.04, 0.06, 0.08 PID USER PR NI VIRT RES SHR CODE DATA %MEM COMMAND 1461 olpc 20 0 65964 38m 14m4 23m 16.7 python finally, i have a joyride-2263, which has been up for 6 days. i don't have copy/paste access to it, but the sugar shell is currently taking 99.6m VIRT, 64m RES, 14m SHR, and is using 28% of system memory. paul p.s. in addition, i think a lot of system processes have grown somewhat. for instance, login now has 100k more DATA space in 759 than it had in 708. others (e.g., xinit) haven't grown at all. (also measured with top.) =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 2406
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2406 Changes in build 2406 from build: 2405 Size delta: 0.00M -etoys 3.0.2139-1 +etoys 3.0.2141-1 --- Changes for etoys 3.0.2141-1 from 3.0.2139-1 --- + Enable object chooser -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
IPv6 problem on crank
I got really weird problems on my build diff script today, with a gazillion of them frozen (they're triggered by cron). I tracked it down to a non-working IPv6 connection to xs-dev. This hangs: [EMAIL PROTECTED]:~$ curl -I http://xs-dev.laptop.org/ but forcing IPv4 makes it work: [EMAIL PROTECTED]:~$ curl -I -4 http://xs-dev.laptop.org/ - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
i wrote: i think there's definitely a sugar shell leak. here's some partial data, gathered from a few machines on my desk right now. (be careful with the column headings -- i rearranged partway through to get separate CODE and DATA columns.) (also, don't do an absolute compare between the 708 build and the 759 build -- the latter is chock full of activites, the former has none at all.) build 708: top - 17:45:17 up 59 min, 3 users, load average: 0.03, 0.05, 0.01 PID USER PR NI VIRT RES SHR CODE DATA %MEM COMMAND 1741 olpc 15 0 53128 27m 13m4 14m 12.2 python same build 708, roughly twenty minutes later: top - 18:03:16 up 1:17, 3 users, load average: 0.01, 0.01, 0.00 PID USER PR NI VIRT RES SHR CODE DATA %MEM COMMAND 1741 olpc 15 0 53308 28m 13m4 14m 12.3 python another hour later on 708: top - 19:06:19 up 2:21, 3 users, load average: 0.00, 0.00, 0.00 PID USER PR NI VIRT RES SHR CODE DATA %MEM COMMAND 1741 olpc 15 0 53576 28m 13m4 15m 12.3 python call it 200 KB/hour? build 759: top - 12:20:00 up 39 min, 4 users, load average: 0.00, 0.06, 0.11 PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 1461 olpc 20 0 60576 33m 14m S 0.3 14.5 0:48.38 python same build 759, almost two hours later: top - 14:04:11 up 2:23, 3 users, load average: 0.04, 0.06, 0.08 PID USER PR NI VIRT RES SHR CODE DATA %MEM COMMAND 1461 olpc 20 0 65964 38m 14m4 23m 16.7 python and another hour on 759: top - 15:07:25 up 3:27, 3 users, load average: 0.00, 0.04, 0.02 PID USER PR NI VIRT RES SHR CODE DATA %MEM COMMAND 1461 olpc 20 0 70468 42m 14m4 28m 18.6 python seems more like 4.5 MB/hour. (there are a lot of variables in play here -- the main thing is that something's certainly leaking.) paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
On Tue, Sep 9, 2008 at 9:13 PM, [EMAIL PROTECTED] wrote: i wrote: i think there's definitely a sugar shell leak. here's some partial data, gathered from a few machines on my desk right now. (be careful with the column headings -- i rearranged partway through to get separate CODE and DATA columns.) (also, don't do an absolute compare between the 708 build and the 759 build -- the latter is chock full of activites, the former has none at all.) build 708: top - 17:45:17 up 59 min, 3 users, load average: 0.03, 0.05, 0.01 PID USER PR NI VIRT RES SHR CODE DATA %MEM COMMAND 1741 olpc 15 0 53128 27m 13m4 14m 12.2 python same build 708, roughly twenty minutes later: top - 18:03:16 up 1:17, 3 users, load average: 0.01, 0.01, 0.00 PID USER PR NI VIRT RES SHR CODE DATA %MEM COMMAND 1741 olpc 15 0 53308 28m 13m4 14m 12.3 python another hour later on 708: top - 19:06:19 up 2:21, 3 users, load average: 0.00, 0.00, 0.00 PID USER PR NI VIRT RES SHR CODE DATA %MEM COMMAND 1741 olpc 15 0 53576 28m 13m4 15m 12.3 python call it 200 KB/hour? build 759: top - 12:20:00 up 39 min, 4 users, load average: 0.00, 0.06, 0.11 PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 1461 olpc 20 0 60576 33m 14m S 0.3 14.5 0:48.38 python same build 759, almost two hours later: top - 14:04:11 up 2:23, 3 users, load average: 0.04, 0.06, 0.08 PID USER PR NI VIRT RES SHR CODE DATA %MEM COMMAND 1461 olpc 20 0 65964 38m 14m4 23m 16.7 python and another hour on 759: top - 15:07:25 up 3:27, 3 users, load average: 0.00, 0.04, 0.02 PID USER PR NI VIRT RES SHR CODE DATA %MEM COMMAND 1461 olpc 20 0 70468 42m 14m4 28m 18.6 python seems more like 4.5 MB/hour. (there are a lot of variables in play here -- the main thing is that something's certainly leaking.) The shell shouldn't be doing anything while idle, so checking if the trigger is activity network would help here. Thanks, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
tomeu wrote: On Tue, Sep 9, 2008 at 9:13 PM, [EMAIL PROTECTED] wrote: (there are a lot of variables in play here -- the main thing is that something's certainly leaking.) The shell shouldn't be doing anything while idle, so checking if the trigger is activity network would help here. point of reference: on irc you mentioned the buddy list had been an issue in the past. does the sugar shell maintain that even when that screen isn't visible? paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
On Tue, Sep 9, 2008 at 9:24 PM, [EMAIL PROTECTED] wrote: tomeu wrote: On Tue, Sep 9, 2008 at 9:13 PM, [EMAIL PROTECTED] wrote: (there are a lot of variables in play here -- the main thing is that something's certainly leaking.) The shell shouldn't be doing anything while idle, so checking if the trigger is activity network would help here. point of reference: on irc you mentioned the buddy list had been an issue in the past. does the sugar shell maintain that even when that screen isn't visible? Some history: http://dev.laptop.org/ticket/5532 Info about buddies is permanently stored in the presence service, in the PS wrapper in the sugar shell and in the view. None of this data gets released due to the user switching views. Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 2407
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2407 Changes in build 2407 from build: 2406 Size delta: 0.00M -kernel 2.6.25-20080908.1.olpc.63579b21df15ab7 +kernel 2.6.25-20080909.2.olpc.2dfd32b70c58803 -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] What's cooking in the XS pot this week (2008-09-08)
On Sun, Sep 7, 2008 at 9:52 PM, Martin Langhoff [EMAIL PROTECTED] wrote: Today, I am trying really hard to wrap up remaining F9 issues. This week is going to be focused on feature work for xs-0.5! (Wooohoo!), and we have until the end of the month to work on xs-0.5 . The roadmap looks roughly like this: https://dev.laptop.org/query?group=statusmilestone=xs-0.5 now, that's an optimistic roadmap. We'll put a ton of work in, and yet quite a few things will not make it. If you care about the XS, *now* is the time to show your hand and help a bit... So I was poking around looking for something to work on... https://dev.laptop.org/ticket/6731 I'm a little confused about the use case, probably because I'm missing the design discussions that led to this request. Is this for remote login, or for local login? If it's remote login, why not use ssh keys? If it's for local login, it seems a little overcomplicated. Is there something else I should spend some time on? I've had one of 'those' weekends, but this should be calming down soon, so I'll have a little free time. -RN -- Robin Norwood The Sage does nothing, yet nothing remains undone. -Lao Tzu, Te Tao Ching ___ Server-devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/server-devel
Re: Stability and Memory Pressure in 8.2
On Tue, Sep 09, 2008 at 03:13:28PM -0400, [EMAIL PROTECTED] wrote: [759 sugar shell leak] seems more like 4.5 MB/hour. joyride-2399 sitting back at home with no activities, doing nothing all day: -bash-3.2# uptime 18:14:19 up 20:46, 8 users, load average: 0.15, 0.09, 0.12 -bash-3.2# /home/olpc/bin/ps_mem.py | grep python 70.1 MiB + 6.6 MiB = 76.7 MiB python (5) [...time passes...] -bash-3.2# uptime 19:52:08 up 22:24, 8 users, load average: 0.08, 0.07, 0.01 -bash-3.2# /home/olpc/bin/ps_mem.py | grep python 70.3 MiB + 6.6 MiB = 76.8 MiB python (5) paul Martin pgprMb6vdCsQp.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
On Tue, Sep 9, 2008 at 4:01 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: A couple of low risk fixes which could save ~6 mb at startup: Remove numpy usage from the shell http://dev.laptop.org/ticket/8372 (has patch) gst usage in the shell wastes 2.6mb http://dev.laptop.org/ticket/8375 These seem obvious and low risk. +1 from me. (We should be careful to test the numpy removal w/ differing locales, to ensure #5559 doesn't regress.) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
wireless lights
What would a concise and accurate definition of the wireless lights (for 8.2) be? To ordinary users, they are 'Meaningless eye candy'. They appear to not be 100% reliable if lit. They certainly are meaningless when blinking. They even appear to not be 100% reliable if not lit. Deeply regusted, mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] wireless lights
mikus wrote: What would a concise and accurate definition of the wireless lights (for 8.2) be? To ordinary users, they are 'Meaningless eye candy'. They appear to not be 100% reliable if lit. They certainly are meaningless when blinking. They even appear to not be 100% reliable if not lit. mikus -- i think brian was looking for something that would fit on the picture, as a label. can you be more succinct? ;-) paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
q2e15 and a bricked BTest-2
About a week ago I attempted the update the firmware on a BTest-2 machine from q2c11 to q2e15. There were no error messages, but after it shut down the screen no longer turns on. The EC seems to be working (mostly at least) ok. The idea was to test SqueakNOS but its boot.fth file uses commands that were not implemented in q2c11. Attempts to manually use the old commands to boot resulted in a messed up screen for about a second followed by an automatic reboot. So I downloaded q2e15 and did the upgrade (the better was at about 85% rather than completely full). Now pressing the power button will cause the power led to light up but no others and the screen remains off. Two very slight clicks can be heard on both speakers every two seconds. Pressing the power button long enough will make the power led turn off. I suspected that the download might have been bad and so downloaded it again using a different web browser, but the result was bit identical to what I had used in the upgrade. Plugging the machine into the external power makes the battery led light up yellow for a few minutes, but then it starts to blink red very slowly. The battery has to be removed for that to stop. Removing the external power sometimes causes a lot of noise (from the speakers, I guess). I know that newer versions of the OS can't be used on such an old machine and had expected there to be limits for the firmware too, but everything I found on the wiki indicated that all versions are compatible with it (only ATest has limits). While it is easy for me to make a serial cable to get more details about what it going on and to flash another version of the firmware, a lack of time will keep me from doing this in the next few weeks. -- Jecel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
On Tue, Sep 09, 2008 at 05:10:41PM +, Deepak Saxena wrote: * We need to find out why the oom-killer is not killing things fast enough. Based on our results, we might consider configuring /proc/$pid/oom_adj to preferentially kill some processes (e.g., the foreground [or background?] activities.) In the cases I've been playing with, browse is the only activity that is running. Will try bumping its oom_adj to see if this improves OOM kill latency. Did 'echo 15 /proc/pid/oom_adj`' and this does not help much. The system starts getting laggy at the point we reach about 3M remaining memory (according to top) but the OOM killer does not actually kick in until we fail an allocation which happens sometime in later. Need to capture what is happening at the kernel level during this window though I don't think that fixing this at the OOM killer layer is doable for 8.2. I have yet to see an actual deadlock. What I saw when trying to reproduce #3816 is that the OOM killer just takes a very very long time to kick in. - whether our kernel overcommits when allocation requests are made? By default vm.overcommit_memory is set to 0 which will refuse Obvious overcommits of address space. I will try setting this to 3 along with vm.overcommit_ratio to 0 to force no overcommit at all and see how the system reacts. This didn't quite do what I expected as I missread the docs. If we set overcommit_ratio=100 and overcommit_memory=3, the kernel will not overcommit memory and we end up with Browse crashing gracefully w/o bogging down the whole system or with Browse just gracefully ignoring any user input in the address bar due to probably a failed allocation of some sort when creating a new webpage instance. ~Deepak ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] wireless lights
Maybe the best solution would be to just label them and not provide a description? I could call them Wireless activity lights? Brian On Tue, Sep 9, 2008 at 4:37 PM, [EMAIL PROTECTED] wrote: mikus wrote: What would a concise and accurate definition of the wireless lights (for 8.2) be? To ordinary users, they are 'Meaningless eye candy'. They appear to not be 100% reliable if lit. They certainly are meaningless when blinking. They even appear to not be 100% reliable if not lit. mikus -- i think brian was looking for something that would fit on the picture, as a label. can you be more succinct? ;-) paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] wireless lights
mikus wrote: What would a concise and accurate definition of the wireless lights (for 8.2) be? To ordinary users, they are 'Meaningless eye candy'. They appear to not be 100% reliable if lit. They certainly are meaningless when blinking. They even appear to not be 100% reliable if not lit. mikus -- i think brian was looking for something that would fit on the picture, as a label. can you be more succinct? ;-) I really don't have a suggestion. The only succinct one I can think of is 'TBD'. Would kids understand that? I believe the original intent was to show connected with the left one, and in use with the right one. Though the capability is there, correct invoking of those indicators appears not to be there. My suggestion for 9.x developers would be to use the left one to say connected to the internet, and to blink the right one when traffic is active. [The Frame will show users if mesh is connected.] [I think there is *someone* who knows what rapid blinking means, but since I've seen rapid blinking when the XO had a SOLID connection, and seen rapid blinking when the XO had NO connection, I don't think rapid blinking can be easily defined.] mikus p.s. This discussion reminds me that many desktop systems have a disk is busy light. On the XO, it really is not possible (except for a few Activities which change the pointer shape) to tell if the XO is still doing what it had last been told, or if it's gone idle. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
Remove numpy usage from the shell I have not been following this thread - but: There were several Activities (not just Measure) which used 'numeric'. Then 'numeric' was removed from the builds. I don't know what those Activities are using now. My concern is that if they happened to switch to using 'numpy' in place of using 'numeric' then no numpy might also cause ripples. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
numpy will still work fine for activities. Marco On Tue, Sep 9, 2008 at 10:52 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: Remove numpy usage from the shell I have not been following this thread - but: There were several Activities (not just Measure) which used 'numeric'. Then 'numeric' was removed from the builds. I don't know what those Activities are using now. My concern is that if they happened to switch to using 'numpy' in place of using 'numeric' then no numpy might also cause ripples. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Expected date for 8.2.0
Hi Michael, quote who=Michael Stone The final weeks of September seem more likely to me at the moment. If you want to stay up to date, please watch http://wiki.laptop.org/go/8.2.0 Then you'll receive instant notifications. :) Erk. OK, thanks! I'll be travelling out to do the rollouts on the 22nd September. I guess I'll see how it goes :) Also, will you be able to help test our next release candidate(s)? Of course. I'll put the latest joyride on my devel machine now to test. Cheers, Pia -- Software Freedom Dayhttp://softwarefreedomday.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] What's cooking in the XS pot this week (2008-09-08)
On Wed, Sep 10, 2008 at 7:48 AM, Robin Norwood [EMAIL PROTECTED] wrote: So I was poking around looking for something to work on... https://dev.laptop.org/ticket/6731 I'm a little confused about the use case, probably because I'm missing the design discussions that led to this request. Is this for remote login, or for local login? If it's remote login, why not use ssh keys? If it's for local login, it seems a little overcomplicated. Yeah, that's a complicated one :-) Douglas has it mostly cooked, his work probably will merit a review once he pushed the git repo packages out. This is the design doc: http://wiki.laptop.org/go/XS_Blueprints:OTP_root_passwords Is there something else I should spend some time on? I've had one of 'those' weekends, but this should be calming down soon, so I'll have a little free time. Fantastic - Some things in Bugzilla... - Anaconda conflicts with xs-config - Filed as BZ 461550 http://dev.laptop.org/ticket/8366 - Anaconda crash during install with USB-disk-based ks.cfg BZ 461453 - this probably affects all USB-disk based installs. - Anaconda: Install from USB disk: only ISO picked up BZ 461548 - Anaconda: Install from USB disk: Awkward to provide a ks.cfg BZ 461549 Other possible candidates in dev.laptop.org -- mainly stuff that I 'bumped' from the xs-0.5 list because I didn't think I'd have the time... - # 8363 Cannot include beecrypt in Pungi/Revisor build - this is probably a bug worthy of filing in BZ but needs a bit of diagnosis. - #8360 Polish USB boot installer behaviour - #8364 XS Install image is too large - #8365 Customise installer boot menu - #7707 Automate configuration of ejabberd - #7709 ejabberd configuration needs to support domain config changes (needs ejabberd internals knowledge) - #7795 Journalled yum/rpm - #7815 Get rproxy on the XS infrastructure (rpm package is one step :-) ) - #7846 Create a custom 'setup' package to manage uid/gid allocation - #8033 Create xs-release or olpcxs-release package to replace fedora-release cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/server-devel
Libertas firmware on F9 for the XS
Now that I have a F9-based XS build, I've dropped the custom-compiled driver and the firmware for Libertas, hoping to use the stock standard F9. But that might be a bit optimistic :-) After a quick check it looks like the XO images are shipping newer Libertas firmware as you can see below. The XO builds also have a few problems with the Firmware too, so I'm not entirely sure what to do... - F9 libertas-usb8388-firmware-5.111.20.p49-1 - F9/XO (8.2-759) libertas-usb8388-firmware-5.111.22.p18-1 The main question for Libertas experts from the POV of the XS is: what firmware is most stable? On the XS power consumption and sleep are not high priority. Stability and performance over long periods of time is. Also - should I look at replacing / recompiling the driver that F9 ships? (Hoping not...) If you say yes, be aware it is a major maintenance hassle for the already short-handed XS team, so I'll want to know what benefits it brings. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Expected date for 8.2.0
On Wed, Sep 10, 2008 at 10:29 AM, Pia Waugh [EMAIL PROTECTED] wrote: Of course. I'll put the latest joyride on my devel machine now to test. Go for 8.2-759 - that's pretty close to being a release candidate, and it's fairly good. Two things that hit mainstream usage and are being worked on: bad WPA support, odd Out-of-memory situations - activities get a kill -9 without so much as a pardon me. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Expected date for 8.2.0
Hi Martin, quote who=Martin Langhoff On Wed, Sep 10, 2008 at 10:29 AM, Pia Waugh [EMAIL PROTECTED] wrote: Of course. I'll put the latest joyride on my devel machine now to test. Go for 8.2-759 - that's pretty close to being a release candidate, and it's fairly good. Two things that hit mainstream usage and are being worked on: bad WPA support, odd Out-of-memory situations - activities get a kill -9 without so much as a pardon me. Cool, will test later today and come back with feedback. Martin, does that mean the XS release is pushed back too? Cheers, Pia -- Software Freedom Dayhttp://softwarefreedomday.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] F9 XS - Take it for a spin...
On Wed, Sep 10, 2008 at 4:29 AM, Jerry Vonau [EMAIL PROTECTED] wrote: That is an anaconda re-compile time, think I can fix it. Keep me posted on that one. If you are recompiling anaconda... can you tweak the part where it writes ifcfg-ethX to check for existing files and _not_ overwrite them? - Anaconda will need to be told where the ISO is. Pick Hard Drive install, sdb1, and the path is 'iso' add to the kickstart file after interactive: harddrive --partition=sdb1 --dir=iso I don't want to hard-code sdb1 anywhere. That's the real issue, and will probably take a bit of work in anaconda. The 'cdrom' thing is an alias, and must be triggering a what's my first SCSI/ATA device that looks like a cdrom, ah, that's what the user meant bit of logic. Anaconda should have a usbdrive:/ alias... cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/server-devel
Re: Stability and Memory Pressure in 8.2
On 9 Sep 2008, at 05:10, Michael Stone wrote: * We need to determine why we encounter low-memory and out-of-memory situations more frequently than in previous releases. - This means that we need to measure how our memory consumption profile has changed since our previous releases. (cscott observes that we were unable to attack the F-9 image size issues until we were able to quantify the effect of changes we had made or were considering making. Consequently, he suggests that we will be unable to attack our current space consumption problems until we are able to generate good numbers (and displays).) - We need to think carefully about (or measure) whether our memory-consumption patterns have changed. SUMMARY: 759 vs 711 is only eating an extra ~16Mb of ram after a clean boot (no running Activities) Just some very quick general observations between build 771 and build 759 running on XO hardware. Tests were taken after clean reboots; allowing things to settle (~5min before collecting stats); with no Activities or UI use (data collected via a remote ssh session); jabber server was set to an unreachable name and no local salute buddies; net connection was to an AP, with about ~4 other APs visible in my neighbourhood. Using free, the reported buffers/cache is generally the more interesting value. After a clean boot 759 is now using an extra 16Mb (up to 115Mb). The reported total has gone up 80k, so I guess the kernel is a little smaller :-) The reported mem free is down by 8Mb (down to 47Mb) indicating better use of available memory (caches went up by that same ~8Mb, plus extra some buffers by 100K). As far as processes are concerned /usr/bin/sugar-shell is initially the most hungry, 711 it starts out at 12.2% of total used (RES=28m, SHR =12m, DATA=15m). For 759 it's gone up to 14.3% (RES=33m, SHR=14m, DATA=18m). Working down the list journal is next, 711 starts out at 8.7% of total used (RES=20m, SHR=10m, DATA=1m). For 759 it's gone up to 10.1% (RES=23m, SHR=11m, DATA=11m). These figures are with an empty journal due to the break in compatibility when switching between these builds :-( Next for 759 is more interesting as it reflects the changes to rainbow and (I assume) the pre-loading of commonly used modules for Activity efficiency (I need to test Activity usage changes separately from this email**). So /usr/sbin/rainbow-daemon for 711 is just 3.1% (RES=7m, SHR=1m, DATA=6m), while 759 is up at 9.6% (RES=22m, SHR=10m, DATA=11m). Other processes such as /usr/bin/datastore-service, and /usr/bin/ sugar-presence-service, have grown slightly by small amounts, /usr/ bin/sugar-shell-service has shrunk slightly - nothing exciting. FWIW: The pmap tool seems like it might show interesting data for comparisons (lists where a specific PIDs memory is going at a library level). Most of the interesting stuff is hidden in [ anon ] blocks, but knowing all the libs referenced and their size should be of use. Have been experimenting a little with a script to collect and compare data for all processes between builds - need to find a clear way to visualise the results in a useful (not an 'oh my god spiders with pens are attacking') way. **I'll try and test several Activity versions that can run on both builds and see how their individual resources have changed, will post later. --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Expected date for 8.2.0
Hi Martin, Go for 8.2-759 - that's pretty close to being a release candidate, and it's fairly good. Two things that hit mainstream usage and are being worked on: bad WPA support, odd Out-of-memory situations - activities get a kill -9 without so much as a pardon me. I don't think we have anyone working on better WPA support, but I might be wrong -- if this is important to you, make sure to let Greg know you think someone should be tackling it as a release blocker. (Current 8.2 blockers: http://dev.laptop.org/report/32.) - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC library] [Activities] Combined Sugar/XO manual outline
nice pics brian...keyboard stuff looks good too adam On Tue, 2008-09-09 at 13:04 -0400, Brian Jordan wrote: What would a concise and accurate definition of the wireless lights (for 8.2) be? This information seems to suggest the lights aren't working how they ideally would http://wiki.laptop.org/go/Power_Management#Wireless_Lights Brian On Tue, Sep 9, 2008 at 12:55 PM, [EMAIL PROTECTED] wrote: brian wrote: Hi all, See these diagrams: http://dev.laptop.org/~bjordan/screenshots/Picture%2083.png http://dev.laptop.org/~bjordan/screenshots/Picture%2084.png should the wireless lights be labeled? paul =- paul fox, [EMAIL PROTECTED] ___ Library mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/library ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Update ejabberd package
On Wed, Sep 10, 2008 at 1:28 AM, Guillaume Desmottes [EMAIL PROTECTED] wrote: As mentioned few weeks ago, I created an updated version of the ejabberd XS package. Excellent. I'll give it a spin asap, now that the F9 based XS is in better shape. This package still suffers shared roster bugs but after lot of tests they appear to be upstream problems and should not be a regression comparing to the current package. I think it would be worth to consider inclusion of this new package to XS for wider testing. Can you give me a bit of info on how much you've tested it internally. Also, I'll be looking for hints on how to use Daf's new testing tools effectively... (any links, clues...?) cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/server-devel
Re: Expected date for 8.2.0
On Wed, Sep 10, 2008 at 11:11 AM, Pia Waugh [EMAIL PROTECTED] wrote: Martin, does that mean the XS release is pushed back too? XS-0.4 is already out and done -- safe and sane to install, and includes a facility that you can use to install the OS updates to the laptops. There is also an extra rpm package (being finished now) that you can use to serve activity updates. Both require a bit of manual intervention to use the local server, but should be a bit easier for large numbers of XOs than a purely USB-based upgrade. (Unless you are reimaging, and you have a lots of USB keys!) XS-0.5 will be out end of Sept or early days Oct. Hve you still got those notes on proxy configuration? I want them :-) m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Expected date for 8.2.0
Hi Martin, quote who=Martin Langhoff XS-0.4 is already out and done -- safe and sane to install, and includes a facility that you can use to install the OS updates to the laptops. There is also an extra rpm package (being finished now) that you can use to serve activity updates. Both require a bit of manual intervention to use the local server, but should be a bit easier for large numbers of XOs than a purely USB-based upgrade. Ok, cool. XS-0.5 will be out end of Sept or early days Oct. And 0.5 has the backup stuff built in? That was the functionality I was hoping to get by Sept 17th :( I'll play with the beta stuff and see how it goes by the 22nd when I need to implement. Hve you still got those notes on proxy configuration? I want them :-) Sure. Am updating the server installation wiki page right now. I don't have the server up in front of me but will update the page with further details in the next day or two. http://wiki.laptop.org/go/XS_Server_Installation Cheers, Pia -- Software Freedom Dayhttp://softwarefreedomday.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 2410
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2410 Changes in build 2410 from build: 2408 Size delta: 0.00M -ohm 0.1.1-6.18.20080828git.olpc3 +ohm 0.1.1-6.19.20080910git.olpc3 -pygame 1.8.0-1.olpc3.2 +pygame 1.8.0-1.olpc3.3 +SDL_Pango 0.1.2-8 --- Changes for ohm 0.1.1-6.19.20080910git.olpc3 from 0.1.1-6.18.20080828git.olpc3 --- + #7981: Use more efficient EC mask setting. + #8062: Inherit automatic/extreme PM settings from the Sugar profile. --- Included SDL_Pango version 0.1.2-8 --- -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 2411
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2411 Changes in build 2411 from build: 2410 Size delta: 0.00M -kernel 2.6.25-20080909.2.olpc.2dfd32b70c58803 +kernel 2.6.25-20080909.3.olpc.850b087f7daf1b0 -bootfw q2e16-1.olpc2.unsigned +bootfw q2e17-1.olpc2.unsigned --- Changes for bootfw q2e17-1.olpc2.unsigned from q2e16-1.olpc2.unsigned --- + trac #8379 - fixed pretty boot (recently broken) -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Libertas firmware on F9 for the XS
Martin Langhoff [EMAIL PROTECTED] wrote on 09/09/2008 07:04:31 PM: After a quick check it looks like the XO images are shipping newer Libertas firmware as you can see below. The XO builds also have a few problems with the Firmware too, so I'm not entirely sure what to do... - F9 libertas-usb8388-firmware-5.111.20.p49-1 - F9/XO (8.2-759) libertas-usb8388-firmware-5.111.22.p18-1 You are definitely better off using 5.110.22.p18 Also - should I look at replacing / recompiling the driver that F9 ships? (Hoping not...) If you say yes, be aware it is a major maintenance hassle for the already short-handed XS team, so I'll want to know what benefits it brings. The driver on F9 shouldn't be very different from the current XO one. So you are probably safe keeping it. M.___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Libertas firmware on F9 for the XS
On Wed, Sep 10, 2008 at 1:40 PM, Michail Bletsas [EMAIL PROTECTED] wrote: - F9 libertas-usb8388-firmware-5.111.20.p49-1 - F9/XO (8.2-759) libertas-usb8388-firmware-5.111.22.p18-1 You are definitely better off using 5.110.22.p18 With my release-manager hat on: can I have more info to help me decide? I just checked and the firmware on the last F7-based build was 20.p49, same as F9, so staying with it means I am dealing with a known quantity... - is there a good changelog between 20.p49 and 22.p18 ? - with 20.p49 the AA dies overnight, does 22.p18 fix this? - any notes from stability testing done with 22.p18? cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 2412
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build2412 Changes in build 2412 from build: 2411 Size delta: -0.13M -xapian-core-libs 1.0.7-1.fc9 +xapian-core-libs 1.0.7-1.fc9.1 -- This mail was automatically generated See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a comparison ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Closing up 8.2.0.
Dear devel@, This is your notification of our serious intent to release 8.2.0 within the next three weeks, if possible. * This week, we intend to publish an unsigned raw OS and an unsigned G1G1 derivative image for testing. We will begin our the first-boot activation security audit on this image. We also hope to publish draft release criteria. * Next week, we hope to feel ready to publish a signed candidate raw OS and signed G1G1 derivative image. These candidates will undergo widespread testing and will be at genuine risk of being released. * PLEASE offer your tickets under the 'approval for release' action if you have changes that need to be included. See http://wiki.laptop.org/go/Trac_ticket_workflow for details. * PLEASE continue to offer the same dedication and contribution quality you've demonstrated of the last four weeks as you fix blockers, polish, analyse memory-pressure, conduct exploratory and systematic testing, and improve our documentation -- you're doing wonderful work and we're all going to really proud (and glad!) of it in just a few short weeks. Thanks, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Stability and Memory Pressure in 8.2
On 10 Sep 2008, at 00:11, Gary C Martin wrote: SUMMARY: 759 vs 711 is only eating an extra ~16Mb of ram after a clean boot (no running Activities) **I'll try and test several Activity versions that can run on both builds and see how their individual resources have changed, will post later. OK, news is not great on the Activity front... SUMMARY: 759 vs 711 each Activity instance in 759 consumes an average of 1Mb more memory than the same Activity running in 711, with Write-57 reportedly taking significantly more than that (perhaps ~7Mb). Is top and/or ps memory usage calculated in the same way between these builds? Could make collecting real data pretty painful. Tests were taken after clean reboots and allowing things to settle (~5min); five activities were launched in order Moon-4, Write-57, Record-57, Paint-20, and Calculate-23; Journal was made the current Activity and the view was switched to home; data collected via a remote ssh session. Wanted to test Browse as it's a known memory eater (well most browsers are), but will need to dig out the most recent version that works with 711 for a reasonable comparison. With all five Activities launched, free buffers/cache reported 5m more memory was being used under 759. Looking at each Activity's foot print shows 759 all having less shared memory, and more resident and data memory. Write-57 759 - 15.5% (RES=35m, SHR=13m, DATA=20m) 711 - 12.4% (RES=28m, SHR=15m, DATA=11m) Record-57 759 - 14.2% (RES=32m, SHR=14m, DATA=64m) 711 - 13.1% (RES=30m, SHR=16m, DATA=61m) Calculate-23 759 - 10.6% (RES=24m, SHR=8m, DATA=15m) 711 - 10.1% (RES=23m, SHR=10m, DATA=11m) Paint-20 759 - 10.1% (RES=23m, SHR=8m, DATA=14m) 711 - 9.6% (RES=22m, SHR=10m, DATA=10m) Moon-4 759 - 9.7% (RES=22m, SHR=8m, DATA=13m) 711 - 9.2% (RES=21m, SHR=11m, DATA=10m) Well, I was hoping to see the numbers go the other way with the rainbow fork trick sharing more module code between Activities. Could be worse I guess – I should also test opening N instances of the same Activity and see which way memory usage has moved in that scenario. --Gary P.S. No body spotted my intentional 771 mistake in the last email, it was of obviously meant to be 711 :) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Wellington testers + Activities vs 8.2-759
[EMAIL PROTECTED] said: There is another bug somewhere in the network stack. With my Belkin PreN router (MIMO chpset), every connection attempt fails which is initiated automatically (asks for a password which almost never works). When I wait until the XO gives up connecting and then click on the AP, it succeeds 100% (gets the password from networks.cfg). It looks like a big fat race condition to me, but unfortunately I do not even know where to start looking at the source so I will not fix it that is sure. I've got a Linksys WRT54GL using stock firmware and WPA 2. There are no other XOs or XO-servers nearby. I've seen up to 4 of my neighbors WiFi boxes. Usually there are only one or two. I've rebooted about a dozen times in the past few days. It connected cleanly all but once. That time, it connected after I poked Connect on the right blob. Is there some place I can look for more info after it doesn't work? -- These are my opinions, not necessarily my employer's. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Bundle activity
Hello all, I am one of the students who will be working on the Bundle activity suggested by Eben Eliason. I understand that the activity should be designed to manage a variety of archive formats (zip, tar, gz, etc.), and it should support both the extraction of files from an archive into the Journal as well as linking a set of entries from the Journal into a bundle. Also, I see a few additional details are provided in its wiki [ http://wiki.laptop.org/go/Bundle_(activity)]. Is this an active project right now? If not, our team would like to start working on it soon, but first we are looking for feedback on functionality, how it should integrate with the Journal, UI particulars, etc. If this project is not currently active, we are eager to hear any helpful input you might have. Thanks, Matt ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] Update ejabberd package
On Wed, Sep 10, 2008 at 11:14 AM, Martin Langhoff
[EMAIL PROTECTED] wrote:
Can you give me a bit of info on how much you've tested it internally.
Also, I'll be looking for hints on how to use Daf's new testing tools
effectively... (any links, clues...?)
And also - I am *extremely* interested in hearing from you and Daf
what the memory usage is like. Rough numbers are ok - and bad news are
ok too. In fact, I want to have a good picture of what the bad news
are...
From what I understand reading #5313, there are 2 factors in memory usage
- number of entries in the roster ('all', or 'online')
- number of users connected
How does the memory usage scale as those two grow?
cheers,
m
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel
[Server-devel] Follow up on my Moodle plans
I've opened this thread on the Moodle forums... http://moodle.org/mod/forum/discuss.php?d=105466 cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] How does anaconda decide to upgrade vs install? (Cannot upgrade F7 to F9)
On Wed, Sep 10, 2008 at 4:48 AM, Jerry Vonau [EMAIL PROTECTED] wrote: Martin Langhoff wrote: On Tue, Sep 9, 2008 at 3:37 PM, Martin Langhoff [EMAIL PROTECTED] wrote: - The development version of the OLPC school server - a F9-based spin. Oddly, the problem seems to be with the custom F9 XS spin. If I boot using the official F9 DVD, it offers to upgrade, so... Think if you keep the name Fedora .discinfo should match the product compare the .discinfo files in the root of both disks and indeed, that's the case. Thanks for the hint. It gets matched with /etc/redhat-release from the fedora-release package... cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] How does anaconda decide to upgrade vs install? (Cannot upgrade F7 to F9)
On Wed, Sep 10, 2008 at 5:22 PM, Martin Langhoff [EMAIL PROTECTED] wrote: and indeed, that's the case. Thanks for the hint. It gets matched with /etc/redhat-release from the fedora-release package... Now, further nots sparing the anaconda folk XS-specific stuff. The F7-based versions of the XS called themselves Fedora. I think it's time to start calling ourselves XS properly. This means that - We need to define a name. 'OLPC School Server' is my pick. First hit on google is correct, whereas OLPC XS has too many caps, and points to discussion about the hardware Wad planning back in the day. - We need to replace the fedora-release RPM with xs-release for future upgrades to work. - Optional but nice - add a menu entry in the isolinux.cfg that passes 'upgradeany' - Mention it in the release notes and install instructions -- either the boot menu option or adding 'upgradeany' manually. cheers, martin -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [mule-dev] Re: [mule-scm] [mule] [12630] branches/mule-2.x/modules/builders: make the servlet API dependency provided so it doesn't end up in the distributions.
Daniel Feist wrote: Doesn't the jetty transport need the servlet-api dependency? It does but IIRC it gets its own servlet API dependency as a transitive one of jetty. -dirk - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
