Re: Testing the Wireless driver changes
Dan, Do we have a description of the dbus API for the XO NM implementation somewhere? [Like the one in: http://people.redhat.com/dcbw/NetworkManager/NetworkManager%20DBUS%20API.txt ] Thank you! Carrano On Jan 17, 2008 6:24 PM, Dan Williams [EMAIL PROTECTED] wrote: On Thu, 2008-01-17 at 14: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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: Testing the Wireless driver changes
After downloading the firmware, the ARM is told by the boot2 to jump to a specific location of the internal memory. If the firmware is not downloaded, the boot2 starts the grab the firmware from the Flash and jumps to the same location of the internal memory once that is done. The flash tool does not figure out anything here. The boot2 code is smart enough to figure that out. Best Regards, Ronak From: Michail Bletsas [mailto:[EMAIL PROTECTED] Sent: Saturday, January 19, 2008 10:23 AM To: Dan Williams; Ronak Chokshi Cc: Ricardo Carrano; devel; David Woodhouse; Giannis Galanis; [EMAIL PROTECTED] Subject: Re: Testing the Wireless driver changes Does the Boot2 code take care of figuring out the correct address to write the thick firmware to, or does the flash tool have to figure out the address to write it to? Normally this address 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, You have to ask Ronak that. Right now the flash writing logic lives in the firmware. M. ___ 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
Dan Williams [EMAIL PROTECTED] wrote on 01/19/2008 12:48:06 PM: Hmm, ok... So all the external USB 8388 dongles have a larger SPI flash to contain both the Boot2 code and the 100K thick firmware? yes, M.___ Devel mailing list Devel@lists.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 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. 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... -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
Michail, This would be 3107, right ? 3109 is when we started seeing the auto-update mode. John On Jan 18, 2008, at 4:22 PM, David Woodhouse wrote: On Fri, 2008-01-18 at 15:50 -0500, Michail Bletsas wrote: Ideally, we want to just kill the auto-mesh-repeater mode, where boot2 times 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, that is all that is needed to disable autoboot on the active antennas. OK, that's the plan for the Mongolia deployment then. Wad, please can you confirm (with libertas-flash.py) and forward me the current (XO) version of Boot2, so I can do that? Thanks. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
John Watlington [EMAIL PROTECTED] wrote on 01/18/2008 04:56:26 PM: Michail, This would be 3107, right ? 3109 is when we started seeing the auto-update mode. Yes, M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
On Fri, 2008-01-18 at 16:56 -0500, John Watlington wrote: Michail, This would be 3107, right ? 3109 is when we started seeing the auto-update mode. OK, so can we go between 3109 and 3107 in both directions using libertas-flash.py or did the protocol get changed without telling us? We never did get Marvell's 'firmware update' patch for the driver to apply to the kernel they claim it applies to, did we? -- dwmw2 ___ 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 15:50 -0500, Michail Bletsas wrote: Ideally, we want to just kill the auto-mesh-repeater mode, where boot2 times out after 5 seconds and loads the firmware from the internal flash (which is obviously larger on these devices than on the XO). Can we achieve that just by updating to a 'normal' Boot2 version from the XO? Yes, that is all that is needed to disable autoboot on the active antennas. OK, that's the plan for the Mongolia deployment then. Wad, please can you confirm (with libertas-flash.py) and forward me the current (XO) version of Boot2, so I can do that? Thanks. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
David Woodhouse [EMAIL PROTECTED] wrote on 01/18/2008 03:31:08 PM: Ideally, we want to just kill the auto-mesh-repeater mode, where boot2 times out after 5 seconds and loads the firmware from the internal flash (which is obviously larger on these devices than on the XO). Can we achieve that just by updating to a 'normal' Boot2 version from the XO? Yes, that is all that is needed to disable autoboot on the active antennas. M. ___ 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 14:47 -0500, Dan Williams wrote: So wait, what's going on here? I thought the devices attached to school servers were just run-of-the-mill USB 8388 devices like the 8388 daughterboard of the XO, but different connector, right? What is the post-boot firmware flash functionality supposed to apply to, the host-less active antenna? (which is what I heretofore had understood). These two are the same device (active antenna). The device behaves differently depending on whether it detects a USB link on startup. --Ben ___ 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 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. 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). -- dwmw2 ___ 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
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. M. ___ 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
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? -- These are my opinions, not necessarily my employer's. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
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
Re: Testing the Wireless driver changes
Hal Murray wrote: When it comes to our radio - we *designed it* to start forward frames soon after you initialize it and keep doing it regardless of what the host interface does. In the context of making the radio safe to use on airplanes... Does the firmware turn the radio on at boot time? OFW turns on the radio only if the need arises, i.e. if you are trying to boot from the wireless network. Does your initialize above mean firmware level or OS level? ___ 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
I apologize if I am over simplifying: - mesh stop was considered when we had compatibility issues with lazy-wds routers. We addressed this, right? Do we still need this feature? Michail? - For airplane mode or relatives, we need to shut up radio (any traffic). On Jan 17, 2008 5:05 PM, Dan Williams [EMAIL PROTECTED] wrote: On Thu, 2008-01-17 at 13:30 -0500, Michail Bletsas wrote: Hal Murray [EMAIL PROTECTED] wrote on 01/17/2008 12:55:47 PM: When it comes to our radio - we *designed it* to start forward frames soon after you initialize it and keep doing it regardless of what the host 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). Sigh. There are two issues that you're not sufficiently separating: 1) Whether the mesh is enabled/disabled at Layer 2. This has nothing to do with the ethX device and is a completely orthogonal problem. (or if it _does_ have any user-visible interaction with the ethX device that's a total layering violation, and somebody needs to be taken behind the woodshed and shot) 2) Whether the radio is on/off at Layer 1. This affects _both_ the ethX device and the mshX device. There are acceptable, upstreamable solutions for both of these problems. Solution for #1: up/down on the mshX device; if the mshX device is marked !IFF_UP, the mesh functionality should probably be disabled. The 8388 can keep the state and forwarding/blinding tables around until poweroff/reset, but it should simply stop handling any mesh frames at this point. This can certainly be implemented with a CMD_802_11_MESH_CONTROL firmware command _in_the_driver_, but there's no need for another iwpriv just to achieve the same thing that up/down already can do. Then modify NM and system scripts to never down the mesh device except in correct circumstances. Solution for #2: already exists with 'iwconfig iface txpower off' and 'iwconfig iface txpower auto'. -- The other discussion to have is what should the default radio state be in. If the default state is OFF until it's explicitly turned on by NetworkManager or the user, then: a) it should be verified that the firmware doesn't turn the radio on until told to do so b) it should be verified that the driver doesn't turn the radio on until the device is brought up (ifconfig eth0 up) c) it should be verified that nothing in the host OS (startup scripts like the 'network' service calling ifup or NetworkManager bring the device up) until the point at which the user has explicit control Note that this approach would not be conducive to a nice exploratory out-of-box experience (hence I don't really condone this approach wholeheartedly) where access points and friends are immediately visible from the Mesh view, until you explain to 5 year olds what the heck wireless is and why it's off-by-default in the first place. People traveling in RF-prohibited environments should be the ones who bear the burden of turning off the RF, since not too many of the target audience is going to ever be flying on a plane or driving by a blasting site. Plus those people who are flying on planes likely already know that they _need_ to turn off the wireless component, which isn't likely to be known by the 5 - 10 year old children in Peru who may never been near an airplane anyway. Dan ___ 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
Indeed we had this airplane mode discussion two weeks ago: Why don't we? --- To completely silence the radio: #!/bin/bash rmmod usb8xxx mv /lib/firmaware/usb8883.bin /lib/firmaware/usb8883.bin.quiet It will survive reboots. --- To bring it back: #!/bin/bash mv /lib/firmaware/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
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
For airplane mode, is there some command OFW can run to make the whole eth/msh device poweroff and disappear until the next powercycle? If so, maybe we could hook another key check into /boot/olpc.fth? -Bennett pgps5csES4LCD.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
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.) mikus ___ 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 Thu, 2008-01-17 at 12:32 -0500, Michail Bletsas wrote: There is an iwpriv eth0 radiooff/radioon IOCTL hook in the firmware which was meant to control the radio power directly - it was removed a few months ago since it wasn't considered to its thing in the proper linux manner. I looked for it and I couldn't find it. Please could you point me at the commit in which it was removed? I'm not entirely sure it ever made it into our driver. Certainly it never made it into the upstream driver, and the upstream driver is all that really matters, in the long term. ** I don't know how iwconfig eth0 txpower off is implemented, if it uses the same IOCTL with iwpriv eth0 radiooff, then it is doing the right thing. It uses CMD_802_11_RADIO_CONTROL with the RADIO_OFF argument, which I believe is the correct thing to do. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
I see. But i hope this is not done only because of the airline issue, and that there are other reasons that it useful to boot with firmware unloaded. Because as far as the airline issue is concerned, we should not take it tooo seriously. As long as we have a working solution it is fine. Not many people will use it anyway. U see my point? Also, if it is smth simple we can quickly implement is for Update.1. On Jan 17, 2008 7:36 PM, David Woodhouse [EMAIL PROTECTED] 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. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
Let's not forget the dongles that act as dumb repeaters on their own, based on their firmware. Are they gonna use a different firmware instead? p. David Woodhouse wrote: We should change the firmware so that it isn't active automatically as soon as it's loaded -- let the driver activate it 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. -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
David Woodhouse [EMAIL PROTECTED] wrote on 01/17/2008 06:26:38 PM: It uses CMD_802_11_RADIO_CONTROL with the RADIO_OFF argument, which I believe is the correct thing to do. If that's the case then it does the right thing - no need to worry with the earlier iwpriv call. M.___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
[EMAIL PROTECTED] wrote on 01/17/2008 02:17:44 PM: I apologize if I am over simplifying: - mesh stop was considered when we had compatibility issues with lazy-wds routers. We addressed this, right? Do we still need this feature? Michail? The only reason to have this, is for debugging puproses - For airplane mode or relatives, we need to shut up radio (any traffic). and to be able to completely silence the radio in airplane mode. M. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
Yani,
On the msh0_rename interface:
http://dev.laptop.org/ticket/5746
-- RC
On Jan 15, 2008 10:29 PM, Giannis Galanis [EMAIL PROTECTED] wrote:
David,
There are a couple of issues i would like to address, mostly related to
the new wireless driver.
First, the netstat command:
About 50% of 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.
For example,
what is the situation with mesh on or off
is the mesh-start file still in use
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
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
IMHO, there is no point in investing time in mesh stop/start now (or any
time in the future unless there is a strong reason for that - which we lack
now).
On Jan 16, 2008 1:48 PM, Dan Williams [EMAIL PROTECTED] wrote:
On Tue, 2008-01-15 at 19:29 -0500, Giannis Galanis wrote:
David,
There 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
Re: Testing the Wireless driver changes
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...;-) M. ___ 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
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 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: Testing the Wireless driver changes
On Jan 16, 2008 2:46 PM, Dan Williams [EMAIL PROTECTED] wrote: On Wed, 2008-01-16 at 20:22 -0200, Ricardo Carrano wrote: I believe what you want is radio off, not mesh stop. radio off == iwconfig eth0 txpower off that's always been around from day #1. That turns off the radio for this session. How do you disable it so it doesn't come on at the next boot? -- 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
Is this related to Wodehousian? :) - Jim On Wed, 2008-01-16 at 15:15 -0500, Dan Williams wrote: On Wed, 2008-01-16 at 15:11 -0500, Michail Bletsas wrote: Dan Williams [EMAIL PROTECTED] wrote on 01/16/2008 10:48:13 AM: There's a long explanation for that, but 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 -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Testing the Wireless driver changes
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.
For example,
what is the situation with mesh on or off
is the mesh-start file still in use
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
