On Wed, Feb 22, 2012 at 02:37, Norbert Preining [off-list ref] 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:

quoted

quoted

On Fr, 27 Jan 2012, Norbert Preining wrote:

quoted

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