OLPC PM - the early years

Now that Mitch has his fast path resume working, it is time for the kernel
guys to earn their keep too.   OFW now handles the actual suspend and
resume of the core - we call into the subroutine at 0xf0000,  the system
suspends, and upon resume, control comes back to us.  OFW even nicely 
restores us back to protected mode, which simplifies things greatly.

So, replacing what we had previously, we just set up the SCI wakeup bits
(and soon, GPE0 bits, right EC hackers?), save our current processor state,
call into the routine, and the do it all backwards.

I also added suspend/resume functionality for the MFGPT timers, so that
the MFGPT clock event gets correctly restored for NOHZ mode.  The patch is
attached - I'll push it into unstable if nobody cries too hard.

Next up, KFB suspend / resume support and I2C suspend/resume.

Jordan
--

-- 
Jordan Crouse
Senior Linux Engineer
Advanced Micro Devices, Inc.
<www.amd.com/embeddedprocessors>

diff --git a/arch/i386/kernel/geode.c b/arch/i386/kernel/geode.c
index 9ee54b6..2e6ec95 100644
--- a/arch/i386/kernel/geode.c
+++ b/arch/i386/kernel/geode.c
 <at>  <at>  -1,5 +1,5  <at>  <at> 
 /* AMD Geode southbridge support code

Re: OLPC "iperf hang" notes

David Miller wrote:
>
> Looks like the retransmits on the sender side are being
> dropped at the device.
>
>   
Quite possibly.

I decoded the packets in the USB trace.  There is a lot of packet 
reordering going on - the sequence numbers don't increase monotonically.

Subtracting out the first sequence number and dividing by the constant 
fixed length of the outgoing packets, the sequence is:

0 1  4  6  2  3  7  5  8  9  11  13  10 14 12  15  16  18  20  17  21  
19  22  23  *  25 *  27  28  29  30

The ACKs work as expected, i.e. when the sequence fills in, the ACKs 
catch up.

"*" shows a sequence number that never showed up - packets "24" and "26" 
were not transmitted.  The ACK sequence stalled after "23", reflecting 
the fact that 24 never arrived.

I killed the process 12 seconds after progress stalled (i.e. after point 
"30').  There were no retransmissions during that time.

Re: OLPC PM - the early years

Jordan Crouse wrote:
> Now that Mitch has his fast path resume working, 

Where "working" in this case currently means "sometimes it wakes up, and 
sometimes it doesn't" 

Mitch

Wikiosity

_______________________________________________
Devel mailing list
Devel <at> laptop.org
http://mailman.laptop.org/mailman/listinfo/devel

Re: Why not Xvid? [was codec optimization]

Sorry for jumping ahead, but this something I really don't understand.
Let's assume that there are currently a few valid US patents on JPEG, 
MJPEG (There are probably more) as well as for MPEG4.2 (xvid divx wmv1 
and many more are MPEG4 part 2 implementations). My question is, so 
what? A patent is a territorial legal being -- it is valid only where it 
was granted. Even if JPEG is covered by hundreds of active US patents, 
and some unenforceable EU patents, it has nothing to do with countries 
in which the OLPCs will be distributed, since those patents are invalid 
there.

salsaman <at> xs4all.nl wrote:
> On Tue, February 27, 2007 19:46, José Antonio wrote:
>> What about Xvid? It is open source and is the better codec in CPU
>> resources
>> use and quality...
> 
> Well, if you are going to use patented codecs, why not just use x264. It's
> better quality than xvid.
x264 requires more computation power for decoding compared to xvid.

> 
> Gabriel.
> http://lives.sourceforge.net
> 
Zvi.

Re: Why not Xvid? [was codec optimization]

On Thu, 2007-03-01 at 18:55 +0000, Zvi Devir wrote:
> Sorry for jumping ahead, but this something I really don't understand.
> Let's assume that there are currently a few valid US patents on JPEG, 
> MJPEG (There are probably more) as well as for MPEG4.2 (xvid divx wmv1 
> and many more are MPEG4 part 2 implementations). My question is, so 
> what? A patent is a territorial legal being -- it is valid only where it 
> was granted. Even if JPEG is covered by hundreds of active US patents, 
> and some unenforceable EU patents, it has nothing to do with countries 
> in which the OLPCs will be distributed, since those patents are invalid 
> there.

That is a good way to sabotage a project.  I'll leave the legal stuff up
to our lawyers but taking a who cares attitude does not solve the issue.
Countries can do what they want, which is why we are using the gstreamer
framework.  If they feel that mp3 or mpeg or whatever is legal to put on
the machines they can do it but we are not going to ship with patent
encumbered formats which could put some countries in awkward positions.
That is not a decision we can make for the people receiving the laptops.

BTW Jpeg is obviously ok to use since I have yet to see a distro pull it
out. Not sure about MJpeg.

--

-- 
John (J5) Palmieri <johnp <at> redhat.com>

Re: Why not Xvid? [was codec optimization]

John (J5) Palmieri wrote:

>On Thu, 2007-03-01 at 18:55 +0000, Zvi Devir wrote:
>  
>
>>Sorry for jumping ahead, but this something I really don't understand.
>>Let's assume that there are currently a few valid US patents on JPEG, 
>>MJPEG (There are probably more) as well as for MPEG4.2 (xvid divx wmv1 
>>and many more are MPEG4 part 2 implementations). My question is, so 
>>what? A patent is a territorial legal being -- it is valid only where it 
>>was granted. Even if JPEG is covered by hundreds of active US patents, 
>>and some unenforceable EU patents, it has nothing to do with countries 
>>in which the OLPCs will be distributed, since those patents are invalid 
>>there.
>>    
>>
>
>That is a good way to sabotage a project.  I'll leave the legal stuff up
>to our lawyers but taking a who cares attitude does not solve the issue.
>Countries can do what they want, which is why we are using the gstreamer
>framework.  If they feel that mp3 or mpeg or whatever is legal to put on
>the machines they can do it but we are not going to ship with patent
>encumbered formats which could put some countries in awkward positions.
>That is not a decision we can make for the people receiving the laptops.
>
>BTW Jpeg is obviously ok to use since I have yet to see a distro pull it
>out. Not sure about MJpeg.
>
>  
>

The jpeg patents expired some time last year. Mjpeg should be patent 
free as it is simply a sequence of jpegs (which was pointed out already).

Gabriel.
http://lives.sourceforge.net

Re: codec optimization

Also sprach Dan Williams:

 > > I am interested in helping optimize the video/audio codec used in OLPC.
 > > But I don't know which one will be used mainly. Can anyone point it out to me?
 > 
 > It's likely Ogg Theora (video) and Ogg Vorbis (audio).  They are in need
 > to some optimization help, so anything you could provide would be great.

After some late nights in the lab, we have just proposed making video
a first-class citizen on the web by adding a <video> element:

  http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-February/009702.html

Our internal implementation uses Theora and it looks great. We havn't
tried it on the XO yet.

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome <at> opera.com                  http://people.opera.com/howcome

Re: OLPC "iperf hang" notes

Hi Mitch,

I took a over-the-air capture of the transmitted frames and repeated
your analysis.  This is the sequence that I got:

2 4 1 3 5 7 9 6 10 8 11 12 14 16 13 17 15 18 19 20 21 * 23 24 25 26 27
(I uploaded the capture here http://dev.laptop.org/ticket/915, "*" is
for packet 23)

The TCP trace acknowledgments up to packet 20.  This last
acknowledgement is repeated 6 times and after that the connection is
frozen.

Javier

> I decoded the packets in the USB trace.  There is a lot of packet
> reordering going on - the sequence numbers don't increase monotonically.
>
> Subtracting out the first sequence number and dividing by the constant
> fixed length of the outgoing packets, the sequence is:
>
> 0 1  4  6  2  3  7  5  8  9  11  13  10 14 12  15  16  18  20  17  21
> 19  22  23  *  25 *  27  28  29  30
>
> The ACKs work as expected, i.e. when the sequence fills in, the ACKs
> catch up.
>
> "*" shows a sequence number that never showed up - packets "24" and "26"
> were not transmitted.  The ACK sequence stalled after "23", reflecting
> the fact that 24 never arrived.
>
> I killed the process 12 seconds after progress stalled (i.e. after point
> "30').  There were no retransmissions during that time.
>
> _______________________________________________
> Devel mailing list
> Devel <at> laptop.org
> http://mailman.laptop.org/mailman/listinfo/devel
>

--

-- 
Javier Cardona
cozybit Inc.
p 415 974 6770
f 415 974 6771
c 415 630 0627
e javier <at> cozybit.com

Re: OLPC "iperf hang" notes

In Javier's trace, only 26 packets were transmitted, whereas in each of 
my test runs, there were exactly 29 outgoing packets.  So I guess the 
"29" number is not exactly repeatable.

I wonder what is causing the packet reordering?  Does iperf explicitly 
force reordering in order to stress test the TCP?  I would expect 
out-of-order packets to be extremely rare - virtually nonexistent - 
within the confines of a single machine.

Javier Cardona wrote:
> Hi Mitch,
>
> I took a over-the-air capture of the transmitted frames and repeated
> your analysis.  This is the sequence that I got:
>
> 2 4 1 3 5 7 9 6 10 8 11 12 14 16 13 17 15 18 19 20 21 * 23 24 25 26 27
> (I uploaded the capture here http://dev.laptop.org/ticket/915, "*" is
> for packet 23)
>
> The TCP trace acknowledgments up to packet 20.  This last
> acknowledgement is repeated 6 times and after that the connection is
> frozen.
>
> Javier
>
>
>
>> I decoded the packets in the USB trace.  There is a lot of packet
>> reordering going on - the sequence numbers don't increase monotonically.
>>
>> Subtracting out the first sequence number and dividing by the constant
>> fixed length of the outgoing packets, the sequence is:
>>
>> 0 1  4  6  2  3  7  5  8  9  11  13  10 14 12  15  16  18  20  17  21
>> 19  22  23  *  25 *  27  28  29  30
>>
>> The ACKs work as expected, i.e. when the sequence fills in, the ACKs
>> catch up.
>>
>> "*" shows a sequence number that never showed up - packets "24" and "26"
>> were not transmitted.  The ACK sequence stalled after "23", reflecting
>> the fact that 24 never arrived.
>>
>> I killed the process 12 seconds after progress stalled (i.e. after point
>> "30').  There were no retransmissions during that time.
>>
>> _______________________________________________
>> Devel mailing list
>> Devel <at> laptop.org
>> http://mailman.laptop.org/mailman/listinfo/devel
>>
>
>