headers
John Richard Moser | 1 Oct 2006 01:27
Picon

gcc optimizations


It looks like the redundancy analyzer in gcc is broken.  My first hint
was that after 6 hours of work I finally narrowed down some interesting
performance measurements using nbench[1]* to Partial Redundancy
Elimination; my second was popping into #gcc on OFTC and being told the
RA is "stupid" and doesn't work so hot on x86.

It turns out that -O2 turns -ftree-pre on by default, and -Os turns it
off; so certain operations were quite awesomely faster with -Os (and
others slower).  Fiddling with tons of optimizations I eventually
noticed the SAME hit -O2 takes in ONE optimization; I disabled this
during an -O2 compile of nbench and lo and behold the numbers looked a
lot better.

Details on the Wiki at [2].  Somebody should plug some real-world
application into this, like rendering a JPEG image, Web page, or Ogg
Vorbis file and measuring how long this takes in real time using both
'-O2' and '-O2 -fno-tree-pre'.  Some code seems slightly slower, while
most code seems significantly faster.

[1]http://www.tux.org/~mayer/linux/bmark.html
[2]http://wiki.laptop.org/go/User:Bluefoxicy/gcc_optimizations

*nbench is highly CPU intensive, it does no IO benchmarks.  The CPU will
get hot.  I compiled it on a tmpfs mounted on /tmp/x to avoid touching
flash.

--
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Williams | 1 Oct 2006 16:55
Picon
Favicon

Marvell regulatory domain info storage?

Hi,

Talking with Mitch this week brought up an interesting question.  Where
regulatory domain information for the wireless stored?  We have to know
what channels we can(not) operate on for a given country, and therefore
must communicate that information to the laptop.

Does the Marvell chip have internal EEPROM that we write the appropriate
region code to?  Or must we pull that value from the SPI flash and write
it to the card during init?  It appears that the driver pulls a preset
region code from the card, see wlan_ret_get_hw_spec() in wlan_cmdresp.c.
That indicates that the region code is either in (a) firmware, or (b) in
EEPROM on the card.  The region code may apparently be set from
userspace with a private ioctl.

Thoughts?  At worst, we do country-specific flashes, which we were
already going to do for fonts & translations.  At best, the server
and/or firstboot process communicates region code somehow.

Dan
Permalink | Reply | 15 comments |
headers
Krishna Sankar (ksankar | 1 Oct 2006 21:27
Picon
Favicon

RE: Marvell regulatory domain info storage?

As you mentioned, we would need the country specific flashes and that
would be a good place for the region codes as well. The only caveat is,
what happens when a kid with a laptop goes from one country to another ?

An alternative is to tie-in the region codes with some related GUI
element, like the Time Zone. 

May be, a combination - the default region code set in flash, which
becomes the norm after reset et al. Plus a hook to change it, tied to
TZ, (i.e. if a TZ - which necessities a change in region code - is set,
reset the region code as well) and a GUI to set the region code
independent of anything else. If we have the automatic time sync, this
will get more interesting ...

I think we can provide the coarse APIs (getCurrentRegionCode(),
SetRegionCode()) and (under the cover) required steps (rewrite, reset et
al) to make this happen. We would need to maintain the RegionCode-TZ
mapping somewhere in the flash or embedded as a hardware table in the
OS.

One point to explore - is the region code mandatory and is the Marvell
chip capable of all region codes or do we need different Marvell chips
for different regions ?

Cheers
<k/> 

> -----Original Message-----
> From: devel-bounces <at> laptop.org 
> [mailto:devel-bounces <at> laptop.org] On Behalf Of Dan Williams
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jim Gettys | 1 Oct 2006 21:32
Favicon
Gravatar

Re: Marvell regulatory domain info storage?

On Sun, 2006-10-01 at 10:55 -0400, Dan Williams wrote:
> Hi,
> 
> Talking with Mitch this week brought up an interesting question.  Where
> regulatory domain information for the wireless stored?  We have to know
> what channels we can(not) operate on for a given country, and therefore
> must communicate that information to the laptop.
> 
> Does the Marvell chip have internal EEPROM that we write the appropriate
> region code to?  Or must we pull that value from the SPI flash and write
> it to the card during init?  

This should be pretty easy.  On the manufacturing line, they know what
language/keyboard they are loading, and the machine's destination.

> It appears that the driver pulls a preset
> region code from the card, see wlan_ret_get_hw_spec() in wlan_cmdresp.c.
> That indicates that the region code is either in (a) firmware, or (b) in
> EEPROM on the card.  The region code may apparently be set from
> userspace with a private ioctl.
> 
> Thoughts?  At worst, we do country-specific flashes, which we were
> already going to do for fonts & translations.  At best, the server
> and/or firstboot process communicates region code somehow.
>  

Doesn't help: you could be off frequency for these operations.
                           - Jim

--

--
(Continue reading)

Permalink | Reply | 14 comments |
headers
Khaled Hassounah | 2 Oct 2006 01:09
Favicon

Re: Marvell regulatory domain info storage?

> As you mentioned, we would need the country specific flashes and that
> would be a good place for the region codes as well. The only caveat is,
> what happens when a kid with a laptop goes from one country to another ?

Trying to solve that problem would be an overkill. You don't reconfigure
your network card every time you travel.

Khaled
Permalink | Reply | 0 comments |
headers
Mitch Bradley | 2 Oct 2006 08:04
Favicon

Re: Marvell regulatory domain info storage?

The region code, or something equivalent, is a good candidate for the 
"manufacturing data" that Quanta will put in their special section of 
FLASH.  I'm thinking of a two-prong approach:

a) The manufacturing data will include a region code and the driver will 
have a lookup table that maps region code to a list of 
regulatory-approved channels.

