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
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 this address
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're the
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
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
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 issue of
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
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
times
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
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?
We
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 just
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
achieve
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
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 the
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
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 from BEFORE
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-enabled (by
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
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 airplanes...
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 radio on at
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
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
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
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 mind.
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
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 that is
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 somewhere in the
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 looked
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
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
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.
[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
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:
About 50% of
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 error.
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,
There
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 ears.
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 arterial
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 an
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 Carrano
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 wanting
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 radio for this
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 for that, but
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,
43 matches
Mail list logo
