Re: Why does Sugar mount removable volumes ?
As 1.5 and other portable devices are using SD as their main storage: What is a removable volume ? On Nov 18, 2009, at 1:10 AM, Mikus Grinbergs wrote: > I have the subdirectories for some Activities installed on my > "permanent" SD card (it's in the "external" slot of my XO-1.5). > Os42 is not mounting (at boot) my "permanent" SD card. I > experimented with removing the SD card's entry from /etc/fstab. > > The first time sugar came up (after boot), it did not show the > activities on my SD card in Home View - because that SD card was not > yet mounted at the time sugar started. I did ctl-alt-erase to > restart sugar. Now sugar came up *showing* those activities. > > > What I believe happened: 1) Because the system did not mount the SD > card, sugar the first time could not "link" to the activities on it. > 2) But sugar itself mounted all removable volumes accessible by > the machine, including my SD card. 3) So when sugar started the > second time, those activities could be "linked", and sugar showed > them. Sounds reasonable, given my experience. Sugar is definitely doing the mounts into /media. > My question -- how come Sugar mounts *all* removable volumes ? Why not ? It seems reasonable that a user would want to copy something onto removable media. (BTW, isn't there a more appropriate mailing list for Sugar feature discussions, not that we don't miss the occasional one on devel ?) Cheers, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Why does Sugar mount removable volumes ?
I have the subdirectories for some Activities installed on my "permanent" SD card (it's in the "external" slot of my XO-1.5). Os42 is not mounting (at boot) my "permanent" SD card. I experimented with removing the SD card's entry from /etc/fstab. The first time sugar came up (after boot), it did not show the activities on my SD card in Home View - because that SD card was not yet mounted at the time sugar started. I did ctl-alt-erase to restart sugar. Now sugar came up *showing* those activities. What I believe happened: 1) Because the system did not mount the SD card, sugar the first time could not "link" to the activities on it. 2) But sugar itself mounted all removable volumes accessible by the machine, including my SD card. 3) So when sugar started the second time, those activities could be "linked", and sugar showed them. My question -- how come Sugar mounts *all* removable volumes ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
some os42 impressions
I've noticed "time-outs-from-the-game" with os40 that I had not noticed before. For instance, when I boot with the check game key, the boot process simply stops for more than 50 seconds (just after a message about rtc) before continuing. Sometimes quite trivial commands just stop for a noticeable number of seconds (garbage collection?). And once when I was editing in 'vi', it took about two seconds between a keypress, and the character appearing on the screen. Also, shutdown seems to remove the directory from /media on which a removable volume is mounted. [Before os42, shutdown would remove such a directory if it was created by automount, but *not* if it had been manually created by the user.] The effect is that my "permanent" SD card is no longer being mounted when I boot, even though I have an entry for it in /etc/fstab mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Information on XO-1 power efficiency
On Tue, 17 Nov 2009, John Gilmore wrote: >> Is USB device discover inherently slow? Or is the sloth just handling >> strange cases? Can I speed things up if I only need to verify that devices I >> knew about are still there? > > Bringing up the USB bus is apparently *designed* to take a large > fraction of a second. After you turn on USB bus power, you have to > wait for X hundred milliseconds for the power to stabilize and for any > devices to come out of power-on reset. Ditto after you turn on USB > signalling. I seem to remember a discussion on linux-kernel about USB startup. historicly it waited 500ms (half a second) to allow devices to startup. there was apparently an attempt to shorten this to 100ms to speed up boot and people reported issues with devices not being detected. apparently it's highly dependant on the exact devices that you have, some are MUCH faster than others. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Information on XO-1 power efficiency
On Nov 11, 2009, at 3:04 PM, Hal Murray wrote: > Has anything interesting changed in this area for XO-1.5? YES! XO-1.5 no longer uses any USB devices internally. We used SDIO instead. This not only provides lower power operation to start with, it also should allow us to suspend/resume much faster. The peak bus throughput is much lower than USB 2.0's potential, but still reasonable for 802.11b/g. When we move to 802.11n (probably in a year), the SDIO interface will be more of an issue. Cheers, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Information on XO-1 power efficiency
> How well does sleep-between-keystrokes work if I ignore USB? Pretty well -- but check bugs.laptop.org. That's where our institutional memory of the bugs that prevented full blown suspend exists. Search for "power" or "suspend" or "sleep". If you're serious about working on this, I can spend some time looking in there for the next low hanging fruit. I remember there were some high priority bugs we were trying to shoot. When OLPC had to fire most of the software team for lack of money, and focus down its efforts on what its country partners wanted, Chris and I stopped working on improving power consumption. > Has anything interesting changed in this area for XO-1.5? Lots, though as far as I know, auto-suspend on XO-1.5 is not working yet. > Is USB device discover inherently slow? Or is the sloth just handling > strange cases? Can I speed things up if I only need to verify that devices I > knew about are still there? Bringing up the USB bus is apparently *designed* to take a large fraction of a second. After you turn on USB bus power, you have to wait for X hundred milliseconds for the power to stabilize and for any devices to come out of power-on reset. Ditto after you turn on USB signalling. The way to play with this is to unload the USB module from the XO-1 kernel. Then it won't play any part in suspend/resume. (This will lose you the WiFi.) You'll be left with something that suspends in ~250 ms and resumes in ~400 ms as I recall. Resume time with USB is >900 ms. To fix this, refactor the USB startup code so that it runs asynchronously on resume (i.e. it doesn't prevent the kernel from starting to run user programs). This should produce a kernel that resumes in about the same amount of time, whether or not you have a USB module loaded. The trick is probably to manage this in a way that upstream will accept. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: OS and Firmware testing for XO 1.5 B2
Thank very much for this report. Please trac serious problems! Comments inline, wad On Nov 15, 2009, at 2:51 PM, Tiago Marques wrote: > Hi all, > Here's some data I collected: > > Firmware Q3A13-Q3A15: > - > OS30: > hdparm -t /dev/mmcblk0: ~700KiB/s (buffered), this is too slow > for these cards, should be at least 2MiB/s > > OS32: > Gnash and youtube don't work, just an error screen. This is > for an older codec and newer h.264 > Two battery icons/devices. One works and gets updated, the > other mimics the real battery at boot and stays that way. > Screen corruption in both gnome and sugar, when minimizing > window or using the frame, for instance. > No speaker hum is a plus, contrary to XO-1. When the mic led > is turned on there is a hum with no sound but some piece of software > usually turns both off. Kudos, some power is being saved here see: > http://dev.laptop.org/ticket/9505 > Pretty fast boot times > Slow app load times (perhaps the performance issue found with > hdparm, see below) > hdparm -tT /dev/mmcblk: > cached: 11, 13, 0.75, 0.622, 42, 83, 8.9, 138 > buffered: 1.10, 4.6, 3.86, 3, 4, 2.6, 0.86, 1.28 > Video(flash player 10): > h.264: ok, no skips in sound, ~3-10 fps(rough > estimate) > older(mpeg-2?): very good performance > Speakers don't turn off, sometimes, when phones plugged in, at > OFW playing the boot song. Not surprising, as the speaker mute on headphone insert is now implemented by software (and probably not in OFW). Please trac this as low priority. > OS34: > Still two batteries > Video seems to play at the same framerate as OS32 but h.264 > is stalling a lot, skipping music even. Not network related, video was > buffered more than enough. This was reproduced consistently. > Connects to all my APs fine, which was something > problematic(still is) in the XO-1. Connecting to WPA-EAP wasn't a > problem with Gnome's nm-applet. > > OS40+Q3A16: > KB and touchpad hanged after firmware upgrade, USB worked > fine. Removed the battery. > hdparm -tT /dev/mmcblk: > cached: ~245MB/s, very consistent > buffered: 10.8-16.5, the 16+ MB/s figure is much > more common than the ~10MB/s one (this is excellent! Are you caching > data in RAM somehow?) There is no way this is accurate. It is being cached... > Apps boot reasonably fast now > No screen flash anymore > Jumpy mouse issue seems better but not gone. > Still displays two batteries (mimics on sugar but doesn't > update, shows 0% in gnome) > Mouse cursor not animated on Gnome. > Firefox in Gnome has a too big default "zoom". Fonte size in > Gnome Apps is good. > Browse seems to need an extra level of zoom. > Youtube video (adobe flash) > h.264: ok, no skips in sound, occasional 1s video > stall, ~6-12fps measured with "show video info" option > older: ok, very good performance, no sound skips, > occasional 1s skips on video(not unlike my desktop machine) > Gnash and youtube is a no go. No error now, just a black > screen > > Overall: >Wireless signal seems better over XO-1 >Apps are ***much*** more usable with the extra CPU and RAM. Hasn't > "locked" once due to lack of RAM and swap space, as was common with > the XO-1. >It's a shame browse doesn't let you launch more than one instance > now and there are no tabs. >Switch from gnome to sugar works great. >Hardware seems to suffer greatly from electrical noise coming from > the motherboard, shuts off when opening an app, minimizing apps, > maximizing etc. Perhaps C-states related? Please trac this immediately!!! http://dev.laptop.org Email to devel is interesting, but Trac is the tool for reporting problems like this. This is the first we've heard of something like this. We certainly haven't seen it around here. >CPU doesn't throttle but hits 90ºC when running show-temperature. > Haven't had time to check if it's proper contact or not. 90C is fine for the die temperature (which is what is being reported.) Without throttling and no heat spreader, you would see 120+ Throttling should keep it below 100C > Flash videos: > 480x264, h.264?, http://www.youtube.com/watch?v=Lpvai3DQ0Co - The > video tested up to OS40 was like this, I confirmed it was h.264 when > gnashed gave an error. This one seems like it but since the other one > was pulled down due to copywritght issues, I couldn't confirm. > Framerate seems similar, anyone knows how to check this? > 320x240, not h.264, http://www.youtube.com/watch?v=zeeie9l9taM > > > Best regards, > Tiago > ___ > Devel mailing list > Devel@lists.laptop.org
Re: OS and Firmware testing for XO 1.5 B2: gnash
> Gnash and youtube is a no go. No error now, just a black screen Within the last month, Youtube changed their default player to require Adobe Flash 10, including ActionScript 3. Gnash does not yet implement AS3 properly -- that's why you got a black rectangle. The (shrinking) gnash team is working on this, but they won't have even an internal version that plays today's youtube before the end of November -- maybe much longer. There's a hack though: rewrite the URL from: http://www.youtube.com/watch?v=zeeie9l9taM to http://www.youtube.com/v/zeeie9l9taM That uses the old player. (The videos themselves are unchanged, it's just the stupid stuff around the edges, like the Play/Pause button, that's causing the trouble.) John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Does anyone boot OLPC on nfsroot?
Consider the rdshell boot option so that you can gain control instead of sleeping forever. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Does anyone boot OLPC on nfsroot?
Does the OLPC initramfs "dracut" support nfsroot? It can load from tftp server when I type "boot net". I use OLPC sourse kernel and add support to root on nfs. The initrd.img is original,I didn't change it. the OLPC file is copied from olpc.fth and kernel command lines is "root=/dev/nfs nfsroot=:/ ip:dhcp" The message show that it can get ip form DHCP server. But always stop at "No root device found""Boot has failed,sleeping forever." Does anyone have any idea? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New F11 for XO-1.5 build 42
http://wiki.laptop.org/go/F11_for_1.5 http://dev.laptop.org/~cjb/f11-1.5/os42 Compressed image size: 412.28mb (-0.39mb since build 41) Description of changes in this build: * Kernel fix for keyboard crash over suspend/resume (#9661) Package changes since build 41: -bitfrost-1.0.2-1.fc11.i586 +bitfrost-1.0.3-1.fc11.i586 +jack-audio-connection-kit-0.116.2-1.fc11.i586 -kernel-2.6.31_xo1.5-20091115.1440.1.olpc.ff74321.i586 +kernel-2.6.31_xo1.5-20091117.1739.1.olpc.331d136.i586 -kernel-firmware-2.6.31_xo1.5-20091115.1440.1.olpc.ff74321.i586 +kernel-firmware-2.6.31_xo1.5-20091117.1739.1.olpc.331d136.i586 +libfreebob-1.0.11-5.fc11.i586 -libsndfile-1.0.17-8.fc11.i586 +libsndfile-1.0.20-3.fc11.i586 -readahead-1.5.0-1.fc11.i586 +readahead-1.5.4-1.fc11.i586 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New Synthetic Phonics Literacy Activity
On Wed, 2009-11-18 at 00:33 +0430, Mike Dawson wrote: > Hi All, > > As many of the target areas for the XOs suffer from massive illiteracy > problems, and some live away from where schools will be built during > the time that they grow up and could benefit from a literacy learning > activity using home schooling. > > http://wiki.laptop.org/go/SynPhony > > Norbert Rennert has done work on a prototype Synthetic phonics based > application that can pick out appropriate words from a list according > to learner's levels and the phonics being stressed. Then we have > espeak that can handle text to speech. > > We can migrate this to using HTML 5 for it's database and built it as > an offline application (which could then use any other source to > update word lists etc). We can then define a means to link words to > other media such as images. Looks great Mike! You could also easily migrate to using html5's tag instead of flash. That will make the size of the application much smaller and easier to build and manipulate. It should also improve performance as u won't have to load the flash plugin. What license is SynPhony under? I am busy for next 4 weeks polishing Karma but would like to apply Karma to this -- Bryan W. Berry Senior Engineer OLE Nepal, http://www.olenepal.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New F11 for XO-1.5 build 41
http://wiki.laptop.org/go/F11_for_1.5 http://dev.laptop.org/~cjb/f11-1.5/os41 Compressed image size: 412.67mb (+1.51mb since build 40) Description of changes in this build: * add support for 1.5 B3 machines Package changes since build 40: +bitfrost-1.0.2-1.fc11.i586 -bitfrost-1.0.3-1.fc11.i586 -dracut-modules-olpc-0.2.5-1.fc11.i586 +dracut-modules-olpc-0.2.7-1.fc11.i586 -kernel-2.6.31_xo1.5-20091113.1122.1.olpc.ace10c8.i586 +kernel-2.6.31_xo1.5-20091115.1440.1.olpc.ff74321.i586 -kernel-firmware-2.6.31_xo1.5-20091113.1122.1.olpc.ace10c8.i586 +kernel-firmware-2.6.31_xo1.5-20091115.1440.1.olpc.ff74321.i586 +olpc-bootanim-2.10-1.fc11.i586 -olpc-bootanim-2.9-1.fc11.i586 -olpc-netutils-0.7-1.olpc3.noarch +olpc-netutils-0.8-1.fc11.noarch -olpc-utils-1.0.7-1.fc11.i586 +olpc-utils-1.0.8-1.fc11.i586 -symlinks-1.2-33.fc11.i586 +symlinks-1.4-2.fc11.i586 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 slow disk writes
Good catch, Ben! In fact, I don't think either the XO-1 or XO-1.5 needs to sync before suspend.Maybe before a sleep, but not an aggressive suspend. A more vexing problem is not cutting SD power until it has finished completing its write. To address that problem, I propose trac #9692. Cheers, wad On Nov 17, 2009, at 1:03 PM, Benjamin M. Schwartz wrote: > Daniel Drake wrote: >> Today I tried to figure out why running "sync" often takes 5-10 >> seconds >> or longer. This slows down suspend, where all data is synced to disk. > > On the XO-1, it was necessary to sync before suspend, because there > was no > guarantee that a suspended laptop would reawaken any time soon. On > 1.5 > (and even on XO-1 with newer software) we should have fully working > timed > wakeups. That means the kernel could set a policy of a "sync every 5 > minutes", and wake up out of suspend in order to perform the sync. > This > is, IMHO, actually better than a "sync on every suspend" policy, > because > it enables things like write combining that improve performance and > reduce > flash wear. > > Of course, getting sync to be very fast would also be nice. > > --Ben > > ___ > 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: XO-1.5 slow disk writes
There is no reason to believe that form factor is the crucial difference. I see variation between manufacturers and device class, with little correlation to size (full size vs. micro). Your full size Sandisk is likely to be an extreme III (class 6) versus the class 2 OEM version that we use internally. wad On Nov 17, 2009, at 1:02 PM, Daniel Drake wrote: > On Tue, 2009-11-17 at 18:56 +0100, Sean DALY wrote: >> as a former audio engineer, I was surprised recently to see a unit >> like the Samson R16 for sale: >> >> http://www.samsontech.com/products/productpage.cfm?prodID=2009 >> >> which uses an SD Card as its main memory. 8 track linear PCM audio >> record, 16 track playback. >> >> Of course, it's a case of several large files not lots of little >> ones... but it struck me that there must be some kind of SD r/w >> optimization in a unit like that. > > Another possibility is that SD cards might generally work a lot better > than miniSD ones. At least I have a Sandisk SD card here that > considerably outperforms the Sandisk miniSD card in my XO-1.5. > > Daniel > > > ___ > 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: Devel Digest, Vol 45, Issue 37
Martin, By modifying the jffs2 images directly won't we lose the customized tarball and contents file that the XS uses to provide OS updates to XOs? DSD has a good how to here that illustrates what I mean: http://wiki.paraguayeduca.org/index.php/Construir_OS Reuben On Nov 17, 2009, at 3:54 PM, devel-requ...@lists.laptop.org wrote: Message: 1 Date: Tue, 17 Nov 2009 18:22:00 + From: Daniel Drake Subject: Re: Mounting jffs2 images on F11 / kernel 2.6.31? To: Martin Langhoff Cc: OLPC Devel Message-ID: <1258482120.2738.12.ca...@localhost.localdomain> Content-Type: text/plain On Tue, 2009-11-17 at 19:11 +0100, Martin Langhoff wrote: Has this been seen before? Background: Turns out that using block2mtd, a loop device and some elbow grease, it is reasonably easy to mount jffs2 images on a normal linux host. (This is helping me simplify image-builder...) I saw this before while working with block2mtd on another project and was basically told not to use it. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 slow disk writes
We already tried running the SD interface at half speed to reduce power dissipation. It runs at full speed by default. wad On Nov 17, 2009, at 12:49 PM, Peter Robinson wrote: > Hi Daniel, > >> Today I tried to figure out why running "sync" often takes 5-10 >> seconds >> or longer. This slows down suspend, where all data is synced to disk. >> In all cases that I looked at, the amount of data being synced was >> tiny. >> One example: in one run it had 160kB data to sync and it took 7.7 >> seconds. (blktrace is very handy for figuring this out) >> >> I traced this all the way to the SDHCI driver. These writes are >> typically small and scattered, and our hardware (or the card itself) >> takes a long time to process them. Many of the 1024 byte writes take >> 500-600ms. All other disk I/O is halted during these times. The >> delay is >> purely after submitting the SDHCI write command, and waiting for the >> completion interrupt to arrive. >> >> I then wrote a C application to reproduce the exact set of writes >> from a >> 20-second sync that I logged (using random data, but the same >> sectors, >> sizes and ordering) and reproduced the issue that way. >> >> I also moved the card over to my Dell laptop, ran the same program >> and >> saw the same (terrible) results. >> >> All info here: >> http://dev.laptop.org/ticket/9688 >> >> >> So, I have a feeling that at least with today's generation of miniSD >> cards we're going to be stuck with bad write performance, >> particularly >> for random-style access like this. >> >> One experiment that would be interesting to run would be to try >> this on >> one of the PhoenixBIOS boards, and then try it with the exact same SD >> card on a regular XO-1.5. Just in case... > > You might want to look at some of the SD/MMC frequency patches that he > applies to the kernel for the Nokia Internet tablet devices. I think > the default kernel defaults to a frequency half or even less than > half. The issue that might be encountered is that it doesn't always > work well on low quality SD cards but it would be at least worth > experimenting with it. > > His blog is here > http://intr.overt.org/blog/ > > The patches and a readme about them are here for the Nokia device (I > suspect they're just about the same everywhere). > http://intr.overt.org/5.2008.43-mmc-kernel/ > > Hope that can be of some help, or at least head you in the right > direction. > > Cheers, > Peter > ___ > 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: Mounting jffs2 images on F11 / kernel 2.6.31?
On Tue, Nov 17, 2009 at 07:36:03PM +0100, Martin Langhoff wrote: so there is a reasonable chance that .31 speeds our boot on XO-1. Hoping the F11/XO-1 builds include a .31 sometime... :-) 2.6.31 has been pretty unstable (WLAN stops working, X server crashes) for me, but at least I got resume and DCON working again. :) YMMV. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Fwd: XO-1.5 slow disk writes
On Tue, Nov 17, 2009 at 6:05 PM, Peter Robinson wrote: > On Tue, Nov 17, 2009 at 6:02 PM, Daniel Drake wrote: >> On Tue, 2009-11-17 at 18:56 +0100, Sean DALY wrote: >>> as a former audio engineer, I was surprised recently to see a unit >>> like the Samson R16 for sale: >>> >>> http://www.samsontech.com/products/productpage.cfm?prodID=2009 >>> >>> which uses an SD Card as its main memory. 8 track linear PCM audio >>> record, 16 track playback. >>> >>> Of course, it's a case of several large files not lots of little >>> ones... but it struck me that there must be some kind of SD r/w >>> optimization in a unit like that. >> >> Another possibility is that SD cards might generally work a lot better >> than miniSD ones. At least I have a Sandisk SD card here that >> considerably outperforms the Sandisk miniSD card in my XO-1.5. > > Yes, that's quite possible as well. There's all sorts of different > speeds for the cards. I've never really seen a fast mini or micro SD > card. And I've also never seen an SD one. Even USB drives share the same problem and some SSDs. See: http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=17 If you manage to find SD cards with a proper FTL with some cache, I doubt it will be cheap. Perhaps some caching done in RAM to coalesce writes where possible? A guy has implemented that for windows but I can't seem to find the link. Best regards > > Peter > ___ > 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: New Synthetic Phonics Literacy Activity
On Tue, Nov 17, 2009 at 12:03, Mike Dawson wrote: > Hi All, > > As many of the target areas for the XOs suffer from massive illiteracy > problems, and some live away from where schools will be built during > the time that they grow up and could benefit from a literacy learning > activity using home schooling. > > http://wiki.laptop.org/go/SynPhony Excellent. > Norbert Rennert has done work on a prototype Synthetic phonics based > application that can pick out appropriate words from a list according > to learner's levels and the phonics being stressed. Then we have > espeak that can handle text to speech. > > We can migrate this to using HTML 5 for it's database and built it as > an offline application (which could then use any other source to > update word lists etc). We can then define a means to link words to > other media such as images. > > We have no shortage of potential test beds here in Afghanistan that > could benefit massively, illiteracy is at the heart of many problems > here. If we can support the mass production of literacy learning > experiences then that could have a significant positive impact. > > Contributors both in terms of those involved in linguistics and > literacy (we have people for Dari and Pashto) as well as those > familiar with the involved technologies would be most appreciated. I > will myself be focusing on this and have reasonable experience with > Javascript, SQL, etc. We are working on a Dari version of espeak that > is in prototype at the moment. I will be happy to help in any way I can. I have worked with the espeak developers on ideas for karaoke-style marking of the text being read, and I can help document the Activity for teachers and other stakeholders. > Regards, > > -Mike > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > -- Edward Mokurai (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) Cherlin Silent Thunder is my name, and Children are my nation. The Cosmos is my dwelling place, the Truth my destination. http://www.earthtreasury.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New Synthetic Phonics Literacy Activity
Hi All, As many of the target areas for the XOs suffer from massive illiteracy problems, and some live away from where schools will be built during the time that they grow up and could benefit from a literacy learning activity using home schooling. http://wiki.laptop.org/go/SynPhony Norbert Rennert has done work on a prototype Synthetic phonics based application that can pick out appropriate words from a list according to learner's levels and the phonics being stressed. Then we have espeak that can handle text to speech. We can migrate this to using HTML 5 for it's database and built it as an offline application (which could then use any other source to update word lists etc). We can then define a means to link words to other media such as images. We have no shortage of potential test beds here in Afghanistan that could benefit massively, illiteracy is at the heart of many problems here. If we can support the mass production of literacy learning experiences then that could have a significant positive impact. Contributors both in terms of those involved in linguistics and literacy (we have people for Dari and Pashto) as well as those familiar with the involved technologies would be most appreciated. I will myself be focusing on this and have reasonable experience with Javascript, SQL, etc. We are working on a Dari version of espeak that is in prototype at the moment. Regards, -Mike ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Serial auto-enable works on B3
BTW, after removing the power resistor, you must be careful to clean off excess solder, because the crucial gap is small and "embedded" in the large pads. I had to use ChipQuick to get the resistor off, then I had to add regular solder back to the pad to alloy with the ChipQuik, as ChipQuik doesn't flow onto solder wick very well. Richard A. Smith wrote: >> With the dongle connected to the serial connector on the B3, it comes up >> with serial enabled. Disconnected, serial is disabled. >> >> I haven't tried the pencil-enable technique. >> > > The new batch of serial adapters with this enable signal built in should be > ready in about a week or so. 1cc will have a small stash of them and the > rest will be available from the association and spare parts places like XO > Explosion, etc. > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Serial auto-enable works on B3
> With the dongle connected to the serial connector on the B3, it comes up > with serial enabled. Disconnected, serial is disabled. > > I haven't tried the pencil-enable technique. The new batch of serial adapters with this enable signal built in should be ready in about a week or so. 1cc will have a small stash of them and the rest will be available from the association and spare parts places like XO Explosion, etc. -- Richard A. Smith One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Mounting jffs2 images on F11 / kernel 2.6.31?
On Tue, Nov 17, 2009 at 7:11 PM, Martin Langhoff wrote: > Ubuntu Kinky Koala w 2.6.30 mounts our os802.img (and edits it) like a > charm... but my F11/linux-2.6.31 box doesn't like it in the least: There is another difference between the 2 kernels - 2.6.30 mounts it in 6.4 seconds, hot cache. - 2.6.31 mounts it in 1.16 seconds, hot cache so there is a reasonable chance that .31 speeds our boot on XO-1. Hoping the F11/XO-1 builds include a .31 sometime... :-) 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: Mounting jffs2 images on F11 / kernel 2.6.31?
On Tue, Nov 17, 2009 at 7:22 PM, Daniel Drake wrote: > On Tue, 2009-11-17 at 19:11 +0100, Martin Langhoff wrote: > I saw this before while working with block2mtd on another project and > was basically told not to use it. Ok. The mismatched eraseblock config is fixed. block2mtd seems to be the thing to use for larger-than-ram images, and the maemo ppl use it. I'll keep an eye out for data corruption -- but it seems to be working pretty well so far. 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: Mounting jffs2 images on F11 / kernel 2.6.31?
On Tue, 2009-11-17 at 19:11 +0100, Martin Langhoff wrote: > Has this been seen before? > > Background: Turns out that using block2mtd, a loop device and some > elbow grease, it is reasonably easy to mount jffs2 images on a normal > linux host. (This is helping me simplify image-builder...) I saw this before while working with block2mtd on another project and was basically told not to use it. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Mounting jffs2 images on F11 / kernel 2.6.31?
On Tue, Nov 17, 2009 at 7:11 PM, Martin Langhoff wrote: > Ubuntu Kinky Koala w 2.6.30 mounts our os802.img (and edits it) like a > charm... but my F11/linux-2.6.31 box doesn't like it in the least: I guess the default eraseblock has changed. Fixed with: echo "/dev/loop0,128KiB" > /sys/module/block2mtd/parameters/block2mtd 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
Mounting jffs2 images on F11 / kernel 2.6.31?
Ubuntu Kinky Koala w 2.6.30 mounts our os802.img (and edits it) like a charm... but my F11/linux-2.6.31 box doesn't like it in the least: dmesg: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0001e000: 0xc369 instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0001e004: 0x2aa7 instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0001e008: 0xecea instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0001e00c: 0x1715 instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0001e010: 0x563d instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0001e014: 0xdb4a instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0001e018: 0xae82 instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0001e01c: 0x7a39 instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0001e020: 0x21d6 instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0001e024: 0x99df instead Further such events for this erase block will not be printed Node at 0x0001ec98 with length 0x1368 would run over the end of the erase block Perhaps the file system was created with the wrong erase size? Has this been seen before? Background: Turns out that using block2mtd, a loop device and some elbow grease, it is reasonably easy to mount jffs2 images on a normal linux host. (This is helping me simplify image-builder...) 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: XO-1.5 slow disk writes
On Tue, Nov 17, 2009 at 6:02 PM, Daniel Drake wrote: > On Tue, 2009-11-17 at 18:56 +0100, Sean DALY wrote: >> as a former audio engineer, I was surprised recently to see a unit >> like the Samson R16 for sale: >> >> http://www.samsontech.com/products/productpage.cfm?prodID=2009 >> >> which uses an SD Card as its main memory. 8 track linear PCM audio >> record, 16 track playback. >> >> Of course, it's a case of several large files not lots of little >> ones... but it struck me that there must be some kind of SD r/w >> optimization in a unit like that. > > Another possibility is that SD cards might generally work a lot better > than miniSD ones. At least I have a Sandisk SD card here that > considerably outperforms the Sandisk miniSD card in my XO-1.5. Yes, that's quite possible as well. There's all sorts of different speeds for the cards. I've never really seen a fast mini or micro SD card. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 slow disk writes
Daniel Drake wrote: > Today I tried to figure out why running "sync" often takes 5-10 seconds > or longer. This slows down suspend, where all data is synced to disk. On the XO-1, it was necessary to sync before suspend, because there was no guarantee that a suspended laptop would reawaken any time soon. On 1.5 (and even on XO-1 with newer software) we should have fully working timed wakeups. That means the kernel could set a policy of a "sync every 5 minutes", and wake up out of suspend in order to perform the sync. This is, IMHO, actually better than a "sync on every suspend" policy, because it enables things like write combining that improve performance and reduce flash wear. Of course, getting sync to be very fast would also be nice. --Ben signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 slow disk writes
On Tue, 2009-11-17 at 18:56 +0100, Sean DALY wrote: > as a former audio engineer, I was surprised recently to see a unit > like the Samson R16 for sale: > > http://www.samsontech.com/products/productpage.cfm?prodID=2009 > > which uses an SD Card as its main memory. 8 track linear PCM audio > record, 16 track playback. > > Of course, it's a case of several large files not lots of little > ones... but it struck me that there must be some kind of SD r/w > optimization in a unit like that. Another possibility is that SD cards might generally work a lot better than miniSD ones. At least I have a Sandisk SD card here that considerably outperforms the Sandisk miniSD card in my XO-1.5. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 slow disk writes
as a former audio engineer, I was surprised recently to see a unit like the Samson R16 for sale: http://www.samsontech.com/products/productpage.cfm?prodID=2009 which uses an SD Card as its main memory. 8 track linear PCM audio record, 16 track playback. Of course, it's a case of several large files not lots of little ones... but it struck me that there must be some kind of SD r/w optimization in a unit like that. Sean. On Tue, Nov 17, 2009 at 6:39 PM, Adrian Chadd wrote: > My experience with SD media in general (and I can't test it on XO > systems; I loaned mine out to other testers for the time being) is > that the performance is wildly varied. > > It probably doesn't help that the underlying IO is translating as > "read, erase, write" in some cases for lots of sub-flash-"chunk/page" > writes and how that is treated is highly device dependent. > > It may be a fun experiment (for values of "fun" that appeal to me at > least) to write some direct-to-device IO tests which experiment with > differing write and erase sizes. Say, try doing random writes of 1k > data in 1k offsets, in 2k offsets, in 4k offsets, etc. Then try 2k > data in the same offsets. See what changes. That may give you some > subtle hints as to what the SD controller is doing. > > This is why the idea of buffering IO and doing up a log structured FS > on the consumer flash devices is an interesting prospect, if difficult > to get right. You have this massive disconnect between read and write > IO times, you want to minimise the amount of writing you do but you > absolutely have no issue doing a whole lot of reads. > > The actual SSD devices as far as I can gather do a variety of magic to > try and drop the flash erase time from hurting write performance so > much. I cant comment there with any experimental or other authority. > > HTH, > > > Adrian > > (ObNote: I've been toying with small object cache stuff on commodity > flash media lately; the above is purely from experiences with that.) > > 2009/11/18 Daniel Drake : >> Hi, >> >> Today I tried to figure out why running "sync" often takes 5-10 seconds >> or longer. This slows down suspend, where all data is synced to disk. >> In all cases that I looked at, the amount of data being synced was tiny. >> One example: in one run it had 160kB data to sync and it took 7.7 >> seconds. (blktrace is very handy for figuring this out) >> >> I traced this all the way to the SDHCI driver. These writes are >> typically small and scattered, and our hardware (or the card itself) >> takes a long time to process them. Many of the 1024 byte writes take >> 500-600ms. All other disk I/O is halted during these times. The delay is >> purely after submitting the SDHCI write command, and waiting for the >> completion interrupt to arrive. >> >> I then wrote a C application to reproduce the exact set of writes from a >> 20-second sync that I logged (using random data, but the same sectors, >> sizes and ordering) and reproduced the issue that way. >> >> I also moved the card over to my Dell laptop, ran the same program and >> saw the same (terrible) results. >> >> All info here: >> http://dev.laptop.org/ticket/9688 >> >> >> So, I have a feeling that at least with today's generation of miniSD >> cards we're going to be stuck with bad write performance, particularly >> for random-style access like this. >> >> One experiment that would be interesting to run would be to try this on >> one of the PhoenixBIOS boards, and then try it with the exact same SD >> card on a regular XO-1.5. Just in case... >> >> Daniel >> >> >> ___ >> 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: XO-1.5 slow disk writes
Hi Daniel, > Today I tried to figure out why running "sync" often takes 5-10 seconds > or longer. This slows down suspend, where all data is synced to disk. > In all cases that I looked at, the amount of data being synced was tiny. > One example: in one run it had 160kB data to sync and it took 7.7 > seconds. (blktrace is very handy for figuring this out) > > I traced this all the way to the SDHCI driver. These writes are > typically small and scattered, and our hardware (or the card itself) > takes a long time to process them. Many of the 1024 byte writes take > 500-600ms. All other disk I/O is halted during these times. The delay is > purely after submitting the SDHCI write command, and waiting for the > completion interrupt to arrive. > > I then wrote a C application to reproduce the exact set of writes from a > 20-second sync that I logged (using random data, but the same sectors, > sizes and ordering) and reproduced the issue that way. > > I also moved the card over to my Dell laptop, ran the same program and > saw the same (terrible) results. > > All info here: > http://dev.laptop.org/ticket/9688 > > > So, I have a feeling that at least with today's generation of miniSD > cards we're going to be stuck with bad write performance, particularly > for random-style access like this. > > One experiment that would be interesting to run would be to try this on > one of the PhoenixBIOS boards, and then try it with the exact same SD > card on a regular XO-1.5. Just in case... You might want to look at some of the SD/MMC frequency patches that he applies to the kernel for the Nokia Internet tablet devices. I think the default kernel defaults to a frequency half or even less than half. The issue that might be encountered is that it doesn't always work well on low quality SD cards but it would be at least worth experimenting with it. His blog is here http://intr.overt.org/blog/ The patches and a readme about them are here for the Nokia device (I suspect they're just about the same everywhere). http://intr.overt.org/5.2008.43-mmc-kernel/ Hope that can be of some help, or at least head you in the right direction. Cheers, Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1.5 slow disk writes
My experience with SD media in general (and I can't test it on XO systems; I loaned mine out to other testers for the time being) is that the performance is wildly varied. It probably doesn't help that the underlying IO is translating as "read, erase, write" in some cases for lots of sub-flash-"chunk/page" writes and how that is treated is highly device dependent. It may be a fun experiment (for values of "fun" that appeal to me at least) to write some direct-to-device IO tests which experiment with differing write and erase sizes. Say, try doing random writes of 1k data in 1k offsets, in 2k offsets, in 4k offsets, etc. Then try 2k data in the same offsets. See what changes. That may give you some subtle hints as to what the SD controller is doing. This is why the idea of buffering IO and doing up a log structured FS on the consumer flash devices is an interesting prospect, if difficult to get right. You have this massive disconnect between read and write IO times, you want to minimise the amount of writing you do but you absolutely have no issue doing a whole lot of reads. The actual SSD devices as far as I can gather do a variety of magic to try and drop the flash erase time from hurting write performance so much. I cant comment there with any experimental or other authority. HTH, Adrian (ObNote: I've been toying with small object cache stuff on commodity flash media lately; the above is purely from experiences with that.) 2009/11/18 Daniel Drake : > Hi, > > Today I tried to figure out why running "sync" often takes 5-10 seconds > or longer. This slows down suspend, where all data is synced to disk. > In all cases that I looked at, the amount of data being synced was tiny. > One example: in one run it had 160kB data to sync and it took 7.7 > seconds. (blktrace is very handy for figuring this out) > > I traced this all the way to the SDHCI driver. These writes are > typically small and scattered, and our hardware (or the card itself) > takes a long time to process them. Many of the 1024 byte writes take > 500-600ms. All other disk I/O is halted during these times. The delay is > purely after submitting the SDHCI write command, and waiting for the > completion interrupt to arrive. > > I then wrote a C application to reproduce the exact set of writes from a > 20-second sync that I logged (using random data, but the same sectors, > sizes and ordering) and reproduced the issue that way. > > I also moved the card over to my Dell laptop, ran the same program and > saw the same (terrible) results. > > All info here: > http://dev.laptop.org/ticket/9688 > > > So, I have a feeling that at least with today's generation of miniSD > cards we're going to be stuck with bad write performance, particularly > for random-style access like this. > > One experiment that would be interesting to run would be to try this on > one of the PhoenixBIOS boards, and then try it with the exact same SD > card on a regular XO-1.5. Just in case... > > Daniel > > > ___ > 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
XO-1.5 slow disk writes
Hi, Today I tried to figure out why running "sync" often takes 5-10 seconds or longer. This slows down suspend, where all data is synced to disk. In all cases that I looked at, the amount of data being synced was tiny. One example: in one run it had 160kB data to sync and it took 7.7 seconds. (blktrace is very handy for figuring this out) I traced this all the way to the SDHCI driver. These writes are typically small and scattered, and our hardware (or the card itself) takes a long time to process them. Many of the 1024 byte writes take 500-600ms. All other disk I/O is halted during these times. The delay is purely after submitting the SDHCI write command, and waiting for the completion interrupt to arrive. I then wrote a C application to reproduce the exact set of writes from a 20-second sync that I logged (using random data, but the same sectors, sizes and ordering) and reproduced the issue that way. I also moved the card over to my Dell laptop, ran the same program and saw the same (terrible) results. All info here: http://dev.laptop.org/ticket/9688 So, I have a feeling that at least with today's generation of miniSD cards we're going to be stuck with bad write performance, particularly for random-style access like this. One experiment that would be interesting to run would be to try this on one of the PhoenixBIOS boards, and then try it with the exact same SD card on a regular XO-1.5. Just in case... Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: GSM/CDMA Modems support
martin wrote:
> On Mon, Nov 16, 2009 at 9:32 PM, Martin Abente
> wrote:
> > Is there any chance to include CONFIG_USB_SERIAL_OPTION module in the
> > kernel for the F11-XO{1,1.5} builds? In our region, GSM/CDMA connections
> > are very popular so it would be nice to have support for them (for multiple
> > purposes: end-user usage, support team, etc.).
>
> Also very important for the XS-on-XO kernel.
>
> For how to get these thins to happen, see Paul Fox's reply to a
> similar request about USB webcams yesterday...
but even given yesterday's mail, if there's a strong need for a
particular module that's especially important for deployments, we
can/will certainly add it to our builds. the "bag of modules"
rpm is really a proposal for taking care of individual,
non-mainstream needs. (it might also be that on XO-1.5 we have
the luxury of shipping a lot more modules. haven't really looked
into that much.)
paul
=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Serial auto-enable works on B3
This is just a success report on the new serial auto-enable feature on B3. I removed the mistakenly-stuffed power resistor (pr148) on the serial_en signal and modified a USB serial dongle (cut the trace that goes from 3.3V to pin 1 of the header, soldered a jumper from pin 1 to pin 4). With the dongle connected to the serial connector on the B3, it comes up with serial enabled. Disconnected, serial is disabled. I haven't tried the pencil-enable technique. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
