headers
Mitch Bradley | 1 Nov 2006 03:56
Favicon

System Software Telecon Meeting Minutes, 2006-10-31

System SW Meeting Minutes
2006-10-31

 Richard (moderator)  Mitch (scribe),  Jim,  Chris Ball,  Zephaniah,  Ray,
  Ted,  Chris Blizzard,  Jordan,  Marcello,  Ivan,  MFoster,   Dave 
Woodhouse, Andres

=== Agenda ===
Blizzard:
 * have net manager and browser in build, working well.  camera 
userspace sw working.
 * tmpfs is implemented
 * x setup is working

Chris Ball:
 * the SD is not finding the card (even after cold boot)
 * we can't test simultaneously until SD works, but then it will be easy 
to test simultaneously

Mark Foster:
 * Marvell is trying to get new FPGA bits Real Soon Now

Priorities:
 * Get all the hardware working

 - Get a network manager interface for Sugar, get the browser working well
done
  - Something to demonstrate the camera and video
  - Stabilize the X setup
(Continue reading)

Permalink | Reply | 0 comments |
headers
MBurns | 1 Nov 2006 07:49
Picon

Getting developer boards to talk to eachother.

(Wasn't sure if I should send this to networking <at> , devel-board <at> , or devel <at> . My apologies if this is the wrong choice.)

Problem: Mesh networking (dev board to dev board) does not work. Peer discovery, Mesh View, etc, does not seem to function.

Scenario:
* 2 a-test boards
* both on build 133 (latest),
* 2nd generation (the updated version) wireless card,

Both boards are detecting an in-range wireless network (so they are functioning). The boards don't seem to self-assign themselves address, and putting them on the same 192.168.1/24 subnet didn't help either. Should this be an automatic thing, or is it a known issue?

Any thoughts on what I might do to troubleshoot? I'm giving a talk to a Portland LUG on Thursday and would love to have them working for demonstrations.

--
Michael Burns
Oregon State University

_______________________________________________
Devel mailing list
Devel <at> laptop.org
http://mailman.laptop.org/mailman/listinfo/devel
Permalink | Reply | 2 comments |
headers
Dan Williams | 1 Nov 2006 08:02
Picon
Favicon

Re: Getting developer boards to talk to eachother.

On Tue, 2006-10-31 at 22:49 -0800, MBurns wrote:
> (Wasn't sure if I should send this to networking <at> , devel-board <at> , or
> devel <at> . My apologies if this is the wrong choice.)
> 
> Problem: Mesh networking (dev board to dev board) does not work. Peer
> discovery, Mesh View, etc, does not seem to function. 
> 
> Scenario:
> * 2 a-test boards
> * both on build 133 (latest),
> * 2nd generation (the updated version) wireless card, 
> 
> Both boards are detecting an in-range wireless network (so they are
> functioning). The boards don't seem to self-assign themselves address,
> and putting them on the same 192.168.1/24 subnet didn't help either.
> Should this be an automatic thing, or is it a known issue?

Are you using WEP?  Are you creating an ad-hoc network or using an
existing infrastructure network?  How are you configuring the wireless
settings for the boards?

They won't self-assign an address automatically, and there are a few
NetworkManager bits necessary for automatic ad-hoc connections at
startup which is probably what people are looking for here.

Dan

> Any thoughts on what I might do to troubleshoot? I'm giving a talk to
> a Portland LUG on Thursday and would love to have them working for
> demonstrations. 
> 
> --
> Michael Burns
> Oregon State University
> _______________________________________________
> Devel mailing list
> Devel <at> laptop.org
> http://mailman.laptop.org/mailman/listinfo/devel
Permalink | Reply | 1 comment |
headers
MBurns | 1 Nov 2006 08:13
Picon

Re: Getting developer boards to talk to eachother.

Dan, thanks for the quick response.

On 10/31/06, Dan Williams <dcbw <at> redhat.com> wrote:
Are you using WEP?  Are you creating an ad-hoc network or using an
existing infrastructure network?  How are you configuring the wireless
settings for the boards?

No WEP. I am trying to make an ad hoc network if possible. An existing network is available for a secondary test scenario as well.

My initial thought was that it would auto configure, so I made minimal configuration changes. Aside from installing the driver and ensuring they are on, I have not set anything specific. Is it is simply a matter of setting them both on the same ssid and assigning valid IP addresses (the former was a step I forgot to try).

They won't self-assign an address automatically, and there are a few
NetworkManager bits necessary for automatic ad-hoc connections at
startup which is probably what people are looking for here.

That is what I would like to get documentation on. Ideally, of course, IPv6 will just auto configure itself, or at least a IPv4 can self-assign from 169.254.x.x.

What other steps need to be taken for NetworkManager to be able to take advantage of an ad hoc network?

--
Michael Burns
Oregon State University
_______________________________________________
Devel mailing list
Devel <at> laptop.org
http://mailman.laptop.org/mailman/listinfo/devel
Permalink | Reply | 0 comments |
headers
Richard Hughes | 1 Nov 2006 14:26
Picon

Re: [PATCH v2] Re: Battery class driver.

On Tue, 2006-10-31 at 16:06 +0200, Shem Multinymous wrote:
> 
> In the case at hand we have mWh and mAh, which measure different
> physical quantities. You can't convert between them unless you have
> intimate knowledge of the battery's chemistry and condition, which we
> don't.

I'm thinking specifically for ACPI at the moment.

When ACPI can't work out a value, i.e. it's not known, it returns a
value of 0xFFFFFFFF. This can happen either for a split second on
disconnect, or if the hardware really doesn't know the value.

With the battery class driver, how would that be conveyed? Would the
sysfs file be deleted in this case, or would the value of the sysfs key
be something like "<invalid>".

This is something I'm just thinking about for the HAL backend, and
whatever is decided should probably be documented.

Richard.
Permalink | Reply | 0 comments |
headers
David Woodhouse | 1 Nov 2006 14:54
Favicon

Re: [PATCH v2] Re: Battery class driver.

On Wed, 2006-11-01 at 13:26 +0000, Richard Hughes wrote:
> With the battery class driver, how would that be conveyed? Would the
> sysfs file be deleted in this case, or would the value of the sysfs
> key be something like "<invalid>". 

I'd be inclined to make the read return -EINVAL.

--

-- 
dwmw2
Permalink | Reply | 0 comments |
headers
Henrique de Moraes Holschuh | 1 Nov 2006 15:36
Picon
Favicon

Re: [PATCH v2] Re: Battery class driver.

On Wed, 01 Nov 2006, David Woodhouse wrote:
> On Wed, 2006-11-01 at 13:26 +0000, Richard Hughes wrote:
> > With the battery class driver, how would that be conveyed? Would the
> > sysfs file be deleted in this case, or would the value of the sysfs
> > key be something like "<invalid>". 
> 
> I'd be inclined to make the read return -EINVAL.

-EIO for transient errors (e.g. access to the embedded controller/battery
charger/whatever fails at that instant), -EINVAL for "not supported"
(missing ACPI method, attribute not supported in the specific hardware)?

--

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
Permalink | Reply | 0 comments |
headers
Jim Gettys | 1 Nov 2006 17:06
Favicon
Gravatar

Hardware/driver status

Here is some status for those not in the midst of the whirlwind.

BTest hardware/driver status:

DCON ASIC working: 
	required some special initialization 
	look up table is being used to compensate for a miswiring.
Keyboard/touchpad: working
CaFE FPGA:
	NAND Flash: working w. ECC.
	Camera: working
	SD: last few bugs being chased.
 	Remaining: testing of all three interfaces simultaneously
USB: Problems have been mostly identified and fixed.  One board sample
	doing something strange electrically undergoing failure
	analysis at AMD
Wireless: needs testing.
Audio: needs testing.
--

-- 
Jim Gettys
One Laptop Per Child
Permalink | Reply | 2 comments |
headers
Shem Multinymous | 1 Nov 2006 17:36
Picon

Re: [PATCH v2] Re: Battery class driver.

On 11/1/06, Henrique de Moraes Holschuh <hmh <at> hmh.eng.br> wrote:
> On Wed, 01 Nov 2006, David Woodhouse wrote:
> > On Wed, 2006-11-01 at 13:26 +0000, Richard Hughes wrote:
> > > With the battery class driver, how would that be conveyed? Would the
> > > sysfs file be deleted in this case, or would the value of the sysfs
> > > key be something like "<invalid>".
> >
> > I'd be inclined to make the read return -EINVAL.
>
> -EIO for transient errors (e.g. access to the embedded controller/battery
> charger/whatever fails at that instant), -EINVAL for "not supported"
> (missing ACPI method, attribute not supported in the specific hardware)?

Shouldn't it be -EIO or -EBUSY for transient errors (depending on
type), and -ENXIO when not provided by hardware?
The -EINVAL is more appropriate for bad user-supplied values (out of
range etc.) to writable attributes.

  Shem
Permalink | Reply | 0 comments |
headers
Jim Gettys | 1 Nov 2006 17:41
Favicon
Gravatar

Schedules.

Here's the current dates for people.
	Nov. 1 or 2	BIOS release; current testing release is 
			ready except for DCON
	Nov. 3		Proposals of for inclusion in BTest-1 due to
			Jim Gettys and Chris Blizzard, if you haven't
                        already been in touch
	Nov. 5		Drop dead date on new packages
			Anything not packaged and ready to go into 
			the build will not be accepted after this date.
			Bug fixes will be permitted after this date,
			but the closer to Nov. 10, the  more critical
			and less invasive they should be.
        Nov. 10		Image due at Quanta
--

-- 
Jim Gettys
One Laptop Per Child
Permalink | Reply | 0 comments |

Gmane