David,
There are a couple of issues i would like to address, mostly related to the
new wireless driver.
First, the netstat command:
About 50% of the time it becomes very slow(practically freezes) and spews a
"getnameinfo error".
The result from strace is:
---
.
socket(PF_INET, SOC
Yani,
On the msh0_rename interface:
http://dev.laptop.org/ticket/5746
-- RC
On Jan 15, 2008 10:29 PM, Giannis Galanis <[EMAIL PROTECTED]> wrote:
> David,
>
> There are a couple of issues i would like to address, mostly related to
> the new wireless driver.
>
> First, the netstat command:
> Abou
On Tue, 2008-01-15 at 19:29 -0500, Giannis Galanis wrote:
> David,
>
> There are a couple of issues i would like to address, mostly related
> to the new wireless driver.
>
> First, the netstat command:
> About 50% of the time it becomes very slow(practically freezes) and
> spews a "getnameinfo er
IMHO, there is no point in investing time in mesh stop/start now (or any
time in the future unless there is a strong reason for that - which we lack
now).
On Jan 16, 2008 1:48 PM, Dan Williams <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-01-15 at 19:29 -0500, Giannis Galanis wrote:
> > David,
> >
>
Dan Williams <[EMAIL PROTECTED]> wrote on 01/16/2008 10:48:13 AM:
> There's a long explanation for that, but the short one is that the
> driver should no longer periodically run around in circles screaming,
> then have an arterial hemorrhage, and collapse on the ground spurting
> blood from it's
On Wed, 2008-01-16 at 15:11 -0500, Michail Bletsas wrote:
> Dan Williams <[EMAIL PROTECTED]> wrote on 01/16/2008 10:48:13 AM:
>
>
> > There's a long explanation for that, but the short one is that the
> > driver should no longer periodically run around in circles screaming,
> > then have an arter
2008/1/16 Ricardo Carrano <[EMAIL PROTECTED]>:
> IMHO, there is no point in investing time in mesh stop/start now (or any
> time in the future unless there is a strong reason for that - which we lack
> now).
The stated reason for wanting this feature is to easily disable
wireless before getting on
I believe what you want is "radio off", not "mesh stop".
On Jan 16, 2008 8:01 PM, Edward Cherlin <[EMAIL PROTECTED]> wrote:
> 2008/1/16 Ricardo Carrano <[EMAIL PROTECTED]>:
> > IMHO, there is no point in investing time in mesh stop/start now (or any
> > time in the future unless there is a strong
On Wed, 2008-01-16 at 20:22 -0200, Ricardo Carrano wrote:
> I believe what you want is "radio off", not "mesh stop".
"radio off" == iwconfig eth0 txpower off
that's always been around from day #1.
> On Jan 16, 2008 8:01 PM, Edward Cherlin <[EMAIL PROTECTED]> wrote:
> 2008/1/16 Ricardo C
On Wed, 2008-01-16 at 14:01 -0800, Edward Cherlin wrote:
> 2008/1/16 Ricardo Carrano <[EMAIL PROTECTED]>:
> > IMHO, there is no point in investing time in mesh stop/start now (or any
> > time in the future unless there is a strong reason for that - which we lack
> > now).
>
> The stated reason for
On Jan 16, 2008 2:46 PM, Dan Williams <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-01-16 at 20:22 -0200, Ricardo Carrano wrote:
> > I believe what you want is "radio off", not "mesh stop".
>
> "radio off" == iwconfig eth0 txpower off
>
> that's always been around from day #1.
That turns off the rad
Is this related to Wodehousian? :)
- Jim
On Wed, 2008-01-16 at 15:15 -0500, Dan Williams wrote:
> On Wed, 2008-01-16 at 15:11 -0500, Michail Bletsas wrote:
> > Dan Williams <[EMAIL PROTECTED]> wrote on 01/16/2008 10:48:13 AM:
> >
> >
> > > There's a long explanation fo
> When it comes to our radio - we *designed it* to start forward frames
> soon after you initialize it and keep doing it regardless of what the
> host interface does.
In the context of making the radio safe to use on airplanes...
Does the firmware turn the radio on at boot time?
Does your "ini
Hal Murray <[EMAIL PROTECTED]> wrote on 01/17/2008 12:55:47 PM:
>
> > When it comes to our radio - we *designed it* to start forward frames
> > soon after you initialize it and keep doing it regardless of what the
> > host interface does.
>
> In the context of making the radio safe to use on ai
Hal Murray wrote:
>> When it comes to our radio - we *designed it* to start forward frames
>> soon after you initialize it and keep doing it regardless of what the
>> host interface does.
>>
>
> In the context of making the radio safe to use on airplanes...
>
> Does the firmware turn the radi
On Thu, 2008-01-17 at 17:06 -0200, Ricardo Carrano wrote:
> Indeed we had this airplane mode discussion two weeks ago:
> Why don't we?
> ---
This is the correct sledgehammer approach as mbletsas has consistently
pointed out.
For a more user-friendly solution, (short of a hardware rfkill s
I apologize if I am over simplifying:
- mesh stop was considered when we had compatibility issues with lazy-wds
routers. We addressed this, right? Do we still need this feature? Michail?
- For airplane mode or relatives, we need to shut up radio (any traffic).
On Jan 17, 2008 5:05 PM, Dan William
There is quite a bit of important history removed from this discussion.
We designed the laptop to be able to do mesh forwarding *all the time*.
This was a fundamental decision because it affected every other choice
that we made in the wireless subsystem.
One of the issues that it introduced is t
Indeed we had this airplane mode discussion two weeks ago:
Why don't we?
---
To completely silence the radio:
#!/bin/bash
rmmod usb8xxx
mv /lib/firmaware/usb8883.bin /lib/firmaware/usb8883.bin.quiet
It will survive reboots.
---
To bring it back:
#!/bin/bash
mv /lib/firmaware/u
On Thu, 2008-01-17 at 13:30 -0500, Michail Bletsas wrote:
> Hal Murray <[EMAIL PROTECTED]> wrote on 01/17/2008 12:55:47 PM:
>
> >
> > > When it comes to our radio - we *designed it* to start forward frames
> > > soon after you initialize it and keep doing it regardless of what the
> > > host inte
On Thu, 2008-01-17 at 12:32 -0500, Michail Bletsas wrote:
> There is quite a bit of important history removed from this discussion.
>
> We designed the laptop to be able to do mesh forwarding *all the time*.
> This was a fundamental decision because it affected every other choice
> that we made i
On Thu, 2008-01-17 at 09:51 -1000, Mitch Bradley wrote:
> I suppose that OFW could reset the wireless to turn it off and then do
> some chipset configuration hack that would make that USB port
> disappear. I'm just guessing though; I haven't studied the 5536 manual
> with this possibility in mi
For "airplane mode", is there some command OFW can run to make
the whole eth/msh device poweroff and disappear until the next
powercycle? If so, maybe we could hook another key check into
/boot/olpc.fth?
-Bennett
pgps5csES4LCD.pgp
Description: PGP signature
__
I suppose that OFW could reset the wireless to turn it off and then do
some chipset configuration hack that would make that USB port
disappear. I'm just guessing though; I haven't studied the 5536 manual
with this possibility in mind.
That seems like a fairly horrible way to solve a Linux prob
>> To completely silence the radio:
>> #!/bin/bash
>> rmmod usb8xxx
>> mv /lib/firmaware/usb8883.bin /lib/firmaware/usb8883.bin.quiet
> For a more user-friendly solution, (short of a hardware rfkill switch)
> put a toggle somewhere in the control panel for "Don't turn the radio on
> automatically"
On Thu, 2008-01-17 at 14:18 -0500, Mikus Grinbergs wrote:
> >> To completely silence the radio:
> >> #!/bin/bash
> >> rmmod usb8xxx
> >> mv /lib/firmaware/usb8883.bin /lib/firmaware/usb8883.bin.quiet
>
> > For a more user-friendly solution, (short of a hardware rfkill switch)
> > put a toggle some
On Thu, 2008-01-17 at 12:32 -0500, Michail Bletsas wrote:
> There is an "iwpriv eth0 radiooff/radioon" IOCTL hook in the firmware
> which was meant to control the radio power directly - it was removed a few
> months ago since it wasn't considered to its thing in the "proper" linux
> manner.
I
On Thu, 2008-01-17 at 19:16 -0500, Giannis Galanis wrote:
> It must be noted that the important issue of this discussion is how to have
> the radio blocked from BEFORE the XO boots, so as not to be conflicting with
> the airline regulations.
We should change the firmware so that it isn't active a
It is included in http://wiki.laptop.org/go/Wireless_Driver_README
and if it helps i believe it was removed around september i believe.
It was definitely an active ioctl.
It must be noted that the important issue of this discussion is how to have
the radio blocked from BEFORE the XO boots, so as
I see.
But i hope this is not done only because of the airline issue, and that
there are other reasons that it useful to boot with firmware unloaded.
Because as far as the airline issue is concerned, we should not take it tooo
seriously. As long as we have a working solution it is fine. Not many p
Let's not forget the dongles that act as dumb repeaters on their own,
based on their firmware. Are they gonna use a different firmware instead?
p.
David Woodhouse wrote:
> We should change the firmware so that it isn't active automatically as
> soon as it's loaded -- let the driver activate it w
David Woodhouse <[EMAIL PROTECTED]> wrote on 01/17/2008 06:26:38 PM:
>
> It uses CMD_802_11_RADIO_CONTROL with the RADIO_OFF argument, which I
> believe is the correct thing to do.
>
If that's the case then it does the right thing - no need to worry with
the earlier iwpriv call.
M.__
[EMAIL PROTECTED] wrote on 01/17/2008 02:17:44 PM:
> I apologize if I am over simplifying:
>
> - mesh stop was considered when we had compatibility issues with
> lazy-wds routers. We addressed this, right? Do we still need this
> feature? Michail?
The only reason to have this, is for debugging
On Fri, 2008-01-18 at 10:33 -0500, Michail Bletsas wrote:
> Dan Williams <[EMAIL PROTECTED]> wrote on 01/18/2008 10:08:09 AM:
>
> > On Fri, 2008-01-18 at 08:36 +0800, David Woodhouse wrote:
> > > On Thu, 2008-01-17 at 19:16 -0500, Giannis Galanis wrote:
> > > > It must be noted that the important
On Fri, 2008-01-18 at 10:08 -0500, Dan Williams wrote:
> Yes. The active antennas firmware would need to be slightly altered to
> start on firmware boot, but the normal XO firmware should certainly be
> radio-off-until-driver-enabled (by setting IFF_UP or device open).
Let us make a clear distin
Michail,
This would be 3107, right ?
3109 is when we started seeing the auto-update mode.
John
On Jan 18, 2008, at 4:22 PM, David Woodhouse wrote:
>
> On Fri, 2008-01-18 at 15:50 -0500, Michail Bletsas wrote:
>>> Ideally, we want to just kill the auto-mesh-repeater mode, where
>>> boot2
>
John Watlington <[EMAIL PROTECTED]> wrote on 01/18/2008 04:56:26 PM:
>
> Michail,
> This would be 3107, right ?
> 3109 is when we started seeing the auto-update mode.
>
Yes,
M.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org
On Fri, 2008-01-18 at 16:56 -0500, John Watlington wrote:
>
> Michail,
> This would be 3107, right ?
> 3109 is when we started seeing the auto-update mode.
OK, so can we go between 3109 and 3107 in both directions using
libertas-flash.py or did the protocol get changed without telling us?
W
On Fri, 2008-01-18 at 15:50 -0500, Michail Bletsas wrote:
> > Ideally, we want to just kill the auto-mesh-repeater mode, where boot2
> > times out after 5 seconds and loads the firmware from the internal flash
> > (which is obviously larger on these devices than on the XO). Can we
> > achieve that
David Woodhouse <[EMAIL PROTECTED]> wrote on 01/18/2008 03:31:08 PM:
>
> Ideally, we want to just kill the auto-mesh-repeater mode, where boot2
> times out after 5 seconds and loads the firmware from the internal flash
> (which is obviously larger on these devices than on the XO). Can we
> achie
On Fri, 2008-01-18 at 14:47 -0500, Dan Williams wrote:
> So wait, what's going on here? I thought the devices attached to school
> servers were just run-of-the-mill USB 8388 devices like the 8388
> daughterboard of the XO, but different connector, right?
>
> What is the post-boot firmware flash f
On Fri, 2008-01-18 at 14:47 -0500, Dan Williams wrote:
> What is the post-boot firmware flash functionality supposed to apply to,
> the host-less active antenna? (which is what I heretofore had
> understood).
As Ben says, they're the same thing. If you don't load the firmware
within 5 seconds of t
On Fri, 2008-01-18 at 08:36 +0800, David Woodhouse wrote:
> On Thu, 2008-01-17 at 19:16 -0500, Giannis Galanis wrote:
> > It must be noted that the important issue of this discussion is how to have
> > the radio blocked from BEFORE the XO boots, so as not to be conflicting with
> > the airline regu
Dan Williams <[EMAIL PROTECTED]> wrote on 01/18/2008 10:08:09 AM:
> On Fri, 2008-01-18 at 08:36 +0800, David Woodhouse wrote:
> > On Thu, 2008-01-17 at 19:16 -0500, Giannis Galanis wrote:
> > > It must be noted that the important issue of this discussion is
> how to have
> > > the radio blocked f
On Sat, 2008-01-19 at 01:38 +0800, David Woodhouse wrote:
> On Fri, 2008-01-18 at 10:08 -0500, Dan Williams wrote:
> > Yes. The active antennas firmware would need to be slightly altered to
> > start on firmware boot, but the normal XO firmware should certainly be
> > radio-off-until-driver-enable
On Sat, 2008-01-19 at 04:31 +0800, David Woodhouse wrote:
> On Fri, 2008-01-18 at 14:47 -0500, Dan Williams wrote:
> > What is the post-boot firmware flash functionality supposed to apply to,
> > the host-less active antenna? (which is what I heretofore had
> > understood).
>
> As Ben says, they'r
Dan Williams <[EMAIL PROTECTED]> wrote on 01/19/2008 12:48:06 PM:
>
> Hmm, ok... So all the external USB 8388 dongles have a larger SPI flash
> to contain both the Boot2 code and the 100K thick firmware?
>
yes,
M.___
Devel mailing list
Devel@lists.la
On Sat, 2008-01-19 at 13:05 -0500, Michail Bletsas wrote:
>
>
> Dan Williams <[EMAIL PROTECTED]> wrote on 01/19/2008 12:48:06 PM:
>
>
> >
> > Hmm, ok... So all the external USB 8388 dongles have a larger SPI
> flash
> > to contain both the Boot2 code and the 100K thick firmware?
> >
> yes,
>
> Does the Boot2 code take care of figuring out the correct address to
> write the thick firmware to, or does the flash tool have to figure out
> the address to write it to? Normally this address is embedded in the
> firmware flash file header, is there an address the tool should check
> for to
Woodhouse; Giannis Galanis;
[EMAIL PROTECTED]
Subject: Re: Testing the Wireless driver changes
>
> Does the Boot2 code take care of figuring out the correct address to
> write the thick firmware to, or does the flash tool have to figure out
> the address to write it to? Normally
Dan,
Do we have a description of the dbus API for the XO NM implementation
somewhere?
[Like the one in:
http://people.redhat.com/dcbw/NetworkManager/NetworkManager%20DBUS%20API.txt
]
Thank you!
Carrano
On Jan 17, 2008 6:24 PM, Dan Williams <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-01-17 at 14
51 matches
Mail list logo
