Re: EC corruption by q2f04rc firmware
On 10/31/2011 12:34 AM, Kevin Gordon wrote: RS: Symptoms identical using multiple batteries, same XO. Same batteries worked fine in another XO. No flashing red using Q2E48, see Flashing red over time using the rc, even with A/C in. EEPROM read errors don't change based on the presence of external power. So, now with a fixed target, upon physical inspection, the copper prongs inside the battery compartment seemed 'bent'. Not sure why the new firmware would do the flashing red for this problem; but, The new firmware has a lot of validity checks on data reads. If the reads were resulting in invalid data then thats why you would get an error. I realigned the prongs, put the batteries in, and I no longer get any flashing reds, just perfectly charging batteries, all three; and watch-battery shows no errors. Glad it was something simple. Bent prongs is a new one. -- Richard A. Smith rich...@laptop.org One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Dracut RTC development
On Fri, Oct 28, 2011 at 2:06 PM, Esteban Bordón ebor...@plan.ceibal.edu.uy wrote: Hi all, Is there any development of RTC anti rollback in dracut modules? Which should be its behavior? What do you mean by RTC anti roll back? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Dracut RTC development
RTC anti-rollback (RTCAR) is a Open Firmware based security feature intended to prevent RTC rollback attacks - subversion of timed leases by setting the real-time clock backward in time. http://wiki.laptop.org/go/RTC_Anti-rollback Esteban. 2011/10/31 Peter Robinson pbrobin...@gmail.com On Fri, Oct 28, 2011 at 2:06 PM, Esteban Bordón ebor...@plan.ceibal.edu.uy wrote: Hi all, Is there any development of RTC anti rollback in dracut modules? Which should be its behavior? What do you mean by RTC anti roll back? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: EC corruption by q2f04rc firmware
To date I have one 2007-vintage XO-1 with q2f04rd (and os882). It worked normally (and never lost charge while plugged in to AC) until I closed the lid (thereby putting it into suspend). Upon opening the lid and pressing power, the power light changed to red, and the native XO green keyboard no longer worked. [I then used an external USB keyboard.] The XO-1 continued to function normally (except for no native keyboard), except that the power light continued to remain red. I removed AC and let the XO-1 continue until it shut down when it had exhausted its battery. I then plugged the AC back in (power light showed orange) and let it recharge until the power light was green, then rebooted. That XO-1 is now functioning normally. Closing the lid puts it into suspend, but after opening the lid and pressing power it resumes properly (power light is green) and (WITH THE AC PLUGGED IN) functions normally. With AC removed, shutting the lid then opening the lid and pressing power caused the power light to go red - but the XO-1 continued to function normally (did not check keyboard - was using external USB). (With AC removed) repeated closing the lid then reopening and pressing power caused the system to halt with the EC problem - disconnect ... message. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Where we are at ~ 11.3.x, 12.x
We are at an interesting point, schedule wise. To a large extent we have been working in a concentrated effort for XO-1.75, and it has been mostly in sync. This is about to change. On the software for XO-1.75 front, we are about to split our efforts. With the 11.3.0 release, the Sugar/Fedora/Gnome team will be aggressively moving their focus and attention to F16, which brings a ton of API and infra changes (they'll probably later move to F17, which shouldn't break APIs) -- only attending to very high priority bugs on the 11.3.x track. We'll continue working on kernel and power mgmt infra on the 11.3.x track. I propose that we aim to cut a final 11.3.1 shortly before Xmas. If at that point we have good-enough PM, audio, and we are not facing any major issues, that will be the final 11.3.x release. We want to put a good 11.3.x-for-XO-1.75 out, but we _must_ shift our focus to 12.1.0 (F16/F17), where we will be using hard fp, with compiler options pretty close to our hardware's ideal. On XO-1 and 1.5, 11.3.0 is shaping up to be a fantastic release. It has all the 11.2.0 goods, plus working Collaboration, and a ton of improvements, big and small. It's the release we always wanted to have ;-) The F16/17 timeframe (loosely defined as mid-2012) gives us enough time to have a much more polished power mgmt; one that puts the ball where we want it in terms of battery time when in ebook usage mode, and in use under weak power sources (such as solar panels). In general, we have a big mountain of work on the F16/F17 track, but it is also the opportunity to make XO-1.75 shine. At the hardware level, XO-1.75 is the machine we wanted to build from day one -- the power draw and performance are ideal for our goals. Now we /just/ have to show we can write software to drive it right! :-) m -- mar...@laptop.org -- Software Architect - OLPC - 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
11.3.0 can have difficulties with wired ethernet adapter
Using os883 with q3b22.rom on an XO-1.5. On first-time boot-up with a build, which interface gets assigned to the ethernet depends upon when the ethernet-USB adapter gets plugged in to the XO. [If plugged in too soon, the wired ethernet gets assigned the 'eth0' interface -- which causes conflicts trying to use wireless.] Further, with the ethernet-USB adapter plugged in, shutdown usually takes about a minute (while displaying the U/L warnings screen). It appears that something regarding the ethernet is being timed out. [Also, since this summer the Fedora 14 NetworkManager has gotten aggressive -- it periodically simply disconnects my ethernet connection (so that it can scan for wireless signals ??). My bypass is to stop the NetworkManager before connecting the XO to the internet using the wired ethernet rather than connecting the XO through a wireless AP.] mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.0 can have difficulties with wired ethernet adapter
On Mon, Oct 31, 2011 at 9:14 AM, Mikus Grinbergs mi...@bga.com wrote: Using os883 with q3b22.rom on an XO-1.5. On first-time boot-up with a build, which interface gets assigned to the ethernet depends upon when the ethernet-USB adapter gets plugged in to the XO. [If plugged in too soon, the wired ethernet gets assigned the 'eth0' interface -- which causes conflicts trying to use wireless.] This is a known bug. I don't know the bug number off the top of my head. It is a race condition between the usb ethernet and the wireless renaming udev rules. To fix this unplug wired ethernet, remove /etc/udev/rules.d/70-persistent-net.rules and reboot the computer. Wait for the computer to come up and then plug in the usb ethernet adapter. This will allow the persistent rules file to set wireless as eth0 and usb ethernet as eth1 and susbsequent reboots want cause the race condition where usb ethernet grabs eth0 and then udev hangs trying to rename wlan0 to eth0 which is taken. Further, with the ethernet-USB adapter plugged in, shutdown usually takes about a minute (while displaying the U/L warnings screen). It appears that something regarding the ethernet is being timed out. Haven't see this sorry. Perhaps getting the device renaming and persistent rules straightened out will fix it. [Also, since this summer the Fedora 14 NetworkManager has gotten aggressive -- it periodically simply disconnects my ethernet connection (so that it can scan for wireless signals ??). My bypass is to stop the NetworkManager before connecting the XO to the internet using the wired ethernet rather than connecting the XO through a wireless AP.] Have definitely not seen this. NetworkManager will bring up both interfaces if they are available. Are you sure that NM isn't connecting to wireless in a bad environment and causing the network to hang because it is going out the wifi connection instead of the usb ethernet? Please open a ticket for this and we can get some NM logs to see what is happening. -Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.0 can have difficulties with wired ethernet adapter
On Mon, Oct 31, 2011 at 4:14 PM, Mikus Grinbergs mi...@bga.com wrote: Using os883 with q3b22.rom on an XO-1.5. On first-time boot-up with a build, which interface gets assigned to the ethernet depends upon when the ethernet-USB adapter gets plugged in to the XO. [If plugged in too soon, the wired ethernet gets assigned the 'eth0' interface -- which causes conflicts trying to use wireless.] Can you explain how we can reproduce this? At which point do you connect the ethernet adapter? We already have a mechanism in place that should reserve eth0 for the internal wifi card, so this is unexpected. Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.0 can have difficulties with wired ethernet adapter
On Mon, Oct 31, 2011 at 4:59 PM, Jon Nettleton jon.nettle...@gmail.com wrote: We have mechanisms that rename the wifi interface to eth0. The problem is that the usb ethernet comes of first and is given eth0 which causes udev to thrash when wifi is brought up and it tries to rename it. I think it usually ends up naming the device wlan-eth0 or something like that. When I implemented this wifi rename, I checked the udev code and found that it checked all rules file for something that might claim the persistent name being generated, and if so, it would not use that name for persistent rules and instead moved to 'eth1' - and I tested this thoroughly (this was back in Fedora 11). Perhaps this behaviour has changed, I'll try your reproduction steps. Thanks Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Dracut RTC development
On Fri, Oct 28, 2011 at 9:06 AM, Esteban Bordón ebor...@plan.ceibal.edu.uy wrote: Is there any development of RTC anti rollback in dracut modules? Which should be its behavior? Hi Esteban, we are working at this with Manuel. I've been a bit distracted with C1 bringup. Let's take this offlist and work on it. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - 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: 11.3.0 release candidate 4 (build 883) released
Hi Daniel,On 29 Oct 2011, at 22:28, Daniel Drake wrote:Hi,We're pleased to announce our 4th release candidate of our new11.3.0 software release.Information and installation instructions can be found here:http://wiki.laptop.org/go/Release_notes/11.3.0Quick links for those who know which files need to be grabbed and saveto USB disks:http://download.laptop.org/xo-1/os/candidate/883/http://download.laptop.org/xo-1.5/os/candidate/883/http://download.laptop.org/xo-1.75/os/candidate/883/This is a signed release candidate that can be installed on all XOs,even those with security enabled.We're looking for testing and feedback on all aspects of the system.I've just been testing Telescope-12 on the XO-1.75 running the new 883 build, first the good news, the camera is showing up correctly in Record and Telescope, fab! :) Now the not so hot:- While in Telescope-12, clicking the digital zoom toolbar button completely locked up the XO-1.75 (re-testing with an XO-1 the digital zoom works ok).- After some waiting and many attempted keyboard shortcuts, I decided to power down. Clicking the power hardware button did not trigger the usual shut down screen during this particular lockup case; clicking the power button twice (assuming it might just be the gfx that had locked-up) had no effect; finally I held down the power button for some seconds until the power led flashes and then the hard powers off.- On reboot the Journal now shows 3 corrupt entries (see attached screen shot) with no name and unknown metadata. None of the three entries allow invoking the details view or raise their palette so can not be erased via the Sugar Journal UI.The three corrupt entries will be an entry for Browse where I visited ASLO to download telescope and then quit Browse; the downloaded Telescope-12 bundle; and the instance entry for the Telescope that was running when the XO locked up.Given the nature of the hard power off I understand why some data would not have been synched to disk, but just wanted to raise this case here. I guess the actionable items might be:1) fixing Telescope-12's digital zoom not to lock up an XO-1.75 (I don't have an XO-1.5 to test but I re-checked on an XO-1 which still worked fine).2) Seeing why the XO-1.75 hard crashed, I'm assuming something camera driver related may have borked badly (I do have a serial cable here for un-bricking an XO-1.75 but don't know my way around that side of things very well).3) Making Datastore more robust to corrupt entries; and/or perhaps just not displaying corrupt entries in the Journal UI (assuming they can be tested for reliably); and/or allowing them be erased via the Journal UI; and/or improving the way Journal displays a corrupt entry (broken document icon, fake title name).I'll hang onto this datastore as is, for a little while, in case someone wants to explore.Regards,--GaryThanks for any help you can offer, and for all the feedback that wasreceived throughout development.Our scheduled release date is November 1st.Please review the "Known problems" section of the release notes. Somedocumented issues are carried over from previous releases, but othersare new and are things that we will aim to fix in the few weeks beforerelease, including:XO-1.75 Sound does not work in many activities (ticket #11296). There is no suspend/resume support yet. There is slight mouse cursor visual corruption in Sugar, and themouse cursor in GNOME appears odd, but is otherwise functional.XO-1 users: we have identified a bug in the firmware releases shippedduring 11.3.0 development and in earlier 11.3.0 release candidatebuilds 880 and 881.Affected versions are Q2E46 and Q2E47. You can check which version youare running in the Sugar 'Settings' dialog.Unfortunately, a bug in the firmware update code means that thesefirmware versions will not automatically upgrade to newer versions. Wehave fixed this in Q2E48 (included in 11.3.0 build 882 onwards), butexisting users of Q2E46 and Q2E47 will need to update manually. Sorryabout that. The procedure is outlined here:http://dev.laptop.org/ticket/11336#comment:8Ask for help on these lists if needed.Users of 11.2.0 and previous (who will be running older firmwarereleases such as Q2E45) are not affected, and XO-1.5 and XO-1.75 usersare similarly unaffected.Changes since build 882:Camera use under Scratch on XO-1.5 no longer exhibits bad colors.Upgrades from 11.2 will now prompt the user to update activities.An XO-1.75 "third dot" boot hang is hopefully fixed.uvc USB webcam driver is now available on XO-1.75XO-1.75 kernel update includes some audio improvements - but we knowthere are still issues.XO-1 screen backlight will turn itself off upon inactivity againXO-1.5 and XO-1.75 firmware updates included.Closed tickets:#11357 Boot freezing on third clock dot#11297 Scratch: Camera quality in xo-1.5 is worst than in os874#11304 11.3.0 build 8 is not dimming, powering off the screen backlight on XO-1#11354 UVC webcam driver not available on XO-1.75#11355 No
Re: EC corruption by q2f04rc firmware
mi...@bga.com said: To date I have one 2007-vintage XO-1 with q2f04rd (and os882). It worked normally (and never lost charge while plugged in to AC) until I closed the lid (thereby putting it into suspend). Upon opening the lid and pressing power, the power light changed to red, and the native XO green keyboard no longer worked. I can reproduce this, or something very similar. I'm using q2f04rc and 883 on a XO-1 c2 For me, the key is to make it happen is removing AC power. Closing and opening the lid works normally if the AC is plugged in. Without AC, I've seen the battery LED go red at least twice, but I can't make it happen now. Ahh... found it. I only get the red LED if the battery is fully charged. What do you call the LED next to the battery LED that indicates that the system is running? That's tangled up in this confusion too. I've seen my system running when that LED is off and seen it turn on when I poke the power-off button and back off when I try to start the system. I'll call it the CPU LED. Starting with a full battery and no AC, the pattern is: battery LED is off, CPU LED is on close lid short delay CPU LED goes out few second delay battery LED goes orange few second delay battery LED goes red pause open lid (I've got it setup to auto start) system goes active, CPU LED stays off, battery LED stays red, keyboard doesn't work -- Where is the nice big picture of the XO with labels for everything? (I thought I had it bookmarked.) How do I find it at times like this? -- These are my opinions, not necessarily my employer's. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