b) Optionally, the manufacturing data can also include an explicit 
channel list (probably a bitmask) that, if present, will override the 
region-derived channel list.

Jim Gettys wrote:
> On Sun, 2006-10-01 at 10:55 -0400, Dan Williams wrote:
>   
>> Hi,
>>
>> Talking with Mitch this week brought up an interesting question.  Where
>> regulatory domain information for the wireless stored?  We have to know
>> what channels we can(not) operate on for a given country, and therefore
>> must communicate that information to the laptop.
>>
>> Does the Marvell chip have internal EEPROM that we write the appropriate
>> region code to?  Or must we pull that value from the SPI flash and write
>> it to the card during init?  
>>     
>
> This should be pretty easy.  On the manufacturing line, they know what
> language/keyboard they are loading, and the machine's destination.
>
(Continue reading)

Permalink | Reply | 11 comments |
headers
Dan Williams | 2 Oct 2006 15:45
Picon
Favicon

Re: Marvell regulatory domain info storage?

On Sun, 2006-10-01 at 20:04 -1000, Mitch Bradley wrote:
> The region code, or something equivalent, is a good candidate for the 
> "manufacturing data" that Quanta will put in their special section of 
> FLASH.  I'm thinking of a two-prong approach:
> 
> a) The manufacturing data will include a region code and the driver will 
> have a lookup table that maps region code to a list of 
> regulatory-approved channels.

Right; the current libertas driver already looks up the region code from
the card itself.  But if we get that from the manufacturing area, the
driver has a few tables (mostly for US, EU, and Japan) that show allowed
channels.  We'll likely need to add a lot more tables for different
countries.

> b) Optionally, the manufacturing data can also include an explicit 
> channel list (probably a bitmask) that, if present, will override the 
> region-derived channel list.

I'm not sure, but there may also be power restrictions on a per-country
basis too.  Need to look that up.  At least the FCC restricts power
output of unlicensed devices, but I'm not sure if that's band-specific.

Dan

> 
> Jim Gettys wrote:
> > On Sun, 2006-10-01 at 10:55 -0400, Dan Williams wrote:
> >   
> >> Hi,
(Continue reading)

Permalink | Reply | 10 comments |
headers
Zarro Boogs per Child | 2 Oct 2006 18:17
Favicon

Re: [Trac #135] Web browser does not start up

#135: Web browser does not start up
--------------------+-------------------------------------------------------
 Reporter:  ianb    |        Owner:  dcbw
     Type:  defect  |       Status:  new 
 Priority:  normal  |    Milestone:      
Component:  sugar   |   Resolution:      
 Keywords:          |  
--------------------+-------------------------------------------------------
Comment (by ianb):

 I figured out why this is happening, though not how to resolve.

 My system Python version (on Ubuntu) uses UCS2 as the internal format for
 Unicode.  Both the custom Python included with the jhbuild, and the Python
 on RedHat systems, uses UCS4.

 Currently I have the custom Python installed, but pygobject is being built
 against the system Python.  This causes the error.

--

-- 
Ticket URL: <http://dev.laptop.org/ticket/135#comment:3>
One Laptop Per Child <http://laptop.org/>
Permalink | Reply | 0 comments |
headers
Zarro Boogs per Child | 2 Oct 2006 18:35
Favicon

Re: [Trac #135] Web browser does not start up

#135: Web browser does not start up
--------------------+-------------------------------------------------------
 Reporter:  ianb    |        Owner:  dcbw
     Type:  defect  |       Status:  new 
 Priority:  normal  |    Milestone:      
Component:  sugar   |   Resolution:      
 Keywords:          |  
--------------------+-------------------------------------------------------
Comment (by ianb):

 OK, turned out {{{build/bin/sugar}}} used {{{#!/usr/bin/python}}}.
 Changing it manually to {{{#!/usr/bin/env python}}} made it work (by using
 the custom Python).

 I then had to symlink in the dbus and libxml2 libraries from the system
 site-packages, since they aren't being installed as part of the jhbuild
 currently.  Then it started up.

--

-- 
Ticket URL: <http://dev.laptop.org/ticket/135#comment:4>
One Laptop Per Child <http://laptop.org/>
Permalink | Reply | 0 comments |
headers
Zarro Boogs per Child | 2 Oct 2006 18:54
Favicon

Re: [Trac #53] LinuxBIOS sometimes hangs after "Jumping to LinuxBIOS"

#53: LinuxBIOS sometimes hangs after "Jumping to LinuxBIOS"
-------------------------------+--------------------------------------------
 Reporter:  wmb <at> firmworks.com  |        Owner:  mfoster
     Type:  defect             |       Status:  closed 
 Priority:  blocker            |    Milestone:  ATest  
Component:  linuxbios          |   Resolution:  fixed  
 Keywords:                     |  
-------------------------------+--------------------------------------------
Changes (by cjb):

  * status:  assigned => closed
  * resolution:  => fixed

Comment:

 Closing.

--

-- 
Ticket URL: <http://dev.laptop.org/ticket/53#comment:37>
One Laptop Per Child <http://laptop.org/>
Permalink | Reply | 0 comments |

Gmane