linux-kernel - RE: 3.4-rc2, ilwagn still most of the time completely unusable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 25 Apr 2012 01:06:17 +0000
From:	"Venkataraman, Meenakshi" <meenakshi.venkataraman@...el.com>
To:	Norbert Preining <preining@...ic.at>
CC:	Emmanuel Grumbach <egrumbach@...il.com>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"ipw3945-devel@...ts.sourceforge.net" 
	<ipw3945-devel@...ts.sourceforge.net>,
	"ilw@...ux.intel.com" <ilw@...ux.intel.com>
Subject: RE: 3.4-rc2, ilwagn still most of the time completely unusable

Hey Norbert,

>WIth that turned off I *believe* I have better results, but I will tet
>it a bi tmore.

[MV] How is this looking now?

>> I don't see the invalid station activation error in the log you sent me, so I'm
>guessing it appears only on the other network. Do send us logs for that.
>
>Now I got one ....
>	http://www.logic.at/people/preining/syslog-debug.bz2
>take care, unpacked it is big!

[MV]  I'm going through this log -- don't have a root cause for this yet, but getting closer to it. I see in this log that authentication is timing out. It appears that the driver sent out the authentication frame, and received some frame OTA, but I can't tell what it received from just the dmesg log. I'd like some trace-cmd logs from you. Is it possible for you to collect a trace-cmd log and send over the binary to me?

>One more thing, I believe that this happens most of the times
>(but not necessarily exclusively, but I don't have statistics)
>after resume (from suspend to ram).

[MV]  This is good to know. I wonder if this is related to the PCIe l used on your platform. Can you try to use PCIe link state management to L0s in your BIOS and see if the stability of your system improves?

>>So saying, it seems that with power_save=0 even if I get several of
>these:
>[ 1601.552069] tx session timer expired on tid 0
>[ 1601.552116] Tx BA session stop requested for 00:24:c4:ab:bd:e0 tid 0
>[ 1601.576292] Stopping Tx BA session for 00:24:c4:ab:bd:e0 tid 0
>[ 1603.470312] Open BA session requested for 00:24:c4:ab:bd:e0 tid 0
>[ 1603.480274] activated addBA response timer on tid 0
>[ 1603.483479] switched off addBA timer for tid 0
>[ 1603.483485] Aggregation is on for tid 0
>the connection does not break down, as before. Well, I am not sure whether
>it is a consequence or coincidence.

[MV] the tx session timer expiry ... hmm... I haven't looked at it. Otherwise, it seems to be Tx Aggregation sessions being turned on and turned off, so perhaps we will reduce the debug level at which it is printed. One of us is looking at the frequency with which these messages are being reported.

Thanks,
Meenakshi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/