Re: XO frequently hangs on shutdown w/ 0.82
On Wed, 2009-06-03 at 14:28 +0200, Tomeu Vizoso wrote: On Wed, Jun 3, 2009 at 14:21, Bryan Berry br...@olenepal.org wrote: I am curious if a number of other deployments have encountered this problem or just us. We find that the XO occasionally hangs on shutdown. We are using 0.82 I have created a ticket for this http://dev.laptop.org/ticket/9319 I realize that OLPC has roughly zero resources to fix problems like this. I would really appreciate it if someone could let me know how difficult a problem this is. If it is relatively easy, we could try to fix it ourselves. Maybe you are seeing the issue discussed here? http://lists.laptop.org/pipermail/devel/2009-May/024414.html Regards, Tomeu I believe that is the same error we are encountering. Sorry for the late reply. sorry i didn't provide a more detailed message. I seem to encounter every time I am really busy attacking some other problem. This image describes my problem exactly http://wiki.laptop.org/images/8/8e/Xo_freeze_on_shutdown.png waiting for X server to shutdown . . xinit: unexpected signal 15 It looks like there are # of tickets related to this problem. Is there already a fix somewhere that I can easily apply? ;) -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
The kernel init improvements will certainly bring 15 other seconds. Maybe some parallelisation of the sysvinit will save some time, say 5 seconds (low end estimation) Parallelization will not help at all if you are using JFFS2. The low level NAND driver that JFFS2 uses busy waits for I/O, and then JFFS2 is CPU-bound on the decompression step, preventing any useful concurrency. The busy-wait could be changed to an interrupt - if only someone had time to do the work and test it extensively. The decompression is going to be CPU bound no matter what you do, so the only option is to arrange for the important files not to be compressed (thus increasing the NAND footprint). Hi Guylhem! What I have been told: The busy waiting happens because there is no scatter-gather support in the NAND driver so the interrupt rate is high and it is faster to busy wait than to context switch. Probably it would help to interrupt for large IO and busy wait for small IO but it needs testing. I promise you that if you happen to make the required efforts to speed up booting then I will finish my fixed LZO decompressor code. It would make reading compressed files actually faster, just I am not a Linux kernel developer so integrating that with Linux would be your job. BTW why the doctors cannot just close the lid and open when needed? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
On Thu, Jun 4, 2009 at 3:41 AM, Guylhem Aznar o...@guylhem.net wrote: Of course I do, but IMHO there are also some things that could have been done differently. Ah, hindsight is so easy ;-) As Mitch's reply shows, we have been looking at the boot times and studying any low-hanging-fruit there. Your stated goal allows for a couple of options... see below. on a SQL database (which needs ~600 Mb of flash total). I'm more of a debian guy, so I took what I knew to have a working base which can be improved. Maybe try deb-xo on an SD card? As Mitch mentions, booting from SD skips various steps that are slow on our platform. Pretests results show a usage pattern where doctors prefer to power on the laptop when some specific information is needed. This behaviour is How about suspend or hibernate? So I see a boot delay that could be easily cut by half, You see lots of things we'd like to have! Have a read of Mitch's reply, there are several spots where you could help us. martin -- martin.langh...@gmail.com mar...@laptop.org -- 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: Bootloader question
I will try fedora 11, if only to have a good refence point. But since you said many of the speedups where dependant on kernel fixes, how is 2.6.29 doing on the XO? Could anyone using f11/2.6.29 on the XO give some feedback ? Off the top of my head from the last time I tested it sound and camera don't work, and there are needed patches for the display DCON, some i2c bus stuff and power saving. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
Martin Langhoff wrote: Easily? Yeah, right. Well, he can show us how it's done. I'll definitely be impressed :-) My point is that, while each individual step is rather straightforward, requiring no new technology, putting together all the pieces to accomplish the goal requires a lot of work and testing. It's a build/packaging/release engineering job that touches many aspects of the system - basically a mini-distro. In my experience, creating a coherent release containing changes to lots of disparate system components is anything but easy. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
On Thu, Jun 4, 2009 at 10:36 AM, Mitch Bradley w...@laptop.org wrote: My point is that, while each individual step is rather straightforward, A ton of careful detail work. As you point out, kernel, firmware and distro hackers have been looking at this for a while, and there are no obvious easy wins left. If Guylhem is prepared to help with a few of those steps, things do get better for everyone. Every little step helps... cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- 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: Bootloader question
I'm thinking about ext4, but I must confess that my experience with ext2 has been pretty frustrating. The ext2/3 on-disk format has sprouted many new features over time. Supporting people who plug in disks that are formatted with the latest fancy feature, then complain that an old firmware release fails to work with it, is difficult. Would the patch that was done to add support to grub for ext4 be of any use to you for reference for adding support? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
I'm not using sugar. The OLPC will be used [by doctors] to access drug information, so I made some different choices. At the moment, I am using a bootstrapped lenny where I removed everything I could. No udev, no hotplug but a custom made script to provide the firmware and do automounts, (etc). Going straight into X to run an old opera version (easier on ram use) Um, you're not using OLPC hardware to teach kids, but because someone gave it to you for free? It's not appropriate -- an ordinary netbook would be much better -- but you're bashing it to fit. By the time you're done, there will be nobody who understands how it works except you. (0) How does your work help OLPC reach its goals? Or do you just want us to help you, while you provide no help to us? (1) Wouldn't the doctors be better off getting a thick printed book? If you're really set on doing this with a computer, how about a US$300 Dell Mini 10v, with a 120GB hard drive, 1GB RAM, and modern processor? Or a US$330 Acer Aspire One 10.1 with 160GB and similar specs? It should be able to resume from disk-based hibernation in seconds, and easily be programmed to hibernate when the lid is closed. On my Acer, stock Ubuntu 9.04 resumes from hibernation in about 35 seconds, including 2 sec of grub menu delay, and there's lots of upstream interest if you find ways to speed it up. Or if you suspend to RAM, it wakes up in 4 seconds, but takes more power while it's closed. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
On Thu, Jun 4, 2009 at 5:55 AM, Mitch Bradley w...@laptop.org wrote: 18 seconds to initrd load dominated by decompression time. Eliminate the initrd ... I'm working on the initrd a but so tested a few things today. Once under linux, a cold-cache read of the initrd takes ~300ms, and the decompression about 1s. Changing the compression to '-1' (fastest) shaves maybe 200ms. OFW doesn't like non-gzipped initrds ;-) I'm tempted to say that reading/uncompressing the initrd is to blame only for about 1.3s -- probably 2s if we count cpio's work. This work is being carried out by OFW, which doesn't seem to be any slower -- following the messages on screen, the 'reading ramdisk' step doesn't take more than 2s. m -- martin.langh...@gmail.com mar...@laptop.org -- 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
olpc-update 'updates' for antitheft
If you head to http://dev.laptop.org/git/projects/olpc-update/ - you'll see a string of updates, as follows: - It now accepts sig02 formatted leases (based on dsd's patch, adding sig02 support). - It will set the RTC if the OAT server gives us a signed time, and our RTC differs by more than a day. (For smaller deltas NTP is boss.) - We now query a list of OAT servers - by default it will try 'schoolserver' and 'antitheft.laptop.org'. - The file /security/oat-server overrides the 'antitheft.laptop.org' entry, so a local team can say 'antitheft.ceibal.gob.uy' for example. - If the OAT server says 'stolen' (always in a properly signed message), the laptop removes any lease keys it may have and halts. It won't remove /security/develop.sig so if you have a developer key, it doesn't actually affect you. These are major changes -- reviews welcome. m -- martin.langh...@gmail.com mar...@laptop.org -- 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
olpcrd: during activation set RTC
I've just pushed to http://dev.laptop.org/git/users/martin/olpcrd-rootskel.git an update that teaches the initrd to ask the server for a signed time, and reset its RTC to it. This tests well with the clock wildly ahead and wildly behind -- I'm hopeful that it'll help with RTC problems in the field. For the patches to work, busybox-udeb needs to get rebuilt with hwclock and date commands. Attempts to slip in the actual hwclock and date binaries from lenny didn't work -- they seem be incompatible with the libc (from libc6-udev). More details in the commit message and diff: http://dev.laptop.org/git/users/martin/olpcrd-rootskel.git/commit/?id=73a7df8edaeaaf6654032b235d7c59c054e004b6 cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- 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: [IAEP] OLPC Volunteer Infrastructure Group Meeting: [Today]
Dogi, Can you post a link to the logs? david On Tue, Jun 2, 2009 at 1:05 PM, Stefan Unterhauser d...@laptop.org wrote: The Volunteer Infrastructure Group (/gang) Meeting is today (June 2th) at 4pm (EST) The Volunteer Infrastructure Group is a team of Volunteer Sysadmins who help maintain services and systems around OLPC and the OLPC/SugarLabs community. The weekly VIG meeting is an excellent chance to get involved, or to be aware of upcoming projects. http://wiki.laptop.org/go/OLPC:Volunteer_Infrastructure_Group http://vig.laptop.org/wiki/index.php/User:Dogi http://idea.laptop.org/ideatorrent/ideatorrent/vig/ http://embed.mibbit.com/?server=irc.oftc.netchannel=%23olpc-adminsettings=12a698505c860f99a6ad1051c57975f9noServerTab=falsenoServerNotices=truenoServerMotd=truenick=Guest Agenda: * backup: new VM for streaming to a robot tape solution * pinguin: new www * meeting: new structure and meeting.sugarlabs.org * vig and wiki (testwiki): migration plan * idea: help promote this idea function * rt: migration plan * maps: there new datas on deployments * bigsister: new VM on w91 Meeting Details: Date: June 2th, 2009 Time: 16:00 EST Location: irc.oftc.net #olpc-admin or click on - http://embed.mibbit.com/?server=irc.oftc.netchannel=%23olpc-adminsettings=12a698505c860f99a6ad1051c57975f9noServerTab=falsenoServerNotices=truenoServerMotd=truenick=Guest ciao dogi ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Olpc-open] Videos of XO 1.5 in Taipei
If the rushes are in PAL DV, this may be useful: $ ffmpeg2theora rawfootage.dv -x 352 -y 288 -v 2 -S 0 -K 128 -c 1 -H 32000 -o rawfootage.ogv Sean On Tue, Jun 2, 2009 at 5:32 PM, Seth Woodworth s...@isforinsects.com wrote: I've been emailing back and forth with Charbax, he's limited for bandwidth while still filming in Taipei, but he will be uploading the HD videos to Dailymotion tomorrow (Taipei time). But I will be asking Sebastian about getting them on olpc.dailymotion.com and/or open.dailymotion.com as ogg videos. Once they are up as ogg, Charbax will post links to the ogg version in the descriptions on the current flash copies. --Sethww On Tue, Jun 2, 2009 at 8:08 AM, Bastien bastiengue...@googlemail.com wrote: Or maybe olpc.tv can send its videos to our contact at Dailymotion? They can encode it in ogg and make them available for kids at: http://olpc.dailymotion.com Don't hesitate. rihowa...@gmail.com rihowa...@gmail.com writes: It would be nice if olpc.tv used ogg vorbis. Is there any way to get the videos of XO 1.5 in Taipei, etc. posted in a linux friendly format? XO users are excluded from viewing material about the XO. Where the FOSS are you!! In other words FOSS you..tube, use Ogg Vorbis!! -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Olpc-open mailing list olpc-o...@lists.laptop.org http://lists.laptop.org/listinfo/olpc-open ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Videos of XO 1.5 in Taipei
I still don't see how two SD cards are required. One can swap to a given subset of an SD card and only wear out those sectors. But no, the SD card is only temporary until we have the SDIO wireless card in place AFAIK. 2009/6/3 Tiago Marques tiago...@gmail.com On Tue, Jun 2, 2009 at 10:51 PM, da...@lang.hm wrote: On Tue, 2 Jun 2009, Tiago Marques wrote: Hi all, I have some questions to whom might be able to answer them. It would be cool to have that 2nd SD card slot(?) at the top available in the final design, are you considering that option? I doubt it for two reasons 1. they are trying to avoid making any changes to the plastic I would have some uses for the slot, even if internal, like a SWAP device. Also could have dual boot in there, extra storage for countries that would require it, etc. 2. the card slot on the top would be exposed to the elements, even when the laptop is closed up. something that they were trying to avoid. Exposed if internal and concealed? Best regards, Tiago Marques David Lang The VX855 seems able to handle it but the C7-M might need a heatspreader. In those conditions how hot/cool are the chips running while in load? At first sight, it would seem the fliped chip designs would require some kind of metalic heatspreader. Also, will that VGA pinout be relatively accessible in the final design? Or is it too much of a cost/hassle to have it in the final design, even if the connectors not soldered? Best regards, Tiago Marques On Tue, Jun 2, 2009 at 1:06 AM, Charbax char...@charbax.com wrote: Posted to http://olpc.tv Filming Pixel Qi and more in just a bit.. -- Charbax, Nicolas Charbonnier ___ 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 ___ 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: Bootloader question
As for speedups, I see 2 different ways : a) using a SD with a fat partition + ext2 filesystem b) using the nand with a fat partition + ubifs - this requires 2.6.29 which is not ready yet. A FAT partition will not work well on the raw NAND of XO-1, because of blocksize, erase block size, and wear leveling issues. It would be better to use a smallish boot partition of say 10 MB, formatted in JFFS2. JFFS2 is fine for small partition sizes. It only starts to be troublesome with large partitions. It's hard to chose at the moment. I guess I'll stick to b) and hope 2.6.29 makes it better, and if it doesn't go for a) Mitch says there's very little time to gain and provides an excellent analysis. I just have a final question there : regarding the 2 seconds SPI flash slowdown, is there a way to boot from the NAND (without reading the full SPI) if there's a special partition at the beginning, or if there isn't or if a special key is pressed at boottime, go back to SPI OFW? That won't work. The only way that the CPU can start is by fetching from SPI FLASH. If you wanted to get into the firmware business, you could write a smallish NAND reader that loads from SPI FLASH then reads the rest from NAND. Doing so would require a substantial amount of detailed knowledge about the hardware, would be difficult to debug and maintain, would require great care to prevent bricking the machine if the NAND contents were overwritten, and might reduce the startup time by 1 second. To sum up what I've read in this thread, what should be done in any case : a) discarding jffs2 b) discarding initrd c) storing the kernel uncompressed in an uncompressed small partition Actually, there is an alternative to discarding the initrd. The trick would be to ensure that most of the stuff in the initrd is reused during runtime, thus avoiding the need to reload the same stuff later. I've done that with embedded systems, in which the entire filesystem is included in initrd, copied to a ram FS, and used forever. Loading initrd from a small JFFS2 partition is just as fast as loading the same amount of code/libraries/files from any other filesystem, and perhaps even faster, since the reads are likely to be sequential and can be done in large chunks. The case in which initrd is wasteful is when a large amount of stuff from initrd is discarded and then reloaded again from a different FS. And yes, this seems trivial to do - the low hanging fruit. Please, can we stop using the word trivial? Although you might not mean it that way, the subtext of saying things are trivial or easy is that the people who didn't do these obvious things in the past are stupid or lazy. It is true that many of the speedup techniques that have been discussed are individually easy to understand and think about, but putting together all the pieces and making them work together flawlessly requires a substantial amount of effort. I would be pleased to see someone make that effort, but asserting that the whole deal is easy is disrespectful to the people who have spent countless hours packaging the various OLPC distributions and sorting out many hundreds of little problems. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
olpc-2.6 2.6.30-rc5 /dev/rtc0 broken
Hi Deepak, I'm seeing one of these commits: http://dev.laptop.org/git/olpc-2.6/commit/?h=2.6.30-rc5id=351881b12fa5628ee44f27dd4d28482b0d66dff4 http://dev.laptop.org/git/olpc-2.6/commit/?h=2.6.30-rc5id=8dc06e452713a214220516649d216fd603888ad9 ... as stopping commands like rtcwake -m mem -a -s 5 from working with error messages like /dev/rtc0 not enabled for wakeup events. I can't bisect any more since 8dc06e45.. doesn't build for me. A before and after set of kernels from my tree[1] may assist in confirming: Before[2] (rtcwake ... behaves as expected): http://www.martindengler.com/~martin/tmp/kernel-2.6.30-20090604.1.olpc.9f05ee9.i586.rpm After[3] (rtcwake ... complains and fails): http://www.martindengler.com/~martin/tmp/kernel-2.6.30-20090604.1.olpc.50da7dc.i586.rpm Martin 1. at http://dev.laptop.org/git/users/mdengler/olpc-2.6/log/?h=2.6.30-rc5-mtd - I've reordered your latest commits a bit to get make olpc-kernel-rpm working before the XO-1/XO-1.5 commits landed. 2. http://dev.laptop.org/git/users/mdengler/olpc-2.6/commit/?h=2.6.30-rc5-mtdid=9f05ee9ba20581e7970683f478e25be594e105ee 3. http://dev.laptop.org/git/users/mdengler/olpc-2.6/commit/?h=2.6.30-rc5-mtdid=50da7dc2f63b6657645bd3a1676bb7d4b44317b0 pgpJ84InY9rst.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
