Re: [PATCH runin] Port to systemd
On 04/23/2012 01:08 PM, Daniel Drake wrote: runin does make a lot of effort to be started early, but it explicitly pulls in olpc-configure as a dependency before being run. I helped Richard with this when it was originally implemented. My systemd port maintains the same behaviour. In the very early days runin started before anything else so Wad and Martin you do remember that correctly. Runin, however, uses X and in the move to a consolidated build for 1.0 and 1.5 X needs different setups to start. Rather than duplicate that code in runin Daniel worked with me to move runin to after olpc-configure. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Battery losing charge while off
On 05/23/2012 10:04 AM, Yioryos Asprobounitis wrote: One of my XO batteries (~2years old) is loosing about 12% of its charge in 24h period while the XO is off. This is not related to a specific XO but rather the battery itself. How are you measuring the loss? What happens if the battery is not installed in an XO? -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Battery losing charge while off
On 05/24/2012 02:56 PM, Yioryos Asprobounitis wrote: One of my XO batteries (~2years old) is loosing about 12% of its charge in 24h period while the XO is off. This is not related to a specific XO but rather the battery itself. How are you measuring the loss? Just looking at the Sugar battery monitor in 2 XO-1s running 21011o0 and os880 (but this one with FW updated to q2f08) What happens if the battery is not installed in an XO? Actually, it does NOT discharge when off the XOs ! I guess I should get some power logs. Anything else? So now that you know its not the battery what are the symptoms? You turn off the XO at night and then in the morning the battery is 12% less? -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Battery losing charge while off
On 05/24/2012 11:59 PM, Yioryos Asprobounitis wrote: laptop serial number. Was it a pre-production XO-1 ? Both XO-1s used to test the battery are C2 machines #CSH7470023EA #SHF80701C99 The batery in question is #00802091012110003588 So let me review and see if I have all the details. Seems like each new email has more new details. - Battery does not lose charge outside the laptop. - Tested the battery in 2 different laptops and the loss is the same. Roughly 12% overnight. - A different battery in those same laptops does not lose 12% -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Battery losing charge while off
On 05/31/2012 08:18 AM, Richard A. Smith wrote: So let me review and see if I have all the details. Seems like each new email has more new details. I'm asking you to verify that these facts are true based on your testing. - Battery does not lose charge outside the laptop. - Tested the battery in 2 different laptops and the loss is the same. Roughly 12% overnight. - A different battery in those same laptops does not lose 12% In case its not clear. If you have not done this test with a different battery in the 2 laptops then please do so. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Battery losing charge while off [Devel Digest, Vol 75, Issue 63]
On 06/01/2012 10:12 AM, Yioryos Asprobounitis wrote: Done See attached screenshot. I don't see anything that looks obviously wrong. So here's a test to see if the EC is going to sleep or not. Run the battery down to where the red LED is active. Then power off the laptop. If the EC goes into stop mode the red LED should go out after a few seconds. If you press a game button the EC should wake up briefly and the led will turn back on then in a few seconds go back out. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance
On 05/30/2012 03:34 AM, Yioryos Asprobounitis wrote: If you want an idea of low-level performance, I can suggest running LMBench. Got the Debian lmbench_3.0-a7 source that compiles and runs fine w/o bitkeeper. Run the hardware part of the tests on the XO-1.5 (os880) and xo-1.75 (os12- correct kernel) with the same configuration. What was striking was that the XO-1.75 used 25% of the battery for 1 run while the XO-1.5 used 65% of the battery! If you are going to do more of this then you really need a better tool than just the battery SOC measurement. olpc-pwr-log can sample the information on a periodic basis and then my processing scripts can run through those logs and produce various reports. All of my tools are in my olpc-pwrlogs repo git://dev.laptop.org/users/rsmith/olpc-pwrlogs Let me know if you are interested and want to know how to use the tools. Most of the test had empty values but the informative ones (below) show that the XO-1.5 is better in basic integer operations and memory bandwidth while the XO-1.75 is better in float and double operations as well as in memory latency. I'm not sure how much this means for real life usage :-/ I'm very suspect of this measurement. The 1.5 has a hardware floating point unit and the 1.75 is still using soft-float. Its extremely unlikely that the floating point performance on 1.75 is better than the 1.5. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 4]
On 06/03/2012 04:43 AM, Yioryos Asprobounitis wrote: serial connector loaded. Its the connector under the heat spreader. There goes my new XO-1.75... Think of it a a rite of passage. Just to be sure, is the UART 4, CN23, shown in the attached picture in blue. Correct? Correct. If OK, please advise further actions. First upgrade the firmware to the latest version and let it update the EC code. Then just plug up the serial connector and then do a full power cycle of the unit by removing both external power and the battery and then plugging in the problem battery. Send the output. May or may not be anything of interest in that log. Then see if the problem duplicates on the 1.75. You can get a quick reading from the EC of the battery level by using the command 'b3'. Type b3 enter which turns on some simple debug info. You can't leave that on however because it will prevent the EC from going into stop mode. 'b0' will turn it back off. You have to be really quick with the serial commands when the XO is off. When off and running on battery the EC will go into stop mode and it does that really fast. When its in stop mode you can't talk to it on the serial port.I usually have one hand ready to type b3 and then wake the EC up by a very short power button press. Then before it goes back into stop mode type b3enter. Once a second it will output a short battery stat then type b0 to stop it and allow it to go back into stop mode. So hook up the EC serial port and log the output. Then charge up the battery. b3 to get some readings. Disconnect external power and then b0 . You should see it go into stop mode. In 24 hours wake the EC up do b3 to get a 2nd set of readings and then send the log output. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 4]
On 06/10/2012 01:07 AM, Yioryos Asprobounitis wrote: Took some time and a lot of juggling and ended up to a lot of questionmarks in black diamonds so I do not really know if I did it right or wrong, but here is the screen log just the same. You may or may not have done anything wrong but the output is not valid. Perhaps your comm settings are wrong? 115200,n,8,1 is what they should be set to. Its exactly the same as if you were connected to the OFW or Linux output. The EC output is readable text and if you press enter with no command you get back a prompt. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 21]
On 06/12/2012 12:26 PM, Yioryos Asprobounitis wrote: OK Attached are the screenlogs from the serial output screenlog.charging is yesterdays log whith half full to fully charged battery 2339275:LDACR Update request ACR:-19791 LDACR:-19792 2339471:GC_LDACR=-19792 SOC = 58 2470692:LDACR Update request ACR:-19722 LDACR:-19792 2470857:GC_LDACR=-19792 SOC = 95 2477403:LDACR Update request ACR:-19719 LDACR:-19720 2477565:GC_LDACR=-19720 SOC = 96 2665019: LCS:8 CFC:4 CHG=1 Vb:7395 Vavg:0x5eb3 Bat Full Your battery jumped from 58% to Full while only receiving around 30mAh of charge. So it has issues. For an older battery I would suspect charge balance symptom but your serial number starts with 008 which is beyond the lot of problem batteries and you have indicated you already ran bat-recover. So either your battery was not really at 58% or its suffered a lot of capacity loss. The next step would be to do a full discharge/recharge/discharge cycle while running olpc-pwr-log (stop powerd first) to measure the existing capacity. A quick summary of the procedure: - Boot laptop; stop powerd; run olpc-pwr-log; disconnect external power let laptop power off shut off. - Remove battery;connect external power; boot; stop powerd; run olpc-pwr-log; insert battery; let charge to full; - Ctrl-C to stop olpc-pwr-log; re-run olpc-pwr-log; disconnect external power; let laptop power off; You can try to figure out the log files from the code I previously pointed you at or you can send them to me. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 21]
On 07/04/2012 12:20 PM, Yioryos Asprobounitis wrote: 0 bg-acr! solved the problem of the erratic reading. Logs look more reasonable now (though there is still a sudden jump from 87 to 96% during charging in one log. Thats normal. There isn't any calibration of the capacity as the capacity of the battery decreases. So while charging its going to reach full sooner. When its full the SOC is set to 97%. Battery capacity looks also improved (2.8Ah in one run) I don't see any of your logs that have 2.8Ah they all look like 2.5Ah and 2.6Ah to me. Which log are you referring to? However, the original issue of battery losing ~12% charge per day while in the XO with the laptop off, is there. There is certainly something up with your battery. The charging log shows where the problem is. Look at line 386 in pwr-120703-010410-355aaa250043.csv . Thats where the battery stop reaches its full condition (Voltage@ 7.4V and current 120mA). Normally the status would switch to Full and the current would bounce around very close to zero. Your battery however has a constant discharge current of 16mA. So despite having the power connected your battery is slowly discharging. This seem strange but its possible because when the EC detected the battery was full it turned off the mosfet that is in the charging path. So the battery is isolated from the system. Only when you unplug power does the mosfet re-engage so the battery can then supply power. If you want to prove its the battery then try the same test on other XO-1s and on your 1.75. Another test you could do is to see if the ACR changes with the battery removed from the laptop. You can do this with batman. The steps would be: 1) Connect XO 1 or 1.5 to external power. 2) Boot the machine and stop at the open firmware prompt 3) Allow battery to charge up up until full. 4) print out the ACR with: ok bg-acr@ .bg-acr 5) remove battery 6) record the printed ACR number somewhere 7) Note time of battery removal 8) Wait 24 hours. 9) repeat steps 1-4 10) subtract the 2 ARC numbers to the the net ACR. According to your log your average draw is 16.4mA. So if you let it sit for 24h I would expect your net acr to be in the range of 390 - 400 mAh (the number is in uAh so thats 39 to 40) If it happens outside the XO then you know its in the battery. If not then its some interesting combination of battery and XO. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 21]
On 07/21/2012 03:05 AM, Yioryos Asprobounitis wrote: - ok bg-acr@ .bg-acr (Should print zero) ACR: -0.42 Hmm... I was expecting zero. I'm traveling to Taiwan right now and don't have 1.0 or 1.5 with me to check. - Insert battery - ok bg-acr@ .bg-acr ACR: -0.84 .42mAh / 24 hours = 17.5uA so very low. Does not appear to be a hardware fault in the battery. - ok batman-stop - Poweroff - Remove AC - 25 h battery IN the XO - remove battery - Plug AC - Boot XO and stop at OFW - ok batman-start - Insert battery - ok bg-acr@ .bg-acr ACR -469.52 Assuming -.84mAh was where you started thats 468.68 mAh / 25h = 18.7mA which is just about what olpc-pwr-log indicated was happening. This really smells like the EC not going to sleep although I thought we proved it was going to sleep with an earlier test. (Low battery LED going out when you power off) Please dump the registers and EEPROM (bat-dump-banks) again and I'll program them into a battery and test it on a XO-1. No rush though I won't be able to do anything with this for at least 2 weeks when I back in Boston and working. Perhaps I'll think of some other thing to look at between now and then. -insert battery - ok bg-acr@ .bg-acr (no batman.fth/batman-start) commands like bg-acr@ require batman-start to work correctly. If batman-start has not been called then they will call it for you. We call it explicitly so that the charging system is disabled prior to inserting the battery. Booted up with battery, plugged AC, power LED stays red. This is an invalid condition. With AC connected you should either have: Blinking red: Error yellow (some say orange): Charging Green: Full If its not one of the above then either the EC charging system is disabled in which case the LED values are somewhat random or your power adapter is not providing power. Booted without battery, inserted battery, battery shows empty and charging. Charged to about 15% slowly, then jumped to 81% and then 97% in under 1 min and the power LED turned green! Now, you are going to say again that I do not know what I'm doing, but sure none of these looks very normal behavior to me and may have to do with how the battery communicates its state than its state per se. Yes and I'll continue to say it as long as you continue to do things that are invalid and will produce nonsensical results. I've told you a few times that when you run commands like bg-acr! that you are modifying important values outside of the EC and that until you do a full discharge/recharge cycle normal reporting won't yield valid results. The jumps are when the EC detects specific conditions and tries to reset the SOC accordingly. Normal and expected. If you want to understand whats going on the please run olpc-pwr-log so you can observe the voltage and current and see when the EC changes things based on those values. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 21]
On 07/21/2012 12:53 PM, Yioryos Asprobounitis wrote: I'm sorry but I did not run any bg-acr! commands except the one you suggested. The only command that I run outside your suggestions is bg-acr@ .bg-acr with no batman.fth/batman-start first, which certainly can not account for the erratic behavior. Commands _like_ 'bg-acr!' that includes all of the bg-* commands and many others. They _require_ batman-start to function. If it hasn't been called then they do it for you. Thus if you have run those command and not run batman-stop then the charging system will behave erratically. bg-acr! changes values that take the EC close to a full cycle to recovery from so even after a full reset the reporting can be incorrect. I keep saying that the battery EC might have a problem There is no battery EC. The battery only has a sensor chip. The EC on the XO talks to that chip and reads voltage, current, temperature, ACR and a few other values. and you just dismiss all the indications (like a full battery reporting as empty) I'm sorry if my last mail came across the wrong way I was in a bit of a hurry before my flight. Its just that I keep telling you that nothing you have presented so far indicates there is a communication problem between the EC and battery. I'll be the very first to tell you when I see something I think is funky. Just like with the rollover bug. I'm not dismissing what you say. I'm just trying to tell you that you aren't doing anything useful debugging wise when you try to figure out whats going on based on the charging LED or what sugar tells you. The use of _any_ of the debugging commands I gave you will screw up the normal battery reporting. If you want to known whats happening when you boot Linux then please do a full power cycle and run olpc-pwr-log. Those log files are much, much, more useful than what the LED/Sugar is doing. The LED/sugar can lie to you but the log files do not. Normally, I boot the laptop without the battery installed, run olpc-pwr-log and then insert the battery. olpc-pwr-log will wait for a battery to show up. including even the fact that EC reports the battery is asleep while the discharge data show that is not. Its not possible for the battery to go to sleep. I don't understand what you are referring to. Oh well, I do not think that one battery in a couple of millions worths all this trouble. Actually I believe it is worth the trouble because there is never just a single problem that doesn't happen to another machine. If you have this failure then there are probably many more. Its just never been reported. I'm happy to keep working on this if you don't mind the time. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO battery/performance [Devel Digest, Vol 76, Issue 21]
On 07/22/2012 04:29 PM, Yioryos Asprobounitis wrote: As I said before, the problem needs an engineer if it is to be investigated any further, and I'm not. You are welcome to the battery. Ok. Well then please send me the battery. Richard Smith One Laptop per Child 222 3rd St. STE 0234 Cambridge, MA 02142 +1 617-714-4589 Thanks for all your help so far. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Blinking red battery light on XO-1
On 08/03/2012 11:38 PM, Hal Murray wrote: I have a hack script that reboots the XO every 4 hours. It's got a patch to check /sys/class/power_supply/olpc-battery/error and log the answer instead of rebooting. The error was 20 (Sorry I didn't remember to look there earlier.) 20 is 0x14 which is bank zero error. I think you are the 2nd person to report a transient bank 0 problem. Thats odd since I would expect a bank 0 error to be permanent. The code does several re-reads before giving up and throwing the error. From errors that dsd has reported I've been suspecting that there is some timing that may be marginal since a reset fixes it I wonder if there is something that is going wrong and messing up the 1-wire timing. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Attempting to re-purpose former XO 1.5 4GB microSD cards.
On 09/16/2012 09:57 PM, Kevin Gordon wrote: Therefore, I fear that I must have been an ESD devil this morning when I took the cards out of the machine, and fried them by not taking recommended precautions. I can think of no other plausible reason. But, it appears it's just these two cards, and not the process. Next time, no skipping the wrist strap. Sorry for the bother. Aaargh .. but thanks again for answering quickly and adding even more doisk management tools to the arsenal. I doubt it was ESD. Rather I suspect you were hit with what our manufactures called an SPO or sudden power off. I suspect the card power bounced while the FTL was moving some blocks around. You don't actually have to remove the card for this to happen as the power to the card socket is software controlled. We dealt with this numerous times while qualifying SD cards. The EC in the XO keeps the power up on the SD card for several seconds after the main power it turned off to help prevent this from happening. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Xo1.5 crashes
On 10/07/2012 10:21 PM, Mikus Grinbergs wrote: IIRC, Richard warned about connecting an XO's USB socket to any USB device where that devices's USB socket can emit power (that sets up a condition where a non-XO device can try to send power to the XO -- which is a no_no). The details are fuzzy but in Kevin's case I believe he was trying to use a external CDROM that drew a lot of juice tying to spin up and fail. To compensate he was connecting one of those rechargeable batteries with a 5V USB output via a Y cable. So now you have 2 power sources fighting it out on the USB bus and the XO-1.5 would lose. So when i plug one usb device into the xo be it an ipod or a cell phone while running on battery the screen goes white and the laptop reboots. It works fine when plugged in charging though. I just wanted to let you all know what im experiencing. I believe the devices are drawing too much current from the laptop and forcing a reboot. It doesnt matter which usb port i plug it into. What production rev model is your 1.5? Did you get it from the developer program? I have a vague recollection that some of our earlier runs of 1.5 had a USB issue like that. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [TRANSIENT ISSUE] 3G-Modem not being recognised
On 11/21/2012 02:40 AM, James Cameron wrote: Perhaps this service provider can provide technical support? If it's as simple as adding a single entry to powerd's usb-inhibits file like how 'hid' is treated then why has this not been done? My guess is priorities are elsewhere in the stack at the moment, and we have very few deployments demanding this be fixed. I don't think having an end-user with no experience with USB IDs add an entry to the usb-inhibits file, or having to remember to turn off a major feature is the correct long term solution IMHO. Certainly not. I didn't think you or Ajay were end-users though. My advice to end-users would be to wait for the problem to be fixed, or ask their deployment technical people to turn off the major feature permanently, or build a fix. In the previous thread this was discussed in (See Patch: Mobile dongles) the proposal was that inhibit would be triggered by the presence of module 'usb_wwan'. Jerry submitted patches that did that. Paul was wondering if there was a better way than looking for a module loaded. Powerd already has a mechanism where it disables suspend while an association is in process and Paul was wondering if you could leverage the existing infrastructure for this. The thread dies after that. So I think anyone wanting this to get integrated as a stock feature should investigate if you can use a NM hook to send the DBUS message to powerd to inhibit. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [TRANSIENT ISSUE] 3G-Modem not being recognised
On 11/21/2012 01:07 AM, Jerry Vonau wrote: Dropping the power to the usb bus is making the modem play peek-a-boo with the kernel: http://dev.laptop.org/ticket/10708. http://dev.laptop.org/ticket/10708 And just to be clear its more than just a power dropping problem. Both 1.75 and XO-4 both have the ability to keep the USB bus powered during suspend (with an EC firmware change) but on resume the kernel resets the USB bus. I don't know if the kernel has an option not to do that. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 13.1.0 development build 18 released
On 12/11/2012 08:33 PM, James Cameron wrote: Thanks for the logs off-list, I've reviewed them. You hit a known problem that has since been fixed. The battery low status bit was not necessarily cleared despite charging commencement. This was fixed in http://dev.laptop.org/git/users/rsmith/ec-cl4-mmp3/commit/?id=f3a823876d2084fd0b22e79f75bfc05f32b7626d which was between EC 0.3.04 and EC 0.3.05. Q7B07 contained the former, and Q7B08 contained the latter. I'm going to have re-do that and qualify the clear with a SOC 10 conditional. I've realized that clearing the flag unconditionally bypasses OFW's check to make sure that the battery is not low prior to starting a firmware flash. A battery that was very low but just plugged up to power should still be considered low. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [support-gang] Customization Sticks fails on 13.1.0 12.1.0 for XO-1
On 03/09/2013 01:35 PM, Kevin Gordon wrote: I seem to remember from the devel list that martin and Daniel said there are no plans to re-enable it. The future is OOB. Chopping the list down to just devel@ for my comments. Perhaps I don't understand but I don't see how OOB can work for a setup like Adam is describing in Haiti where they have laptops in the mix that are secure. Unless they first un-secure every laptop a custom OS build wth OOB would have to be signed by OLPC or Reuben would have to give them a Haiti key thats installed via keyjector. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [support-gang] Customization Sticks fails on 13.1.0 12.1.0 for XO-1
On 03/11/2013 10:26 AM, Daniel Drake wrote: would have to be signed by OLPC or Reuben would have to give them a Haiti key thats installed via keyjector. This is not a new situation for us, and the approach we have taken in the past is to help such deployments un-secure all of their laptops, or provide a keyjector to insert custom keys, upon their request. Nod. Kejector for small deployments is new to me. I thought keyjector was only for special cases. I don't think most of the folks on say the support-gang list have any idea that keyjector is an option for them. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Possible fix for Gray dots forever problem
This bug is is Trac #12618 When Nancie was at Twine she left me an XO-1 with this condition. Based on Adams observation that laptops in this state also seem to ignore the power button I suspected that powerd problems were the root cause. The root of the problem appears to be that the system date on the affected laptop was set to sometime in 1968. This date is prior to the unix epoch date of 1970 and therefore all the timestamps were negative causing powerd to ignore all events. Updating the system date to be current fixed both problems. The mechanism for how this happens is currently unknown. In general the Linux kernel on our machines ignores the century field from the RTC and adds 2000 to the year value. I was unable to find a setting of the RTC that would make linux read 1968 for the date. The proposed fix is to either set the date from OFW using ok ntp-set-clock (you need a valid wifi or USB ethernet network) or by using the check key to boot to linux and doing: date --utc --set=-MM-DD HH:MM:SS hwclock --systohc The hwclock --systohc is necessary because 'date' only updates the systemclock and not the RTC. If this fixes it I would recommend a reinstall of the OS after you do this to reset the date on a lot of files that that created when the OS first boots. The funky date may cause other problems yet undiscovered. Nancie: You can help us figure out how this happens. Before you try to fix your machines that have this problem please boot them (holding the check button) and look to see what the system date is set to. Load up terminal and run 'date' If the year is less than 1970 please do the following: dmesg dmesg-n.log (where n is a number for each log file) sudo hwclock -r Send me the dmesg output files and the dates reported by hwclock If the date is not less than 1970 please hold that machine for further inspection. Hope this helps. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [support-gang] Customization Sticks fails on 13.1.0 12.1.0 for XO-1
On 03/11/2013 10:08 PM, John Watlington wrote: Nod. Kejector for small deployments is new to me. I thought keyjector was only for special cases. I don't think most of the folks on say the support-gang list have any idea that keyjector is an option for them. I don't think it is an option. A keyjector should not be made publicly available. That is more along the line of what I thought was status quo. Please don't redistribute secure laptops --- OLPC's policy since early 2009 has been to deprecate the security system. The exceptions have been deployments large enough to have dedicated support staff capable of handling their own keys. That policy is fine but perhaps needs to be more visible to the people going into areas where secure laptops were distributed and we should try to be helpful to those people when they request developer keys. The point of my comments was clarification that olpc-os-builder is not an end all solution to the lack of the customization key not working anymore and should not be offered up as such. Doing customization by a bash script after boot is a fine solution and now people can invest time in polishing that script. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [support-gang] Customization Sticks fails on 13.1.0 12.1.0 for XO-1
On 03/11/2013 10:48 PM, John Watlington wrote: That policy is fine but perhaps needs to be more visible to the people going into areas where secure laptops were distributed and we should try to be helpful to those people when they request developer keys. If someone isn't being helpful about providing developer keys, let me know. No specific instances that I know of but for some of these people its a daunting task especially if they have limited Internet. Just a friendly reminder that some of these people may need a bit of hand holding. I know because I've helped several of them in the past and sometimes it can be a bit frustrating. :) -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Auckland Testing Summary 23 March 2013
On 03/25/2013 02:03 PM, Richard Smith wrote: Battery life on XO-4 C2 seems significantly improved over previous builds. We would be interested in a confirmation or otherwise of this in the power log analysis. I guess you are comparing to 13.1.0 build 36? The big difference here is that 13.1.0 build 36 has automatic power management disabled, it is now enabled in 13.2.0 (not 100% stable just yet, but we continue to shake out the bugs). Its probably the firmware change rather than a build specific change. We turned off unused cores and in q7b23 and that made almost 800mW worth of difference across the board in operational power draw. I'll do a plot of your power logs though and confirm. It appears there is considerable difference between your previous tests and now. Last round of logs I have from you prior to this one was March 2nd and prior to that was November 15, 2012 is that correct or did I miss a batch between November and March? Here's a ploy of XO-4 only 13.1.0-32 vs 13.2.0-1 all your other XO-4 13.1.0 builds I have were very early and not really interesting from a power standpoint. http://dev.laptop.org/~rsmith/auckland_13.1_vs_13.2.png Your peak decreased which I believe is from your firmware upgrade but does not explain the whole story. A closer look at your log file shows a much, much higher suspend frequency in 13.2. In your 13.1 tests you had perhaps 1 or 2 suspends whereas in the 13.2 log files almost every other line is a suspend event. You didn't change your testing procedure did you? Something that would allow for more idleness? -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Developer key request issue ?
On 04/03/2013 03:37 PM, lio...@olpc-france.org wrote: Hi all, Is there any issue with the Activation Service? I asked a developer key for a XO-1 about 72h ago and I can’t retrieve the key. I’ve got the message: “Your developer key will be ready in 0 minutes. Please check back later.” You are behind a 71k laptop lease generation request. Which looks like it still has another 40 hours to go before it finishes. If you absolutely gotta have it now then send me your serial number and I'll see if I can get it generated for you. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
activation.laptop.org downtime Monday 2013-04-08
OLPC has has an upgrade of activation.laptop.org planned but it always seems to be in use when we try to schedule. Switching the machines requires a full backup and then restore with the database off-line so there will be a service outage. Since there is no best time I've declared that we just go ahead and do it. Monday, 2013-04-08 activation.laptop.org will respond with an error to any activation requests. It should be back up and running normally on Tuesday. 2013-04-09. Moving to the new hardware should help with decreasing the time when large chunk of lease renewals is requested. Thanks. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: activation.laptop.org downtime Monday 2013-04-08
On 04/04/2013 04:42 PM, Richard A. Smith wrote: Monday, 2013-04-08 activation.laptop.org will respond with an error to any activation requests. It should be back up and running normally on Tuesday. 2013-04-09. Activation is back up and running. The old server is in read-only mode if you connect and you get errors then your DNS has not updated yet. The new IP for activation.l.o should resolve to 18.85.2.163 -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
So long and thanks for all the fish.
This is my public announcement that I'm leaving OLPC. I have accepted a new position at Bobo Analytics. My last day with OLPC is the 21st. At Bobo I'll be working along side with Ed McNierney and Mitch Bradly so it won't feel too far away from OLPC. The last 6.5 years have been an amazing journey. There really aren't the words to express it. I'm extremely honored to have had the chance to work at OLPC and been able to work with some of the most amazing people I've ever met. I'm proud of what OLPC, its associates and volunteers have been able to accomplish and I'll always carry fond memories of my contributions to the project. I'll continue to lurk on IRC and you can still reach me by my rich...@laptop.org address. If that stops at some point then smithb...@gmail.com will be around as long as google keeps it. Take care everyone. Richard. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [support-gang] Real time clock battery during XO storage
On 12/09/2013 08:07 PM, James Cameron wrote: The symptom is that pressing the power button gives about a one second pulse on the power indicator, then it goes blank. There is no serial cable output from the processor. Take a look at the EC output. It won't be as verbose as later generations but might provide some clues The laptop starts fine with the RTC oscillator stopped, provided it stopped because of removal of the RTC battery. It just won't start if the RTC oscillator is stopped by writing to RTC control register. Seems to me that this is may be some sort of OFW issue. I seem to remember that we store some state in the RTC memory that is checked at early startup. Just stopping the OSC would leave the memory as is (I think). Perhaps that confuses OFW and its waiting for the something to respond that never will. Speculation: the XO-1 embedded controller is not detecting a 32 KHz signal from ball C8, GPIO27, or is not detecting some other normal response of the processor, and is abandoning the power up. Nope. Not for XO-1. Thats the SCI# signal and its an output from the EC (and not used). Unlike 1.5 and beyond in XO-1 there is minimal feedback to the EC about the state of the CPU booting. It's mostly just EC timers. I won't say its impossible but I don't have any memory of anything like that and a quick look at the system power up code doesn't bring back an memories. -- Richard A. Smith rich...@laptop.org Former One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Xubuntu on OLPC X-1
On 07/01/2014 10:51 AM, Hellânio Costa wrote: Thanks for listening, Well, apparently I better go from idea to use fedora with xfce, but it becomes unfeasible to use sd card in each device and therefore we restricted the internal memory of the notebook. I believe a teacher contact Ricardo Carrano can I get a case of successful use of these notebooks. The most important thing now is to get a developer key for me to use the OLPC OS Builder and leave the system as clean as possible. With the exception of Postal Mail one of the procedures listed here: http://wiki.laptop.org/go/Activation_and_developer_keys Should get you a developer key. If you want to get keys for a lot of machines all at once then you should follow the collection stick procedure here: http://wiki.laptop.org/go/Collection_stick If you have any problems with getting the collection stick to work a very, very common failure is just a USB disk that behaves badly. There are both hardware problems or formatting problems that can trip up the procedure. If the collection stick doesn't seem to work then try a different USB disk. If that doesn't help then just report back your scenario here and someone will be able to help you sort out where the problem is. -- Richard A. Smith rich...@laptop.org Former One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
I'm down in Uruguay this Xmas.
I'm going to be spending my Christmas holiday on the beaches of La Paloma, Uruguay. I'll be there Dec 24th - Jan 3. One of those days my girlfriend and I plan to go in to Montevideo and look around the city. I'd love to get a tour of the Plan Ceibal offices and chat, lunch, or dinner, with anyone still around who's working with XO's. I've sent mail to various people I had contact with, Miguel, and to the stock email address cei...@ceibal.edu.uy. Most of the emails bounced and the response from the ceibal@ address was that they would pass my info on to people on the project. However, I've not heard back from anybody. Anyone here know of someone I could contact @Ceibal who's involved with the XO's they have? -- Richard A. Smith <rich...@laptop.org> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Server-devel] help us finalize XS Community Edition version 0.3
On 05/10/2013 05:10 PM, Holt wrote: Now we're getting towards the halfway point of our community's 4th Hack Sprint outside Toronto here ( photos @ http://haitidreams.wordpress.com/2013/05/09/school-server-community-edition-toronto-hack-sprint-begins/ ) hoping for testers across XO-1 (maybe!), XO-1.5, XO-1.75 and XO-4 -- as things become much more reliable in coming weeks. I've got XO-4s. I can test with. I'll be happy to try it if things are far enough along. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] [XSCE] Reflashing over a network
On 08/29/2013 04:45 AM, Tony Anderson wrote: The real advantage of wireless 'flashing' could be that a roomful of laptops could be flashed concurrently as in NandBlast. I assume that NandBlast is using the broadcast capability of the network. This is getting beyond my understanding of networking, but wouldn't it be possible to implement the 'sender' side of NandBlast on the server and have it start broadcasting the image. Nandblaster is much more complex than a simple broadcast. It does use broadcast but it does it in as low level and as raw of a format possible. The reason is that wireless is lossy and broadcast packets have no means of ack from the clients. To compensate nandblaster uses forward error correction where it sends extra information with each block(s) of data. You can sort of think of it as RAID 5 for wireless. The actual amount of data is configurable but and example would be that for every 2 blocks of data 1 extra block is sent that allows you to reconstruct the 2 blocks of data from any of the 3 blocks. In that case you could sustain a 33% data loss and still get 100% of the data. But you have also decreased your throughput by that same 33%. In order to make this scheme work you have to turn off a whole host of things that are stock with wireless. The wireless card in XO-1 allowed operation at a very low level. The cards in XO-1.5 and beyond had varying degrees of that low level functionality making it more difficult to make nandblaster TX work. Over time I think some of those limitations were dealt with. I've lost touch of the complete state of nandblaster. James can perhaps update with exactly what works and what doesn't. Getting a good nandblaster in a noisy wireless environment can be very tricky. Unless you get 100% data the client has to wait an entire cycle of the image to pick up the missing blocks. That can be a long time. But if you crank up the error correction so your 100% reception rate goes up the overall programming time still suffers because for 99% of the image data you sent error correction that was not needed. You can quickly end up sending double the original image size. When the image size increased in XO-1.5. Mitch Bradley and I spent a lot of time working on a wired version of nandblaster for the factory production line. (At the factory XO's were flashed via USB wired network adapters) While it worked it was a bit twitchy based on what sort of equipment was in between the server and the XO clients. Broadcast and multi-cast packets are not handled optimally by a lot of equipment. We were able to get a lower programming time by using fiber-optics to the programming rack and a server that could handle the IO requirements of many stock http: connections sending the same file. That eventually gave way to a gang programmer for XO-1.5 SD cards and then for XO-1.75 and XO-4 the factory now preps a bunch of USB flash drives and uses those. USB flash drives have the unique ability to scale perfectly with the the number of XOs you want to program at once. It actually turns out to be cheaper than a bunch high performance equipment too. Somewhere in the repositories we have the code (linux) that will generate a image file with the forward error correction and a server that will broadcast that image onto any network that can do multi-cast. I think that should work with any wireless setup as long as its configured to allow multi-cast ranges. The XO (OFW) client would night need some love as its not been used since 1.5. IIRC the changes to stock nandblaster were not that extensive. One could also make a tiny linux version of the client that you could netboot and do it that way although net booting in the face of massive multi-cast traffic might be problematic. Perhaps you could load the tiny-linux client via USB and then let it join the multi-cast network. If you have a lot of XOs to program and you don't require speed then a nandblaster type solution is very workable. Its slow but requires very few resources. Again I'm hazy on the current state of nandblaster so someone else will have to tell you how much effort is needed in the XO firmware to make that something that might be compatible with an XS broadcaster. -- Richard A. Smith rich...@laptop.org Former One Laptop per Child ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] [XSCE] activation server feature XSCE 5.0
On 07/04/2014 07:36 PM, Sameer Verma wrote: I think the next step in diagnosis will be to find out what the XO does during the activation step, find out how XS-0.7 implements this, and ensure XSCE does as well. A quick note. I remember that with XS 0.7 running on CentOS6.x it had to be the 32 bit OS. Reuben Caron may know more. I ran into this problem when porting the OLPC activation server from running on a 32-bit VM to running natively on owl.laptop.org which is 64-bit. The issues were with the toms libs that did all the crypto and optimised math. They would not produce correct results in earlier 64bit releases. This was fixed in later versions. I can't remember the gory details but there's some tweaks that need to be made to the makefile and to pysign but after that it works. Looking at my build of bios-crypto on owl I still have the changes should anyone want to build a package for 64bit. -- Richard A. Smith rich...@laptop.org Former One Laptop per Child ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
