Re: [PATCH] Add libertas_disablemesh module parameter to disable mesh interface
On Fri, 2011-05-13 at 15:16 +0200, Sascha Silbe wrote: Excerpts from Dan Williams's message of Thu May 12 05:11:36 +0200 2011: On Wed, 2011-05-11 at 14:52 +0200, Sascha Silbe wrote: This allows individual users and deployments to disable mesh support at runtime, i.e. without having to build and maintain a custom kernel. Does the mesh interface somehow cause problems, even when nothing is using it? Some people suspect it does, but there's no hard data showing that. But then the problems are often hard to reproduce in the first place, so proving a correlation with mesh is even harder. That's not an excuse for not finding and fixing the problem though. What problems are we actually talking about here? The hardware based mesh support is based on an outdated draft of 802.11s and not interoperable with any other device AFAIK. For most users Ad-hoc networks are the better option. Disabling mesh support as low-level as possible makes it less likely that any remains are causing trouble. With at least four layers (firmware, kernel, NM, Sugar) involved in managing connectivity and one of the (firmware) being closed source, I prefer to simplify things by eliminating three layers for functionality we don't intend to use. It makes debugging (and blaming ;) ) a lot easier. In the field, mesh support is currently disabled using /sys/class/net/eth0/lbs_mesh. However, it comes back after resume (possibly only if powercycled) and needs to be disabled again by post-resume hacks. Race conditions with NM are possible. That's a parameter handled by the driver; so shouldn't we make sure it's respected again on resume? A user space option would be to teach NM to disable mesh support (at runtime - we don't want to ship a custom NM package). I'd expect the patch to be much more invasive than the one posted for libertas. Not really, but we already have on/off for a bunch of other stuff, I don't see why we can't add one for OLPC mesh. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Add libertas_disablemesh module parameter to disable mesh interface
On Wed, 2011-05-11 at 14:52 +0200, Sascha Silbe wrote: This allows individual users and deployments to disable mesh support at runtime, i.e. without having to build and maintain a custom kernel. Does the mesh interface somehow cause problems, even when nothing is using it? I'd expect that if the mesh interface was simply left alone, there would be no need to disable it. Dan Based on a patch by Paul Fox p...@laptop.org. Signed-off-by: Sascha Silbe si...@activitycentral.com --- drivers/net/wireless/libertas/main.c |9 - 1 files changed, 8 insertions(+), 1 deletions(-) The patch is based on the OLPC 2.6.35 kernel tree, but applies cleanly to wireless-next. diff --git a/drivers/net/wireless/libertas/main.c b/drivers/net/wireless/libertas/main.c index 8445473..62069e2 100644 --- a/drivers/net/wireless/libertas/main.c +++ b/drivers/net/wireless/libertas/main.c @@ -41,6 +41,10 @@ unsigned int lbs_debug; EXPORT_SYMBOL_GPL(lbs_debug); module_param_named(libertas_debug, lbs_debug, int, 0644); +unsigned int lbs_disablemesh; +EXPORT_SYMBOL_GPL(lbs_disablemesh); +module_param_named(libertas_disablemesh, lbs_disablemesh, int, 0644); + /* This global structure is used to send the confirm_sleep command as * fast as possible down to the firmware. */ @@ -1086,7 +1090,10 @@ int lbs_start_card(struct lbs_private *priv) lbs_update_channel(priv); - lbs_init_mesh(priv); + if (!lbs_disablemesh) + lbs_init_mesh(priv); + else + lbs_pr_info(%s: mesh disabled\n, dev-name); /* * While rtap isn't related to mesh, only mesh-enabled -- 1.7.4.1 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: NetworkManager time sync
On Mon, 2010-07-05 at 08:41 -0300, Esteban Bordon wrote: You have to put a script calling ntpdate in /etc/NetworkManager/dispatcher.d/ You can also get the NTP server that may be passed down from DHCP in the environment of the script on 'up' events. See 'man NetworkManager'. That's of course useless if you can't trust DHCP, but might be helpful. Dan regards, Esteban. 2010/7/3 Bernie Innocenti ber...@codewiz.org Dan, we don't have any way to synchronize the clock on the XO... I'd rather avoid running ntp all the time as it wastes 2MB of RSS. Does NetworkManager provide a service to automatically call ntpdate when the interface goes up? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Fix ethtool reporting no WOL options supported if WOL is not already active
On Sun, 2010-05-23 at 10:03 +0200, Sascha Silbe wrote:
This patch fixes the libertas driver incorrectly reporting that Wake-on-LAN
is not supported if Wake-on-LAN is currently disabled.
Looks good to me; could you repost to linux-wirel...@vger so I can ack
it and Linville will pick it up?
Dan
---
drivers/net/wireless/libertas/ethtool.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
Without patch:
r...@xo15-minimal:~# ethtool wlan0
Settings for wlan0:
Supports Wake-on: d
Wake-on: d
r...@xo15-minimal:~# ethtool -s wlan0 wol pum
r...@xo15-minimal:~# ethtool wlan0
Settings for wlan0:
Supports Wake-on: pumb
Wake-on: pum
r...@xo15-minimal:~# ethtool -s wlan0 wol d
r...@xo15-minimal:~# ethtool wlan0
Settings for wlan0:
Supports Wake-on: d
Wake-on: d
r...@xo15-minimal:~#
With patch:
xo-sascha:~# ethtool eth0
Settings for eth0:
Supports Wake-on: pumb
Wake-on: d
xo-sascha:~# ethtool -s eth0 wol pum
xo-sascha:~# ethtool eth0
Settings for eth0:
Supports Wake-on: pumb
Wake-on: pum
xo-sascha:~# ethtool -s eth0 wol d
xo-sascha:~# ethtool eth0
Settings for eth0:
Supports Wake-on: pumb
Wake-on: d
diff --git a/drivers/net/wireless/libertas/ethtool.c
b/drivers/net/wireless/libertas/ethtool.c
index 6eb9a88..4a337b7 100644
--- a/drivers/net/wireless/libertas/ethtool.c
+++ b/drivers/net/wireless/libertas/ethtool.c
@@ -145,14 +145,11 @@ static void lbs_ethtool_get_wol(struct net_device *dev,
{
struct lbs_private *priv = dev-ml_priv;
- if (priv-wol_criteria == 0x) {
- /* Interface driver didn't configure wake */
- wol-supported = wol-wolopts = 0;
- return;
- }
-
wol-supported = WAKE_UCAST|WAKE_MCAST|WAKE_BCAST|WAKE_PHY;
+ if (priv-wol_criteria == EHS_REMOVE_WAKEUP)
+ return;
+
if (priv-wol_criteria EHS_WAKE_ON_UNICAST_DATA)
wol-wolopts |= WAKE_UCAST;
if (priv-wol_criteria EHS_WAKE_ON_MULTICAST_DATA)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [OLPC/Paraguay] Debugging NetworkManager-0.7.2.995 + Power Management
On Mon, 2010-04-05 at 17:34 -0300, mabente wrote: Very sorry for the late response, here is the messages log and gdb backtrace log! Hopefully it will be helpful :) Yes, quite. Please try: https://admin.fedoraproject.org/updates/NetworkManager-0.7.2.996-1.fc11,NetworkManager-vpnc-0.7.2.996-1.fc11,NetworkManager-openconnect-0.7.2.996-1.fc11,NetworkManager-pptp-0.7.2.996-1.fc11,NetworkManager-openvpn-0.7.2.996-1.fc11 and let me know if that fixes the problem. The upstream fix for the issue is: 0.7.x: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=NETWORKMANAGER_0_7id=e44e908747edc8eb61506bb29e7ac24292f7565c 0.8.x: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=a7e3d2acc29d3e7c267298df9a19a514ca628b37 Thanks! Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC/Paraguay] Debugging NetworkManager-0.7.2.995 + Power Management
On Tue, 2010-03-30 at 14:07 -0300, Bernie Innocenti wrote: On Tue, 2010-03-30 at 09:16 -0700, Dan Williams wrote: Yeah, I haven't been able to reproduce that, but I only have an XO1.5 with me (which doesn't have mesh), and I think the issue is timing related. So it's good that you can reproduce it. That gives us a chance to fix it. We could definitely reproduce the issue also on the XO-1.5, using os115 from OLPC: But... the 1.5 doesn't have the mesh capability (unless you're using a dongle?) and thus wouldn't hit the codepath specified, no? Unless there's some really, really egregious bug in the original mesh code in NM that calls into the mesh device without any mesh device having ever been created, that is... http://build.laptop.org/10.2.0/os115 Just leave the automatic power management on and let the system go to sleep a few times. Sugar or GNOME? At least if you can reproduce with a 1.5 then I have chance of seeing it in action too. Dan So what is going on is that the mesh device and the wifi device are obviously the same device, because they really share the same silicon. So we need to make sure the mesh device knows about it's companion wifi device. Can I get some /var/log/messages logging from NetworkManager over a suspend/resume cycle? I'd like to see if the kernel removes either the wifi or the mesh device and then adds it back after resume, or whether the device sticks around throughout the entire cycle. From what I've seen in gdb after the segfault, it looked very much like the is_companinion() callback had being invoked an object that has been already freed. The GObject class was zeroed out. I'll wait for Martin (tch) to come back from lunch to send you the full log. This segfault indicates one of two things: 1) a reference counting issue; there's a missing g_object_ref() somewhere, which means that the Mesh object is getting unreffed one too many times, leading to its destruction 2) the kernel is removing the underlying device and there's a missing idle, timeout, or signal clear command. The mesh device listens for a number of signals of other objects, but when the mesh object gets destroyed, we need to remember to stop listening for those signals or we'll end up in the signal handler after the object is destroyed (use-after-free). We looked for paths where the signal is being attached and removed, and it *looked* like removal was being done correctly on disposal. Tch added some debug output to track the life-cycle of objects. Can I also get a backtrace of the crash? Bernie's backtrace didn't have debugging info, which your clearly have. Tch will follow up with the complete backtrace, he has a debugging environment where NM was built from sources. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: NetworkManager from fedora-updates-testing broken on F11-XO1
On Thu, 2010-02-25 at 21:38 -0300, Bernie Innocenti wrote:
On Thu, 2010-02-25 at 14:11 -0300, Bernie Innocenti wrote:
Feb 25 17:01:30 xo-37-38-0f NetworkManager: *** START
**
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 0:
NetworkManager(nm_logging_backtrace+0x45) [0x8078da5]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 1: NetworkManager
[0x8072f4d]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 2: [0xb77c6400]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 3: NetworkManager
[0x8067a5b]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 4:
/lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__OBJECT+0x88) [0x93f338]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 5:
/lib/libgobject-2.0.so.0(g_closure_invoke+0x1b2) [0x932352]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 6:
/lib/libgobject-2.0.so.0 [0x947cf0]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 7:
/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7bd) [0x94905d]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 8:
/lib/libgobject-2.0.so.0(g_signal_emit+0x26) [0x9494e6]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 9:
NetworkManager(_nm_marshal_VOID__STRING_STRING_POINTER_POINTER+0x9d)
[0x808ab1d]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 10:
/lib/libgobject-2.0.so.0(g_closure_invoke+0x1b2) [0x932352]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 11:
/lib/libgobject-2.0.so.0 [0x947cf0]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 12:
/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7bd) [0x94905d]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 13:
/lib/libgobject-2.0.so.0(g_signal_emit+0x26) [0x9494e6]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 14: NetworkManager
[0x806df19]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 15: /usr/lib/libhal.so.1
[0x71bc3e3]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 16:
/lib/libdbus-1.so.3(dbus_connection_dispatch+0x36d) [0x703287d]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 17:
/usr/lib/libdbus-glib-1.so.2 [0x71ca19d]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 18:
/lib/libglib-2.0.so.0(g_main_context_dispatch+0x1f8) [0x852308]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 19: /lib/libglib-2.0.so.0
[0x8559e0]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 20:
/lib/libglib-2.0.so.0(g_main_loop_run+0x1bf) [0x855e4f]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 21:
NetworkManager(main+0xe37) [0x8073d97]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 22:
/lib/libc.so.6(__libc_start_main+0xe6) [0x673a86]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: Frame 23: NetworkManager
[0x80570d1]
Feb 25 17:01:30 xo-37-38-0f NetworkManager: *** END
**
Feb 25 17:02:14 xo-37-38-0f kernel: [ 3523.422953] psmouse serio1: detected
37px jump in x
Ok, I traced it down to ./src/nm-device-olpc-mesh.c:is_companion(), at
the memcmp() line.
their_addr is on the stack, so the invalid pointer must be priv. I can't
debub further without rebuilding the rpm with -g. Any idea what might
have gone wrong here?
static gboolean
is_companion (NMDeviceOlpcMesh *self, NMDevice *other)
{
NMDeviceOlpcMeshPrivate *priv = NM_DEVICE_OLPC_MESH_GET_PRIVATE
(self);
struct ether_addr their_addr;
if (!NM_IS_DEVICE_WIFI (other))
return FALSE;
nm_device_wifi_get_address (NM_DEVICE_WIFI (other), their_addr);
if (memcmp (priv-hw_addr.ether_addr_octet,
their_addr.ether_addr_octet, ETH_ALEN) != 0) {
return FALSE;
}
Hmm, doesn't ring a bell immediately. I pushed a fix for the driver
thing and am doing another NM build for F11. I'll try to take a look at
this after the new build goes through.
Dan
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: NetworkManager from fedora-updates-testing broken on F11-XO1
On Wed, 2010-02-17 at 22:44 -0300, Bernie Innocenti wrote:
On Wed, 2010-02-17 at 11:08 -0800, Dan Williams wrote:
On Wed, 2010-02-17 at 10:20 -0300, Bernie Innocenti wrote:
On Mon, 2010-02-15 at 16:15 -0800, Dan Williams wrote:
Not a known issue; but I'll try to reproduce on mine. Unless Daniel
gets there first of course.
I retrieved the log:
I was able to reproduce the issue as well. The problem is that the
libertas driver isn't correctly showing the 'driver' link in sysfs, it's
showing it as 'usb' which is wrong... we may just work around that in
NM, but Id like to figure out why libertas is screwing this up on
F11/F12 first.
Thanks for analyzing this.
As soon as you have a patch, I'd like to test it in my local olpc-2.6
kernel builds.
It'll probably take more investigation than I have time for this week,
so I'll just patch NM to accept the invalid driver name ('usb') as a
fallback. Which is the behavior that 0.7.2 had anyway, so you can
consider it a regression in 0.7.2.995. We'll eventually fix libertas
but I don't think we should block this on a libertas fix.
Dan
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: NetworkManager from fedora-updates-testing broken on F11-XO1
On Wed, 2010-02-17 at 10:20 -0300, Bernie Innocenti wrote: On Mon, 2010-02-15 at 16:15 -0800, Dan Williams wrote: Not a known issue; but I'll try to reproduce on mine. Unless Daniel gets there first of course. I retrieved the log: I was able to reproduce the issue as well. The problem is that the libertas driver isn't correctly showing the 'driver' link in sysfs, it's showing it as 'usb' which is wrong... we may just work around that in NM, but Id like to figure out why libertas is screwing this up on F11/F12 first. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: NetworkManager from fedora-updates-testing broken on F11-XO1
On Mon, 2010-02-15 at 20:17 -0300, Bernie Innocenti wrote: We didn't collect the logs in the field, but in /var/log/messages we found an assertion failure from NM which was more or less like driver ! = NULL, just after logging something about the OLPC mesh device. Wireless wasn't working at all afterwards. The broken package is NetworkManager-0.7.2.995-1.git20100202.fc11 . Reverting to a previous version cured the issue for us. Let me know if this is a known problem or if you need more help tracking it down. It can be reproduced systematically on F11-XO1. Not a known issue; but I'll try to reproduce on mine. Unless Daniel gets there first of course. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] ESSIDs and BSSIDs, NM and Sugar
On Fri, 2009-08-07 at 16:23 +0200, Tomeu Vizoso wrote: On Fri, Aug 7, 2009 at 16:19, Martin Langhoffmartin.langh...@gmail.com wrote: Following the let's make Sugar more deployable theme that Daniel started a while ago, I am looking at something that Reuben mentioned last week he discovered in the field. Apparently, the Sugar + NM combination we ship (on XO OS 802) cannot do the BSSID migration that you would expect. In other words, if you have a school with more than 1 AP, you should normally set all the APs to the same ESSID, set them on different channels, work on the tx power if there are more than 1 per channel, etc. With such a setup, clients will dynamically assess which BSSID has better signal / noise and associate to that one. But we seem to fail at this. With our current stack we will always reassociate to the first BSSID we associated for that ESSID. See below for a bit of sleuthing... 2009/8/6 Daniel Drake d...@laptop.org: 2009/8/7 Martin Langhoff mar...@laptop.org: Apparently, NM saves the BSSID (or the channel?) in its state file in .sugar (networks.conf?). So once you associate to network 'foo' one one BSSID, it will only ever reconned to that BSSID. No, this is Sugar that manages this file. So if there is any bug here, it's a sugar bug. Just checked - ~/,sugar/default/nm/networks.cfg has a 'bssids' line for each ESSID. I don't have a chance to test here now (lack of gear time here in Lima) but this will be interesting to track down. ~~~ Maybe there is something wrong in how we save multiple BSSIDs? Or maybe we shouldn't save the BSSID, and stick to just ESSIDs? Dan, do you know anything about this? NM is not normally involved in BSSID - BSSID roaming; that is purely the responsibility of the supplicant and driver. I'm pretty sure you guys are locking the BSSID in the NMConnection details you're sending, which means NM is only sending the ESSID to the supplicant. The supplicant then performs a scan, and if there is a compatible AP with the given ESSID, will associate to it. If the driver looses association to that AP, the supplicant will either perform an additional scan, or use the cached scan list to find a better AP with the same ESSID. If it finds another AP with the configured ESSID, it will attempt to associate to that AP. The driver/firmware are also allowed to roam between BSSIDs of the same ESSID, but I don't think the current libertas firmware actually does that. Thus, it's all up to the supplicant. Set up debugging options on wpa_supplicant (-dddt) in the dbus-activation file in /usr/share/dbus-1/system-services/ and try to reproduce the problem. That should show pretty clearly what's going on. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Setting up the mesh device
On Tue, 2008-06-24 at 18:09 -0400, Polychronis Ypodimatopoulos wrote: Sjoerd Simons wrote: I'm setting the ESSID on the msh0 interface indeed. But i never get an association event on it.. While i even get an association event on eth0 when it's not up (but with msh0 being up obviously) :) Seems i've got some more bugs to file Why would you set an ESSID on the mshX interface in the first place? I understand that, from a solid layering perspective, you should be able to set essids on mshX since it's treated as a wireless interface, but it would logically separate network users. It's hard enough as it is to discover nodes in different channels (although different channels do have a radio scaling advantage). You need a way to tell the firmware that you'd like to apply the configuration. And once you tell the firmware that, the firmware somehow needs to notify you that it's completed the requested operations. There is a small but noticeable amount of time between when you send the request, and when the firmware has completed the channel change and set up the state. If you don't wait for the notification, you'll assume you can send traffic when you actually cannot, and things like mDNS announcements and such will be lost. With WEXT, setting either the SSID or the BSSID are those triggers, and the SIOCGIWAP event is the notification. Unfortunately, because WEXT doesn't have a direct link between requests and replies, we have to enforce stricter semantics on behavior. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Setting up the mesh device
On Wed, 2008-06-25 at 02:34 +0100, Sjoerd Simons wrote: On Tue, Jun 24, 2008 at 06:09:58PM -0400, Polychronis Ypodimatopoulos wrote: Sjoerd Simons wrote: I'm setting the ESSID on the msh0 interface indeed. But i never get an association event on it.. While i even get an association event on eth0 when it's not up (but with msh0 being up obviously) :) Seems i've got some more bugs to file Why would you set an ESSID on the mshX interface in the first place? I understand that, from a solid layering perspective, you should be able to set essids on mshX since it's treated as a wireless interface, but it would logically separate network users. It's hard enough as it is to discover nodes in different channels (although different channels do have a radio scaling advantage). Because we can? Seriously it's not for NetworkManager to decide this kind of policy, some higher layer needs to tell it what to do. If that's the same essid for all machine that's fine (most likely the update sugar NM bits will just have one essid hardcoded). The current wireless firmware might not even actually bother with checking essid's on traffic all. The firmware's mesh functionality doesn't care what the SSID is. The only thing that distinguishes one mesh from another is the tuple of (channel, encryption). I don't even think BSSID matters (which it does in ad-hoc and infrastructure networks). Thus, the only policy that upper layers can or need to apply is the channel and encryption that the connection might use; hence why we eventually exposed the separate channels in Sugar. Dan The more important part, like Dan explained, is that this is the way to tell wireless drivers in linux to go and configure what's needed and tell us when they're ready for actual traffic (by means of an association event). So we can start doing things like dhcp and/or autoip. Sjoerd ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Setting up the mesh device
On Tue, 2008-06-24 at 19:42 +0100, Sjoerd Simons wrote: Hi, I'm currently working on adding support for the olpc mesh device to NM 0.7. I feel sorry for you :) In some ways 0.7 has made it a lot better for you (concurrent device support) and in other ways it's made it a bit harder (more encapsulation of devices due to a well-thought-out object model). From what i understand from David Woodhouse we should be able to really use it as two seperated devices these days (with the obvious constraint that it shares the radio ofcourse). Some testing shows that i can indeed use the mesh while the eth0 is completely unconfigured. Now when configuring the msh0 device NM 0.6 does the following: 0. Set eth0 in ad-hoc mode 1. Set eth0's essid to olpc-mesh 2. Wait for an association event on eth0 3. Continue with ip configuration. It was done on eth0 because at the time it was implemented, common attributes were defined to be set on ethX and were removed from mshX entirely. Due to discussions late last year, they got added back to the mshX interfaces, but there was no functional break and thus no need to update NM. You can now set the parameters directly on the mshX device. Which makes me wonder about the following things: * Why is the eth0 device set in ad-hoc mode? See above. Should need this any more, the mesh device should be set adhoc now instead. * In what way is the olpc-mesh essid special for eth0? It's not, but setting an SSID is the way in WEXT that you say do this all for me. So the card will technically not be set up how you want it until you set the SSID. You can simply set the SSID on the mesh interface now and not on the eth interface. * What's the actual meaning of the association event on eth0 for the msh0 and why should we wait on it. And if it's important, why is this event on eth0 instead of msh0 ? You need to wait for the association event before going ahead with any additional configuration, because that's the signal that the firmware has joined the right IBSS and that it's set up to send and receive traffic. I don't know offhand if the firmware sends the association event on the mesh interface these days; it used to, and it should, if the SIOCSIWESSID command is done on the mesh interface. If it doesn't do this, then the driver should be changed to fix that and ensure that commands sent to the mesh interface return events there and not on ethX. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 10:37 -0400, Michail Bletsas wrote: [EMAIL PROTECTED] wrote on 06/03/2008 10:12:31 AM: On Mon, 2008-06-02 at 17:12 -0700, Brian Cavagnolo wrote: To update boot2, copy the boot2 and firmware images to /lib/firmware and: echo boot2_image_name /sys/class/net/eth2/lbs_boot2 echo firmware_image_name /sys/class/net/eth2/lbs_fw So why are we doing this with the driver, and not the userspace update tool? Marvell keeps wanting to do firmware update in the driver, and we (David and I at least) keep saying no. If there are issues that prevent the userspace firmware update tool from working, then we need to fix those issues. Firmware updates from the driver were a disaster the first time around, and I don't quite see how that may have changed this time? If you really want, the userspace tool can be rewritten in C. It is not a matter of Python vs C. The userspace tool is extremely awkward to use (since it requires the driver modules to be unloaded which in turn makes the identification of How does it make the ID more difficult? What do we need besides the bcdDevice ID that tells us what boot2 version the device has? Is there something more needed to find out if the device has larger EEPROM for active antenna support perhaps? devices on the XO even more difficult) and it bricks wireless modules while the driver method doesn't. So the statement that firmware updates from the driver were a disaster is simply not true. It bricks the modules because the only people with the access to the docs and firmware (Marvell) didn't try to debug the issue, or correct the tool. There's only so much _I_ can do without access to the firmware source itself if other people who have the info aren't really jumping on these problems, when I don't have the info. This is low level hardware functionality that needs to be implemented in a fail-safe manner. Out testing has showed that the driver/firmware method (the driver just controls the memory updating code on the firmware) is more robust than the userspace tool. The original issue was that the driver needed to be told how to flash using module parameters, which is just a non-starter. A dynamic, sysfs-based interface is quite a lot better; I'm willing to keep discussing that solution. But some questions: 1) is the interface extendable to flashing firmware on CF SDIO 8385 and SD 8686 too? 2) does the patch handle resets and everything correctly, ie can I flash the firmware and then immediately start using the device? Can I also stop using the device and flash the firmware on-demand without unloading the driver? Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 11:18 -0400, John Watlington wrote: On Jun 3, 2008, at 11:08 AM, David Woodhouse wrote: On Tue, 2008-06-03 at 11:03 -0400, John Watlington wrote: My bad. This is now Trac #7170 http://dev.laptop.org/ticket/7170 All of the information in this ticket comes from email exchanged with dcbw and dwmw2 when I first discovered it. Didn't we fix that months ago by increasing the time we wait for flashing? Is this really what Ricardo was talking about? I think you are referring to same increased time that Dan mentions in his comment ?I don't remember any discussion after that email exchange (on Feb. 1, 2008). But then again, my memory is going... He needs to be careful he doesn't get the same kind of reputation as Michail already has. We have enough people whose words need to be taken with a _large_ pinch of salt around here already. Let's keep the discussion professional, please. I was under the impression that there was one big difference between the method used in the driver and the userspace method. One uses the host processor to do the programming, and the other uses the ARM on the module. Nope. There is no difference. They both should send _exactly_ the same USB byte stream to the usb8388. If they do not, there is a bug. Unfortunately nobody at Marvell who actually _has_ documentation on how to flash for the active antenna and later boot2 firmware changes (if any) volunteered that information or tried to fix the tool, to my knowledge. I didn't have active antenna hardware myself, and therefore I can't risk bricking the _only_ usb8388 I have with random firmware that wasn't intended for my part. I'm happy to test this out and try to get the userspace tool working again if given: 1) one or more active antenna modules to potentially brick 2) documentation on what exactly has changed (if anything) between boot2 3107 and the active antenna boot2 firmware dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Mon, 2008-06-02 at 17:12 -0700, Brian Cavagnolo wrote:
To update boot2, copy the boot2 and firmware images to /lib/firmware and:
echo boot2_image_name /sys/class/net/eth2/lbs_boot2
echo firmware_image_name /sys/class/net/eth2/lbs_fw
So why are we doing this with the driver, and not the userspace update
tool? Marvell keeps wanting to do firmware update in the driver, and we
(David and I at least) keep saying no. If there are issues that prevent
the userspace firmware update tool from working, then we need to fix
those issues. Firmware updates from the driver were a disaster the
first time around, and I don't quite see how that may have changed this
time?
If you really want, the userspace tool can be rewritten in C.
Dan
Signed-off-by: Brian Cavagnolo [EMAIL PROTECTED]
---
drivers/net/wireless/libertas/if_usb.c | 65
1 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/libertas/if_usb.c
b/drivers/net/wireless/libertas/if_usb.c
index 91413a6..6a32f37 100644
--- a/drivers/net/wireless/libertas/if_usb.c
+++ b/drivers/net/wireless/libertas/if_usb.c
@@ -46,6 +46,62 @@ static void if_usb_free(struct if_usb_card *cardp);
static int if_usb_submit_rx_urb(struct if_usb_card *cardp);
static int if_usb_reset_device(struct if_usb_card *cardp);
+/* sysfs hooks */
+
+/**
+ * Set function to write firmware to device's persistent memory
+ */
+static ssize_t if_usb_firmware_set(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct lbs_private *priv = to_net_dev(dev)-priv;
+ struct if_usb_card *cardp = priv-card;
+ char fwname[FIRMWARE_NAME_MAX];
+ int ret;
+
+ sscanf(buf, %29s, fwname); /* FIRMWARE_NAME_MAX - 1 = 29 */
+ ret = if_usb_prog_firmware(cardp, fwname, BOOT_CMD_UPDATE_FW);
+ if (ret == 0)
+ return count;
+
+ return ret;
+}
+
+/**
+ * lbs_fw attribute to be exported per ethX interface through sysfs
+ * (/sys/class/net/ethX/lbs_fw). Use this like so to write firmware to the
+ * device's persistent memory:
+ * echo usb8388-5.126.0.p5.bin /sys/class/net/ethX/lbs_fw
+ */
+static DEVICE_ATTR(lbs_fw, 0200, NULL, if_usb_firmware_set);
+
+/**
+ * Set function to write firmware to device's persistent memory
+ */
+static ssize_t if_usb_boot2_set(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct lbs_private *priv = to_net_dev(dev)-priv;
+ struct if_usb_card *cardp = priv-card;
+ char fwname[FIRMWARE_NAME_MAX];
+ int ret;
+
+ sscanf(buf, %29s, fwname); /* FIRMWARE_NAME_MAX - 1 = 29 */
+ ret = if_usb_prog_firmware(cardp, fwname, BOOT_CMD_UPDATE_BOOT2);
+ if (ret == 0)
+ return count;
+
+ return ret;
+}
+
+/**
+ * lbs_boot2 attribute to be exported per ethX interface through sysfs
+ * (/sys/class/net/ethX/lbs_boot2). Use this like so to write firmware to
the
+ * device's persistent memory:
+ * echo usb8388-5.126.0.p5.bin /sys/class/net/ethX/lbs_boot2
+ */
+static DEVICE_ATTR(lbs_boot2, 0200, NULL, if_usb_boot2_set);
+
/**
* @brief call back function to handle the status of the URB
* @param urb pointer to urb structure
@@ -246,6 +302,12 @@ static int if_usb_probe(struct usb_interface *intf,
usb_get_dev(udev);
usb_set_intfdata(intf, cardp);
+ if (device_create_file(priv-dev-dev, dev_attr_lbs_fw))
+ lbs_pr_err(cannot register lbs_fw attribute\n);
+
+ if (device_create_file(priv-dev-dev, dev_attr_lbs_boot2))
+ lbs_pr_err(cannot register lbs_boot2 attribute\n);
+
return 0;
err_start_card:
@@ -271,6 +333,9 @@ static void if_usb_disconnect(struct usb_interface *intf)
lbs_deb_enter(LBS_DEB_MAIN);
+ device_remove_file(priv-dev-dev, dev_attr_lbs_boot2);
+ device_remove_file(priv-dev-dev, dev_attr_lbs_fw);
+
cardp-surprise_removed = 1;
if (priv) {
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 11:34 -0300, Ricardo Carrano wrote: On Tue, Jun 3, 2008 at 11:12 AM, Dan Williams [EMAIL PROTECTED] wrote: On Mon, 2008-06-02 at 17:12 -0700, Brian Cavagnolo wrote: To update boot2, copy the boot2 and firmware images to /lib/firmware and: echo boot2_image_name /sys/class/net/eth2/lbs_boot2 echo firmware_image_name /sys/class/net/eth2/lbs_fw So why are we doing this with the driver, and not the userspace update tool? Marvell keeps wanting to do firmware update in the driver, and we (David and I at least) keep saying no. If there are issues that prevent the userspace firmware update tool from working, then we need to fix those issues. Firmware updates from the driver were a disaster the first time around, and I don't quite see how that may have changed this time? A necessary rectification: Firmware updates from the driver are the only method that works currently. If we want to name one method a disaster, we would have to choose the userspace tool, since it will brick many of your active antennae. It worked up until boot2 3109; and then apparently nobody at OLPC cared enough to fix the tool after that, and nobody at Marvell cared enough to tell anyone what changed so that somebody _could_ fix the tool. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 11:26 -0400, Dan Williams wrote: On Tue, 2008-06-03 at 10:37 -0400, Michail Bletsas wrote: [EMAIL PROTECTED] wrote on 06/03/2008 10:12:31 AM: On Mon, 2008-06-02 at 17:12 -0700, Brian Cavagnolo wrote: To update boot2, copy the boot2 and firmware images to /lib/firmware and: echo boot2_image_name /sys/class/net/eth2/lbs_boot2 echo firmware_image_name /sys/class/net/eth2/lbs_fw So why are we doing this with the driver, and not the userspace update tool? Marvell keeps wanting to do firmware update in the driver, and we (David and I at least) keep saying no. If there are issues that prevent the userspace firmware update tool from working, then we need to fix those issues. Firmware updates from the driver were a disaster the first time around, and I don't quite see how that may have changed this time? If you really want, the userspace tool can be rewritten in C. It is not a matter of Python vs C. The userspace tool is extremely awkward to use (since it requires the driver modules to be unloaded which in turn makes the identification of How does it make the ID more difficult? What do we need besides the bcdDevice ID that tells us what boot2 version the device has? Is there something more needed to find out if the device has larger EEPROM for active antenna support perhaps? devices on the XO even more difficult) and it bricks wireless modules while the driver method doesn't. So the statement that firmware updates from the driver were a disaster is simply not true. It bricks the modules because the only people with the access to the docs and firmware (Marvell) didn't try to debug the issue, or correct the tool. There's only so much _I_ can do without access to the firmware source itself if other people who have the info aren't really jumping on these problems, when I don't have the info. This is low level hardware functionality that needs to be implemented in a fail-safe manner. Out testing has showed that the driver/firmware method (the driver just controls the memory updating code on the firmware) is more robust than the userspace tool. The original issue was that the driver needed to be told how to flash using module parameters, which is just a non-starter. A dynamic, sysfs-based interface is quite a lot better; I'm willing to keep discussing that solution. But some questions: 1) is the interface extendable to flashing firmware on CF SDIO 8385 and SD 8686 too? So this point is moot because the patch is only applicable to USB right now, and we don't have any USB devices other than 8388. The question below still stands though... Dan 2) does the patch handle resets and everything correctly, ie can I flash the firmware and then immediately start using the device? Can I also stop using the device and flash the firmware on-demand without unloading the driver? Dan ___ libertas-dev mailing list [EMAIL PROTECTED] http://lists.infradead.org/mailman/listinfo/libertas-dev ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 11:30 -0400, Michail Bletsas wrote: [EMAIL PROTECTED] wrote on 06/03/2008 11:20:51 AM: A necessary rectification: Firmware updates from the driver are the only method that works currently. If we want to name one method a disaster, we would have to choose the userspace tool, since it will brick many of your active antennae. It worked up until boot2 3109; and then apparently nobody at OLPC cared enough to fix the tool after that, and nobody at Marvell cared enough to tell anyone what changed so that somebody _could_ fix the tool. Dan, The required functionality is a superset of what the userspace tool was originally developed to do (update the boot2 code). We now have a much bigger firmware blob to write to the EEPROM (besides the boot2 code) and Marvell always felt that it is better for the ARM processor on the wireless module to handle that task. That's fine, since there is no real difference in the flashing procedure between boot2 and normal firmware AFAICT, the tool should work with that firmware just fine. And a slight correction, but better for the ARM processor is wrong, because it's _always_ been the ARM updating the normal (ie non-boot2) firmware in this scenario, even if the userspace tool was doing it. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 13:49 -0400, Michail Bletsas wrote: Dan Williams [EMAIL PROTECTED] wrote on 06/03/2008 01:20:11 PM: On Tue, 2008-06-03 at 13:03 -0400, Michail Bletsas wrote: Dan Williams [EMAIL PROTECTED] wrote on 06/03/2008 11:26:21 AM: It is not a matter of Python vs C. The userspace tool is extremely awkward to use (since it requires the driver modules to be unloaded which in turn makes the identification of How does it make the ID more difficult? What do we need besides the bcdDevice ID that tells us what boot2 version the device has? Is there something more needed to find out if the device has larger EEPROM for active antenna support perhaps? It makes it more difficult because instead of network interfaces (eth0, eth1 etc), one ends up having to deal with USB ids. In devices with multiple intefaces (an XO with an active antenna for example), that is very confusing. This is fair; except that the network interface name is subject to change and you can't guarantee that eth0 will always be the same device unless you use something like udev rules to rename devices on the fly when they are plugged in based on the device's MAC address, which requires loading the driver first. The kernel has never had a guarantee about device ordering. So if you _really_ want to make sure you're updating the right device, then you get Marvell to start putting real serial #s into the USB interface's serial number slot instead of 0. My usb8388 says: bcdDevice 31.02 iManufacturer 1 Marvell iProduct2 MARVELL Wireless Device iSerial 0 - bNumConfigurations 1 that's the only way to guarantee that you're updating the device you want to update. That's a good suggestion. From a practical perspective though, in XOs, the onboard interface is always eth0 these days. Yes, but I thought the discussion was more about active antenna updates, where you may have more than one usb8388, and thus you actually care about updating a specific adapter. In the normal XO case, you only have one usb8388, and thus the userspace flash tool will work just fine. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 13:03 -0400, Michail Bletsas wrote: Dan Williams [EMAIL PROTECTED] wrote on 06/03/2008 11:26:21 AM: It is not a matter of Python vs C. The userspace tool is extremely awkward to use (since it requires the driver modules to be unloaded which in turn makes the identification of How does it make the ID more difficult? What do we need besides the bcdDevice ID that tells us what boot2 version the device has? Is there something more needed to find out if the device has larger EEPROM for active antenna support perhaps? It makes it more difficult because instead of network interfaces (eth0, eth1 etc), one ends up having to deal with USB ids. In devices with multiple intefaces (an XO with an active antenna for example), that is very confusing. This is fair; except that the network interface name is subject to change and you can't guarantee that eth0 will always be the same device unless you use something like udev rules to rename devices on the fly when they are plugged in based on the device's MAC address, which requires loading the driver first. The kernel has never had a guarantee about device ordering. So if you _really_ want to make sure you're updating the right device, then you get Marvell to start putting real serial #s into the USB interface's serial number slot instead of 0. My usb8388 says: bcdDevice 31.02 iManufacturer 1 Marvell iProduct2 MARVELL Wireless Device iSerial 0 - bNumConfigurations 1 that's the only way to guarantee that you're updating the device you want to update. devices on the XO even more difficult) and it bricks wireless modules while the driver method doesn't. So the statement that firmware updates from the driver were a disaster is simply not true. It bricks the modules because the only people with the access to the docs and firmware (Marvell) didn't try to debug the issue, or correct the tool. There's only so much _I_ can do without access to the firmware source itself if other people who have the info aren't really jumping on these problems, when I don't have the info. Marvell already has a working method. Are you suggesting that they are obliged to support yours on top of theirs? They are obliged to work with the upstream community to find a solution that works for everyone, not just their customers. The solution they originally had didn't work for us (upstream or OLPC), and thus we developed the userspace flash tool. Now that CozyBit/Marvell have taken a different, better approach we can restart the discussions around it. Personally, I don't particularly care either way. The userspace flash tool does have some benefits, specifically that you don't have to load the driver before you flash the device, because the patch that's been posted will only allow the firmware to be flashed after the driver has been bound and potentially started the device, loaded the original firmware, and turned on the radio. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Mon, 2008-06-02 at 17:12 -0700, Brian Cavagnolo wrote:
To update boot2, copy the boot2 and firmware images to /lib/firmware and:
echo boot2_image_name /sys/class/net/eth2/lbs_boot2
echo firmware_image_name /sys/class/net/eth2/lbs_fw
So by this point the driver has already sent BOOT_CMD_FW_BY_USB and
there's already a runtime firmware loaded on the device.
Am I correct in assuming that the runtime firmware implements _all_ the
same boot commands that the boot2 firmware does, including UPDATE_BOOT2
(flash new boot2 to EEPROM), FW_BY_USB (execute uploaded firmware but do
not flash), and UPDATE_FW (flash new runtime firmware to EEPROM)? Or
does the runtime firmware only support flashing, not re-executing itself
with FW_BY_USB?
Are there _any_ side effects of sending the boot command to a running
firmware? We didn't have to care about these before because the module
wasn't loaded, and when you were done flashing you were supposed to load
the module which would reset the card.
You'll need to grab priv-driver_lock before calling if_usb_prog_fw().
If you don't, anyone can issue WEXT commands or call 'ifconfig eth0 up'
and start inserting random commands into the command queue. I'm not
even sure grabbing priv-driver_lock will help you here, because the
firmware upload code was always executed _before_ there was a network
interface registered with the system, and thus doesn't need to do _any_
locking at all. So just grabbing priv-driver_lock doesn't necessarily
stop other USB commands from getting issued, though in practice since
you have to have priv-driver_lock held before grabbing a free cmd_node
from the driver core, this would stop the driver core from sending
commands during a firmware upload. So the behavior you'd get would be
that an iwconfig call would block until the firmware upload was
complete, then immediately send the pending command to the firmware.
Hence my question about side-effects above.
Does the loaded runtime firmware just write the new firmware to EEPROM
and then continue as normal? If so, I assume that the new firmware is
not expected to be active until (a) reboot, (b) USB port reset, (c) OLPC
EC-triggered reset, (d) CMD_802_11_RESET, or (e) hotplug of the active
antenna.
The code probably shouldn't allow updating the firmware if the battery
is low. Unfortunately, this isn't something that can or should be
stuffed into the driver, which is one great benefit of doing the update
in userspace. Second, you probably want to make sure that the system is
prohibited from entering the suspend state during a firmware update.
This is also probably better done via userspace. Obviously neither of
these two is implemented in the current userspace tool but they would be
nice, and not something that can be done from the kernel side in any
upstream-able manner.
Dan
Signed-off-by: Brian Cavagnolo [EMAIL PROTECTED]
---
drivers/net/wireless/libertas/if_usb.c | 65
1 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/libertas/if_usb.c
b/drivers/net/wireless/libertas/if_usb.c
index 91413a6..6a32f37 100644
--- a/drivers/net/wireless/libertas/if_usb.c
+++ b/drivers/net/wireless/libertas/if_usb.c
@@ -46,6 +46,62 @@ static void if_usb_free(struct if_usb_card *cardp);
static int if_usb_submit_rx_urb(struct if_usb_card *cardp);
static int if_usb_reset_device(struct if_usb_card *cardp);
+/* sysfs hooks */
+
+/**
+ * Set function to write firmware to device's persistent memory
+ */
+static ssize_t if_usb_firmware_set(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct lbs_private *priv = to_net_dev(dev)-priv;
+ struct if_usb_card *cardp = priv-card;
+ char fwname[FIRMWARE_NAME_MAX];
+ int ret;
+
+ sscanf(buf, %29s, fwname); /* FIRMWARE_NAME_MAX - 1 = 29 */
+ ret = if_usb_prog_firmware(cardp, fwname, BOOT_CMD_UPDATE_FW);
+ if (ret == 0)
+ return count;
+
+ return ret;
+}
+
+/**
+ * lbs_fw attribute to be exported per ethX interface through sysfs
+ * (/sys/class/net/ethX/lbs_fw). Use this like so to write firmware to the
+ * device's persistent memory:
+ * echo usb8388-5.126.0.p5.bin /sys/class/net/ethX/lbs_fw
+ */
+static DEVICE_ATTR(lbs_fw, 0200, NULL, if_usb_firmware_set);
+
+/**
+ * Set function to write firmware to device's persistent memory
+ */
+static ssize_t if_usb_boot2_set(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct lbs_private *priv = to_net_dev(dev)-priv;
+ struct if_usb_card *cardp = priv-card;
+ char fwname[FIRMWARE_NAME_MAX];
+ int ret;
+
+ sscanf(buf, %29s, fwname); /* FIRMWARE_NAME_MAX - 1 = 29 */
+ ret = if_usb_prog_firmware(cardp, fwname, BOOT_CMD_UPDATE_BOOT2);
+ if (ret == 0)
+ return count;
+
+ return ret;
+}
+
+/**
+ *
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 13:09 -0400, Michail Bletsas wrote: Dan Williams [EMAIL PROTECTED] wrote on 06/03/2008 12:09:11 PM: On Tue, 2008-06-03 at 11:30 -0400, Michail Bletsas wrote: [EMAIL PROTECTED] wrote on 06/03/2008 11:20:51 AM: A necessary rectification: Firmware updates from the driver are the only method that works currently. If we want to name one method a disaster, we would have to choose the userspace tool, since it will brick many of your active antennae. It worked up until boot2 3109; and then apparently nobody at OLPC cared enough to fix the tool after that, and nobody at Marvell cared enough to tell anyone what changed so that somebody _could_ fix the tool. Dan, The required functionality is a superset of what the userspace tool was originally developed to do (update the boot2 code). We now have a much bigger firmware blob to write to the EEPROM (besides the boot2 code) and Marvell always felt that it is better for the ARM processor on the wireless module to handle that task. That's fine, since there is no real difference in the flashing procedure between boot2 and normal firmware AFAICT, the tool should work with that firmware just fine. And a slight correction, but better for the ARM processor is wrong, because it's _always_ been the ARM updating the normal (ie non-boot2) firmware in this scenario, even if the userspace tool was doing it. There has to be a real difference since the flashing code is in the firmware which the userspace tool doesn't load, relying on whatever support was originally in the boot2 code. There is support for flashing using either the MFG firmware images (.img files), or the chunked firmware files (.bin files). The MFG images are flashed by the runtime firmware, while the chunked format is flashed by the boot2 firmware. To flash Boot2 with an MFG firmware (which first loads the runtime firmware), you use the -m command to the flash tool like so: ./libertas-flash.py -m mfg image runtime firmware The current code appears to assume that an MFG flash will only flash boot2 firmware, and only supports runtime firmware update when the flashing is performed by boot2. It looks pretty easy to add support for MFG flashing of the runtime firmware, by the runtime firmware, since the support is already there for boot2 update by runtime firmware. Which brings us to Feb. I didn't understand exactly how the active antennas were supposed to get flashed, which (from your comments) looks to be a runtime firmware flash from the runtime firmware using BOOT_CMD_UPDATE_FW. I didn't have any active antennas at the time to test with nor firmware that would go on them. I also didn't have any details about exactly how the active antennas differed from the XO usb8388. Re-reading the comments in #7170 show Wad was trying to do a runtime-firmware update of the Boot2 code only, not a runtime firmware update of the runtime firmware. That had always worked on XOs, leading me to suspect some difference in hardware behavior between XO and active antenna. Dan Because of the uniqueness of the active antenna's hardware, Marvell moved the code that was specific to the active antenna flashing into the firmware. If I remember correctly, the trend for the boot2 code is to make it as small as possible and burn it into the device's ROM in the newer devices. M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] libertas: add sysfs hooks to update boot2 and persistent firmware
On Tue, 2008-06-03 at 22:08 +0100, David Woodhouse wrote: On Tue, 2008-06-03 at 11:28 -0400, Dan Williams wrote: I'm happy to test this out and try to get the userspace tool working again if given: Last time I knew, the userspace tool _was_ working. Although we'd stripped out the support from the kernel driver ages ago and wrote libertas-flash.py, Michail for some reason told Marvell to put it back into the driver instead of updating libertas-flash.py as they should have done -- but we _fixed_ that back in January when I was in Mongolia and had active antennae to update, didn't we? I'm a bit confused that we're having the same discussion _again_. Yeah, me too. But it doesn't look like the tool will update the runtime firmware from the runtime firmware, it'll only update the runtime firmware from the boot2 firmware. If they are indeed pulling the update capability out of future boot2 versions, then we'll need to update the tool to handle this. dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Sun, 2008-05-18 at 20:48 +0100, David Woodhouse wrote:
On Tue, 2008-05-13 at 15:38 +0100, David Woodhouse wrote:
On an SMP host, are you sure we can't end up setting the multicast list
simultaneously on the two logical devices?
(A: No.)
Try it like this... completely untested and hence probably broken in
some stupid and minor way, but testing is something for tomorrow, not
Sunday night when I'm supposed to be cooking dinner.
We now merge duplicates from the two address lists while we're building
the CMD_MAC_MULTICAST_ADR packet to send to the device, so we don't
artificially limit each device to MRVDRV_MAX_MULTICAST_LIST_SIZE/2
addresses. We'll go into allmulti mode only if the total number of
addresses, excluding duplicates, exceeds the limit. Although I'm not
wonderfully happy that we don't have any way of interrogating the
firmware for its limit; what happens when we send more addresses than
the firmware can cope with?
Is the firmware multicast address limit the same for every firmware from
5.0.x up to 9? Is it something that people with the firmware dev kit
can change with a recompile? Because if it changes between any of the
firmware revisions already out there (including for 8385 CF, 8686 SDIO,
8388 USB, etc) then we'll probably need a lookup table. I just hope the
different firmwares does something sensible when they get more than they
can handle?
Dan
We also deal with the locking issues -- that we could be in
lbs_set_multicast_list() for eth0 and msh0 simultaneously on two
different CPUs -- by punting the actual work to a workqueue. Which can
lock and use the multicast lists directly from each device, so we don't
need our own copy of each.
And it moves CMD_MAC_MULTICAST_ADR to a direct command, as we have been
doing for all commands.
Overall, it results in the net addition of five lines of code, instead
of the 64 lines added by the previous version :)
diff --git a/drivers/net/wireless/libertas/cmd.c
b/drivers/net/wireless/libertas/cmd.c
index 6328b95..2473ba8 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/libertas/cmd.c
@@ -778,28 +778,6 @@ out:
return ret;
}
-static int lbs_cmd_mac_multicast_adr(struct lbs_private *priv,
- struct cmd_ds_command *cmd,
- u16 cmd_action)
-{
- struct cmd_ds_mac_multicast_adr *pMCastAdr = cmd-params.madr;
-
- lbs_deb_enter(LBS_DEB_CMD);
- cmd-size = cpu_to_le16(sizeof(struct cmd_ds_mac_multicast_adr) +
- S_DS_GEN);
- cmd-command = cpu_to_le16(CMD_MAC_MULTICAST_ADR);
-
- lbs_deb_cmd(MULTICAST_ADR: setting %d addresses\n,
pMCastAdr-nr_of_adrs);
- pMCastAdr-action = cpu_to_le16(cmd_action);
- pMCastAdr-nr_of_adrs =
- cpu_to_le16((u16) priv-nr_of_multicastmacaddr);
- memcpy(pMCastAdr-maclist, priv-multicastlist,
-priv-nr_of_multicastmacaddr * ETH_ALEN);
-
- lbs_deb_leave(LBS_DEB_CMD);
- return 0;
-}
-
/**
* @brief Get the radio channel
*
@@ -1279,8 +1257,7 @@ void lbs_set_mac_control(struct lbs_private *priv)
cmd.action = cpu_to_le16(priv-mac_control);
cmd.reserved = 0;
- lbs_cmd_async(priv, CMD_MAC_CONTROL,
- cmd.hdr, sizeof(cmd));
+ lbs_cmd_async(priv, CMD_MAC_CONTROL, cmd.hdr, sizeof(cmd));
lbs_deb_leave(LBS_DEB_CMD);
}
@@ -1392,10 +1369,6 @@ int lbs_prepare_and_send_command(struct lbs_private
*priv,
cmdptr, cmd_action);
break;
- case CMD_MAC_MULTICAST_ADR:
- ret = lbs_cmd_mac_multicast_adr(priv, cmdptr, cmd_action);
- break;
-
case CMD_802_11_MONITOR_MODE:
ret = lbs_cmd_802_11_monitor_mode(cmdptr,
cmd_action, pdata_buf);
@@ -1484,7 +1457,7 @@ int lbs_prepare_and_send_command(struct lbs_private
*priv,
ret = lbs_cmd_bcn_ctrl(priv, cmdptr, cmd_action);
break;
default:
- lbs_deb_host(PREP_CMD: unknown command 0x%04x\n, cmd_no);
+ lbs_pr_err(PREP_CMD: unknown command 0x%04x\n, cmd_no);
ret = -1;
break;
}
diff --git a/drivers/net/wireless/libertas/cmdresp.c
b/drivers/net/wireless/libertas/cmdresp.c
index 5abecb7..4c3c5ec 100644
--- a/drivers/net/wireless/libertas/cmdresp.c
+++ b/drivers/net/wireless/libertas/cmdresp.c
@@ -316,7 +316,6 @@ static inline int handle_cmd_response(struct lbs_private
*priv,
break;
- case CMD_RET(CMD_MAC_MULTICAST_ADR):
case CMD_RET(CMD_802_11_RESET):
case CMD_RET(CMD_802_11_AUTHENTICATE):
case CMD_RET(CMD_802_11_BEACON_STOP):
@@ -376,8 +375,8 @@ static inline int handle_cmd_response(struct lbs_private
*priv,
break;
default:
- lbs_deb_host(CMD_RESP:
Re: [PATCH stable] Separate multicast configuration for mesh and wlan interfaces.
On Mon, 2008-05-19 at 12:05 +0100, David Woodhouse wrote: On Mon, 2008-05-19 at 07:01 -0400, Dan Williams wrote: Is the firmware multicast address limit the same for every firmware from 5.0.x up to 9? Is it something that people with the firmware dev kit can change with a recompile? Because if it changes between any of the firmware revisions already out there (including for 8385 CF, 8686 SDIO, 8388 USB, etc) then we'll probably need a lookup table. If we can avoid a lookup table, that would be nice. Perhaps we could list the MAC addresses after trying to set them, and see how many we get back? Unless there's a better way... That wouldn't help if some version of firmware couldn't handle the case when it's given more than it's max (see below). I just hope the different firmwares does something sensible when they get more than they can handle? Like automatically going into ALLMULTI mode? That would be nice, but I find it unlikely. No, like not bounds-checking the given list against an internal max value and overrunning a buffer, because it expects the driver to be bounds-checking the value and not giving it more than it can handle. That's probably not the case, but would be nice to have some confirmation that various firmware versions do handle this OK. If they do, then we can play some tricks like reading it back to see if they all get set correctly or whatnot. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH stable] libertas: Extend CMD_MESH_CONFIG to get and set persistent mesh default params.
On Fri, 2008-05-16 at 17:51 +0200, Stefanik Gábor wrote:
On Fri, May 16, 2008 at 4:50 PM, Johannes Berg
[EMAIL PROTECTED] wrote:
On Fri, 2008-05-16 at 15:09 +0100, David Woodhouse wrote:
On Thu, 2008-05-15 at 11:01 -0700, Brian Cavagnolo wrote:
This patch is based on a patch from Shailendra Govardhan. It introduces
several new iwprivs: {get,set}_bootflag {get,set}_boottime
{get,set}_def_chan
{get,set}_def_protid {get,set}_def_metid {get,set}_def_meshcap
{get,set}_def_meshid. These commands are only supported on Marvell
hardware
that implements persistent defaults, such as the OLPC Active Antenna.
Accordingly, this patch may not be suitable for upstream merging.
But this is the _one_ thing which might actually be OK to do with a
private ioctl, since it's very hardware-specific. Unlike like all the
mesh-mangling stuff where we really ought to be compatible with o11s.
So maybe, just maybe, we _can_ do this with iwpriv and push that
upstream.
Maybe we do, after all, need an iwpriv equivalent in cfg80211/nl80211 so
that we can kill wext at some point.
Or maybe this should be in sysfs or so?
johannes
Or maybe in configfs? That's a better place for configuration options.
(BTW rt2x00 uses debugfs as an iwpriv replacement, so that's another
possibility.)
I keep proposing debugfs too, but in some cases the commands aren't just
for poking around with stuff. configfs is probably a better answer to
tweakables that aren't just ricer-geekporn.
Dan
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Association test
On Fri, 2008-02-08 at 14:58 -0200, Ricardo Carrano wrote: I installed d-feet on an XO. But when I run './d-feet -l' I get: Traceback (most recent call last): File /usr/bin/d-feet, line 47, in module app = DFeetApp.DFeetApp() File /usr/lib/python2.5/site-packages/dfeet/DFeetApp.py, line 29, in __init__ ui = UILoader(UILoader.UI_MAINWINDOW) File /usr/lib/python2.5/site-packages/dfeet/_ui/uiloader.py, line 34, in __init__ self.ui = gtk.Builder() AttributeError: 'module' object has no attribute 'Builder' What am I doing or assuming wrong? It needs a newer GTK that supports GtkBuilder. 2.6.12 or later I think. Dan Thanks! You could use d-feet to view the interfaces then: https://hosted.fedoraproject.org/d-feet/ Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XOs B4 and USB-SVGA adapters
On Sat, 2008-01-26 at 18:38 +0100, Florian Fainelli wrote: Hi all, I am trying to use a USB-SVGA adapter based on the SiS 35x chips with a XO Beta4. It seems like even with an external USB hub which is externally powered, the SVGA adapter does not received enough power, which I find strange because it works on other laptops (IBM, Dell, Apple ...). Is there any know problem with this revision of the XO and the USB power ? Thank you very much in advance for your answer. The module isn't compiled into the kernel, for starters, because the OLPC uses a stripped down kernel. Others have gotten the sisusbvga module compiled, see the Rebuilding the Kernel thread on this list. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: free firmware for 88W8388
On Wed, 2008-01-23 at 16:53 +0100, [EMAIL PROTECTED] wrote: Citando Rózsás Gödény [EMAIL PROTECTED]: I started to modify qemu to emulate 88W8388. Now it can load the firmware ( usb8388.bin) into ram and starts the firmware, albeit it drops an error after some time. So it is very simple so far, I worked on it for a couple of hours so far. My short term goals: - emulate the usb device of the 8388 and create a connection between the linux kernel driver and the emulator so from linux pow starting the emulator looks as plugging in the usb device - modify qemu so that i/o ports of 8388 could be accessed from outside of the emulator. I guess that the arm core of 8388 communicates with the other parts (the radio interface) via io ports so if we can see which ports are read/written by the arm core we can do the same from the free firmware. Anyway, if we want to write the free firmware, a good emulator of 8388 is handy. Anybody interested ? I am. I'm currently analyzing the firmware, I didn't try the emulation approach so far. Are you committing your work to some repository? I think we can't disclose details about reverse engineering work, though, if we are interested in a clean-room approach. So I'd rather No, you can't. One team reverse engineers the hardware and creates a specifications document, the second team implements (from scratch or from unencumbered FOSS sources) the firmware that conforms to that specification. The two teams cannot talk about anything that deals with the hardware/firmware other than creating the specification document. For an example of this, see the b43 driver effort for enabling broadcom hardware in Linux. So one of you finds out the hardware details of the OLPC's libertas chip (registers, IO ports, how to control the MAC, etc) and the other one of you writes the bits necessary for emulating that hardware in QEMU. Then somebody else (or the person doing the QEMU bits) can go on to write the open firmware. But the person who reverse engineered the hardware _cannot_ ever work on the open firmware or the QEMU emulation bits if you want to preserve the cleanroom setup. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Rebuilding the Kernel
On Wed, 2008-01-23 at 11:24 -0500, Tom Hoffman wrote: Hi all, I'm trying to get a USB2VGA adapter working. Step 1 would appear to be compiling the SISUSBVGA module in the standard kernel tree and getting it onto my XO. So I've been trying http://wiki.laptop.org/go/Rebuilding_OLPC_kernel And rpmbuild bombs out the same way whether I use a SRPM or git: ++ /usr/bin/id -u + '[' 500 = 0 ']' + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + mv linux-2.6. vanilla mv: cannot stat `linux-2.6.': No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.57150 (%prep) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.57150 (%prep) This is on Fedora 8. Anyone have any helpful advice? I'll update the wiki if you do. You don't need to rebuild the kernel itself. All you need is to install the kernel-devel package for the kernel you want to build against. Then cd into your usb2vga driver directory. Run: make -C /lib/modules/kernel version/build SUBDIRS=`pwd` modules And it'll spit out a .ko you can load if usb2vga has a makefile in the appropriate form (which should be quite simple). If you want to build it for the XO, find out the version of the kernel running on the XO, and get the matching kernel-devel package from Andres' site at http://dev.laptop.org/~dilinger/stable/ And do the same: make -C /lib/modules/olpc kernel version/build SUBDIRS=`pwd` modules Many times, the module (like madwifi, some out-of-tree v4l2 drivers, or others) will include the right makefile magic for you to just type 'make' and it'll handle this all for you. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: free firmware for 88W8388
On Wed, 2008-01-23 at 14:40 -0500, Albert Cahalan wrote: Dan Williams writes: No, you can't. One team reverse engineers the hardware and creates a specifications document, the second team implements (from scratch or from unencumbered FOSS sources) the firmware The only unencumbered FOSS sources are public domain. Creating BSD code from GPL code is no different from creating GPL code from a binary blob. Without the clean-room approach, By unencumbered I meant that you cannot use code (even if it's FOSS) that may possible have been posted from questionable sources who may not have observed cleanroom practices. For example, if code from somebody just showed up one day that emulated the radio IC on the 8388, you could not use (or look at) that code for a cleanroom effort without being 100% sure that the code in question was also cleanroomed. Dan the GPL code authors would have an easier time proving that the BSD code is contaminated. It's not certain that they would succeed of course, just as it isn't certain that a binary blob vendor would succeed against a GPL firmware that was made without a clean-room approach. This is purely a matter of having a more solid defense if it can be shown that there was no access to the original. Any Linux hackers want to sue *BSD hackers? :-) (as always, this is not be be considered legal advice) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: free firmware for 88W8388
On Wed, 2008-01-23 at 21:03 +0100, Rózsás Gödény wrote: Hi I hope you can make options to start with any of the 3 firmwares. Perhaps I wish to try writing a boot1 or boot2. Um, Boot1 is burned into ROM on the 8388 and you probably can't change that without a lot of voodoo magic :) Only Boot2 and the post-boot firmware are loadable. Dan yes, that is an option - modify qemu so that i/o ports of 8388 could be accessed from outside of the emulator. I guess that the arm core of 8388 communicates with the other parts (the radio interface) via io ports so if we can see which ports are read/written by the arm core we can do the same from the free firmware. accessed from outside? (to just view them, to hook them up to something, etc.?) what I mean is that whenever the firmware inside the emulator writes an io port the emulator forwards it to a named pipe also the emulator reads that pipe and sends data the other way around, too then a simple perl script can play the radio part, we can log what the core sends and we can try to inject data into the firmware as if it came from the air interface it may or may not work :) regarding the legality of this: I have the firmware from olpc image and never agreed to Marvell's conditions that are mentioned on the wiki still I don't want to reverse engineer the firmware what I suggest is similar to the approach of the samba team, they listened on the ethernet interface and tried to understand the bits and bytes then they replayed the traffic with their own code. we can listen in the io ports or whatever is necessary and replay it from out own firmware without looking into the firmware itself I guess samba team had a few windows machines (client and server) to generate the traffic so we can use the firmware to generate the traffic, too I'm rather worried about 802.11s, if we implement it following the standard we might have some trouble because of patent trolls. -- Rózsás Gödény ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Why can't i access /dev/dsp or /dev/snd on my XO
On Mon, 2008-01-21 at 19:05 +, Ivo Emanuel Gonçalves wrote: On 1/21/08, Dan Williams [EMAIL PROTECTED] wrote: Except that it's completely insane to try to diverge from the upstream kernel and userland here. Uh? You are supposed to costumize the kernel as you feel like it. Freedom of choice and all. Also, if it may bother you, why not bring the issue up to Mr Torvalds? By diverging from upstream, you bear the entire responsibility for making sure your modifications work with later kernel releases. As the kernel moves forward, your custom code becomes harder and harder to merge with each new kernel release, because the upstream kernel people don't care what customizations you've done. The end result: divergence == lots of work There's already not enough people to do the work, therefore divergence is just an awful idea. Andres already has enough to do when merge times come around, and having two of him doesn't fix the divergence problem at all, it just punts the problem out another 6 months. Divergence is usually manageable for small patches, tweaks, and single drivers. But for something like the entire sound framework? That's just insane. Dan Plus, does OSS support software mixing so that multiple processes pumping out different bitrates and channels of audio can all talk to the same sound device at the same time? Granted, ALSA doesn't have that working as well as I'd like, but if OSS doesn't support that then there is no point in switching to OSS. Certainly. Just an extreme example I tried for fun in my system: YouTube (Flash) foobar2000 (Wine) Kaffeine (Xine) ogg123 (libao) All at the same time sending a bunch of different signals (audio cacophony but still understandable) to the speakers. Different bitrates and volume. Through OSS 4. The only problem with support for OSS in the XO is that there is no driver for the CS5536 yet (there is one for CS5530 though). I checked yesterday. That is the only reason why this may be a bad idea. But you know what, writing drivers for OSS is trivial for people who know how to write drivers. If people agree it may be a good idea to improve the audio system of the XO, then someone will certainly write the driver and spending one or two days doing it for the future benefits of OSS is certainly a good idea. -Ivo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
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 same thing. If you don't load the firmware within 5 seconds of the boot2 code starting up, the thing loads its own firmware from the internal flash. 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? Dan Yes, it's horrid. It doesn't even preserve the boot2 version, because we did some stupid hack to preserve that in the _driver_ rather than keeping it internal, so when we send the CMD_802_11_RESET command to kick the device back into boot2, we get 'device firmware changed' from the kernel and it appears as a completely new device... 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 by updating to a 'normal' Boot2 version from the XO? (Yes, I should be sleeping. No, I have no idea what timezone I'm in). ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
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 verify, or is that address completely irrelevant because the boot2 code is smart enough to figure out where to put it? Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
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 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 automatically as soon as it's loaded -- let the driver activate it when it's appropriate. Then the decision as to whether the radio is blocked can properly be handled in userspace, and the device can be left quiescent if appropriate. 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). So let's alter a fundamental design principle so that the XO doesn't transmit a single frame when riding an airplane... ?? I don't think so. If people feel so strong about this they can always block firmware loading. Mesh forwarding will go on when you initialize the adapter and it is up to the user to turn it off if they feel that they have too. We're not really arguing here, we agree. Everyone agrees that wireless +mesh should start automatically by default after bootup. What David (and I in like 3 mails yesterday in this thread already) had proposed was that the XO firmware should disable the radio _until_Linux_loads_ and the driver tells it to enable the radio. When Linux loads, the driver (or NetworkManager, or whatever) starts the radio. That way, the user at least has a change to at some point say no, don't turn on the radio by default if they want to. _Nothing_ would change for users who do not want/care/need to touch the radio in this scenario, everything would continue to work as it currently does. I'm not sure where you get the idea that we're saying it should all be in airplane mode all the time unless the child explicitly turns the radio on. We're saying exactly the opposite of that. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
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 regulations. We should change the firmware so that it isn't active automatically as soon as it's loaded -- let the driver activate it when it's appropriate. Then the decision as to whether the radio is blocked can properly be handled in userspace, and the device can be left quiescent if appropriate. 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). Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
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 setting IFF_UP or device open). Let us make a clear distinction between the two types of 'active antenna' here. The ones which are actually attached to servers and acting as wireless devices for a computer, we want to act like in the XO. When they come up automatically into mesh repeater mode, that's actually a complete PITA -- and it means we can't reboot the servers because then the driver can't initialise the wireless because it's in mesh repeater mode and doesn't respond properly to being reset. 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 functionality supposed to apply to, the host-less active antenna? (which is what I heretofore had understood). Dan Only for the standalone devices which we're going to hang in a corridor and feed 5v do we want _any_ kind of automatic network operation. And then it needs to be configurable -- we have to set the channel. Since we need a way to configure the channel on the active antennae, let's use channel zero to indicate 'no automatic mesh'. And please can we have that firmware by tomorrow, Ulan Bator time -- so that I can actually set up the school server so that it's rebootable without subsequently having to disconnect and reconnect the firmware? I'd do it myself, but bug #429 bites again... ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
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 switch) put a toggle somewhere in the control panel for Don't turn the radio on automatically that is _UN_checked by default, and a wireless enabled/disabled button there too. Then (see my other mail in this thread) ensure that the driver starts with the radio off, and that the first time the mesh or eth device is brought up that it turns the radio on. Then ensure that NetworkManager is clued into the preference value above, and that NM sets it's initial wireless-enabled state coherently with the preference value above as well. Were these things done, by default the behavior would be the same as it is now, but those people who wish insane amounts of control over the TX power state can have their fluffy white cake and eat it too. The trick is to prioritize this feature request relative to the other important bugs that must be fixed, since it affects multiple items from the bottom to the top of the stack. Dan 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/usb8883.bin.quiet /lib/firmaware/usb8883.bin rmmod usb8xxx; sleep1; modprobe usb8xxx No reboot necessary. --- Tested in build 684, Do I miss something? On Jan 17, 2008 4:30 PM, Michail Bletsas [EMAIL PROTECTED] 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 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 initialize above mean firmware level or OS level? Initialize means loading the wireless firmware on the radio's ARM core and start running it. If you want to make sure that the radio never transmits a single bit, then preventing that (loading the wireless firmware) is what you need right now. There is explicit mesh start/stop in the plans (already implemented in the firmware but not in place yet since the driver people didn't like it). M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
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. That seems like a fairly horrible way to solve a Linux problem. My thoughts precisely. Fix it where it should be fixed, not by playing russian roulette with a shotgun in a pitch-black room full of cute, cuddly, mewing kittens stacked from floor to ceiling. I've already outlined (twice! if my mails get through moderation on networking@) proposed changes to make airplane mode happen. Dan I'm not volunteering to study this possibility right now; I have other fish to fry. Bennett Todd wrote: 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
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 control panel for Don't turn the radio on automatically that is _UN_checked by default, and a wireless enabled/disabled button there too. ... Then ensure that NetworkManager is clued into the preference value above, and that NM sets it's initial wireless-enabled state coherently with the preference value above as well. Were these things done, by default the behavior would be the same as it is now, but those people who wish insane amounts of control over the TX power state can have their fluffy white cake and eat it too. I'm one of those who wishes for control. The G1G1 offering has set up a user population different from the education design of the OLPC project. I live in the boonies, have no wireless, and there are no other radios within range. My connection is by wired ethernet. Took me a while to find out that NetworkManager would set up my wired connection, if I provided a DHCP server. However, if I happen to unplug my ethernet cable for a while, NetworkManager reverts eth0 back to radio (and I need to reboot to reconnect as wired). What I wish for is a user toggle that when I'm at home will inhibit NetworkManager from supplanting the wired connection. (But I do want to restore radio function when I take my XO to a cafe.) NetworkManager has functionality to enable/disable the wireless, it's just not exposed from the user interface yet. I believe Simon has been looking into this. In the mean-time, you can disable wireless by running: dbus-send --system \ --dest=org.freedesktop.NetworkManager \ /org/freedesktop/NetworkManager \ org.freedesktop.NetworkManager.setWirelessEnabled boolean:false and NetworkManager won't try to use either of the 802.11bg or the mesh interfaces until the next reboot. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
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.
The result from strace is:
---
.
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(172.18.0.1)}, 28) = 0
fcntl64(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
gettimeofday({1200442106, 340565}, NULL) = 0
poll([{fd=4, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1
send(4, \270\227\1\0\0\1\0\0\0\0\0\0\1e\0017\1c\1e\1c\0010\1e\1f\1f
\1f..., 90, MSG_NOSIGNAL) = 90
poll( unfinished ...
It seems(according to Bernie)..that netstat makes queries to the DNS
server but it is temporarily down. Still if you execute the command a
couple of time it works again, but is a very regular phenomenon. This
should be a network issue, and not a driver issue, but can you confirm
that?
Also, the msh0 interface is named after msh0_rename. Is there a reason
for that? Will this change back to normal in the future? How will it
be in Update1?. This inconsistency causes some issues in the
olpc-netstatus command utility.
Can you also please describe the changes from the user's perspective
that are changed/improved in the new driver. So we know were to start
testing from.
The original problem the rewrite was fixing was hanging in the driver.
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. You may have noticed this when doing iwconfig
commands that just never completed, or took 2 or 3 minutes to complete,
during which time the driver was in the afore-mentioned state.
This state could manifest itself as weird NetworkManager errors, network
dropouts, and just plain unexplained network flakiness.
For example,
what is the situation with mesh on or off
There isn't any user-facing control for that at this time AFAIK.
mbletsas wanted some user knob for this. The situation I'd expect is
that the mesh device would go away (a device hotplug event) and
NetworkManager wouldn't expose the mesh device at all. When the mesh
was turned back on, the mesh device would be hotplugged back and NM
would magically notice it just like it does when you plug in some other
USB network device.
There's no way that NetworkManager is going to poll the mesh device with
iwpriv for whether it's on or off (that's just so wrong), so mbletsas
and woodhouse have to find a method they agree on that doesn't require
polling to figure out if mesh is on or off. That may mean having the
iwpriv mesh on/off knob also apply to the eth device, so that you can
turn mesh off by doing:
iwpriv eth0 mesh off
iwpriv msh0 mesh off
and you'll get the same behavior, and then you do
iwpriv eth0 mesh on
to turn it back on, and using the normal Linux device hotplug stuff. I
think mbletsas has historically disliked having to manipulate other
devices than the mesh device to actually affect changes on the mesh
device, but that's life.
is the mesh-start file still in use
Yes, since the mesh-start file is something from NetworkManager and not
driver related.
Dan
are improvements related to 4470
thanx,
yani
On Jan 15, 2008 6:40 PM, Kim Quirk [EMAIL PROTECTED] wrote:
David,
Yani is back from his time off and finished with his exams (at
least for now). Before the new year break, he had been working
on testing, documenting and debugging issues mostly associated
with avahi and telepathy, but also with wireless. He and
Ricardo have been our wireless test experts.
Now that he is back, it would be great if you and Michail can
provide some thoughts on the highest priority testing that we
should do here or at Michail's house (for a little more
controlled RF setting); so we can try to find bugs as quickly
as possible.
Also - Ricardo, you might be able to give us some indication
of your availability for testing and how many laptops you have
in Brazil, etc.
Thanks,
Kim
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
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 hemorrhage, and collapse on the ground spurting blood from it's ears. Dude! I sense some Woodhousian-Shakespearian inspiration in you today...;-) Woodhousian is a good way to put it, certainly. That adjective should be added to the OED :) Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
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 [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 airplane. There is a way to do it at the command line, but I don't see government ministers and education officials doing that with any reliability. If all you want is transport, you can take out the battery pack, but if the mesh is not disabled, it will come alive when the battery pack is inserted, long before you can boot and get to a command line to turn it off. I am quite certain that some of the aforementioned ministers and officials will want to show off their new toyz on planes just like the rest of us. Or we could just wait until there is sufficient public pressure to allow XOs to mesh on airplanes so that the rules are changed. Hey, who wants to make the movie Toyz on a Plane? %-] -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
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 this feature is to easily disable wireless before getting on an airplane. There is a way to do it at the command line, but I don't see government ministers and education officials doing that with any reliability. I've been working with Simon on this for the past week or so. It's almost there on the backend, just needs testing and GUI bits from Simon before it gets pushed to joyride builds. Dan If all you want is transport, you can take out the battery pack, but if the mesh is not disabled, it will come alive when the battery pack is inserted, long before you can boot and get to a command line to turn it off. I am quite certain that some of the aforementioned ministers and officials will want to show off their new toyz on planes just like the rest of us. Or we could just wait until there is sufficient public pressure to allow XOs to mesh on airplanes so that the rules are changed. Hey, who wants to make the movie Toyz on a Plane? %-] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: MP3 and the OLPC
On Mon, 2008-01-14 at 15:03 -0800, Wilhelm Fitzpatrick wrote: I'm trying to understand the legal state of MP3 versus the OLPC platform. Looking at this wiki page: http://wiki.laptop.org/go/Restricted_Formats Seems to indicate that handling MP3 requires a license, and thus an MP3 decoders is not packaged by default, yet I know I can open and play MP3s within eToys, which implies there is an MP3 decoder. Anyone have any insight into this situation? To be shipped on the OLPC platform, code and binaries must be a few things: 1) Open Source 2) Free of known patent encumbrance 3) Redistributable/transferrable Yes, you can ask the MP3 licensing association for a license for your MP3 decoder/encoder, even pay them a flat fee of $50,000 for an unlimited license IIRC. But that license is _NOT_ transferable to other parties. After having paid for that license, you can distribute the MP3 software to your friend, but that friend cannot then give that software to another friend without buying a license himself. And that's the problem with MP3 and open-source. As a small digression, most standards are usually RAND (Reasonable And Non-Discriminatory). MPEG (and hence MP3) is such a standard. That does _NOT_ mean that the standard is free of patent protection, or that licenses are not required to implement the standard. It simply means that the owners of the intellectual property on which the standard is based cannot charge everyone a wildly different amount of money, and cannot refuse to license the technology to somebody just because they don't like them. But that doesn't mean the standards are free and clear to implement and redistribute. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
On Thu, 2008-01-10 at 09:00 +, Simon McVittie wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 09 Jan 2008 at 22:17:18 -0500, John Watlington wrote: We have a presence service which provides a way for P2P applications to find one another, even after the IP changes. Presence Service isn't magical. If a laptop's IP address changes, in the link-local backend (Salut) this will most likely appear as a disconnect + reconnect (and the user will leave all shared activities they were currently in). This is somewhat unavoidable, but if it's a hard requirement that Salut do its best to survive IP addresses changing, file a bug against telepathy-salut. In the server-based backend, an IP address change *will* cause a disconnect and reconnect. This is definitely unavoidable, since XMPP uses a long-lived TCP connection to the server. IP addresses are going to change; that's a fact of life. The best anyone can do is try to not make an IP address change a traumatic experience for the user, and provide mechanisms to ensure that whatever the user was working on at the time doesn't just disappear in a puff of smoke. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
On Fri, 2008-01-11 at 00:09 +, [EMAIL PROTECTED] wrote: On Thu, 10 Jan 2008, Dan Williams wrote: In the server-based backend, an IP address change *will* cause a disconnect and reconnect. This is definitely unavoidable, since XMPP uses a long-lived TCP connection to the server. IP addresses are going to change; that's a fact of life. The best anyone can do is try to not make an IP address change a traumatic experience for the user, and provide mechanisms to ensure that whatever the user was working on at the time doesn't just disappear in a puff of smoke. this means changing every app to be aware of IP changes so that they know that they need to re-connnect to the far end. and for many apps, modifying them to be able to pick up where they left off (and to do so in a secure way so that bad guys can't claim to be you on a new IP address and connect into an authenticated session) good luck in re-writing the world. now, if you are willing to throw way all existing software (and solve the reconnect security problems) you may be able to make it work, but there are no apps that work this way today that I am aware of. The world changed underneath the apps, but the apps weren't modified to handle it. It's not 1997 anymore. People no longer only use desktop workstations with static IP addresses. Laptops are everywhere. You don't keep the same IP address when you walk from Starbucks to Panera. Mobile IP may mostly solve this; and that's fine. But until then, the apps are going to suck if they don't handle address changes which are simply a fact of life. It's not that hard to write an app that notices and handles IP address changes. Not handling this in apps that are written for or ported to the XO is just plain laziness. When porting or writing, you need to handle the always-fullscreen-window case, you need to handle the security system, and you need to be aware of IP address changes. Welcome to 2008. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
On Wed, 2008-01-09 at 12:18 -0600, Charles Durrett wrote: On Jan 9, 2008 11:21 AM, Michail Bletsas [EMAIL PROTECTED] wrote: ... The largest issue is how wrong, ugly and painful is to use DHCP on a mesh network. Because of RADV, IPv6 doesn't have that issue. The original mesh portal discovery method was proprietory but also extremely lightweight and did what it was supposed to do with minimal code. ... I'm late to the party. How/who was it proprietary? The original method used UDP packets with a custom format. I wouldn't say proprietary so much as non-standard since the code that created the UDP packets was open for all to see. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh portal discovery
On Wed, 2008-01-09 at 15:59 -0500, John Watlington wrote: On Jan 9, 2008, at 3:47 PM, Michail Bletsas wrote: The MPP discovery mechanism originally proposed worked great for getting packets out of the mesh through the shortest path. The problem was that outside of running NAT on each MPP, there wasn't a good way to ensure that packets sent to that laptop entered the mesh through the same MPP. The only reason that I can see to use DHCP is if you want to distribute routable IPv4 addresses, something that would be glorious if it could happen but which I don't see happening very often. Neither do I. But I don't want to impose a NAT between two laptops in the same school. It will break P2P applications. If you are not running NAT on the MPPs and you have multiple MPPs per mesh and the external routing protocol decided that packets should return through a different portal, what much do you think you are gaining by using the same path inside the mesh (which b.t.w. is different in each direction anyway!)? I don't care about using the same path, but sending packets for six hops through the mesh when proper routing can reduce it to a single hop seems like piss-poor design. And it makes the mesh interfaces on a single server serve the entire school. Why bother with multiple MPPs at all ? We briefly discussed using a different autoIP range, and decided it was difficult to implement. Again fail to see why - it can be non-standard but definitely not difficult to implement. IIRC, Dan Williams was the person looking into it. It wasn't a Network Manager change, it was a change to Avahi, and would either have to be pushed upstream or maintained indefinitely by us. Plus, AutoIP addresses aren't EVER supposed to be routed --- they are strictly link local due to the assignment process. Thanks for the discussion --- we need to figure out a solution for IPv6 going forward, as none of the current approaches will absolutely not extend to IPv6. - DHCP did what we needed back then, namely 1) a robust discovery mechanism 2) well-tested backoff mechanisms 3) well-known and standardized behavior and packet format 4) well-tested and security audited server and client In the School Server case, using DHCP as the allowed us to collapse two steps of the connection process into one. With the previous method, you would have to _both_ find the MPP using the non-standard MPP discovery method, and second do a DHCP run to get your address from the school server. Using DHCP here _already_ can provide the address of your gateway. You could conceivably do both these operations in parallel but since you have to do DHCP anyway, it's pointless to do some other MPP discovery mechanism. In a school setting autoip might work, but might mean more traffic because of potential address conflicts and the resolution process. So if you want dynamic addressing in the school, DHCP is about the only easy way to do that, and once you're using DHCP the old MPP discovery mechanism is pointless. The above benefit does not apply in the XO-as-MPP case because autoip addressing is used, however the same codepath is used in NetworkManager as the school server case, and therefore there is less code to maintain, and fewer codepaths to test, and fewer opportunities for stuff to go wrong. The only real solution to this problem that doesn't suck is to use IPv6 auto addressing for everything. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Unable to initialize camera (via mmap interface)
On Wed, 2007-12-12 at 16:03 -0800, Peter Krenesky wrote:
Hi all,
I'm trying to initialize the camera device and running into some
errors. I'm attempting to use the mmap interface initialized by
VIDIOCGMBUF ioctl. the ioctl is returning -1 and errno is 22.
Is VIDIOCGMBUF/mmap even supported by the driver/device? If so, any
ideas on what can be going wrong?
What's normally used right now to get video out of the device is
GStreamer. You can see what GStreamer is doing from the stuff in
v4l2src_calls.c. Specifically, look at gst_v4l2src_capture_init(). You
probably want to use the QBUF/DQBUF functionality.
Dan
Here is the c++ code that is causing the problem:
video_mbuf mmap_buf_info;
if (-1 == ioctl(vidfd, VIDIOCGMBUF, mmap_buf_info))
{
printf (ERROR: %i \n, errno);
close();
return(HXR_ENC_NO_VIDEO_CAPTURE);
}
thanks,
-peter
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: WPA - testing
On Thu, 2007-12-13 at 15:14 -0500, Michail Bletsas wrote: Ricardo Carrano [EMAIL PROTECTED] wrote on 12/13/2007 02:54:11 PM: - Whatever changed between 1407 and 1416 seem to have really crashed WPA support, I mean, now we cannot set it to work via wpa_supplicant anymore. Maybe something as simple as actually rebuilding wpa_supplicant? I'd look first at what changed between builds... If the supplicant hasn't been updated for quite a while (it shouldn't have been) then it's much less likely to be a problem. I'm not sure what a rebuild would solve here... Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Voice IM project proposal
On Wed, 2007-12-12 at 10:39 -0500, Chris Ball wrote: Hi, We do already have a video-chat activity under development - due to priorities it hasn't been updated in a while but collaboration on that would be welcome. In particular I think the problems with video-chat were: * There's no stream/VOIP support in Gabble (or was it Salut?) Well, you really, really want to do the video/voip stuff out-of-band WRT the jabber-based communication protocols that salut gabbled do. So you use the presence system to _find_ the other person you want to talk to (or use SIP or whatever), but you have to use some other mechanism than jabber to actually talk to that person. So neither Gabble nor Salut are actually involved in any of this. * We don't have a video codec to use! We don't think we can handle the CPU load of encoding and decoding Theora in real time. The previous videoconferencing demo used h.263, but we're guessing we can't ship that for patent reasons (although I don't think anyone's done the research?). There are three versions of H.263: H.263, H.263+ and H.263/2000 (or H.263++). The first one and second might be usable, but H.263/2000 is totally unusable for legal/patent reasons. And, of course, it would be best to work on getting the Theora encoder/decoder working faster for the XO hardware to ensure that there's a completely free, open, and unencumbered solution available. Dan If anyone's willing to hack on this, I think it'd be a really useful project. Video conferencing was a killer demo when we hooked it up a year ago, it'd be a shame not to be able to offer it. The GIT source for the Video Chat activity is: http://dev.laptop.org/git?p=projects/video-chat-activity;a=summary - Chris. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Upgrading to Fedora 8
On Mon, 2007-12-10 at 19:05 -0500, Bernardo Innocenti wrote: Yesterday I tried upgrading yoyride to Fedora 8, to see how much pain it would be. After enabling the fedora repo in /etc/yum.repos.d/fedora.repo and tweaking it to make it fetch from version 8, I just did: init 3 yum -y dist-upgrade --exclude poppler init 5 Going to init 3 is necessary to conserve memory, otherwise yum fights with sugar and cranks the system to death. Excluding poppler precents a dependency problem in our custom package. Surprisingly, everything worked perfectly after the update, until I rebotted. Then I got into a minor glitch that prevents input hotplug from working when the X server is run by the unprivileged user olpc (X is a suid binary). If I run X manually from the console, everything works fine. There's probably a stricter check on the EUID somewhere in dbus or in hal. NetworkManager will lose the mesh interface if you update to 0.7, FYI. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[RFC PATCH] libertas: turn radio off when down
Backport of a patch to olpc-2.6 I'm going to post to linux-wireless.
When both interfaces are down (~IFF_UP), turn off the radio to save
power. When either interface is opened (via iwconfig up or otherwise)
turn the radio back on unless the radio was explicitly disabled by the
user via 'iwconfig txpower off' which also is the previous behavior
without this patch.
This should allow NetworkManager to be told to go to sleep, at which
point it will mark all devices down, and with this patch should turn off
the radio and save power.
It also cleans up some of the mess that was *_open, the intent for which
(unless I'm reading that code wrong) was just to check whether the
interface was up or not, since that's what open/close do.
Comments?
Signed-off-by: Dan Williams [EMAIL PROTECTED]
diff --git a/drivers/net/wireless/libertas/cmd.c
b/drivers/net/wireless/libertas/cmd.c
index caf0b1c..5a15b56 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/libertas/cmd.c
@@ -479,6 +479,8 @@ static int wlan_cmd_802_11_snmp_mib(wlan_private * priv,
return 0;
}
+#define TURN_ON_RF 0x01
+
static int wlan_cmd_802_11_radio_control(wlan_private * priv,
struct cmd_ds_command *cmd,
int cmd_action)
@@ -510,7 +512,7 @@ static int wlan_cmd_802_11_radio_control(wlan_private *
priv,
break;
}
- if (adapter-radioon)
+ if (adapter-radio_on)
pradiocontrol-control |= cpu_to_le16(TURN_ON_RF);
else
pradiocontrol-control = cpu_to_le16(~TURN_ON_RF);
@@ -1112,7 +1114,7 @@ int libertas_set_radio_control(wlan_private * priv)
CMD_OPTION_WAITFORRSP, 0, NULL);
lbs_deb_cmd(RADIO_SET: radio %d, preamble %d\n,
- priv-adapter-radioon, priv-adapter-preamble);
+ priv-adapter-radio_on, priv-adapter-preamble);
lbs_deb_leave_args(LBS_DEB_CMD, ret %d, ret);
return ret;
diff --git a/drivers/net/wireless/libertas/cmdresp.c
b/drivers/net/wireless/libertas/cmdresp.c
index d391391..433d481 100644
--- a/drivers/net/wireless/libertas/cmdresp.c
+++ b/drivers/net/wireless/libertas/cmdresp.c
@@ -991,7 +991,7 @@ int libertas_process_event(wlan_private * priv)
}
lbs_pr_info(EVENT: MESH_AUTO_STARTED\n);
adapter-mesh_connect_status = LIBERTAS_CONNECTED;
- if (priv-mesh_open == 1) {
+ if (priv-mesh_dev-flags IFF_UP) {
netif_wake_queue(priv-mesh_dev);
netif_carrier_on(priv-mesh_dev);
}
diff --git a/drivers/net/wireless/libertas/dev.h
b/drivers/net/wireless/libertas/dev.h
index 404ca50..62c3e75 100644
--- a/drivers/net/wireless/libertas/dev.h
+++ b/drivers/net/wireless/libertas/dev.h
@@ -100,9 +100,6 @@ struct wlan_mesh_stats {
/** Private structure for the MV device */
struct _wlan_private {
- int open;
- int mesh_open;
- int infra_open;
int mesh_autostart_enabled;
__le16 boot2_version;
@@ -339,7 +336,8 @@ struct _wlan_adapter {
u16 nextSNRNF;
u16 numSNRNF;
- u8 radioon;
+ u8 user_radio_on;
+ u8 radio_on;
u32 preamble;
/** data rate stuff */
diff --git a/drivers/net/wireless/libertas/host.h
b/drivers/net/wireless/libertas/host.h
index 00d5675..eb516be 100644
--- a/drivers/net/wireless/libertas/host.h
+++ b/drivers/net/wireless/libertas/host.h
@@ -183,10 +183,6 @@
#define CMD_TYPE_SHORT_PREAMBLE 0x0002
#define CMD_TYPE_LONG_PREAMBLE 0x0003
-#define TURN_ON_RF 0x01
-#define RADIO_ON0x01
-#define RADIO_OFF 0x00
-
#define SET_AUTO_PREAMBLE 0x05
#define SET_SHORT_PREAMBLE 0x03
#define SET_LONG_PREAMBLE 0x01
diff --git a/drivers/net/wireless/libertas/main.c
b/drivers/net/wireless/libertas/main.c
index 2b104d2..f07d5b4 100644
--- a/drivers/net/wireless/libertas/main.c
+++ b/drivers/net/wireless/libertas/main.c
@@ -11,7 +11,9 @@
#include linux/netdevice.h
#include linux/if_arp.h
#include linux/kthread.h
+#if CONFIG_OLPC
#include asm/olpc.h
+#endif
#include net/iw_handler.h
#include net/ieee80211.h
@@ -406,8 +408,6 @@ static int libertas_dev_open(struct net_device *dev)
lbs_deb_enter(LBS_DEB_NET);
- priv-open = 1;
-
if (adapter-connect_status == LIBERTAS_CONNECTED) {
netif_carrier_on(priv-dev);
}
@@ -433,20 +433,33 @@ static int libertas_dev_open(struct net_device *dev)
*/
static int libertas_mesh_open(struct net_device *dev)
{
- wlan_private *priv = (wlan_private *) dev-priv ;
+ wlan_private *priv = (wlan_private *) dev-priv;
+ int ret = -1;
+
+ lbs_deb_enter(LBS_DEB_NET
Re: [RFC PATCH] libertas: turn radio off when down
On Tue, 2007-11-20 at 23:38 -0600, [EMAIL PROTECTED] wrote: Question. How is this intended to interact with the mesh connectivity intended for the laptops? I'm of the understanding that the mesh being powered and on is more or less a baseline design feature of the XO-as-platform. Yes, though for the first gen machines it's likely that more aggressive power management will be required than was originally thought. However, see my mail to Ashish for more detail. Or is this an airplane mode feature that's going to get a button-push or other widget activation to activate? Mostly for airplane mode, and to turn off the power when the device isn't being used at all. When both interfaces are marked down, you can't pass any traffic through the device anyway. There are cases where mesh forwarding is desirable but the machine is asleep for longer periods of time, in these cases there is no real reason to close the device anyway. Dan I fully support the notion of making it possible to quickly and easily disable the radio, as well as mesh-y bits, saving power and reducing RF in situations where one is either clearly out-of-contact or prohibited from emitting excess RF energy, but I would want it to be: 1) very difficult to do by accident 2) give some indication that the radio is currently off, making it easy to quickly re-enable the radio. What's the plan for UI for this? --elijah On Wed, 21 Nov 2007, James Cameron wrote: Date: Wed, 21 Nov 2007 16:26:57 +1100 From: James Cameron [EMAIL PROTECTED] To: Dan Williams [EMAIL PROTECTED] Cc: Andres Salomon [EMAIL PROTECTED], [EMAIL PROTECTED], Brajesh Dave [EMAIL PROTECTED] Subject: Re: [RFC PATCH] libertas: turn radio off when down On Tue, Nov 20, 2007 at 11:18:07PM -0500, Dan Williams wrote: This should allow NetworkManager to be told to go to sleep, at which point it will mark all devices down, and with this patch should turn off the radio and save power. Good. Comments? Very slight possibility of further factorisation seen, but probably not worth it. Otherwise it seemed to make sense. Is it in a build yet? Acked-by: James Cameron [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: [RFC PATCH] libertas: turn radio off when down
On Tue, 2007-11-20 at 21:45 -0800, Ashish Shukla wrote:
Mesh forwarding is always on. Therefore, disabling radio when interface
in not up will disable mesh forwarding as well. Have you thought of
this?
Yes, though interactions with suspend/resume need to be investigated
here.
First, if NM is told to sleep and marks the device down (ohm would be
doing this normally via a lid button event or such), that means that
either somebody is on an airplane, or the laptop really, really should
get turned _all_ the way off without mesh forwarding.
If you would like to keep mesh forwarding on, the mesh device shouldn't
be brought down [1]. This leads into suspend/resume land. Basically,
when the machine suspends, the mesh device should be kept IFF_UP and NM
shouldn't be told to sleep, since this will be happening very often on
OLPC. I'm not sure if the networking core closes the device on suspend,
hopefully not; if it doesn't close the device, then nothing else should
be touching it and things will work correctly.
Last I knew there were cases where mesh forwarding was _not_ supposed to
be on due to the high power drain of the 8388 when the radio was
enabled, plus the airplane case. As long as the networking core doesn't
close the devices on suspend, this patch shouldn't have side-effects on
mesh forwarding.
Dan
[1] when doing long suspends, when the resume occurs userspace will need
to redo the networking setup anyway, scanning and searching for the
school server or default mesh channel, because a long suspend most
likely means you changed location and increases the likelihood that the
networking situation around you changed as well.
Thanks
-Ashish
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dan
Williams
Sent: Wednesday, November 21, 2007 9:48 AM
To: [EMAIL PROTECTED]
Cc: Brajesh Dave; Andres Salomon
Subject: [RFC PATCH] libertas: turn radio off when down
Backport of a patch to olpc-2.6 I'm going to post to linux-wireless.
When both interfaces are down (~IFF_UP), turn off the radio to save
power. When either interface is opened (via iwconfig up or otherwise)
turn the radio back on unless the radio was explicitly disabled by the
user via 'iwconfig txpower off' which also is the previous behavior
without this patch.
This should allow NetworkManager to be told to go to sleep, at which
point it will mark all devices down, and with this patch should turn
off
the radio and save power.
It also cleans up some of the mess that was *_open, the intent for
which
(unless I'm reading that code wrong) was just to check whether the
interface was up or not, since that's what open/close do.
Comments?
Signed-off-by: Dan Williams [EMAIL PROTECTED]
diff --git a/drivers/net/wireless/libertas/cmd.c
b/drivers/net/wireless/libertas/cmd.c
index caf0b1c..5a15b56 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/libertas/cmd.c
@@ -479,6 +479,8 @@ static int wlan_cmd_802_11_snmp_mib(wlan_private *
priv,
return 0;
}
+#define TURN_ON_RF 0x01
+
static int wlan_cmd_802_11_radio_control(wlan_private * priv,
struct cmd_ds_command *cmd,
int cmd_action)
@@ -510,7 +512,7 @@ static int
wlan_cmd_802_11_radio_control(wlan_private * priv,
break;
}
- if (adapter-radioon)
+ if (adapter-radio_on)
pradiocontrol-control |= cpu_to_le16(TURN_ON_RF);
else
pradiocontrol-control = cpu_to_le16(~TURN_ON_RF);
@@ -1112,7 +1114,7 @@ int libertas_set_radio_control(wlan_private *
priv)
CMD_OPTION_WAITFORRSP, 0, NULL);
lbs_deb_cmd(RADIO_SET: radio %d, preamble %d\n,
- priv-adapter-radioon, priv-adapter-preamble);
+ priv-adapter-radio_on, priv-adapter-preamble);
lbs_deb_leave_args(LBS_DEB_CMD, ret %d, ret);
return ret;
diff --git a/drivers/net/wireless/libertas/cmdresp.c
b/drivers/net/wireless/libertas/cmdresp.c
index d391391..433d481 100644
--- a/drivers/net/wireless/libertas/cmdresp.c
+++ b/drivers/net/wireless/libertas/cmdresp.c
@@ -991,7 +991,7 @@ int libertas_process_event(wlan_private * priv)
}
lbs_pr_info(EVENT: MESH_AUTO_STARTED\n);
adapter-mesh_connect_status = LIBERTAS_CONNECTED;
- if (priv-mesh_open == 1) {
+ if (priv-mesh_dev-flags IFF_UP) {
netif_wake_queue(priv-mesh_dev);
netif_carrier_on(priv-mesh_dev);
}
diff --git a/drivers/net/wireless/libertas/dev.h
b/drivers/net/wireless/libertas/dev.h
index 404ca50..62c3e75 100644
--- a/drivers/net/wireless/libertas/dev.h
+++ b/drivers/net/wireless/libertas/dev.h
@@ -100,9 +100,6 @@ struct wlan_mesh_stats {
/** Private structure for the MV device */
struct
Re: Unicode in filenames
On Thu, 2007-11-15 at 09:54 -0500, C. Scott Ananian wrote: Joyride-277 doesn't validate, because it contains a file from the library with a filename in non-normalized unicode. The file is named 'Annobo?n_Bioko-thumb.jpg', where the ? should be a separated accent on the o, but it is actually stored on the filename with a combined 'o+accent' glyph. Now, at first blush this is a bug in the (fast) contents verifier, which I will fix: all strings should be unicode-normalized before they are compared. But it seems like this raises issues with (for example) URLs to library content. Should we enforce the constraint that all filenames are unicode-normalized on disk, so that we can guarantee that a (unicode-normalized) URL will always resolve correctly? Everything on disk should be UTF-8. Anything that's not UTF-8 will not be guaranteed to work. Filenames need to be converted to UTF-8 before the file is opened/created/renamed/etc. Dan Otherwise we run the risk of someone editing a file and resaving it with a name which *appears* identical, but is actually encoded differently on disk, and having URLs to the file mysteriously break. For the technically-minded, we're talking about using the UTF-8 encoding of Unicode Normalization Form D, as discussed (briefly) at http://wiki.laptop.org/go/Canonical_JSON. The problem has arisen because the old libraries used normalized filenames, but we've switched to installing the libraries from RPMs, and apparently non-normalized filenames have snuck in. If I were to hazard a guess, I'd say that the tar command normalizes filenames as they are archived, while RPM does not. My proposal is to ensure that all filenames in the base system (at least) are in normalization form D. I will write a checker in the build process to ensure this, and we should probably eventually write checkers for the activity/library bundle tools that will do the same. --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Retry frame transmission when libertas driver is busy.
On Fri, 2007-11-02 at 16:17 -0700, Javier Cardona wrote: Andres, On 11/2/07, Andres Salomon [EMAIL PROTECTED] wrote: On Fri, 02 Nov 2007 12:54:35 -0700 (PDT) Ashish Shukla [EMAIL PROTECTED] wrote: So, uh.. This patch is from Javier, but was originally written by Ashish? Did I get the attribution right? :) It's from Ashish. I just verified it and forwarded it on his behalf. Is this simply a workaround to make the driver more reliable with the (broken) p0 firmware, or is it an actual fix (ie, is the proper behavior to be returning NETDEV_TX_BUSY rather than dropping packets)? It's an actual fix: the driver should not drop frames in that situation. There is also a firmware fix that the QA team has tested together with this patch. Can we please post these patches to linux-wireless if they don't contain any OLPC-specific ioctls and such? Even if they do, the generic parts that don't touch ioctl.c can get posted on linux-wireless too. Otherwise Andres is going to have a _really_ nasty time merging with new kernel releases. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
On Thu, 2007-10-25 at 10:15 +0100, Simon McVittie wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We still have one set of OLPC-specific patches to Salut (the link-local collaboration backend) that has been rejected upstream, which is the one that adds support for the deprecated ip4-address buddy property. This was used during a transitional period to enable simple TCP-based collaboration for activities that didn't use Tubes; Sjoerd is reluctant to keep this patch set, because it's meant to have gone away by now! Erik ported Read over to tubes and is working on the camera app AFAIK. I'm not sure if the read bits went into git though? There were some small issues with the patch that needed be corrected before pushing to git for Read. One other user might be Etoys. Dan Is anyone still using this property? If not, can we kill it? It was added in Trial-2, and it was meant to be gone by Trial-3 but was left in just in case, so it really ought to disappear. When it does, we can delete some code from Salut and Presence Service. Places it's exposed in the APIs, which I propose to get rid of: PS D-Bus API: Buddy.GetProperties() returns a dict that contains ip4-address: 10.0.0.1 (or whatever), and Buddy.PropertyChanged signal includes a dict that can contain the same sugar.presence: Buddy has a GLib property ip4-address (aka buddy.props.ip4_address) and can emit it in its property-changed signal The Read activity appears to be the only thing in my jhbuild that uses ip4-address (#4297). It should be ported to either stream tubes (when they're ready in Salut, which should be this or next week) or D-Bus tubes (now). Gabble already supports stream tubes, so stream-tube support can be implemented on a branch and tested against Gabble. Porting from plain TCP to stream tubes should be very straightforward; I hope to produce a proof-of-concept patch for Read later today. Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHIF7HWSc8zVUw7HYRAvp6AJ9G/Xiw27pPPMm0g02vhXzRhzUxqwCfW27Z nh1B/wqe7GD/xf/YaOPVaw8= =42L7 -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Configurable beacon interval
On Thu, 2007-10-25 at 13:38 -0400, Andres Salomon wrote: On Thu, 25 Oct 2007 13:29:50 -0400 Dan Williams [EMAIL PROTECTED] wrote: On Wed, 2007-10-24 at 15:42 -0700, Javier Cardona wrote: From: Brajesh Dave [EMAIL PROTECTED] See https://dev.laptop.org/ticket/2750#comment:12 Requires firmware version 5.110.19.p0 or newer, available here: http://dev.laptop.org/pub/firmware/libertas/ What I'd like to do with patches from now on (now that Libertas is fully merged upstream) is to split out the OLPC specific parts (like the ioctls) and channel those directly into olpc-2.6 through Andres, but push the generic bits straight to linux-wireless and John Linville. I'd like to get rid of libertas-2.6 alltogether, and if people have individual enhancements that they want to carry outside of wireless-2.6 then they should get personal git repos to carry those. Note that we (OLPC) are shipping with 2.6.22. Please let me know of any important fixes/enhancements that are already upstream (or in linville's tree), and I will cherry-pick them. I will commit the 3 patches that Javier sent. Sure; I'm still pretty sure there aren't any that OLPC cares about. I'll go back through them and check. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: retrieving the activity bundle directory
On Thu, 2007-10-11 at 14:29 +0100, Victor Lazzarini wrote: Hi everyone, does anyone know if is there a way to retrieve the activity bundle top directory name under python/sugar? You should be able to: from sugar.activity import activity my_bundle_path = activity.get_bundle_path() Dan Thanks Victor Victor Lazzarini Music Technology Laboratory Music Department National University of Ireland, Maynooth ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #3593 NORM Trial-3: Mesh channel randomization breaks NM 'mesh-start' tweakable
On Wed, 2007-09-19 at 06:18 -0400, Walter Bender wrote:
I would recommend not making the patch; I think I found it confusing
only because I didn't know that random impacted link-local. But do we
still default to channel 1 if no school server is found?
No, I'm not confident that we do.
Dan
-walter
On 9/18/07, Zarro Boogs per Child [EMAIL PROTECTED] wrote:
#3593: Mesh channel randomization breaks NM 'mesh-start' tweakable
-+--
Reporter: dcbw | Owner: jg
Type: defect | Status: new
Priority: normal | Milestone: Trial-3
Component: network manager | Version:
Keywords: |Verified: 0
-+--
Since we switched back to randomized mesh channels two weeks ago at the
request of the server team, this inadvertently broke expectations about
how the /etc/NetworkManager/mesh-start file affects things when using
local-only. In this case, if you do local-only through mesh-start, you
are not guaranteed to come up on channel 1 because the start channel is
random.
Please determine if this is trial-3 material or not. Obviously, the
factors against fixing this for trial-3 are that:
1) our target users for trial 3 aren't expected to have to do this
2) you can always switch directly to mesh-1 from the UI
3) we are in code freeze
However, the fix is low-risk and does not affect normal codepaths.
```
Index: src/nm-device-802-11-mesh-olpc.c
===
--- src/nm-device-802-11-mesh-olpc.c(revision 2824)
+++ src/nm-device-802-11-mesh-olpc.c(working copy)
@@ -459,7 +459,10 @@
self-priv-use_mesh_beacons = TRUE;
}
- self-priv-channel = get_random_channel ();
+ if (self-priv-default_first_step == MESH_S4_P2P_MESH)
+ self-priv-channel = 1;
+ else
+ self-priv-channel = get_random_channel ();
self-priv-activation_started_ids = g_hash_table_new
(g_direct_hash,
g_direct_equal);
@@ -1718,7 +1721,10 @@
nm_device_set_active_link (NM_DEVICE (self), FALSE);
if (reinit_state) {
self-priv-step = self-priv-default_first_step;
- self-priv-channel = get_random_channel ();
+ if (self-priv-default_first_step ==
MESH_S4_P2P_MESH)
+ self-priv-channel = 1;
+ else
+ self-priv-channel = get_random_channel
();
self-priv-chans_tried = 0;
self-priv-channel_locked = FALSE;
}
@@ -1754,7 +1760,10 @@
self-priv-channel =
nm_act_request_get_mesh_channel (req);
self-priv-channel_locked = TRUE;
} else {
- self-priv-channel = get_random_channel ();
+ if (self-priv-default_first_step ==
MESH_S4_P2P_MESH)
+ self-priv-channel = 1;
+ else
+ self-priv-channel = get_random_channel
();
}
}
```
--
Ticket URL: https://dev.laptop.org/ticket/3593
One Laptop Per Child https://dev.laptop.org
OLPC bug tracking system
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: #3593 NORM Trial-3: Mesh channel randomization breaks NM 'mesh-start' tweakable
On Wed, 2007-09-19 at 07:50 -0400, Dan Williams wrote:
On Wed, 2007-09-19 at 06:18 -0400, Walter Bender wrote:
I would recommend not making the patch; I think I found it confusing
only because I didn't know that random impacted link-local. But do we
still default to channel 1 if no school server is found?
No, I'm not confident that we do.
I should add that this was likely an oversight and is quite easy to
correct.
Dan
-walter
On 9/18/07, Zarro Boogs per Child [EMAIL PROTECTED] wrote:
#3593: Mesh channel randomization breaks NM 'mesh-start' tweakable
-+--
Reporter: dcbw | Owner: jg
Type: defect | Status: new
Priority: normal | Milestone: Trial-3
Component: network manager | Version:
Keywords: |Verified: 0
-+--
Since we switched back to randomized mesh channels two weeks ago at the
request of the server team, this inadvertently broke expectations about
how the /etc/NetworkManager/mesh-start file affects things when using
local-only. In this case, if you do local-only through mesh-start, you
are not guaranteed to come up on channel 1 because the start channel is
random.
Please determine if this is trial-3 material or not. Obviously, the
factors against fixing this for trial-3 are that:
1) our target users for trial 3 aren't expected to have to do this
2) you can always switch directly to mesh-1 from the UI
3) we are in code freeze
However, the fix is low-risk and does not affect normal codepaths.
```
Index: src/nm-device-802-11-mesh-olpc.c
===
--- src/nm-device-802-11-mesh-olpc.c(revision 2824)
+++ src/nm-device-802-11-mesh-olpc.c(working copy)
@@ -459,7 +459,10 @@
self-priv-use_mesh_beacons = TRUE;
}
- self-priv-channel = get_random_channel ();
+ if (self-priv-default_first_step == MESH_S4_P2P_MESH)
+ self-priv-channel = 1;
+ else
+ self-priv-channel = get_random_channel ();
self-priv-activation_started_ids = g_hash_table_new
(g_direct_hash,
g_direct_equal);
@@ -1718,7 +1721,10 @@
nm_device_set_active_link (NM_DEVICE (self), FALSE);
if (reinit_state) {
self-priv-step =
self-priv-default_first_step;
- self-priv-channel = get_random_channel ();
+ if (self-priv-default_first_step ==
MESH_S4_P2P_MESH)
+ self-priv-channel = 1;
+ else
+ self-priv-channel = get_random_channel
();
self-priv-chans_tried = 0;
self-priv-channel_locked = FALSE;
}
@@ -1754,7 +1760,10 @@
self-priv-channel =
nm_act_request_get_mesh_channel (req);
self-priv-channel_locked = TRUE;
} else {
- self-priv-channel = get_random_channel ();
+ if (self-priv-default_first_step ==
MESH_S4_P2P_MESH)
+ self-priv-channel = 1;
+ else
+ self-priv-channel = get_random_channel
();
}
}
```
--
Ticket URL: https://dev.laptop.org/ticket/3593
One Laptop Per Child https://dev.laptop.org
OLPC bug tracking system
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: wireless networking
On Mon, 2007-09-17 at 06:55 -0400, Jim Gettys wrote: On Thu, 2007-09-13 at 16:10 -0400, Dan Williams wrote: On Thu, 2007-09-13 at 19:52 +0100, Victor Lazzarini wrote: Thanks, I am now seeing my wireless router on the machines and can ping other machines connected to it. Wired internet seems to work (as far as ifconfig and ping are concerned). Two questions: 1. How should I set my hostname and fix it to work with DHCP? The hostname isn't changed by NM because that breaks Xauth and stops you from being able to launch X apps. I thought this got fixed in X quite a while ago (something like 18 months ago). It certainly used to be a PITA. Certainly not fixed, I just tested it out and it fails miserably. It is a PITA. Somebody who knows X needs to fix Xauth to not rely on hostnames. The xauth cookie depends on the hostname of the machine at the time xinit gets run, so we either need to change our xinit stuff to put 127.0.0.1 there for a hostname, or suck up the fact that changing the hostname kills the ability to start X apps. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: radio off guarantee?
On Tue, 2007-09-18 at 18:52 +0200, [EMAIL PROTECTED] wrote: moin, On Tue, 18 Sep 2007 14:42:51 +1000 James Cameron [EMAIL PROTECTED] wrote: Do we need a solid way to turn off the RF before it's OK to use an XO on an airplane? Our target market usually won't have this problem. Yes, but the developers need a solid way to switch of the RF. The Test XO target market are developers and sometimes they travel by air. Javier wrote: # killall NetworkManager # iwpriv eth0 radiooff How could we ensure not bringing up the RF at boot time? Which file takes care of this at fedora systems? Add a hardware killswitch if you want to be 100% sure. There is no single file that takes care of this on any system really. But if you remove the kernel modules, firmware will not get uploaded to the card, and therefore the radio will essentially do nothing AFAIK. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power envelope (was Re: radio off guarantee?)
On Tue, 2007-09-18 at 12:12 -0400, Mike C. Fletcher wrote: John Watlington wrote: Suppose I'm someplace where I don't expect or want to do any mesh networking. How much would turning off the radio help battery life? Last I checked, the effect was very small. There will be occasional scans as the unit hunts around for nearby radios. One could save more by making those scans back off rather than provide a UI element. We see 700 to 800 mW consumed by the mesh interface, and as with most WiFi interfaces, receiving consumes as much power as transmitting. Isn't that about 1/2 of our total power budget? .7 to .8 W on a 2W machine? I'd thought the Marvell chip was supposed to be down in the .3W range. Obviously haven't been following the hardware closely The .3W number is applicable to _infrastructure_ mode with the Marvell part, because the device (like most 802.11 devices) can go into powersave poll mode when in a BSS. In ad-hoc situations, of course, there is no central controller buffering frames and sending out the TIM and therefore you have to have your RX pieces powered on most of the time to receive traffic from other stations, or you start missing frames entirely. You can't use the same powersave algorithms in a mesh (or adhoc even) network as you can use in an infrastructure network. Of course everything in the world right now pretty much uses infrastructure networks, and so the powersave algorithms are tuned for that. But mesh requires new powersave algorithms, or at least an implementation of existing algorithms. There's enough work getting the mesh implemented and working well right now without throwing power algorithms into the mix. Dan enough. (http://wiki.laptop.org/go/Power_Management is where I got the .3W idea). Is that .7W something we'll be able to bring down with software to reduce collisions or the like? University of Toronto's system's group has algorithms that optimise for power savings by reducing collisions, if that would help. From the same page, we'd only last 20 hours at ~.7W draw with a *full* charge (and with hand-charging a full charge likely won't be there, especially at the end of the day), which means that the machines are going to be dead each morning (having drained their batteries keeping up an unused network all night). With a 40 hour period (.3W) we were possibly going to have some juice left in the morning (need to be at 1/4 power when you shut off for the night), but that becomes less likely with a 20 hour period (need to be at 1/2 power when you shut off for the night). While it makes sense to turn off the wireless networking interface on developer machines, we are hesitant to add this to the UI. We are really relying on laptops to extend the mesh away from the school. If we really are spending half our power budget on the mesh network I would imagine that kids will want to be able to turn it off. Yes, meshing is good, but if you could double your battery life while you're at home reading, that would be very worthwhile too. What about *only* keeping the mesh up (continuously) if you are actually routing packets? That is, wake up the mesh interface every few minutes, check to see if your new routing structure makes you a link that is desirable, and only stay on if that's the case. (I realise I'm talking about long-term projects here). You'd need the machines to be able to queue up messages to go out so that they could leap at the request and say yes, please stay up when a linking machine pops on to check for need (implying from activity requests on the local machine would be likely be sufficient, but a simple UI might be workable too). If the network is inactive for X period, go into periodic sleep mode again to save energy. Even if you had to wake up the processor for a few seconds to run the code that decides whether to sleep, it's only about double the power of running the mesh for those seconds, and it could save you the entire power budget for a few minutes. Of course, in the field it may be that the mesh is so densely used that it's never going to go down with that algorithm, but it seems like something we need to investigate if we really are losing that much power to the interface. Just a thought, Mike ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Marvell
On Thu, 2007-09-13 at 12:27 +0200, David Woodhouse wrote: On Thu, 2007-09-13 at 06:12 -0400, Bernardo Innocenti wrote: There was an alternative libertas driver which uses the device in 'dumb' mode with the kernel's mac80211 stack. Coupled with mesh support in mac80211 that might make a somewhat suboptimal alternative to truly free firmware. Fascinating. This way at least we use a smaller portion of the closed firmware. Where is this driver maintained? 'Maintained' is a bit of a strong word what we have is found at http://lists.infradead.org/pipermail/libertas-dev/2007-August/000641.html That's the 8335 though, which is much more of a softmac part than the 8388. The two are not driver level or firmware level compatible :( Dan And is mesh networking really (going to be) supported in softmac? It's a safe bet that the mac80211 stack will grow 802.11s support at some point. It may well be useful for us to do it relatively soon. We could use _any_ Linux-supported softmac card to interact with the mesh that way. I'd suggest whoever starts a firmware rewriting effort to go this route, at least initially. So they can relay on known-good mac80211 code while rewriting just a tiny low-level RF driver. s/known-good/debuggable/ -- and it might not require too many changes to the existing firmware. In the long run, softmac¹ definitely isn't the way to go for XO -- even if you switch it to being completely autonomous while the XO is off, you just don't want to be processing all the infrastructure stuff on the Geode. For _debugging_ generic mesh stuff, however, I suspect that's precisely how we want it. When it comes to time to thinking about Gen2... CSR have fullmac devices and a whole lot of Linux clue. Definitely worth investigating. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: wireless networking
On Thu, 2007-09-13 at 14:08 +0100, Victor Lazzarini wrote: Hi all, Got the delivery of two B4 machines and joined the list today. I am trying to test the system, so would like to get some help. I am starting with networking; I have not yet updated to the latest OS image, though. I got the two machines side by side. Shouldn't they see each other in Sugar's neighboorhood? I opened the terminal and set them to the same essid but still no sign. Yes, iwconfig is incompatible with NetworkManager because iwconfig changes the parameters underneath NM. You also need an IP address before the two will talk, and when NM manages the connection, it'll do that for you automatically. If you connect them both to the same AP using the GUI, or you remove the saved network config bits in ~/.sugar/default/nm/networks and just start them up and wait a while, they will fall back to channel 1 and mesh with each other. Dan Also, should they not see other AdHoc machines around them (say other windows, linux, OSX). Suggestions? Victor Victor Lazzarini Music Technology Laboratory Music Department National University of Ireland, Maynooth ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: More 16 vs 24 bpp profiling
On Tue, 2007-09-11 at 14:19 -0400, Bernardo Innocenti wrote: On 09/11/2007 01:32 PM, Bernardo Innocenti wrote: The 16bpp codepath has to be broken somewhere if it takes twice the time to copy half the bits :-) It strikes me that we don't see any time spent in pixman_fill_mmx(), even though it's not inlinable. For some reason, pixman thinks it cannot accelerate 16bpp fills with MMX, at least on the Geode. Might be worth investigating... We did have to patch the MMX check in pixman long ago, maybe that got broken somehow? There were actually two, an update to the cpu flags and also a strcmp() on the processor ID that had to be fixed to get pixman to detect MMX capability on the geode. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Marvell
On Mon, 2007-09-10 at 22:37 -0400, Albert Cahalan wrote: Edward Cherlin writes: We need the Marvell documentation, and the location of the code OLPC has written on top of the microkernel. (Both easy enough, I assume.) You'd think so, but nobody has coughed this up despite repeated pleas. I can't even get the extra hardware I asked for, which gets to be rather critical when the time comes to test what things do. I also didn't get my project hosting request approved. Not that documentation is required; reverse engineering is fun. Martin Langhoff quoting Edward Cherlin: Who would like to work on it? I think that is the key problem. If someone can hack in that area (of which I only know enough to say that I cannot even get started), and is interested/motivated enough to do it, they'd be doing it already. The only thing you can do is roll up your sleeves and hack on it yourself if you can, and start posting code and notes. Indeed. Join the party. Notes are here: http://wiki.laptop.org/go/88W8388 For those who haven't ever tried it: reverse engineering is fun! It's a really intense mental activity. Unlike regular coding, it's even more fun with a friend. It would make a wonderful activity for sharing over the mesh. Of course, it's still plenty of fun all by yourself as you empty a 12-pack of Mountain Dew at 4:00 AM. Nothing is better for satisfying a hard-core hacking urge. At least initially, you don't even need hardware for this. You can post your discoveries right here, anonymously if you prefer. Just get the firmware files and go for it. BTW, if any of you are in the USA and start really enjoying this kind of thing, I can probably get you a job doing it full-time. Bernardo Innocenti writes: Implementing the whole 802.11 protocol stack and doing that without any documentation of the MAC hardware and maybe with no access to fancy RF equipment for testing the output... ...*that* would be no fun! Or maybe a lot of fun, depending on how much you like challenges! It is fun as long as you believe that the effort is appreciated and that documentation will not appear without your efforts. It is even more fun if you can discover dark secrets, such as when somebody spotted Marvell using the GPL eCos OS for a different chip. That guy even had the balls to attack the firmware with objdump. Most people prefer an interactive disassembler like IDA or ChARMeD. Dan Williams writes: Somebody needs to take ownership of the issue and run with it. There's no bandwidth right now to do that at OLPC. No problem. Please approve the hosting request. Also, I can only do so much without hardware. Ideally I'd have hardware to spare, because it is possible to scramble the boot2 firmware and may even be possible to do other hardware damage. I'll certainly need something to sniff mesh packets, and doing the mesh protocol will not work without enough devices for a mesh. And it's not just the runtime firmware. Would RMS refuse to recommend the XO because the boot2 firmware that's burned into SPI flash on the wireless module Maybe. In any case, open boot2 firmware would be a good idea. Somebody needs to find a way to unbrick a chip with messed-up boot2 firmware. This is simple. You unsolder the SPI flash from the 8388 board and solder in a freshly programmed SPI flash chip (or the bricked one just fixed). For this of course you need some soldering skills, and an SPI flash programmer. We've bricked SPI flash before and done this procedure to figure out exactly _why_ the flash was bricked (the updater didn't wait long enough for the 8388 to write the new boot2 to the SPI flash) and then to resurrect the part. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Question about Libertas and anycast_mask
On Fri, 2007-08-31 at 10:03 -0400, John Watlington wrote: Dan, The Reliance team in India is having trouble getting the anycast_mask flag set. A mesh interface is configured and up and running. They echo 1 / sys/class/net/msh0/anycast_mask, but subsequent cat /sys/class/net/msh0/anycast_mask return 0. I've never run into this. Can anyone suggest why this is happening, and how to fix it ? We need the kernel version and firmware version they are using. Are they on an XO? A school server? Have they modified anything? What's the git commit hash of the kernel, or the version of the kernel RPM? Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Does sugar web browser support extensions?
On Tue, 2007-08-14 at 15:43 -0400, Samuel Klein wrote: what was the reason not to support firefox addons again? Well, it's not really a decision, but more of a side-effect. The best and most flexible embedding technology to use is pyxpcom. We're embedding a Gecko engine into a different app, and this is of course not firefox. We are not using XUL as the UI toolkit, which is likely what most firefox addons require. It's sort of like Epiphany. You can't put firefox addons into epiphany because epiphany is actually native and doesn't use XUL. We are shipping xulrunner though, so it's conceivable that whenever a xulrunner-based FF comes out it'll just run with the xulrunner we've got, but be completely unsugared. Dan firefox runs smoothly on my B4... and it's pretty great to have access to Google Gears, for instance. SJ On 8/14/07, Noah Kantrowitz [EMAIL PROTECTED] wrote: If you mean normal Firefox add-ons. It does not. We use a simpler core called XULRunner. It does support extensions of a sort using PyXPCom, though I don't (yet) know much about those. --Noah On Aug 14, 2007, at 3:00 PM, Kleber Infante wrote: Hi all, I saw in a post that Sugar web browser does not support extensions. Is that true? If it´s true, what can be done? I would like to know how to install an extension in XO browser. I wanna try to port an Firefox extension to sugar browser. thanks ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Adding the olpc-register script to olpc-util
On Mon, 2007-07-30 at 14:08 -0400, Nelson Elhage wrote:
Here's a fixed version of the patch.
Built as:
http://koji.fedoraproject.org/koji/taskinfo?taskID=84355
dan
- Nelson
On Mon, Jul 30, 2007 at 08:03:00AM -0400, Dan Williams wrote:
On Sat, 2007-07-28 at 11:43 -0400, C. Scott Ananian wrote:
On 7/27/07, Nelson Elhage [EMAIL PROTECTED] wrote:
This is a patch to olpc-util to add a script to register the XO with
the schoolserver for purposes of backup for trial 2
(http://dev.laptop.org/ticket/24).
+sn = read_ofw('mfg-data/SN')
+uuid = read_ofw('mfg-data/U#')
Certain old machines don't have SN or U# data. You should have
read_ofw return None if the file it is looking for doesn't exist, and
then follow the above two lines with:
sn = sn or 'SHF'
uuid = uuid or '----'
That should make things work properly on B1s and hand-built
preproduction machines, among others.
We should think about how we handle a classroom full on B1s (which
have no SN data) on the school server side. B1s do have UUID, so
maybe we should create the schoolserver account based on the first 8
characters of the UUID in this case. This shouldn't make a difference
to the XO code, since the XO ought to take whatever account name the
schoolserver gives it.
I don't believe I have the bits to commit a patch to olpc-util. Could
someone who does (danw? dcbw?) commit this and then ping me to let me
know it's in?
We should probably do the fixes for B1s first...
I also apparently didn't get the first copy of this mail, not sure where
it went...
Dan
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [PATCH] Adding the olpc-register script to olpc-util
On Sat, 2007-07-28 at 11:43 -0400, C. Scott Ananian wrote:
On 7/27/07, Nelson Elhage [EMAIL PROTECTED] wrote:
This is a patch to olpc-util to add a script to register the XO with
the schoolserver for purposes of backup for trial 2
(http://dev.laptop.org/ticket/24).
+sn = read_ofw('mfg-data/SN')
+uuid = read_ofw('mfg-data/U#')
Certain old machines don't have SN or U# data. You should have
read_ofw return None if the file it is looking for doesn't exist, and
then follow the above two lines with:
sn = sn or 'SHF'
uuid = uuid or '----'
That should make things work properly on B1s and hand-built
preproduction machines, among others.
We should think about how we handle a classroom full on B1s (which
have no SN data) on the school server side. B1s do have UUID, so
maybe we should create the schoolserver account based on the first 8
characters of the UUID in this case. This shouldn't make a difference
to the XO code, since the XO ought to take whatever account name the
schoolserver gives it.
I don't believe I have the bits to commit a patch to olpc-util. Could
someone who does (danw? dcbw?) commit this and then ping me to let me
know it's in?
We should probably do the fixes for B1s first...
I also apparently didn't get the first copy of this mail, not sure where
it went...
Dan
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: updatinator status, issues
On Thu, 2007-07-26 at 17:00 +0200, Alexander Larsson wrote: I've updated autoupdatinator (the peer-to-peer mDNS version of the updatinator downloader) to work with the new repository layout where manifests are stored as blobs. I've tested it by publishing an apache http server with a static avahi server file, and it works well. I also updated the server-release tool that lets you publish the olpc:s current image via avahi, but when testing this on my XOs I immediately ran into an issue. When trying to download a blob I got a 404 error. It turns out this was due to the manifest listing /var/lib/rpm/__db.001, which gets removed from the root filesystem at boot. In general I think there are problems with trying to do updates like this if we don't have a pristine version of the current image (even when using e.g. rsync and not updatinator), and we're currently modifying the image all over the place (writing logs, removing rpm db files etc). What is the current status of the vserver work? Perhaps we need to start thinking about that stuff now so we can get robust updates... Anyway, the updatinator stuff is in git for people who'd like to play with the code. I did an update from 530 - 535 yesterday and it worked perfectly, preserving all my user data. Nice job. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: text channel
On Sat, 2007-07-21 at 17:18 +0200, Bert Freudenberg wrote: Comment (by dcbw): You don't actually need Tubes here. Each activity has it's own text channel (even if it doesn't have tubes), which is what we were going to use to do the corkboard stuff. The text channel may possibly be abused for this, though we'd have to check what the link-local stuff does. This sounds interesting. Looking for more details I found http://wiki.laptop.org/go/Activity_Sharing which doesn't really explain what is actually implemented right now, nor what the actual API to use e.g. the text channel would be. Where would I have to look? It basically gives you access to the underlying XMPP chat channel which is what you'd be using if you started a Jabber chat with somebody. Take a look in src/activity.py in the PS, for example _handle_share_join(), and the get_channels() will return the object path of the text channel to your activity, so that you can talk to Telepathy directly. The Chat activity uses the text channel, and so is probably the best guide for how to get it and use it. dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Dramatic image size reduction
On Fri, 2007-07-20 at 10:23 -0400, Bernardo Innocenti wrote: Build 511 was 290MB, build 513 dropped to 218MB, but I couldn't find anything in the ChangeLog to justify this dramatic improvement. Anyone has a clue? The library was broken and was removed. I should have noted that in the changelog. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: updatinator benchmarking (Was: rsync benchmarking)
On Wed, 2007-07-11 at 23:47 +1000, [EMAIL PROTECTED] wrote: Alexander, I should mention that doing better than rsync with a custom solution is not unexpected. rsync tries to be fairly general purpose, and special purpose delta tools can almost always do better, as they can take advantage of more information about the data. Well, what we're more concerned about is spreading around the load of updates, both from a network traffic perspective and a server-utilization perspective than any type of beating of rsync. More of a peer-to-peer model using standard protocols like HTTP. Nothing against rsync, it's quite appropriate for a centrally-managed system with fairly reliable network connections, but that's not the problem that updatinator is actually attempting to solve... different approaches to the same problem really. Dan At least rsync provides a harder target to beat than scp or ftp would, so its useful in that way :-) One thing to watch is round trips. Large numbers of http GET requests means lots of round trips. rsync uses very few round trips, so it tends to do well on high latency links. Cheers, Tridge ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] cafe_ccic: add support for VIDIOC_ENUM_FRAMESIZES and VIDIOC_ENUM_FRAMEINTERVALS
On Fri, 2007-07-06 at 16:30 -0600, Jonathan Corbet wrote: Dan Williams [EMAIL PROTECTED] wrote: Newer gstreamer v4l2 plugins require these ioctls to determine supported frame sizes and rates. Unfortunately, the kernel v4l2 bits don't have members in 'struct video_device' for these ioctls, so we have to override the generic ioctl handler for these two functions. They report only VGA size @ 30fps as being supported for now. Interesting, I didn't know about that. I just sent a question off to Mauro (the V4L2 maintainer) on why those ioctls aren't wired up through video_ioctl2(). His answer, essentially, is nobody was using them yet. Well, gstreamer 0.10.6 now is using those, and in 2.6.22, apparently 4 different drivers have hooked up the FRAMESIZES, and one of those has hooked up FRAMEINTERVALS (pwc, for example, but it doesn't even use the video_ioctl2 hook). The old method of determining largest framesize was complete crack and broke with a lot of drivers, so I'm a great fan of having these explicit commands :) You used to pass in the basically INT_MAX and the driver was supposed to clip that and return what it supported, but since v4l2 drivers are about where wireless+WEXT was 2 years ago, of course nobody has consistent behavior even though v4l2 actually has a spec. I don't think this patch is destined for the mainline in its current form. The right thing to do is to add callbacks for those commands and support them for all drivers through video_ioctl2(). Shouldn't be that Yeah, that's obviously the right thing to do. However, it's not in 2.6.22 yet, and we probably won't ship 2.6.23 in our first release, so we may need to carry some patch like this in olpc-2.6 until we move to 2.6.23. See below for more details :) hard of a thing to do. Once that's done, the cafe_ccic driver should really just push those commands down to the sensor layer. Then you could actually enumerate the real frame sizes and supported rates and you would not have to wire assumptions about the supported video formats into the controller driver. I'm traveling (again, sigh) next week, but could probably hack something up the week after if you don't want to spend more time on this. I'm not sure I'll have time... It's still unknown whether or not we need to move to gstreamer-plugins-good-0.10.6 (which is where the rewritten v4l2src is), because we still need to investigate whether it solves some of the various problems we've seen. If we do move to 0.10.6, we'll need this patch or something like it. If it doesn't, we stick with 0.10.5. Thanks, Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: pivot_root on boot
On Sat, 2007-07-07 at 00:12 -0400, C. Scott Ananian wrote: Quick recap of early boot: a) open firmware checks the status of the foo key, and signature-checks and boots either the primary or the backup kernel, passing fs=primary or fs=backup on the kernel command-line. b) an initramfs script looks for an activation record in /, and initiates activation if not found. If it is found, then we pivot_root to root:/primary or root:/backup, depending on the value of the 'fs' command-line parameter. I've prototyped this process on a hacked build 488. All the real filesystem (except boot) is moved down one level to /a, and we pivot_root to /a during startup. Some things I found out: a) we actually already have an initrd for our kernel, which is built with klibc and is mostly useless: it loads a few modules and invokes klibc's run-init to deallocate the initramfs and pivot to the new root. b) pivoting to a directory which is not a mount point (ie, not the root directory of the mounted fs) is problematic. The --move option to mount only works on mount points. We can --move to the real root and then chroot to the subdirectory, but then this causes problems when we want to remount the real root rw after fsck: mount -o remount,rw / doesn't work, because / isn't actually the mount point. In fact, we can't see the actual mount point anymore. Suggestions: a) get rid of the existing initrd. Un-module the necessary IDE and olpc_nand drivers. b) Create new initrd with activation and pivot code. c) Don't try to pivot_root to the 'real' filesystem. Instead use symlinks: /boot - /current/boot /bin - /current/bin Then we can swing the /current symlink from /a to /b to select either the primary or the backup filesystem. My gut feeling is, let's get the bits to actually generate/support two filesystems into the machine and working before we land something that lets us choose between two filesystems. Boot process is already complicated enough that adding another level to it that may/may not be actually _used_ depending on whether or not we get all the other necessary bits in, doesn't sound like a good idea to me at the moment... I'm basically just worried that if the other stuff doesn't land, we have a bunch of other (unused) pieces that were intended to support the pieces that didn't land, and then we have to spend effort to rip them out. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
cafe_ccic slowness in VIDIOC_S_FMT
Hi, The gstreamer is taking a long time to start the pipeline, so I put some debugging info into the v4l2 source. Here's what I got: 0:00:02.40365 v4l2src v4l2src_calls.c:874:gst_v4l2src_set_capture:v4l2src0 V4L2SRC: Setting capture format to 640x480, format YUYV 0:00:02.403785000 v4l2src v4l2src_calls.c:887:gst_v4l2src_set_capture:v4l2src0 *** VIDIOC_G_FMT: 22 microseconds 0:00:06.059932000 v4l2src v4l2src_calls.c:901:gst_v4l2src_set_capture:v4l2src0 *** VIDIOC_S_FMT: 3655992 microseconds 0:00:06.061419000 v4l2src v4l2src_calls.c:916:gst_v4l2src_set_capture:v4l2src0 *** VIDIOC_G_PARM: 1313 microseconds 0:00:06.082901000 v4l2src v4l2src_calls.c:927:gst_v4l2src_set_capture:v4l2src0 *** VIDIOC_S_PARM: 21368 microseconds 0:00:06.083023000 v4l2src v4l2src_calls.c:1014:gst_v4l2src_capture_init:v4l2src0 initializing the capture system 0:00:06.083127000 v4l2src v4l2src_calls.c:1023:gst_v4l2src_capture_init:v4l2src0 *** calling REQBUFS, requested 2 buffers 0:00:06.088328000 v4l2src v4l2src_calls.c:1028:gst_v4l2src_capture_init:v4l2src0 *** called REQBUFS, got 6 buffers So here you see that calling VIDIOC_S_FMT takes 3655992 microseconds, which is a _really_ long time. Turns out that cafe_cam_configure() from s_fmt_cap() takes 378 jiffies. Breaking this down, the pieces of cafe_cam_configure() and the jiffies they take are: INT_INIT: 301352 - 301682 (330) S_FMT: 301682 - 301725 ( 43) set_flip: 301725 - 301729 ( 4) All INT_INIT does is write the default registers to the chip, which is a lot of calls to (eventually) i2c_smbus_xfer() in drivers/i2c/i2c-core.c. I'm not sure where it goes after that. I assume that each call probably does an mdelay or something. Is there anything that can be done to batch these register writes together, or cut down the time that calling cafe_cam_configure() will take? It takes a _really_ long time to set up for streaming capture as seen from userspace... Thanks, Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: can't get wireless working on B2 updated to 406
On Fri, 2007-07-06 at 15:01 -0400, Chris Ball wrote: Hi, raidautorun: failed to open /dev/md0: No such device or address That's normal. from a root shell ifconfig only lists the lo interface. That's bad. Please open a bug on http://dev.laptop.org/query and attach the file created by dmesg file. You might try removing all power (AC and battery) and rebooting, in case the problem goes away. Well, it depends on whether you did ifconfig or ifconfig -a. If the interface isn't up, it won't show up with a plain ifconfig. That's not extremely surprising if NM couldn't connect to anything. 406 does try mesh stuff, so if you haven't already connected to an infrastructure access point, it's also not surprising that you wouldn't get wireless connectivity until you did that. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: .xo bundles (was Re: #1803 HIGH Trial-2: Add Chat activity to builds)
On Tue, 2007-07-03 at 23:47 +0200, Bert Freudenberg wrote: Comment (by J5): Replying to [comment:4 bert]: Replying to [comment:3 J5]: This was generated incorrectly. First the version should be -9 second the activity should be Chat-9.xo. It looks like it was simply zipped up instead of using the packaging tools. Not sure what else is wrong, but simply zipping up is surely as valid as using whatever tools there are, right? No, right now it works but in the future there is no guarantee as we may do post processing. Also python setup.py dist creates a clean package without any of the stray development files (such as MacOS resource files) getting packaged up. Such garbage should not be included obviously. But I'd much prefer if bundles stay simple zip files without added magic. What kind of post processing do you imagine that could not be easily done manually? Generating the signature and verification information for the bundle for signed bundles, which may eventually be required for automatic installation without nice big warning signs. To manually do that, you'd have to sha1 every file in the bundle, add that to some manifest files, and sha1 the manifest file, etc. A lot harder than just zipping the bundle up, because each time you change a file in the bundle, the old signature is invalid. I'm sure you'd want to do this automatically rather having to do it manually and zipping up the bundle. Originally I'd planned to use a JAR-type signing mechanism for bundles, but that may/may not change. It doesn't have any impact on _developing_ bundles, but would when the time came to make a .xo out of your activity. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Upgrades and image manifests
On Fri, 2007-06-29 at 12:26 -0400, C. Scott Ananian wrote: Please read Ivan's update proposal. He addresses many of the peripheral issues that have arisen, re user notification, etc. At this point, as far as I'm concerned, the only open question is how we get a filesystem image onto the laptop once we know which one to get. Ivan suggests rsync; I refined that somewhat with a directory-at-a-time rsync using manifests; someone else (Mike?) proposed bittorrent, and previously I proposed a bespoke solution using binary diffs and multicast. Alex's work is interesting, but we need to see benchmarks if we're not going to make a decision based on just fiat and personality. I've posted up/download bandwidth for upgrades between 464-465 and 465-466. Following up on Mike's suggestion, I've also patched bittorrent to allow using it for upgrades: the net bandwidth usage is something like 30MB, because it does not use block compression. I can post more detailed comparisons if people are interested. Please perform the equivalent benchmarks on the updatinator, before we continue this discussion. With updatinator, bsdiff-ing the changes between files and gzipping new files is the sweet spot. I tested plain blobs, gzipped blobs, bzip2-ed blobs, bsdiff + gzip, and bsdiff + bzip2. Unfortunately, bzip2's memory consumption on decompress isn't all that great according to other people's research, and gzip gives us the best balance between compression ratio and decompression mem/cpu usage. Scott, you may also want to re-test the rsync benchmarks using rsync compression to make the bandwidth numbers in the rsync benchmarks go down. You didn't mention anything specifically about using wire compression, but the numbers look like you hadn't used it? This patch adds bsdiff + gzip compression to updatinator: http://people.redhat.com/dcbw/updatinator-bsdiff-gzip.patch The difference sizes, using du -csb on the difference blob directory are as follows. This is the amount of data that would be transferred over the network, not including HTTP headers. 464-465: 6,869,799 bytes 465-466: 18,870,574 bytes The resulting image directories verify with both verify-manifest and diff -rua. As an improvement, we should provide a manifest-diff file for each update path (along with the manifests for the actual image) that lists the blobs with their own sha1 sum so that they are self-verifying. This would also simplify the patch quite a bit because there would be less path-munging. The diff-manifest tool that generates the blob diffs will output this data in a somewhat suitable format already. Cheers, Dan Procedure: 1) get the 465 and 466 tree files 2) unpack those trees 3) diff-manifest -g 465-466 465 466 465-manifest.txt 466-manifest.txt 4) cp -r 465 465-test 5) upgrade-manifest -b 465-466 -d 465-test 465-manifest.txt 466-manifest.txt 6) verify-manifest 466-manifest.txt 465-test ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build 472 - testing
On Fri, 2007-06-29 at 21:37 -0400, John (J5) Palmieri wrote: On Fri, 2007-06-29 at 11:23 -0400, Kim Quirk wrote: Test Groups, Build 472 is available, but the biggest problem is that it doesn't get on the mesh or infrastructure AP. Some activities are working and there is more to see in the Journal than the previous build. I'm hoping that we can get another build today with the network problem fixed since that would be important for our 'Release Candidate 1'. Today's milestone is to get to RC1 which has most of the basic functionality that was available in 406 builds. If we can get the mesh connecting again, that would be great! Test release notes: http://wiki.laptop.org/go/Test_Group_Release_Notes (Anyone can add notes about this release page -- please do) I couldn't fix the mesh issues with the current NetworkManager so I have backtracked to an earlier working version in build478. This one gets on the mesh and also on AP points. http://olpc.download.redhat.com/olpc/streams/development/build478/ So thinking about it again, we don't expect the new svn2621 NM bits to work with any existing mesh networks because the server software and hardware needs to change. We have to have a flag day in Cambridge too before we can get the new NM automeshing bits, because the new bits aren't compatible with the old bits on the server side. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Upgrades and image manifests
On Tue, 2007-06-19 at 14:39 +0200, Alexander Larsson wrote: Hi, My name is Alexander Larsson, and I just started working on the field upgrade system of the olpc laptops. I have some ideas I'd like to explain and get feedback on. The olpc uses a full-image system, as opposed to the per-package versioning scheme of deb or rpms. So, an upgrade consists of replacing your system files with a full copy of a later (or earlier) version of the system image. We want to support both upgrading from a central server or from another laptop, and we want to minimize the data we have to download for an upgrade. To support this we create a manifest that describes each image, and we save a copy of the current image manifest installed on the laptop. The manifest format is very similar to the git tree object, and describes each file by listing name, metadata and sha1 hash value of the contents. Here is a small example: - link 777 500:500 foo bar blob 664 500:500 4e1243bd22c66e76c2ba9eddc1f91394e57f9f83 changed.txt blob 664 500:500 65ef9261ad6cfaa8403f2fa66d8edfada1445e5a common blob 664 500:500 f660633c832712eba3c6edd39151987e46bc3f87 image1.txt blob 711 500:500 empty logfs.pdf dir 775 500:500 subdir1 blob 664 500:500 empty subdir1/file1.txt blob 664 500:500 7448d8798a4380162d4b56f9b452e2f6f9e24e7a subdir1/file2.txt --- Given a manifest for the current image and a manifest for the image to upgrade to it is very simple and cheap to calculate what changes you need to make to transform the image (on the client), and what sha1 blobs you need to download. You can then download the file blobs from whatever source you have (they are self-verifying, since they are named by the sha1 hash of the content) and do the upgrade. Two questions here: 1) what does the scheme do in the case where the file it's about to replace on the local machine isn't the same as what the manifest on the local machine says? ie, local changes have changed the sha1 hash of the local file. That's essentially a policy decision, do we replace when there are local changes or don't we. A %config-type thing could work here to mark files that you may/may not always want to replace. 2) After downloading a blob, I assume the tool sha1s the downloaded file to ensure that it's content matches the name, right? It is very simple to host the blobs. We just put them all in a directory named by sha1 and export that with a http server. One can also host multiple versions of an image in the same directory, while minimizing the space used for common data. (Possibly one might want to gzip the blobs too.) I've written some code (attached) to generate and manipulate manifests like these. There are three tools: * generate-manifest: This generates a manifest files given a path to a directory containing the image tree. You can also make it populate a directory of sha1-named blobs by giving it a blob directory with -b. * diff-manifest: Gives a simple visual diff between two manifests. If you pass it -b it will instead give a list of all blobs required to update between the two manifests. * upgrade-manifest: Updates an image from one manifest to another, given a path of a directory with the required blobs. Using these tools I upgraded from olpc-redhat-stream-development-build-406-20070507_2141-devel_ext3-tree to olpc-redhat-stream-development-build-406-20070507_2157-ext3-tree in a directory on my development machine, so it seems to work so far. For finding and downloading updates I was thinking of using avahi to publish the image id + version, and then downloading the data and manifests using http. That way that clients can detect machines around them with later versions and auto-download (and apply automatically or later). The individual laptops can publish the version of the image they are using, and a school server can publish several versions. From the point of view of the individual laptop searching for upgrades they will look the same. Of course, we'd have to sign the manifests with some key to make sure you can't just auto-upgrade any machine to a rouge image. Now over to the questions I have: I'd like to put this code in a repository somewhere. Where should I put it? Does OLPC use selinux or xattrs? Because if so we have to extend the manifest format. We need a library to do http downloads. I see we're shipping libcurl on the laptop. Is it ok to use this library? Yeah, though the ironic thing just occurred to me that libcurl is (along with Mozilla) one of the more frequently updated pieces of a linux distro :) (We also need a very simple http sever that maps sha1 - file in system image for laptop-to-laptop upgrades, but I think we can do that without using a library.) simple means lighttpd in my mind, but apache has a longer track record. Is using avahi/mDNS on the mesh network ok? Certainly. There is no other way to do link-local
Re: Upgrades and image manifests
On Fri, 2007-06-29 at 14:21 +0200, Alexander Larsson wrote: On Fri, 2007-06-29 at 08:22 -0400, Dan Williams wrote: Two questions here: 1) what does the scheme do in the case where the file it's about to replace on the local machine isn't the same as what the manifest on the local machine says? ie, local changes have changed the sha1 hash of the local file. That's essentially a policy decision, do we replace when there are local changes or don't we. A %config-type thing could work here to mark files that you may/may not always want to replace. At the moment it only touches the files that are affected by the diff in the manifest. If a file wasn't changed in the manifests we don't even look at it. However, if the file we're replacing has changed locally, we currently throw that away. 2) After downloading a blob, I assume the tool sha1s the downloaded file to ensure that it's content matches the name, right? Yeah, or rather, while downloading. We need a library to do http downloads. I see we're shipping libcurl on the laptop. Is it ok to use this library? Yeah, though the ironic thing just occurred to me that libcurl is (along with Mozilla) one of the more frequently updated pieces of a linux distro :) I ended up using urllib2 in python. Right, python too :) If we get a factory python process (didn't we have one at one point?) we save some memory. (We also need a very simple http sever that maps sha1 - file in system image for laptop-to-laptop upgrades, but I think we can do that without using a library.) simple means lighttpd in my mind, but apache has a longer track record. simple means 300 lines of C code in serve-manifest.c... That may work even better, 300 lines is certainly 1,000,000 times easier to audit for security problems than all of apache or lighttpd. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Upgrades and image manifests
On Tue, 2007-06-19 at 14:39 +0200, Alexander Larsson wrote: Hi, My name is Alexander Larsson, and I just started working on the field upgrade system of the olpc laptops. I have some ideas I'd like to explain and get feedback on. The olpc uses a full-image system, as opposed to the per-package versioning scheme of deb or rpms. So, an upgrade consists of replacing your system files with a full copy of a later (or earlier) version of the system image. We want to support both upgrading from a central server or from another laptop, and we want to minimize the data we have to download for an upgrade. To support this we create a manifest that describes each image, and we save a copy of the current image manifest installed on the laptop. The manifest format is very similar to the git tree object, and describes each file by listing name, metadata and sha1 hash value of the contents. Here is a small example: - link 777 500:500 foo bar blob 664 500:500 4e1243bd22c66e76c2ba9eddc1f91394e57f9f83 changed.txt blob 664 500:500 65ef9261ad6cfaa8403f2fa66d8edfada1445e5a common blob 664 500:500 f660633c832712eba3c6edd39151987e46bc3f87 image1.txt blob 711 500:500 empty logfs.pdf dir 775 500:500 subdir1 blob 664 500:500 empty subdir1/file1.txt blob 664 500:500 7448d8798a4380162d4b56f9b452e2f6f9e24e7a subdir1/file2.txt --- Given a manifest for the current image and a manifest for the image to upgrade to it is very simple and cheap to calculate what changes you So the manifest you update to is an interesting piece, and it's easier because where you get it from is completely orthogonal to the update process. So, you could: 1) as others have suggested, XO periodically contacts the school server 2) XO sends it's current image, asks what to update to, if anything 3) school server makes policy decision about update 4) school server sends back new manifest 5) XO verifies manifests signature 6) XO downloads changesets This is cool, because it doesn't matter _where_ you get the changesets from, be it the school server (which should be seeding the changesets anyway), or from another XO. It optimizes for bandwidth, but not at the expense of any security. You already know what changesets are valid based on the signature-verified server-provided manifest, and on the self-verifying sha1 of the changesets that anyone can provide to you. All in all, simple, straightforward, and not very much code. Dan need to make to transform the image (on the client), and what sha1 blobs you need to download. You can then download the file blobs from whatever source you have (they are self-verifying, since they are named by the sha1 hash of the content) and do the upgrade. It is very simple to host the blobs. We just put them all in a directory named by sha1 and export that with a http server. One can also host multiple versions of an image in the same directory, while minimizing the space used for common data. (Possibly one might want to gzip the blobs too.) I've written some code (attached) to generate and manipulate manifests like these. There are three tools: * generate-manifest: This generates a manifest files given a path to a directory containing the image tree. You can also make it populate a directory of sha1-named blobs by giving it a blob directory with -b. * diff-manifest: Gives a simple visual diff between two manifests. If you pass it -b it will instead give a list of all blobs required to update between the two manifests. * upgrade-manifest: Updates an image from one manifest to another, given a path of a directory with the required blobs. Using these tools I upgraded from olpc-redhat-stream-development-build-406-20070507_2141-devel_ext3-tree to olpc-redhat-stream-development-build-406-20070507_2157-ext3-tree in a directory on my development machine, so it seems to work so far. For finding and downloading updates I was thinking of using avahi to publish the image id + version, and then downloading the data and manifests using http. That way that clients can detect machines around them with later versions and auto-download (and apply automatically or later). The individual laptops can publish the version of the image they are using, and a school server can publish several versions. From the point of view of the individual laptop searching for upgrades they will look the same. Of course, we'd have to sign the manifests with some key to make sure you can't just auto-upgrade any machine to a rouge image. Now over to the questions I have: I'd like to put this code in a repository somewhere. Where should I put it? Does OLPC use selinux or xattrs? Because if so we have to extend the manifest format. We need a library to do http downloads. I see we're shipping libcurl on the laptop. Is it ok to use this library? (We also need a very simple http sever that maps sha1 - file in system image for
Re: Upgrades and image manifests
On Tue, 2007-06-19 at 14:39 +0200, Alexander Larsson wrote: Hi, My name is Alexander Larsson, and I just started working on the field upgrade system of the olpc laptops. I have some ideas I'd like to explain and get feedback on. One more thing :) I'm sure you know, but something people haven't brought up in the whole updates discussion yet is the whole picture. It's not just about the mechanical process of getting updates from point A to point B, since that completely forgets the users who's XO we're trying to update. It's critical to give some user visibility into the update process. While the tool needs to be resilient against users moving around and downloads timing out, the user also needs the _ability_ to see what the tool is doing, even if the UI or the user don't always want to or care. Sugar may want to notify the user when an update starts so the user knows why their machine is now slower, and why their WLAN light is always on. We should have at least the ability to do the Sidekick thing and allow the user to postpone certain updates, but after a week it gets applied automatically. We may want to show the progress of the update, to give users visibility into the process and when to expect it to get done. We need to notify the user than an update is done, and we would suggest that they reboot (possibly based on a metadata flag in the manifest for suggest-reboot=yes). The update daemon must provide a fair amount read-only status information before and during the update process to allow the GUI bits the flexibility to present that information to the user in the way it sees fit. In the ideal world, that means a D-Bus service that sends signals at various stages and has methods Sugar can call to get more information about the update process. However, that links in more libraries and adds vulnerability window to a critical piece of the system. So in that sense, even though a D-Bus server model is a very good one from an API point of view, perhaps the most responsible method would be simple text files that Sugar can inotify and get the required information. Oh, and we should probably rate-limit or connection-limit the local HTTP server that's serving updates so we don't hammer one particular XO. This could mean putting an _advisory_ try-me=true/false flag in the mDNS advertisement that we switch depending on the current connection load. The server would obviously still boot users if there were too many connections, but at least using the 'try-me' gives other laptops more information about whether they should try to connect right away, or try a different XO that may advertise the same blob. Have you thought about what information the mDNS record would advertise? In the best case, it's as large of a UDP packet as we can push out. And since we can probably deal easily with packets up to the wireless MTU (which is something 2000 bytes), there's more room than the traditional 512 byte UDP packet. However, the space in the mDNS announcement is not unlimited, so I don't think we could put the entire blob list in there :) There's certainly enough room to put a build number, HTTP server port number, manifest hash, etc. Dan The olpc uses a full-image system, as opposed to the per-package versioning scheme of deb or rpms. So, an upgrade consists of replacing your system files with a full copy of a later (or earlier) version of the system image. We want to support both upgrading from a central server or from another laptop, and we want to minimize the data we have to download for an upgrade. To support this we create a manifest that describes each image, and we save a copy of the current image manifest installed on the laptop. The manifest format is very similar to the git tree object, and describes each file by listing name, metadata and sha1 hash value of the contents. Here is a small example: - link 777 500:500 foo bar blob 664 500:500 4e1243bd22c66e76c2ba9eddc1f91394e57f9f83 changed.txt blob 664 500:500 65ef9261ad6cfaa8403f2fa66d8edfada1445e5a common blob 664 500:500 f660633c832712eba3c6edd39151987e46bc3f87 image1.txt blob 711 500:500 empty logfs.pdf dir 775 500:500 subdir1 blob 664 500:500 empty subdir1/file1.txt blob 664 500:500 7448d8798a4380162d4b56f9b452e2f6f9e24e7a subdir1/file2.txt --- Given a manifest for the current image and a manifest for the image to upgrade to it is very simple and cheap to calculate what changes you need to make to transform the image (on the client), and what sha1 blobs you need to download. You can then download the file blobs from whatever source you have (they are self-verifying, since they are named by the sha1 hash of the content) and do the upgrade. It is very simple to host the blobs. We just put them all in a directory named by sha1 and export that with a http server. One can also host multiple versions of an image in the same directory, while minimizing the space used
Re: object store apis
On Thu, 2007-06-28 at 13:59 -0400, SJ Klein wrote: Hello all, Thibaut is the author of meshboard.xo [1], a mesh community-board app that currently (as a hack) uses its own xml-rpc server in each instance to send messages to others running the activity. Ryan Trinkle is interested in working on message passing and discovery of small pieces of content over the network -- items on a community board, or selections from a set of wiki articles that a group is sharing. Copying Lenny Foner who's been involved in related discussions. What's the right way for activities like meshboard to pass posts or updates? Where should feedback about the object store API or desired API go? Tubes, most likely. Given the activity ID, everyone should be able to reconnect to the same tube and then meshboard would sync stuff amongst each buddy's instance. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh network vs broadcast/multicast question
On Wed, 2007-06-27 at 15:18 +0200, Alexander Larsson wrote: On Tue, 2007-06-26 at 11:34 -0400, Michail Bletsas wrote: The key point to remember in order to derive answers to these questions is that our mesh network operates at layer-2 For all practical purposes, there aren't any differences between broadcast and multicast frames and every node maintains a table of recently forwarded broadcast frames so that they are not broadcasted multiple times. One can limit the radious of the (layer-2) neighborhood be means of controlling the Mesh TTL field. That is a global setting though, and not something we want applications to touch. Is there a way for a program to figure out which of a list of ip addresses are neighbours in the mesh (i.e. 1 hop away)? Some combination of the ARP cache and the forwarding table from the firmware would probably be able to give us that information. For each node that is 1 hop away in the fowarding table, check the ARP cache and grab the IP address. '/sbin/iwpriv msh0 fwt_list' gives you the FWT info, though the fields are a bit hard to discern unless you've got the driver source. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: System update spec proposal
On Wed, 2007-06-27 at 17:42 +0200, Alexander Larsson wrote:
On Tue, 2007-06-26 at 15:03 -0400, Mike C. Fletcher wrote:
My understanding here is that Alex's system is currently point-to-point,
but that we don't yet have any way to distribute it on the mesh? That
is, that we are looking at a research project to determine how to make
it work in-the-field using some form of mesh-based discovery protocol
that's going to try to optimise for connecting to local laptops. I
personally don't care which way we distribute, but I'm wary of having to
have some mesh-network-level hacking implemented to provide discovery of
an update server.
I'm not sure what you mean here exactly. Discovery is done using avahi,
a well known protocol which we are already using in many places on the
laptop. The actual downloading of file uses http, which is a well known
protocol with many implementations.
The only thing i'm missing atm is a way to tell which ip addresses to
prefer downloading from since they are close. This information is
already availible in the mesh routing tables in the network driver (and
possibly the arp cache), and its just a question of getting this info
and using it to drive what servers to pick for downloading.
So, like michail said, do something like:
n = 0
while (True) {
buf = output of (iwpriv msh0 fwt_list_neigh n)
if (buf == (null))
break; // all done
parse buf into fields
hwaddr = parsed[0] // Grab the 'ra' field (1st one)
ip4addr = lookup_hwaddr_in_arp(hwaddr)
do something with ip4addr
n++;
}
Look on the 'olpc' branch of the libertas driver here:
http://git.infradead.org/?p=libertas-2.6.git;a=blob;f=drivers/net/wireless/libertas/README;hb=olpc
http://git.infradead.org/?p=libertas-2.6.git;a=blob;f=drivers/net/wireless/libertas/ioctl.c;hb=olpc
The README has a description of the command, and the ioctl.c has the
implementation. Just search for the string neigh and you'll find it.
Dan
Basically aside from the vserver bits, which no one has seen, I don't
see a particular advantage to using rsync. In fact, I see serious
downsides since it misses some of the key critical advantages of using
our own tool not the least of which is that we can make our tool do what
we want and with rsync you're talking about changing the protocols.
Hmm, interestingly I see using our own tool as a disadvantage, not a
huge one, but a disadvantage nonetheless, in that we have more untested
code on the system (and we already have a lot), and in this case, in a
critical must-never-fail system. For instance, what happens if the user
is never connected to another XO or school server, but only connects to
a (non-mesh) WiFi network? Does the mesh-broadcast upgrade discovery
protocol work in that case?
Avahi works fine for these cases too. Of course, since it was originally
created for normal networks. However, if you never come close to another
OLPC machine, then we won't find a machine to upgrade against. Its quite
trivial to make it pull from any http server on the net, but that has to
be either polled (which I don't like) or initiated manually (which might
be fine).
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: mesh network vs broadcast/multicast question
On Tue, 2007-06-26 at 15:22 +0200, Alexander Larsson wrote: Hi dan, I have some questions on the mesh network for the updates work. What is the broadcast domain for a laptop on the mesh? (I.E. how far are broadcast messages sent)? Is it just the set of nodes reachable from your machine, or are broadcasts forwarded by the mesh? Michail? This affects how avahi works, as avahi only uses local broadcasts. Another question is on multicasts. How many hops do multicast packets live on the mesh? And are there any other limits than nr of hops to avoid multicast loops? (Otherwise its likely that nodes see multicast packages many times, especially in dense networks.) Michail? I read on the olpc wiki about the mesh using three different channels. My understanding on this is that these pretty much generate three separate mesh networks that are routed between by the school server, and that laptops can end up on any channel. Right. We have only one radio in the laptops, and therefore we can only tune to one channel at a time. However, having all laptops on one channel would be detrimental from a bandwidth perspective, since all laptops share the bandwidth of the channel, which isn't large (54Mbps but that's certainly not seen in the real-world). Does this mean that two laptops next to each other can be on two completely different networks? This means broadcasts (and by extension Yes. But if they are at school, then you'll be able to see that person because you'll both be connected to the school server. We only (ideally) run into problems when one or the other laptop can't connect to the school server, and they are on different channels. Avahi) cannot reach from one laptop to the other. Is this true? And are we doing something to work around this (like letting users manually switch channels)? We are letting users manually search for friends, which is a fairly lengthy process that involves jumping to each channel, searching for friends and activities using mDNS, then to the next channel, etc. You'll be warned if you do something that will make you jump to a different channel, and therefore break stuff. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Ivan's XO Field Upgrade Proposal
On Tue, 2007-06-26 at 12:16 -0400, C. Scott Ananian wrote: On 6/26/07, Dan Williams [EMAIL PROTECTED] wrote: Downside of this is, as Alex pointed out, it'll load the mesh a _lot_ more than XO-XO updates. Not necessarily. Rsync is pretty efficient: we're still basically distributing just (blockwise) diffs. And we can always do XO-to-XO later: the important thing is to get a rock-solid basis. The selling point (to me) is the simplicity. Like I said: its the simplest thing that works. I'm not arguing simplicity; just that we have to be aware of the implications of having lots of XOs pulling from the server with some overlap with this method, but we don't with XO-XO. We just have to make the tradeoffs clear, and understand them. Dan I can do some benchmarks if people actually need to see numbers. --scott ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh network vs broadcast/multicast question
On Tue, 2007-06-26 at 17:10 -0400, Frank Ch. Eigler wrote: Hi - On Tue, Jun 26, 2007 at 04:49:40PM -0400, Dan Williams wrote: [...] Does this mean that one needs a school server/bridge in order to talk to two differently-channeled friends ? Yes. You must spread the XOs between channels to maximize the overall system bandwidth [...] Is it obvious that this benefit (increased aggregate bandwidth) is worth the cost (the necessity for a special bridge - possibly hamstringing an ad-hoc mesh away from the schoolhouse)? How bandwidth-hungry are common XO activities anyway? It depends, but packing 50 normal laptops onto a single radio channel _today_ with infrastructure APs doesn't really work well, especially when they all start to talk. We're likely to have that many laptops in a single classroom, and when you get a couple classrooms next each other... Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[PATCH] xf86-amd-devel: fix lx Xv downscaling
Try #2.
diff --git a/src/amd_lx_video.c b/src/amd_lx_video.c
index e1e51aa..a4cd91b 100644
--- a/src/amd_lx_video.c
+++ b/src/amd_lx_video.c
@@ -365,6 +365,7 @@ LXDisplayVideo(ScrnInfoPtr pScrni, int id, short width,
short height,
unsigned long yExtra, uvExtra = 0;
DF_VIDEO_POSITION vidPos;
DF_VIDEO_SOURCE_PARAMS vSrcParams;
+ int err;
memset(vSrcParams, 0, sizeof(vSrcParams));
@@ -401,16 +402,14 @@ LXDisplayVideo(ScrnInfoPtr pScrni, int id, short width,
short height,
/* Set up scaling */
df_set_video_filter_coefficients(NULL, 1);
-
- if ((drawW = srcW) (drawH = srcH))
-df_set_video_scale(width, height, drawW, drawH,
- DF_SCALEFLAG_CHANGEX | DF_SCALEFLAG_CHANGEY);
- else if (drawW srcW)
-df_set_video_scale(drawW, height, drawW, drawH,
- DF_SCALEFLAG_CHANGEX | DF_SCALEFLAG_CHANGEY);
- else if (drawH srcH)
-df_set_video_scale(width, drawH, drawW, drawH,
- DF_SCALEFLAG_CHANGEX | DF_SCALEFLAG_CHANGEY);
+
+ err = df_set_video_scale(width, height, drawW, drawH,
+DF_SCALEFLAG_CHANGEX | DF_SCALEFLAG_CHANGEY);
+ if (err != CIM_STATUS_OK) {
+/* Note the problem, but do nothing for now. */
+ErrorF(Video scale factor too large: %dx%d - %dx%d\n,
+ width, height, drawW, drawH);
+ }
/* Figure out clipping */
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [PATCH] xf86-amd-devel: fix lx Xv downscaling
On Mon, 2007-06-25 at 17:21 -0400, Bernardo Innocenti wrote: Dan Williams wrote: Try #2. Does ti fix http://dev.laptop.org/ticket/1601 perhaps? _maybe_, but this was tested on Xorg 1.1.99, so there may be more stuff with 1.3 that's broken. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
