On Wed, Feb 22, 2012 at 02:37, Norbert Preining <preining@xxxxxxxx> wrote: > > Hi Emmanuel, > > sorry to come back soo late to that matter ... I was *really* busy > with real work. > > On Do, 26 Jan 2012, Emmanuel Grumbach wrote: > > > > > > On Fr, 27 Jan 2012, Norbert Preining wrote: > > >> First tests are promising, after reboot it was working immediately > > >> without need to rfkill block/unblock. lso after suspend and resume. > > >> > > >> Will test more the next days and report back. > > > > > > Unfortunately, at the university it is still a complete no-go. > > > Usually the connection works for a short time, then breaks down. > > > After that even unloading and loading the module did not reactivate > > > it, I cannot get a connection at all. But other units, or with > > > older kernel (it was 2.6.3X AFAIR) it was working without a glitch. > > > > > > I uploaded a syslog output including kernel and network manager logs > > > to > > > http://www.logic.at/people/preining/syslog.log > > > (new one). This shows a session from loading the module up to giving > > > up. > > > > > > > I glanced at the logs, and they look healthy from the wifi driver > > side. You just don't get any reply to DHCP_DISCOVER apparently... can > > you get a sniffer ? > > I am pretty sure that the packet in sent in the air, but if you can > > get a capture of that we could check that out. > > I still see that, on 3.3-rc4, and it is the same as usual. The interface > believes it is up and connected, but nothing works. > > I am *100%* sure that this is related to the driver, because in old > revisions (somewhen around 2.6.27 or so) it was working without > any problem, and when it started I reported it long time ago. > > Anyway, today it was really hopeless again, and the exact time it always > hangs is when the kernel driver spits out: > Rx A-MPDU request on tid 0 result 0 > and with debugging on I get in addition: > ieee80211 phy3: release an RX reorder frame due to timeout on > earlier frames > that is where it all goes down the gully, without any reaction from the > outside world suddenly. Before ping was running, then off. > > I uploaded a new syslog.log in the above location that shows 5 min > or so of trial and error. >From the log, I can see that we have a lot of "passive channel failures". Can you try to disable 11n (module_parameter) ? Please also try with debug=0xc0000000 -- 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