It has been a fun and fulfilling weekend tracking down performance
regressions when using DRI on the XO 1.5 platform. One place I was
looking at specifically was blitting solids from userspace to the
kernel. I found that copy_from_user was really chewing up a
significant amount of cpu. Looking f
If your laptops contain your deployment keys, I would recommend using
this [1] so you can easily generate and manage your activations in
situations like this :).
1. http://wiki.paraguayeduca.org/index.php/Yaas_documentation
kind regards,
tch
On Sat, Mar 12, 2011 at 1:46 AM, Sridhar Dhanapalan
w
Nice, you pre-empted my next question! :D
Thanks,
Sridhar
On 15 March 2011 00:03, Martin Abente wrote:
> If your laptops contain your deployment keys, I would recommend using
> this [1] so you can easily generate and manage your activations in
> situations like this :).
>
> 1. http://wiki.parag
On Sunday 13 March 2011, Mikus Grinbergs wrote:
> > The tests have also helped expose other issues with things like sudden
> > power off. In one case a SPO during a write would corrupt the card so
> > badly it became useless. You could only recover them via a super secret
> > tool from the man
On 03/13/2011 06:34 PM, Mikus Grinbergs wrote:
>> The tests have also helped expose other issues with things like sudden
>> power off. In one case a SPO during a write would corrupt the card so
>> badly it became useless. You could only recover them via a super secret
>> tool from the manufacture
of networking) unless your new DRI code is calling this
function directly?
Your performance gains are very exciting but I think they must have
resulted from something else.
My benchmark code is here (including a hack to enable the unaligned
write optimization when X86_INTEL_USERCOPY
On Sunday 13 March 2011, Richard A. Smith wrote:
> On 03/13/2011 01:21 PM, Arnd Bergmann wrote:
> There's a 2nd round of test(s) that runs during the manufacturing and
> burn-in phases. One is a simple firmware test to see if you can talk the
> card at all and then one runs at burn in. It doesn'
On Mar 13, 2011, at 6:34 PM, Mikus Grinbergs wrote:
>> The tests have also helped expose other issues with things like sudden
>> power off. In one case a SPO during a write would corrupt the card so
>> badly it became useless. You could only recover them via a super secret
>> tool from the m
On Monday 14 March 2011 19:50:27 John Watlington wrote:
> Cards that are in the state you describe are most likely dead due to
> running out of spare blocks. There is nothing that can be done to
> rehabilitate them, even using the manufacturer's secret code.
> In a disturbing trend, most of the c
On Sun, Mar 13, 2011 at 11:27:44PM -0700, Yioryos Asprobounitis wrote:
> > You might try patching OpenFirmware to not turn off the
> > card between
> > subsequent accesses.? To do this, assuming you are
> > using Q2E45, add the
> > following early in your olpc.fth file:
> >
> > ??? dev /sd
> > ???
On 14 March 2011 10:58, James Cameron wrote:
> On Sat, Mar 12, 2011 at 03:46:02PM +1100, Sridhar Dhanapalan wrote:
>> There are three main questions raised by this process:
>> [...]
>> 3. why must I wait 24 hours to get the developer key?
>
> Presuming you are asking about an OLPC developer ke
Sridhar -
Yes, that's correct. Multiple valid keys weakens security, since the same
rights can be obtained from multiple sources.
Handling your own key-issuing authority is something we fully support, but it
is a complex and substantial undertaking. It requires a reasonable commitment
to bot
On 15 March 2011 11:01, Ed McNierney wrote:
> Sridhar -
>
> Yes, that's correct. Multiple valid keys weakens security, since the same
> rights can be obtained from multiple sources.
>
> Handling your own key-issuing authority is something we fully support, but it
> is a complex and substantial
On Mar 14, 2011, at 3:18 PM, Arnd Bergmann wrote:
> On Monday 14 March 2011 19:50:27 John Watlington wrote:
>> Cards that are in the state you describe are most likely dead due to
>> running out of spare blocks. There is nothing that can be done to
>> rehabilitate them, even using the manufactu
What would it take to get the current OLPC OS working on a standard
computer, e.g. using VirtualBox?
I found these instructions: http://wiki.laptop.org/go/Emulating_the_XO
Which are deprecated.
I'm thinking of giving it a go, but is there anything I should be aware of?
Sridhar
_
see
http://wiki.sugarlabs.org/go/Downloads#Virtual_Machines_on_all_platforms
Tony
> What would it take to get the current OLPC OS working on a standard
> computer, e.g. using VirtualBox?
>
> I found these instructions: http://wiki.laptop.org/go/Emulating_the_XO
>
> Which are deprecated.
>
> I'm th
16 matches
Mail list logo
