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: 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 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: 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
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: 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
