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 Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel