Jonathan, Thanks for chipping in on this, much appreciated. And thanks to Ben for picking up on the dialogue and helping move things forward.
[ . . . ] > It's possible there's a kernel bug nearby, but the symptom would have > to be something other than crashing a router. :) If this were some > router firmware packaged for Debian, then we'd assign it to that > package and track it that way. As it is, please feel free to ask > questions on linux-ker...@vger.kernel.org if you get to a point where > the kernel's behavior is mysterious and think that could help tracking > this down. I guess some of my irritation and grumpiness is that the Netgear uses a Linux kernel and I am running the latest version of the firmware in it -- the one update available over original purchase is NA, North America only. Given the non-entirely-open nature of the iwlagn and related bits, I would have thought Intel and Netgear folk would be somewhat alarmed by this failure of one of their primary consumer products and wanting to hear of such things. I appreciate Debian people are not going to be able to do much about this per se, but I would have though helping to redirect my bug report to the right forum so as to put pressure on folk who can do something would have been a better approach than simply closing the bug. I do appreciate that Debian folk are all volunteers, triaging is tough, and there is never enough time. I wonder though if there is a way of being able to channel reports such as this so that the right folk get them? > Another useful tool is "git bisect", which you might want to try in > order to find out what kernel behavior change triggered this. I suspect this level of investigation is beyond my current knowledge and time availability. Doing black-box experiments is relatively easy and quick. Sadly I can't see me getting and compiling kernels at this time. Sorry about that, but best to be honest. > Anyway, whoever debugs this will have to understand what the router > does. And looking at and modifying the source is a whole lot more > pleasant than reverse-engineering, so that will probably be someone on > Netgear's end. Perhaps after investigation they will be able to say > if there is an easy workaround on the kernel side. This clearly needs someone from Netgear and/or Intel since, as of now, the problem could be in the Netgear or in the iwlagn subsystem on the laptops. Clearly there has been some change in the iwlagn system between 2.6.38 and 2.6.39 that is causing the problem to exhibit. There is definitely a problem in the Netgear in that it should not crash, it should deal with the problem in a user friendly way. It is though undeniable that there has been a change in the iwlagn subsystem that is not compatible with the extant Netgear equivalent -- which leads one to think of a alteration in the interpretation of the protocol, but I am speaking form a position of deep ignorance of this sort of stuff. > Sorry for the trouble. Thanks for that. It renews my desire to try and find the right place to put the information so something can be done, and done quickly. Must go do g&b test . . . Thanks. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part