On Thu, May 28, 2009 at 1:55 AM, Jouni Malinen <j@xxxxx> wrote: > On Wed, May 27, 2009 at 04:30:17PM -0700, Andrey Yurovsky wrote: >> With today's wireless-testing, bring up an ath9k mesh point locks up >> my test laptop (single CPU) but I don't get any messages (/proc/sysrq >> set to 9, unfortunately I can't use a serial console right now). > > I don't see a full lockup with two cores, but "ifconfig mesh0 up" > process ends up in some kind of unkillable state eating all CPU.. I > would assume this could be the same issue that just happens to show up > more severe with a single CPU. > > dmesg is not showing anything else apart from "mesh: running mesh > housekeeping" popping up every 60 seconds. Pretty much all networking > commands hang (rtnl lock held?) after that, though. After some while, > hung task debugging does indeed start popping up messages that show > rtnl_mutex held, so that's why the system is getting quite unusable. > > Anyway, I don't know what exactly is killing the mp setup (or well, not > exactly killing, but more like causing a busy loop somewhere) or whether > it has anything to do with the driver, but at least this one seems to be > trivial to reproduce: > > modprobe ath9k > iw phy phy0 interface add mesh0 type mp mesh_id foo > ifconfig mesh0 up > > -- > Jouni Malinen PGP id EFC895FA > Thanks. For what it's worth, substituting rt2x00 for ath9k works (ie: one can bring up a mesh) on the same kernel, so it likely has something to do with the driver. -Andrey -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
