RE: [Sugar-devel] Test in Sugar 0.96.1
Yes.. I'm a editor.. but that changes I can't make it.. Maybe a admin can make them?¿ Try it.. Date: Tue, 22 May 2012 08:59:52 -0300 From: gonz...@laptop.org To: alan...@hotmail.com CC: sugar-de...@lists.sugarlabs.org; olpc...@lists.laptop.org; a...@lists.sugarlabs.org; walter.ben...@gmail.com; satel...@bendbroadband.com; devel@lists.laptop.org; dee...@laptop.org.au Subject: Re: [Sugar-devel] Test in Sugar 0.96.1 Thanks Alan for doing this extensive test!I imagine you have spent a lot of time doing the tests.Are you a editor in ASLO now, right? If yes, I think you should update the information about the supported versions. Gonzalo On Tue, May 22, 2012 at 2:58 AM, Alan Jhonn Aguiar Schwyn wrote: Hi, Some time ago, I make this spreadsheet [1] with the results of my test with XO 1.0 on Sugar 0.94.1Now, I'm making a new version [2] of the Sugar Test with the test results on Sugar 0.96.1 (Build 12.1-os11: 21011o0) The list of activities it's based on [3]. Anyone with the link can edit the spreadsheet... And the time goes by.. and the activities are updated.. I attach 2 graphs: the first, with the comparative of the activities for each sugar version (0.82, 0.84, ..., 0.96)with 2 colors: the red bars are of january, the blue bars, of today. The second picture, is of the time of the activities since the latest update: 111 activities have 6 months or less81 activities between 6 months - 1 year251 activities! more than 1 year.. and counting.. The test on Sugar 0.94 are (mostly) finished.. and some activities continues saying in ASLO "I'm run on Sugar 0.82to 0.90" when runs perfectly on 0.94 (and possibly in 0.96) Regards! Alan [1] https://docs.google.com/spreadsheet/ccc?key=0AntaXnq4oy2_dHpvZHhLeGRQYzc1cDlRZU9Mc1NldGc [2] https://docs.google.com/spreadsheet/ccc?key=0AntaXnq4oy2_dDhXak9wYmlZU1pVX19IUGs0NkY3cEE [3] https://docs.google.com/spreadsheet/ccc?key=0AntaXnq4oy2_dFJjNE9TemZUUGtzLVNEQnF4UlIwQkE ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list sugar-de...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Browse crashes - os11 running on XO 1.75
Browse crashes very easily. For example opening http://html5test.com crashes Browse. (By the way Browse does get a nice score on the test). rihowa...@gmail.com linux - the best things in life are free ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Closing audio devices on activity switch (was: Re: [PATCH powerd] audio inhibit support)
[CC'ing sugar-devel as this is about Activity development] Walter Bender writes: [Closing the audio device when switching from Measure to something else] >> What about non-sugarised audio players? Jukebox seems to be broken, so >> someone using a Gnome application (e.g. Rhythmbox) instead would seem >> rather likely. > > I presume that in order to run the GNOME app, you need to either exit > Sugar or launch Terminal. In either case, notify::active should be > enough. Or am I not understanding something? Hmm, thinking about this again, the music player probably isn't that good of an example here. You'd want it running in the background, playing music all the time, not just while you're away from Measure. But just to counter your argument: You can a) easily bind application launches to keyboards shortcuts with metacity (so no Terminal required) and b) have started the application already and just switch windows to use it. Hmm, maybe the music player still fits in here: Start the music player to play some music before start of lesson, use Measure during lesson (keeping the music player running), play some music again in the break, use Measure again. Only slightly contrived IMO. :) Let's make it work as well as we can without going to great lengths. Users will always find novel ways to use our software, I wouldn't want to limit what they can do just because we couldn't think of a use case involving that particular kind of transition. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ pgp3SNrwiL7Y5.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH powerd] Inhibit suspend while audio device is open
Paul Fox writes: > 3) as far as the activity testing you did, i agree with your results > -- i didn't try everything, but Scratch is certainly the biggest > violator, in that it keeps the device in RUNNING state even when > not playing anything, and when not in the foreground. observed > with strace, Scratch actually continuously writes (using ioctl()) > to the device. perhaps someone could work with the scratch > authors on this? Thanks for testing that in detail. I've filed a ticket [1] against the Scratch component on bugs.sl.o. It got assigned to Rafael Ortiz; maybe he has a channel to the Scratch devs. Sascha [1] https://bugs.sugarlabs.org/ticket/3630 -- http://sascha.silbe.org/ http://www.infra-silbe.de/ pgpcFktIEvXlx.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH powerd] Inhibit suspend while audio device is open
Paul Fox writes: > i'm perfectly happy to enable this, if we think it fixes the problem > well enough, and/or we think the applications can be fixed to do the > right thing. (for some reasonable value of "we".) It does for me, but as much testing as I may have done can never account for a million devices in the field. It does more good than harm (and even the harm is on the "safe" side of consuming more power rather than disrupting operation), so I'd recommend to merge it at least for the next release (post-12.1). Whether it should go into 12.1 at this point in time is not my call to make. > in searching for a relevant ticket on d.l.o. just now, i found #6670, > which is quite relevant, if perhaps a bit dated. Thanks for the reference and for CC'ing me. I've commented on the ticket; repeating here for convenience of others following this thread: As Paul pointed out correctly on the mailing list (or maybe IRC), simply reading the current status of the audio device is just a point-in-time check. inotify doesn't notice changes to the status file either. So in theory we're opening ourselves up for a race condition. However, it would be a problem even with a better check: AFAICT using the audio device doesn't increment wakeup_count, so if an Activity started using the audio device right before we suspend, we'd have the same problem. In practice, it will probably be less of a problem, as most usage of audio devices is going to be the direct result of some external event (user input or network traffic). Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ pgpGcv5nktLnz.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[PATCH RFC powerd] Add support for inhibiting suspend via UPower
UPower has API to let applications set "latency requirements" [1]. The
UPower back-end code uses the kernel PM QoS interface [2] to set the
requested CPU (DMA) latency (in µs, up to ~35 minutes) and network
throughput (in kbps). cpuidle hooks into the PM QoS framework to
provide CPU latency management.
By monitoring UPower latency requests we can ensure that we don't
suspend even though some application needs to stay active despite
there being no noticeable user input.
It also has the benefit of letting applications use the UPower API
instead of powerd-specific inhibit files. Once the kernel supports
seamless suspends, taking scheduling information (timers!) and
requested latencies into account, UPower will most likely be the API
of choice for Gnome applications to register their requests.
The latency limits for inhibiting suspend are somewhat arbitrary, as
there's no direct correlation between the latency types known to
UPower and the effects of the user space initiated suspend powerd
does. If powerd suspends, applications won't get to run at all, not
just after some latency. By choosing rather high limits we can let
applications register themselves as requiring to be running from time
to time, but not having particular needs as to how fast the CPU is
running.
Future improvements to this feature may cause powerd to wake up from
time to time to let registered applications get scheduled, according
to the lowest registered latency. But how well that would work is
something that needs to be tested extensively, so it's out of scope
for now. And maybe the work is better spent implementing kernel-driven
seamless suspend rather than tuning the user space solution with its
known, inherent drawbacks.
[1] http://upower.freedesktop.org/docs/QoS.html
[2] https://www.kernel.org/doc/Documentation/power/pm_qos_interface.txt
Signed-off-by: Sascha Silbe
---
For UPower support to actually work, you'll need some fixes to
UPower. One of them has already landed in upstream git, the others
are queued for review. [3]
[3]
http://lists.freedesktop.org/archives/devkit-devel/2012-May/thread.html#1277
powerd-dbus/Makefile |2 +-
powerd-dbus/powerd-dbus.c|1 +
powerd-dbus/powerd-dbus.h|1 +
powerd-dbus/upower_monitor.c | 164 ++
4 files changed, 167 insertions(+), 1 deletion(-)
diff --git a/powerd-dbus/Makefile b/powerd-dbus/Makefile
index aecd61b..4040b4c 100644
--- a/powerd-dbus/Makefile
+++ b/powerd-dbus/Makefile
@@ -10,7 +10,7 @@ CFLAGS += -DG_LOG_DOMAIN=\"powerd-dbus\"
all: powerd-dbus
-powerd-dbus: ohm-keystore-glue.h ohm-keystore.c network.c nm_monitor.c
wpas_monitor.c powerd-dbus.c powerd-dbus.h
+powerd-dbus: ohm-keystore-glue.h ohm-keystore.c network.c nm_monitor.c
wpas_monitor.c upower_monitor.c powerd-dbus.c powerd-dbus.h
opt=-combine; ln -sf /dev/null null.c; \
gcc -flto -c null.c 2>/dev/null && opt=-flto ; \
gcc $(CFLAGS) -fwhole-program $$opt \
diff --git a/powerd-dbus/powerd-dbus.c b/powerd-dbus/powerd-dbus.c
index ccc1ea5..23ac074 100644
--- a/powerd-dbus/powerd-dbus.c
+++ b/powerd-dbus/powerd-dbus.c
@@ -62,6 +62,7 @@ int main(void)
ohm_keystore_new();
wpas_monitor_init();
nm_monitor_init();
+ upower_monitor_init();
g_message("entering main loop");
g_main_loop_run(mainloop);
diff --git a/powerd-dbus/powerd-dbus.h b/powerd-dbus/powerd-dbus.h
index db12ebf..1a81423 100644
--- a/powerd-dbus/powerd-dbus.h
+++ b/powerd-dbus/powerd-dbus.h
@@ -13,6 +13,7 @@ typedef struct OhmKeystore OhmKeystore;
OhmKeystore *ohm_keystore_new(void);
int nm_monitor_init(void);
+int upower_monitor_init(void);
int wpas_monitor_init(void);
void nm_suspend_ok(gboolean suspend_ok);
void wpas_suspend_ok(gboolean suspend_ok);
diff --git a/powerd-dbus/upower_monitor.c b/powerd-dbus/upower_monitor.c
new file mode 100644
index 000..1cd8d85
--- /dev/null
+++ b/powerd-dbus/upower_monitor.c
@@ -0,0 +1,164 @@
+#include
+#include
+#include
+#include
+#include "powerd-dbus.h"
+
+
+#define UPOWER_SERVICE "org.freedesktop.UPower"
+#define UPOWER_QOS_PATH "/org/freedesktop/UPower/Policy"
+#define UPOWER_QOS_IFACE "org.freedesktop.UPower.QoS"
+
+static GDBusProxy *upower_obj = NULL;
+static gint32 network_throughput = -1;
+static gint32 cpu_dma_latency = -1;
+
+static guint timeout_id = 0;
+static gboolean last_susp_ok = TRUE;
+
+
+
+static gboolean send_susp_ok(void)
+{
+ last_susp_ok = TRUE;
+ powerd_send_event("allow-suspend", "upower_suspend_ok");
+ timeout_id = 0;
+ return FALSE;
+}
+
+static void communicate_state(gboolean new_susp_ok)
+{
+ /*
+* If suspend-not-OK but we had a timer about to send suspend-OK,
+* abort the timer.
+*/
+ if (!new_susp_ok && timeout_id) {
+ g_message("%d: abort suspend-OK timer, suspend not OK.",
(int)time(0));
+ g_source_remove(timeout_id);
+ timeout_
[PATCH powerd 2/2] fall back to device tree if olpc-hwinfo is unavailable
olpc-hwinfo is shipped as part of olpc-utils, which does a lot of changes to the system that are not suitable for most systems other than XOs running OLPC OS. olpc-hwinfo will still be used if available, but in addition to reading the DMI information (only available on x86, i.e. on XO-1 and XO-1.5) we now check the device tree (if available), thereby adding XO-1.75 support. Signed-off-by: Sascha Silbe --- powerd | 25 + 1 file changed, 25 insertions(+) diff --git a/powerd b/powerd index c6d9487..028e666 100755 --- a/powerd +++ b/powerd @@ -793,6 +793,31 @@ read_hwinfo() hwversion=$(olpc-hwinfo model) return fi +if [ -r /proc/device-tree/banner-name ] +then +case "$(http://lists.laptop.org/listinfo/devel
[PATCH powerd 1/2] powerd-dbus: fix potential NULL dereference in inactive code segment
The deactivated wpa-supplicant 0.7 support code contains a typo that
could cause a NULL dereference if wpa-supplicant dies at just the
right time.
Signed-off-by: Sascha Silbe
---
powerd-dbus/wpas_monitor.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/powerd-dbus/wpas_monitor.c b/powerd-dbus/wpas_monitor.c
index e28964f..c54530f 100644
--- a/powerd-dbus/wpas_monitor.c
+++ b/powerd-dbus/wpas_monitor.c
@@ -110,7 +110,7 @@ static void monitor_interface(const gchar *path)
0, NULL,
WPAS_SERVICE, path, WPAS_INTERFACE_IFACE,
NULL, &error);
- if (!wpas_obj) {
+ if (!proxy) {
g_warning("Error creating wpas interface proxy: %s\n",
error->message);
g_error_free(error);
return;
--
1.7.10
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
[PATCH powerd 0/2] Fixes
Two fixes I did while working on the UPower support. Sascha Silbe (2): powerd-dbus: fix potential NULL dereference in inactive code segment fall back to device tree if olpc-hwinfo is unavailable powerd | 25 + powerd-dbus/wpas_monitor.c |2 +- 2 files changed, 26 insertions(+), 1 deletion(-) -- 1.7.10 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH powerd] audio inhibit support
On Tue, May 22, 2012 at 1:59 PM, Sascha Silbe wrote: > Walter Bender writes: > >> What I found was that notify::action was enough to catch most of what >> I needed. At first I didn't think it was working properly because I >> wasn't seeing the signal when switching from Measure to the Desktop. >> But as soon as I switched to a different activity, I see the >> notification. So unless the Desktop (or Journal or Neighborhood) need >> to access gstreamer, I think we are OK. > > What about non-sugarised audio players? Jukebox seems to be broken, so > someone using a Gnome application (e.g. Rhythmbox) instead would seem > rather likely. I presume that in order to run the GNOME app, you need to either exit Sugar or launch Terminal. In either case, notify::active should be enough. Or am I not understanding something? -walter > > Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: pointer (touchpad) aceleration and threshold too low in 11.3.* builds
2012/5/22 Martin Langhoff : > On Tue, May 22, 2012 at 1:33 PM, Eduardo H. Silva > wrote: >> Ok, perhaps this is the problem. I actually have a B4, sorry for >> calling it XO-1 (I as I have refered to it forever)... Am I the only >> one getting this experience then? > > So XO-1 B4? Can you confirm as per > http://wiki.laptop.org/go/Touchpad/Testing what touchpad is being > recognized? cat /sys/bus/serio/drivers/psmouse/serio*/protocol gives: OLPC HGPK > Can you propose alternative xset values for acceleration? Just changing the threshold to 0, so 'xset m 7/4 0' improves a lot the general feeling, but swiping from corner to corner, while improved, still takes more than just one swipe. I'll be testing more values. Eduardo > 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: [PATCH powerd] audio inhibit support
Walter Bender writes: > What I found was that notify::action was enough to catch most of what > I needed. At first I didn't think it was working properly because I > wasn't seeing the signal when switching from Measure to the Desktop. > But as soon as I switched to a different activity, I see the > notification. So unless the Desktop (or Journal or Neighborhood) need > to access gstreamer, I think we are OK. What about non-sugarised audio players? Jukebox seems to be broken, so someone using a Gnome application (e.g. Rhythmbox) instead would seem rather likely. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ pgpXtdYOam2FC.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: pointer (touchpad) aceleration and threshold too low in 11.3.* builds
martin wrote: > On Tue, May 22, 2012 at 1:33 PM, Eduardo H. Silva > wrote: > > Ok, perhaps this is the problem. I actually have a B4, sorry for > > calling it XO-1 (I as I have refered to it forever)... Am I the only > > one getting this experience then? > > So XO-1 B4? Can you confirm as per > http://wiki.laptop.org/go/Touchpad/Testing what touchpad is being > recognized? > > Can you propose alternative xset values for acceleration? fyi, i just filed this issue as #11882, so it would be great if any proposals/fixes/suggestions could end up there. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: pointer (touchpad) aceleration and threshold too low in 11.3.* builds
On Tue, May 22, 2012 at 1:33 PM, Eduardo H. Silva wrote: > Ok, perhaps this is the problem. I actually have a B4, sorry for > calling it XO-1 (I as I have refered to it forever)... Am I the only > one getting this experience then? So XO-1 B4? Can you confirm as per http://wiki.laptop.org/go/Touchpad/Testing what touchpad is being recognized? Can you propose alternative xset values for acceleration? 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: pointer (touchpad) aceleration and threshold too low in 11.3.* builds
2012/5/18 Martin Langhoff : > On Wed, May 16, 2012 at 8:17 PM, Eduardo H. Silva > wrote: >> xset q tells that in 11.3.1, the pointer is configured with the values: >> >> acceleration 7/4 threshold: 1 >> >> This takes 2, 3 and sometimes 4 swipes to move across the screen. > > Strange! That's one of our explicit tests -- we test that a quick > diagonal swipe can get you across the screen from one corner to > another. Falling a tad short may be acceptable, this has to be > balanced with aiming for small UI elements in eToys, for example. Perhaps I over-exagerated. But still takes 2 (and a bit) quick swipes to go from corner to corner. > Of course, with slow swipes, it can take many tries to move across the > screen :-) > I am sure that if this was widely broken we'd have been up in arms > about it way earlier. I'm interested to know about your XO -- model > and TP model, perhaps in some cases our touchpad settings are bad. Ok, perhaps this is the problem. I actually have a B4, sorry for calling it XO-1 (I as I have refered to it forever)... Am I the only one getting this experience then? > See the wikipage at http://wiki.laptop.org/go/Touchpad/Testing -- it > also has additional diagnostic tests that can shed light on the topic. Some of the times after doing the "rolling finger" test the cursor became wonky and then fixed itself after a few seconds. And the "corner to corner sweep" fails as well of course. Eduardo > 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: [PATCH powerd] audio inhibit support
On Tue, May 22, 2012 at 9:12 AM, Gary Martin wrote: > Hi Walter, > > You might also want to take a quick look at what Physics is doing, might not > be pretty, but I remember needing to catch more than one event/test to make > sure the simulation was suspended correctly across a range of past build > releases, perhaps also a case where switching to a desktop view vs. another > activity needed to watch for a different event. What I found was that notify::action was enough to catch most of what I needed. At first I didn't think it was working properly because I wasn't seeing the signal when switching from Measure to the Desktop. But as soon as I switched to a different activity, I see the notification. So unless the Desktop (or Journal or Neighborhood) need to access gstreamer, I think we are OK. -walter > > Regards, > --Gary > > On May 21, 2012 1:44 PM, "Walter Bender" wrote: >> >> On Mon, May 21, 2012 at 6:44 AM, Sascha Silbe >> wrote: >> > Walter Bender writes: >> > >> >> On Sun, May 20, 2012 at 7:00 PM, Sascha Silbe >> >> wrote: >> > [...] >> >>> - Turtle Art v138 >> >> >> >> For TA, this is by design: if you are recording data, you want to keep >> >> recording even when in the background. Same goes for Measure. >> > >> > Ah, should have noted exactly what I tested for each Activity. For >> > Turtle Art (wasn't that Turtle Blocks at some time? still confused) that >> > was only playback, not recording. >> > >> >> For playback it should release the device. >> > >> > I agree, for Turtle Art it will usually be the right thing to do when >> > switching to a different Activity. Jukebox OTOH would be a good example >> > of an Activity that should continue playback even in the background (but >> > close the device as soon as it's finished playing). >> > >> > Sascha >> > >> > -- >> > http://sascha.silbe.org/ >> > http://www.infra-silbe.de/ >> >> I see that Clock is using notify::active and then checking >> self.props.active. In Turtle Blocks, I had been using >> visibility-notify-event. Is the former recommended? More reliable? >> >> regards. >> >> -walter >> >> -- >> Walter Bender >> Sugar Labs >> http://www.sugarlabs.org >> ___ >> Devel mailing list >> Devel@lists.laptop.org >> http://lists.laptop.org/listinfo/devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH powerd] audio inhibit support
Hi Walter, You might also want to take a quick look at what Physics is doing, might not be pretty, but I remember needing to catch more than one event/test to make sure the simulation was suspended correctly across a range of past build releases, perhaps also a case where switching to a desktop view vs. another activity needed to watch for a different event. Regards, --Gary On May 21, 2012 1:44 PM, "Walter Bender" wrote: > On Mon, May 21, 2012 at 6:44 AM, Sascha Silbe > wrote: > > Walter Bender writes: > > > >> On Sun, May 20, 2012 at 7:00 PM, Sascha Silbe < > si...@activitycentral.com> wrote: > > [...] > >>> - Turtle Art v138 > >> > >> For TA, this is by design: if you are recording data, you want to keep > >> recording even when in the background. Same goes for Measure. > > > > Ah, should have noted exactly what I tested for each Activity. For > > Turtle Art (wasn't that Turtle Blocks at some time? still confused) that > > was only playback, not recording. > > > >> For playback it should release the device. > > > > I agree, for Turtle Art it will usually be the right thing to do when > > switching to a different Activity. Jukebox OTOH would be a good example > > of an Activity that should continue playback even in the background (but > > close the device as soon as it's finished playing). > > > > Sascha > > > > -- > > http://sascha.silbe.org/ > > http://www.infra-silbe.de/ > > I see that Clock is using notify::active and then checking > self.props.active. In Turtle Blocks, I had been using > visibility-notify-event. Is the former recommended? More reliable? > > regards. > > -walter > > -- > Walter Bender > Sugar Labs > http://www.sugarlabs.org > ___ > 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: Booting OLPC OS 12.1 from USB sticks and SD cards
On Tue, May 22, 2012 at 08:01:48AM -0400, Martin Langhoff wrote: > On Mon, May 21, 2012 at 5:39 PM, Sascha Silbe > wrote: > > If there's interest in diagnosing one or more of the failure modes I can > > give details and maybe assist a bit in debugging (or preferably send you > > the hardware), but it looks like a lot of work > > If an OFW hacker shows some interest, they'd say what to try. We've > tweaked OFW USB and SD timings before to handle marginal or out of > spec devices before :-/ Your wish is my command, etc. I reviewed Sascha's report, and didn't find anything clearly caused by Open Firmware. Could I have more details please? In particular: > > two out of three USB SD card readers failing to work in OFW even > > on XO-1.5. And that's for booting only; flashing from USB stick / > > external SD card often fails somewhere in the middle with CRC > > errors or SDHCI timeouts for media that works fine for booting." Which USB SD card readers are to be supported? I've only the one here. Can samples of these devices be provided? What filesystems are on these devices? Have the filesystems passed consistency checks? Booting requires a different pattern of access to flashing, so no surprise that the symptom is different. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Booting OLPC OS 12.1 from USB sticks and SD cards
On Mon, May 21, 2012 at 5:39 PM, Sascha Silbe wrote: > If there's interest in diagnosing one or more of the failure modes I can > give details and maybe assist a bit in debugging (or preferably send you > the hardware), but it looks like a lot of work If an OFW hacker shows some interest, they'd say what to try. We've tweaked OFW USB and SD timings before to handle marginal or out of spec devices before :-/ >. If reliably identifying > flash media (and consumer hardware in general) were possible for end > users a list of known-working hardware would be a better approach. Retail products change the internals all the time, without bothering to change model name, and sometimes without changing model number. >> Jokes aside, I don't think that booting from USB stick is actually >> safe in the face of suspend/resume. > > I would have expected the same, but in practice it seems to work at > least for a few suspend/resume cycles. Contrast that with a) > suspend/resume not working at all for external SD cards on XO-1 and > XO-1.75 and b) me having disabled aggressive suspend/resume on XO-1.5 > because the SD card wasn't entirely reliable across suspend/resume > either. Right. Though what I am trying to say is that SD card reliability (across s/r cycles) is achievable, USB not so much. 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: [Sugar-devel] Test in Sugar 0.96.1
Thanks Alan for doing this extensive test! I imagine you have spent a lot of time doing the tests. Are you a editor in ASLO now, right? If yes, I think you should update the information about the supported versions. Gonzalo On Tue, May 22, 2012 at 2:58 AM, Alan Jhonn Aguiar Schwyn < alan...@hotmail.com> wrote: > > Hi, > > Some time ago, I make this spreadsheet [1] with the results of my test > with XO 1.0 on Sugar 0.94.1 > Now, I'm making a new version [2] of the Sugar Test with the test results > on Sugar 0.96.1 (Build 12.1-os11: 21011o0) > The list of activities it's based on [3]. > > Anyone with the link can edit the spreadsheet... > > And the time goes by.. and the activities are updated.. > > I attach 2 graphs: the first, with the comparative of the activities for > each sugar version (0.82, 0.84, ..., 0.96) > with 2 colors: the red bars are of january, the blue bars, of today. > > The second picture, is of the time of the activities since the latest > update: > 111 activities have 6 months or less > 81 activities between 6 months - 1 year > 251 activities! more than 1 year.. and counting.. > > The test on Sugar 0.94 are (mostly) finished.. and some activities > continues saying in ASLO "I'm run on Sugar 0.82 > to 0.90" when runs perfectly on 0.94 (and possibly in 0.96) > > > Regards! > > Alan > > > [1] > https://docs.google.com/spreadsheet/ccc?key=0AntaXnq4oy2_dHpvZHhLeGRQYzc1cDlRZU9Mc1NldGc > [2] > https://docs.google.com/spreadsheet/ccc?key=0AntaXnq4oy2_dDhXak9wYmlZU1pVX19IUGs0NkY3cEE > [3] > https://docs.google.com/spreadsheet/ccc?key=0AntaXnq4oy2_dFJjNE9TemZUUGtzLVNEQnF4UlIwQkE > > ___ > Sugar-devel mailing list > sugar-de...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
