On Sunday, 1 of June 2008, Michael Buesch wrote:
On Sunday 01 June 2008 02:40:33 Stefanik Gábor wrote:
Looks like we are losing track of the microcode. The driver thinks
it's loaded, but in fact it isn't. Maybe we should reupload the
microcode on resume.
We already do this, of course.
On Sunday 01 June 2008 02:40:33 Stefanik Gábor wrote:
Looks like we are losing track of the microcode. The driver thinks
it's loaded, but in fact it isn't. Maybe we should reupload the
microcode on resume.
We already do this, of course.
--
Greetings Michael.
On Sunday 01 June 2008 13:47:22 Rafael J. Wysocki wrote:
On Sunday, 1 of June 2008, Michael Buesch wrote:
On Sunday 01 June 2008 02:40:33 Stefanik Gábor wrote:
Looks like we are losing track of the microcode. The driver thinks
it's loaded, but in fact it isn't. Maybe we should reupload
On Sunday 01 June 2008 15:18:39 Rafael J. Wysocki wrote:
On Sunday, 1 of June 2008, Michael Buesch wrote:
On Sunday 01 June 2008 13:47:22 Rafael J. Wysocki wrote:
On Sunday, 1 of June 2008, Michael Buesch wrote:
On Sunday 01 June 2008 02:40:33 Stefanik Gábor wrote:
Looks like we are
Quoting Johannes Berg [EMAIL PROTECTED]:
info-control.hw_key is NULL.
Is a NULL pointer supposed to tell do not encrypt, or is this a
mac80211 bug?
It's probably a bug.
I've bisected it to commit 57ccbb1cbe3f8e10a500ff8b9fb26dc1a542fe99:
mac80211: move TX info into skb-cb
It turns out
On Mon, 2008-06-02 at 00:08 -0400, Pavel Roskin wrote:
wep_encrypt_skb() in wep.c would not return TX_CONTINUE. But most
importantly, there is a suspicious change in wep_encrypt_skb() - the
key is set in the other branch of the condition.
I'll try to restore the original logic in
