Re: PulseAudio vs XO hardware drivers
On Wed, Nov 23, 2011 at 3:20 AM, Martin Langhoff mar...@laptop.org wrote: IIRC, there was a hard/deep/complex bug that held us from using PA in XO-1 and/or XO-1.5 . Not just a run of the mill early PA bug, nor the usual CPU consumption concerns, 'twas a really hard one. Unfortunately searching isn't leading to the right report :-/ -- so I appeal to our communal elephant memories... I seem to remember (dsd likely knows more) it might have been to do with CPU utilisation on the XO-1. You can now tweak it a lot better and it a lot less than it use to. Might be something worth investigating in the 12.x dev cycle. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] automatic backlight control
fors...@ozonline.com.au wrote: Thanks Paul thanks for testing! The logic appears to be buggy, see #11487: XO-1.75 OS12 backlight is off when you come back inside okay, more testing is needed. as you noted, it's quite hard to tell when it's on and off. i'll see if i can come up with an indicator, on the display or on the LEDs, which will help during debug. As it stands, neither the monochrome nor colour modes are OK in full sunlight. The colour mode causes a significant loss of resolution for reading small black text and even more resolution loss with coloured text. to clarify -- neither of these issues is caused by the auto-turnoff, but they might suggest that one or the other modes is a better target in full sun -- is that what you're saying? where can i find some colored text on the laptop? With the monochrome mode, the shadow of your hands as you type is enough to switch mode which is quite distracting the color/mono selection shouldn't have affect on how much light causes the mode switch. The cutin cutout settings are 50 (bright)and 80 (dark). It does not seem worth raising the 80 figure because there is still visible colour information at 70. The 50 figure could be lowered, direct sunlight is 5-10, so I tried 15, this still could give mode switching from your hands' shadow in direct sunlight. how can you tell the switch has occurred, if you're in full sunlight? i honestly can't tell when it's happened. What I suggest is that the backlight not switch off unless you have been in the sun for (eg) 5 minutes, but switch back on immediately in the dark. I don't have the coding skills or I would have tried it out. For anybody who wants to try it powerd is at /usr/sbin/power the brightness settings are at line1853 monochrome is commented out at lines 1764 1793 uncommenting these lines reenables monochrome in response to the sensor but surprisingly not the control keys i don't follow -- the code in powerd currently has (or should have) no effect on how the brightness keys work. they're handled by olpc-brightness. so they should continue doing what they were doing before you modified those lines to reenable zero brightness gives mono behavior. paul Tony fors...@ozonline.com.au wrote: The shift from colour to monochrome is noticable and would be annoying if it happened a lot, for example as clouds pass, trees and people move. If the hysterisis, the difference between cutin and cutout brightness is large, the change in mode will happen a lot less frequently and not be annoying. I would like to try it switching automatically to monochrome but with large hysterisis. I'll wait to try OS12 you may be in a better position to play with this, geographically speaking, than i am -- we're running low on sunlight these days. the hysteresis is currently hard-coded in powerd -- you'll find it in the function ambient_adjust_init(). it only gets set once, though, so after powerd starts, you can change the limits directly and they should take effect immediately. additionally, to cause auto-monochrome to happen, uncomment the obvious lines at the end of set_brightness() and brightness_ramp(). paul Tony ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel _ This mail has been virus scanned by Australia On Line see http://www.australiaonline.net.au/mailscanning =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.1 build 13 released for XO-1.75
On 22 Nov 2011, at 17:28, Martin Langhoff wrote: The oh! and one more thing build. An OFW full of goodies, and a kernel that should S/R reliably. Download from: http://build.laptop.org/11.3.1/os13/ Before I try and open a ticket, is anyone else seeing the cursor sprite corrupt after waking from fast suspend? It doesn't happen every time, but more often than not. Moving the corrupt block of bits over some UI widget restores it back to the correct pointer again. This started appearing in os12. Think I'm also seeing the (clicky) keyboard intermittently fail to wake from the fast suspend as well. Only happend once so far, but it was on first boot while I was typing a name in. I paused after typing one character, just long enough for it to fast suspend. The cursor corrupted when I woke it, and I couldn't type any more name, though I could select/highlight the one character with the trackpad cursor. Have only just installed os13 so will try to trigger it some more. Regards, --Gary Changes: - OFWEC at http://wiki.laptop.org/go/OLPC_Firmware_q4c05 - Kernel Andres Salomon (1): pm: don't use sram when suspending; just use wfi --- os12/xo1.75/os12.packages.txt 2011-11-21 18:10:40.0 -0500 +++ os13/xo1.75/os13.packages.txt 2011-11-22 12:17:38.0 -0500 -kernel-3.0.0_xo1.75-2018.1738.olpc.e3f6aac.armv7l +kernel-3.0.0_xo1.75-2021.1409.olpc.6b59895.armv7l -olpc-firmware-q4c04-1.unsigned.noarch +olpc-firmware-q4c05-1.unsigned.noarch cheers, 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.1 build 13 released for XO-1.75
On Wed, Nov 23, 2011 at 9:47 AM, Gary Martin garycmar...@googlemail.com wrote: Before I try and open a ticket, is anyone else seeing the cursor sprite corrupt after waking from fast suspend? After S/R, we lose the cursor. Sometimes it just goes away, sometimes you get a corrupt version of it. File it against it x.org, to the name of Jon Nettleton :-) Think I'm also seeing the (clicky) keyboard intermittently fail to wake from the fast suspend as well. That probably merits bumping #11379 to blocker again, 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: PulseAudio vs XO hardware drivers
On Tue, Nov 22, 2011 at 9:20 PM, Martin Langhoff mar...@laptop.org wrote: IIRC, there was a hard/deep/complex bug that held us from using PA in XO-1 and/or XO-1.5 . Not just a run of the mill early PA bug, nor the usual CPU consumption concerns, 'twas a really hard one. Unfortunately searching isn't leading to the right report :-/ -- so I appeal to our communal elephant memories... At the time it completely failed on XO-1 with IO errors in the logs. I doubt it was a hard bug, we just took the shortcut of removing it. It definitely needs reevaluating now - we should follow the direction that Fedora and other distros have taken, and this is certainly it. However, I suspect getting all of our use cases (TamTam, measure, speak, record, ...) all working smoothly on 3 laptop models will be a fair amount of work. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.1 build 13 released for XO-1.75
Hi,
I tested it a bit and found:
- same drawing cursor bug as Gary
- pendrive did not automount (did echo
/etc/powerd/flags/inhibit-suspend as Gonzalo suggested, reboot, and
then it work, among with the cursor)
- open, then close Fototoon activity, gives write error. Log attached.
2011/11/23 Martin Langhoff martin.langh...@gmail.com:
On Wed, Nov 23, 2011 at 9:47 AM, Gary Martin garycmar...@googlemail.com
wrote:
Before I try and open a ticket, is anyone else seeing the cursor sprite
corrupt after waking from fast suspend?
After S/R, we lose the cursor. Sometimes it just goes away, sometimes
you get a corrupt version of it.
File it against it x.org, to the name of Jon Nettleton :-)
Think I'm also seeing the (clicky) keyboard intermittently fail to wake from
the fast suspend as well.
That probably merits bumping #11379 to blocker again,
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
--
.. manuq ..
** Message: pygobject_register_sinkfunc is deprecated (HippoCanvasBox)
82.649432 WARNING root: KeepButton has been deprecated since Sugar 0.94 and should not be used in newly written code.
82.671285 WARNING root: No gtk.AccelGroup in the top level window.
82.690386 WARNING root: No gtk.AccelGroup in the top level window.
82.730394 WARNING root: No gtk.AccelGroup in the top level window.
82.759717 WARNING root: No gtk.AccelGroup in the top level window.
82.759717 ERROR root: SCREEN WIDTH 1200 DEF_SPACING 6
83.563315 WARNING root: No gtk.AccelGroup in the top level window.
** (sugar-activity:1176): DEBUG: Got client ID 10f3ec6786f2f3d55a84186503000937
** (sugar-activity:1176): DEBUG: Setting initial properties
** (sugar-activity:1176): DEBUG: Received SaveYourself(SmSaveLocal, !Shutdown, SmInteractStyleNone, !Fast) in state idle
** (sugar-activity:1176): DEBUG: Sending SaveYourselfDone(True) for initial SaveYourself
** (sugar-activity:1176): DEBUG: Received SaveComplete message in state save-yourself-done
86.139245 WARNING root: No gtk.AccelGroup in the top level window.
/usr/lib/python2.7/site-packages/sugar/datastore/datastore.py:103: UnicodeWarning: Unicode unequal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
if key not in self._properties or self._properties[key] != value:
87.501511 ERROR root: Error saving activity object to datastore
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/sugar/activity/activity.py, line 845, in _prepare_close
self.save()
File /usr/lib/python2.7/site-packages/sugar/activity/activity.py, line 679, in save
self.write_file(file_path)
File /home/olpc/Activities/FotoToon.activity/historietaactivity.py, line 124, in write_file
persistence.write(file_path, self.page)
File /home/olpc/Activities/FotoToon.activity/persistencia.py, line 99, in write
'ignore'), data_file_name.encode('ascii', 'ignore'))
File /usr/lib/python2.7/zipfile.py, line 1032, in write
self.fp.write(zinfo.FileHeader())
File /usr/lib/python2.7/zipfile.py, line 342, in FileHeader
len(filename), len(extra))
error: ushort format requires 0 = number = USHRT_MAX
87.583022 WARNING root: No gtk.AccelGroup in the top level window.
108.229625 WARNING root: No gtk.AccelGroup in the top level window.
108.285838 WARNING root: No gtk.AccelGroup in the top level window.
INICIALIZANDO FOTOTOON
Cuadro INIT
write file path /home/olpc/.sugar/default/org.eq.FotoToon/instance/87
{'version': '1', 'boxs': [{'globes': [], 'image_name': ''}]}
file_name /home/olpc/.sugar/default/org.eq.FotoToon/instance/87
Exited with status 0, pid 1176 data (None, open file 'fdopen', mode 'w' at 0xbb9700, dbus.ByteArray('18e1c455a93cb0e37090c8c8c776c663cc205451', variant_level=1))
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: 11.3.1 build 13 released for XO-1.75
El día 23 de noviembre de 2011 15:34, Manuel Quiñones ma...@laptop.org escribió: Hi, I tested it a bit and found: - same drawing cursor bug as Gary - pendrive did not automount (did echo /etc/powerd/flags/inhibit-suspend as Gonzalo suggested, reboot, and then it work, among with the cursor) - open, then close Fototoon activity, gives write error. Log attached. Same error in zipfile.py in Memorize save_game, you cannot create a new game :( -- .. manuq .. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.1 build 13 released for XO-1.75
El día 23 de noviembre de 2011 15:42, Manuel Quiñones ma...@laptop.org escribió: El día 23 de noviembre de 2011 15:34, Manuel Quiñones ma...@laptop.org escribió: Hi, I tested it a bit and found: - same drawing cursor bug as Gary - pendrive did not automount (did echo /etc/powerd/flags/inhibit-suspend as Gonzalo suggested, reboot, and then it work, among with the cursor) - open, then close Fototoon activity, gives write error. Log attached. Same error in zipfile.py in Memorize save_game, you cannot create a new game :( Filled as #11490 -- .. manuq .. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.1 build 13 released for XO-1.75
Looks like a collateral effect of loosing date. Updated the ticket. Gonzalo Filled as #11490 -- .. manuq .. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.1 build 12 released for XO-1.75
On Tue, Nov 22, 2011 at 5:23 AM, James Cameron qu...@laptop.org wrote: Gnome mouse cursor is not reloaded on resume from sleep I can't find a ticket for that, but it is well known. I've filed it as http://dev.laptop.org/ticket/11491 for Jon Nettleton. USB will not mount in Gnome on resume from sleep #11369. Yep. 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
Re: 11.3.1 build 13 released for XO-1.75
On Wed, Nov 23, 2011 at 9:57 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Wed, Nov 23, 2011 at 9:47 AM, Gary Martin garycmar...@googlemail.com wrote: Before I try and open a ticket, is anyone else seeing the cursor sprite corrupt after waking from fast suspend? After S/R, we lose the cursor. Sometimes it just goes away, sometimes you get a corrupt version of it. File it against it x.org, to the name of Jon Nettleton :-) Filed http://dev.laptop.org/ticket/11491 Think I'm also seeing the (clicky) keyboard intermittently fail to wake from the fast suspend as well. That probably merits bumping #11379 to blocker again, Done. 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.1 build 13 released for XO-1.75
2011/11/23 Gonzalo Odiard gonz...@laptop.org: Looks like a collateral effect of loosing date. Updated the ticket. Gonzalo Filled as #11490 I'm almost there fixing the RTC problem #11400. Hopefully next build... 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: Re: [Sugar-devel] automatic backlight control
fors...@ozonline.com.au wrote: Thanks Paul thanks for testing! The logic appears to be buggy, see #11487: XO-1.75 OS12 backlight is off when you come back inside okay, more testing is needed. as you noted, it's quite hard to tell when it's on and off. i'll see if i can come up with an indicator, on the display or on the LEDs, which will help during debug. Its not too hard to write a TurtleArt program which continuously prints the brightness sensor and the screen brightness, there is a block for the brightness sensor and sample python code 'sensor.py' for the screen bightness As it stands, neither the monochrome nor colour modes are OK in full sunlight. The colour mode causes a significant loss of resolution for reading small black text and even more resolution loss with coloured text. to clarify -- neither of these issues is caused by the auto-turnoff, but they might suggest that one or the other modes is a better target in full sun -- is that what you're saying? The loss of resolution in full sunlight results from disabling the monochrome mode, disabled for both manual and automatic triggering in OS12 where can i find some colored text on the laptop? I am not sure what you are asking, links in webpages is one example, you can create coloured text in Write With the monochrome mode, the shadow of your hands as you type is enough to switch mode which is quite distracting the color/mono selection shouldn't have affect on how much light causes the mode switch. no it doesn't, what are you saying? The cutin cutout settings are 50 (bright)and 80 (dark). It does not seem worth raising the 80 figure because there is still visible colour information at 70. The 50 figure could be lowered, direct sunlight is 5-10, so I tried 15, this still could give mode switching from your hands' shadow in direct sunlight. how can you tell the switch has occurred, if you're in full sunlight? i honestly can't tell when it's happened. I am running a Turtleart program to interrogate the sensor and screen brightness What I suggest is that the backlight not switch off unless you have been in the sun for (eg) 5 minutes, but switch back on immediately in the dark. I don't have the coding skills or I would have tried it out. For anybody who wants to try it powerd is at /usr/sbin/power the brightness settings are at line1853 monochrome is commented out at lines 1764 1793 uncommenting these lines reenables monochrome in response to the sensor but surprisingly not the control keys i don't follow -- the code in powerd currently has (or should have) no effect on how the brightness keys work. they're handled by olpc-brightness. so they should continue doing what they were doing before you modified those lines to reenable zero brightness gives mono behavior. The brightness keys no longer give monochrome at zero brightness. You must have coded that somewhere in powerd? Line 1793 looked like it was going to be the culprit. paul Tony fors...@ozonline.com.au wrote: The shift from colour to monochrome is noticable and would be annoying if it happened a lot, for example as clouds pass, trees and people move. If the hysterisis, the difference between cutin and cutout brightness is large, the change in mode will happen a lot less frequently and not be annoying. I would like to try it switching automatically to monochrome but with large hysterisis. I'll wait to try OS12 you may be in a better position to play with this, geographically speaking, than i am -- we're running low on sunlight these days. the hysteresis is currently hard-coded in powerd -- you'll find it in the function ambient_adjust_init(). it only gets set once, though, so after powerd starts, you can change the limits directly and they should take effect immediately. additionally, to cause auto-monochrome to happen, uncomment the obvious lines at the end of set_brightness() and brightness_ramp(). paul Tony ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel _ This mail has been virus scanned by Australia On Line see http://www.australiaonline.net.au/mailscanning =- paul fox, p...@laptop.org ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org
Re: [Sugar-devel] automatic backlight control
fors...@ozonline.com.au wrote: fors...@ozonline.com.au wrote: Thanks Paul thanks for testing! The logic appears to be buggy, see #11487: XO-1.75 OS12 backlight is off when you come back inside okay, more testing is needed. as you noted, it's quite hard to tell when it's on and off. i'll see if i can come up with an indicator, on the display or on the LEDs, which will help during debug. Its not too hard to write a TurtleArt program which continuously prints the brightness sensor and the screen brightness, there is a block for the brightness sensor and sample python code 'sensor.py' for the screen bightness oh, of course. thx. As it stands, neither the monochrome nor colour modes are OK in full sunlight. The colour mode causes a significant loss of resolution for reading small black text and even more resolution loss with coloured text. to clarify -- neither of these issues is caused by the auto-turnoff, but they might suggest that one or the other modes is a better target in full sun -- is that what you're saying? The loss of resolution in full sunlight results from disabling the monochrome mode, disabled for both manual and automatic triggering in OS12 you were complaining about the visuals for both mono and color mode, and i was just verifying that you didn't think those visuals were powerd's fault. it's in a different mode now (color), but you don't seem to think monochrome mode would be any better. this is what's confusing me. where can i find some colored text on the laptop? I am not sure what you are asking, links in webpages is one example, you can create coloured text in Write With the monochrome mode, the shadow of your hands as you type is enough to switch mode which is quite distracting the color/mono selection shouldn't have affect on how much light causes the mode switch. no it doesn't, what are you saying? why did you say with the monochrome mode, ...? The cutin cutout settings are 50 (bright)and 80 (dark). It does not seem worth raising the 80 figure because there is still visible colour information at 70. The 50 figure could be lowered, direct sunlight is 5-10, so I tried 15, this still could give mode switching from your hands' shadow in direct sunlight. how can you tell the switch has occurred, if you're in full sunlight? i honestly can't tell when it's happened. I am running a Turtleart program to interrogate the sensor and screen brightness What I suggest is that the backlight not switch off unless you have been in the sun for (eg) 5 minutes, but switch back on immediately in the dark. I don't have the coding skills or I would have tried it out. For anybody who wants to try it powerd is at /usr/sbin/power the brightness settings are at line1853 monochrome is commented out at lines 1764 1793 uncommenting these lines reenables monochrome in response to the sensor but surprisingly not the control keys i don't follow -- the code in powerd currently has (or should have) no effect on how the brightness keys work. they're handled by olpc-brightness. so they should continue doing what they were doing before you modified those lines to reenable zero brightness gives mono behavior. The brightness keys no longer give monochrome at zero brightness. You must have coded that somewhere in powerd? Line 1793 looked like it was going to be the culprit. no, i coded it in /usr/bin/olpc-brightness. the code in powerd is there for suspend dimming, and now, auto-backlight turnoff. thanks, paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.1 build 13 released for XO-1.75
I also ran into the problem that suspends take longer than on earlier OSs. Frequently a three second wakeup has passed before suspend completes. Even a six second wakeup hangs occasionally. I added pgf's code to tell the kernel to abort a suspend if a wakeup event has happened during the suspend operation to my script, and it fixed the problem. I then ran into the problem that os13 is that it doesn't actually suspend. This appears to be related to EC code --- if it hasn't updated the EC code it works fine.Linux thinks it is suspending, but the power light never blinks. Also seems to relate to having DC power provided. powerd is too aggressive on suspend, given that USB doesn't work after a resume. You have to work fast to get something onto the laptop from a USB stick. Cheers, wad On Nov 23, 2011, at 2:22 PM, Martin Langhoff wrote: 2011/11/23 Gonzalo Odiard gonz...@laptop.org: Looks like a collateral effect of loosing date. Updated the ticket. Gonzalo Filled as #11490 I'm almost there fixing the RTC problem #11400. Hopefully next build... 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Android on XO-1.75
Hi Devs I'm just wondering what's the actual state of Android on the XO-1.75?. Are there any docs or info about how to install it ?. Are there any plans for it on the near future?. Thanks and cheers. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.1 build 13 released for XO-1.75
john wrote: I also ran into the problem that suspends take longer than on earlier OSs. Frequently a three second wakeup has passed before suspend completes. Even a six second wakeup hangs occasionally. I added pgf's code to tell the kernel to abort a suspend if a wakeup event has happened during the suspend operation to my script, and it fixed the problem. I then ran into the problem that os13 is that it doesn't actually suspend. This appears to be related to EC code --- if it hasn't updated the EC code it works fine.Linux thinks it is suspending, but the power light never blinks. Also seems to relate to having DC power provided. i think that EC thing may have been a red herring. it seems that the pgf's code you added may be the culprit. (i.e., the code from http://dev.laptop.org/ticket/11416#comment:3) i don't know what's going on, but if i run, or rerun, your script on a failing machine, i reliably get errors to the effect of processes refuse to freeze after 0.00 seconds (from memory). if i run just a single rtcwake (timeout doesn't matter) _outside_ of your dortc script, that s/r works, and then i can start your script and it, too, works. since powerd will do an rtcwake on its own if you don't kill it soon enough, some of your successful runs may have benefitted from that. so i have your entire testbed running now, mostly using that trick. i did not have to set olpc-ols.0/high_lim to zero. paul powerd is too aggressive on suspend, given that USB doesn't work after a resume. You have to work fast to get something onto the laptop from a USB stick. Cheers, wad On Nov 23, 2011, at 2:22 PM, Martin Langhoff wrote: 2011/11/23 Gonzalo Odiard gonz...@laptop.org: Looks like a collateral effect of loosing date. Updated the ticket. Gonzalo Filled as #11490 I'm almost there fixing the RTC problem #11400. Hopefully next build... 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Android on XO-1.75
I am doing it. It got stuck since when I have received the machine github was down for a long time (was hacked or something). After that I decided to wait for Android 4.0 and just yesterday was I able to download all the source. Since I have already did a half-finished XO-1 port I can tell you that you can expect a first boot in a month... On 2011.11.23. 21:57, Rafael Ortiz wrote: Hi Devs I'm just wondering what's the actual state of Android on the XO-1.75?. Are there any docs or info about how to install it ?. Are there any plans for it on the near future?. Thanks and cheers. ___ 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: 11.3.1 build 13 released for XO-1.75
On Nov 23, 2011, at 4:00 PM, Paul Fox wrote: john wrote: I also ran into the problem that suspends take longer than on earlier OSs. Frequently a three second wakeup has passed before suspend completes. Even a six second wakeup hangs occasionally. I added pgf's code to tell the kernel to abort a suspend if a wakeup event has happened during the suspend operation to my script, and it fixed the problem. I then ran into the problem that os13 doesn't actually suspend. This appears to be related to EC code --- if it hasn't updated the EC code it works fine.Linux thinks it is suspending, but the power light never blinks. Also seems to relate to having DC power provided. i think that EC thing may have been a red herring. it seems that the pgf's code you added may be the culprit. (i.e., the code from http://dev.laptop.org/ticket/11416#comment:3) i don't know what's going on, but if i run, or rerun, your script on a failing machine, i reliably get errors to the effect of processes refuse to freeze after 0.00 seconds (from memory). if i run just a single rtcwake (timeout doesn't matter) _outside_ of your dortc script, that s/r works, and then i can start your script and it, too, works. since powerd will do an rtcwake on its own if you don't kill it soon enough, some of your successful runs may have benefitted from that. so i have your entire testbed running now, mostly using that trick. i did not have to set olpc-ols.0/high_lim to zero. Thanks. I've modified my script to call rtcwake once w. a long wakeup, then to move into the fast cycle with the kernel aborting suspend if the wakeup event overtakes it during suspend. wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: 11.3.1 build 13 released for XO-1.75
So the question is -- what's different about the first S/R cyce. And one
obvious (naive?) answer is: it is killing USB.
Subsequent S/R cycles, perhaps benefit from a faster / different S/R
codepath that doesn't have to deal with USB.
cheers,
m
{ Martin Langhoff - one laptop per child }
On Nov 23, 2011 5:22 PM, John Watlington w...@laptop.org wrote:
On Nov 23, 2011, at 4:00 PM, Paul Fox wrote:
john wrote:
I also ran into the problem that suspends take longer than on
earlier OSs. Frequently a three second wakeup has passed
before suspend completes. Even a six second wakeup hangs
occasionally. I added pgf's code to tell the kernel to abort a
suspend if a wakeup event has happened during the
suspend operation to my script, and it fixed the problem.
I then ran into the problem that os13 doesn't actually
suspend. This appears to be related to EC code --- if it hasn't
updated the EC code it works fine.Linux thinks it is suspending,
but the power light never blinks. Also seems to relate to having
DC power provided.
i think that EC thing may have been a red herring.
it seems that the pgf's code you added may be the culprit. (i.e.,
the code from http://dev.laptop.org/ticket/11416#comment:3) i don't
know what's going on, but if i run, or rerun, your script on a failing
machine, i reliably get errors to the effect of processes refuse to
freeze after 0.00 seconds (from memory). if i run just a single
rtcwake (timeout doesn't matter) _outside_ of your dortc script, that
s/r works, and then i can start your script and it, too, works. since
powerd will do an rtcwake on its own if you don't kill it soon enough,
some of your successful runs may have benefitted from that.
so i have your entire testbed running now, mostly using that trick. i
did not have to set olpc-ols.0/high_lim to zero.
Thanks. I've modified my script to call rtcwake once w. a long
wakeup, then to move into the fast cycle with the kernel aborting
suspend if the wakeup event overtakes it during suspend.
wad
___
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: 11.3.1 build 13 released for XO-1.75
It turns out not to be so simple. I had two laptops stop suspending
after running for over 2K cycles. They weren't hung --- Linux thought
it was suspending/resuming --- but the EC indicated that they were never
actually suspending. Stopping my script and restarting it (with the standalone
rtcwake at the start) caused the laptop to restart suspending.
I'm not sure I can believe test results w. os13...
Cheers,
wad
On Nov 23, 2011, at 6:30 PM, Martin Langhoff wrote:
So the question is -- what's different about the first S/R cyce. And one
obvious (naive?) answer is: it is killing USB.
Subsequent S/R cycles, perhaps benefit from a faster / different S/R codepath
that doesn't have to deal with USB.
cheers,
m
{ Martin Langhoff - one laptop per child }
On Nov 23, 2011 5:22 PM, John Watlington w...@laptop.org wrote:
On Nov 23, 2011, at 4:00 PM, Paul Fox wrote:
john wrote:
I also ran into the problem that suspends take longer than on
earlier OSs. Frequently a three second wakeup has passed
before suspend completes. Even a six second wakeup hangs
occasionally. I added pgf's code to tell the kernel to abort a
suspend if a wakeup event has happened during the
suspend operation to my script, and it fixed the problem.
I then ran into the problem that os13 doesn't actually
suspend. This appears to be related to EC code --- if it hasn't
updated the EC code it works fine.Linux thinks it is suspending,
but the power light never blinks. Also seems to relate to having
DC power provided.
i think that EC thing may have been a red herring.
it seems that the pgf's code you added may be the culprit. (i.e.,
the code from http://dev.laptop.org/ticket/11416#comment:3) i don't
know what's going on, but if i run, or rerun, your script on a failing
machine, i reliably get errors to the effect of processes refuse to
freeze after 0.00 seconds (from memory). if i run just a single
rtcwake (timeout doesn't matter) _outside_ of your dortc script, that
s/r works, and then i can start your script and it, too, works. since
powerd will do an rtcwake on its own if you don't kill it soon enough,
some of your successful runs may have benefitted from that.
so i have your entire testbed running now, mostly using that trick. i
did not have to set olpc-ols.0/high_lim to zero.
Thanks. I've modified my script to call rtcwake once w. a long
wakeup, then to move into the fast cycle with the kernel aborting
suspend if the wakeup event overtakes it during suspend.
wad
___
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: 11.3.1 build 13 released for XO-1.75
john wrote:
It turns out not to be so simple. I had two laptops stop
suspending after running for over 2K cycles. They weren't hung ---
Linux thought it was suspending/resuming --- but the EC indicated
that they were never actually suspending. Stopping my script and
restarting it (with the standalone rtcwake at the start) caused the
laptop to restart suspending.
did you note the console messages? i'm interested in whether the
symptom is the same as i was seeing earlier. in particular, note
whether it says Freezing of tasks aborted..., because that implies
there's a wakeup pending.
given the nature of the failure we were seeing (and that i'm guessing
you saw above), for now i'd eliminate the inner race-stopping loop i
suggested this evening. increase the suspend time to reduce the
likelihood of the alarm firing before suspend occurs. at least that
way if something bad happens it'll stop. (and if it does stop, make
note of the console messages.)
I'm not sure I can believe test results w. os13...
well, the further we get, the more bugs we'll flush out of hiding.
think of it as a good thing!! ;-)
happy thanksgiving, all!
paul
Cheers,
wad
On Nov 23, 2011, at 6:30 PM, Martin Langhoff wrote:
So the question is -- what's different about the first S/R cyce. And one
obvious (naive?) answer is: it is killing USB.
Subsequent S/R cycles, perhaps benefit from a faster / different S/R
codepath
that doesn't have to deal with USB.
cheers,
m
{ Martin Langhoff - one laptop per child }
On Nov 23, 2011 5:22 PM, John Watlington w...@laptop.org wrote:
On Nov 23, 2011, at 4:00 PM, Paul Fox wrote:
john wrote:
I also ran into the problem that suspends take longer than on
earlier OSs. Frequently a three second wakeup has passed
before suspend completes. Even a six second wakeup hangs
occasionally. I added pgf's code to tell the kernel to abort a
suspend if a wakeup event has happened during the
suspend operation to my script, and it fixed the problem.
I then ran into the problem that os13 doesn't actually
suspend. This appears to be related to EC code --- if it hasn't
updated the EC code it works fine.Linux thinks it is suspending,
but the power light never blinks. Also seems to relate to having
DC power provided.
i think that EC thing may have been a red herring.
it seems that the pgf's code you added may be the culprit. (i.e.,
the code from http://dev.laptop.org/ticket/11416#comment:3) i don't
know what's going on, but if i run, or rerun, your script on a failing
machine, i reliably get errors to the effect of processes refuse to
freeze after 0.00 seconds (from memory). if i run just a single
rtcwake (timeout doesn't matter) _outside_ of your dortc script, that
s/r works, and then i can start your script and it, too, works. since
powerd will do an rtcwake on its own if you don't kill it soon enough,
some of your successful runs may have benefitted from that.
so i have your entire testbed running now, mostly using that trick. i
did not have to set olpc-ols.0/high_lim to zero.
Thanks. I've modified my script to call rtcwake once w. a long
wakeup, then to move into the fast cycle with the kernel aborting
suspend if the wakeup event overtakes it during suspend.
wad
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
