Testing the Wireless driver changes

[Ricardo Carrano]

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 <dcbw at redhat.com> 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 <kim at laptop.org> 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 at lists.laptop.org
> > http://lists.laptop.org/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080116/5c2c62e1/attachment.html>