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).<br><br><div class="gmail_quote">On Jan 16, 2008 1:48 PM, Dan Williams <

<a href="mailto:dcbw@redhat.com">dcbw@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="Wj3C7c">

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:

<br>> About 50% of the time it becomes very slow(practically freezes) and<br>> spews a "getnameinfo error".<br>> The result from strace is:<br>> ---------------<br>> .....<br>> socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4

<br>> connect(4, {sa_family=AF_INET, sin_port=htons(53),<br>> sin_addr=inet_addr("<a href="http://172.18.0.1" target="_blank">172.18.0.1</a>")}, 28) = 0<br>> fcntl64(4, F_GETFL)                     = 0x2 (flags O_RDWR)

<br>> fcntl64(4, F_SETFL, O_RDWR|O_NONBLOCK)  = 0<br>> gettimeofday({1200442106, 340565}, NULL) = 0<br>> poll([{fd=4, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1<br>> send(4, "\270\227\1\0\0\1\0\0\0\0\0\0\1e\0017\1c\1e\1c\0010\1e\1f\1f

<br>> \1f"..., 90, MSG_NOSIGNAL) = 90<br>> poll( <unfinished ...><br>> ----------------<br>> It seems(according to Bernie)..that netstat makes queries to the DNS<br>> server but it is temporarily down. Still if you execute the command a

<br>> couple of time it works again, but is a very regular phenomenon. This<br>> should be a network issue, and not a driver issue, but can you confirm<br>> that?<br>><br>> Also, the msh0 interface is named after msh0_rename. Is there a reason

<br>> for that? Will this change back to normal in the future? How will it<br>> be in Update1?. This inconsistency causes some issues in the<br>> olpc-netstatus command utility.<br>><br>> Can you also please describe the changes from the user's perspective

<br>> that are changed/improved in the new driver. So we know were to start<br>> testing from.<br><br></div></div>The original problem the rewrite was fixing was hanging in the driver.<br>There's a long explanation for that, but the short one is that the

<br>driver should no longer periodically run around in circles screaming,<br>then have an arterial hemorrhage, and collapse on the ground spurting<br>blood from it's ears.  You may have noticed this when doing iwconfig

<br>commands that just never completed, or took 2 or 3 minutes to complete,<br>during which time the driver was in the afore-mentioned state.<br><br>This state could manifest itself as weird NetworkManager errors, network

dropouts, and just plain unexplained network flakiness. <div class="Ih2E3d"> > For example, > what is the situation with mesh on or off </div>There isn't any user-facing control for that at this time AFAIK.

<br>mbletsas wanted some user knob for this.  The situation I'd expect is<br>that the mesh device would go away (a device hotplug event) and<br>NetworkManager wouldn't expose the mesh device at all.  When the mesh

<br>was turned back on, the mesh device would be hotplugged back and NM<br>would magically notice it just like it does when you plug in some other<br>USB network device.<br><br>There's no way that NetworkManager is going to poll the mesh device with

<br>iwpriv for whether it's on or off (that's just so wrong), so mbletsas<br>and woodhouse have to find a method they agree on that doesn't require<br>polling to figure out if mesh is on or off.  That may mean having the

<br>iwpriv mesh on/off knob also apply to the eth device, so that you can<br>turn mesh off by doing:<br><br>iwpriv eth0 mesh off<br>iwpriv msh0 mesh off<br><br>and you'll get the same behavior, and then you do<br><br>

iwpriv eth0 mesh on<br><br>to turn it back on, and using the normal Linux device hotplug stuff.  I<br>think mbletsas has historically disliked having to manipulate other<br>devices than the mesh device to actually affect changes on the mesh

<br>device, but that's life.<br><div class="Ih2E3d"><br>> is the mesh-start file still in use<br><br></div>Yes, since the mesh-start file is something from NetworkManager and not<br>driver related.<br><br>Dan<br><div class="Ih2E3d">

<br>> are improvements related to 4470<br>><br>> thanx,<br>><br>> yani<br>><br>><br>><br>> On Jan 15, 2008 6:40 PM, Kim Quirk <<a href="mailto:kim@laptop.org">kim@laptop.org</a>> wrote:<br>

>         David,<br>>         Yani is back from his time off and finished with his exams (at<br>>         least for now). Before the new year break, he had been working<br>>         on testing, documenting and debugging issues mostly associated

<br>>         with avahi and telepathy, but also with wireless. He and<br>>         Ricardo have been our wireless test experts.<br>><br>>         Now that he is back, it would be great if you and Michail can<br>

>         provide some thoughts on the highest priority testing that we<br>>         should do here or at Michail's house (for a little more<br>>         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.

<br>><br>><br>>         Thanks,<br>>         Kim<br>><br></div>> _______________________________________________<br>> Devel mailing list<br>> <a href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org

</a><br>> <a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a><br><br></blockquote></div><br>