Since Linus released 4.7-rc1 today, I've resumed wireless-testing
updates since its merge window hiatus, with tag wt-2016-05-29.
Please test and let me know of any issues.
--
Bob Copeland %% http://bobcopeland.com/
Today I compiled 4.6+ and pulled sources today
iwlwifi isn't super smooth.
[ 112.345457] wlp4s0: authenticate with 00:30:44:1d:cf:2b
[ 112.349002] wlp4s0: send auth to 00:30:44:1d:cf:2b (try 1/3)
[ 112.349647] wlp4s0: authenticated
[ 112.352456] wlp4s0: associate with 00:30:44:1d:cf:2b (try 1/3)
[ 112.353764] wlp4s0: RX AssocResp from 00:30:44:1d:cf:2b (capab=0x11
status=0 aid=3)
[ 112.355035] wlp4s0: associated
[ 112.355393] IPv6: ADDRCONF(NETDEV_CHANGE): wlp4s0: link becomes ready
[ 118.616327] wlp4s0: deauthenticated from 00:30:44:1d:cf:2b (Reason:
15=4WAY_HANDSHAKE_TIMEOUT)
[ 128.673812] wlp4s0: authenticate with 00:30:44:1d:cf:2b
[ 128.676997] wlp4s0: send auth to 00:30:44:1d:cf:2b (try 1/3)
[ 128.677648] wlp4s0: authenticated
[ 128.678691] wlp4s0: associate with 00:30:44:1d:cf:2b (try 1/3)
[ 128.679807] wlp4s0: RX AssocResp from 00:30:44:1d:cf:2b (capab=0x11
status=0 aid=3)
[ 128.681198] wlp4s0: associated
I never experienced the 4 way handshake 802.11i timeout in my home setup.
With other setups plenty of times, especially with mediatek drivers. :)
If you wish I can sniff and see which side is at fault.
Thanks,
Reinoud.
On Sun, May 29, 2016 at 3:40 PM, Bob Copeland <[email protected]> wrote:
> Since Linus released 4.7-rc1 today, I've resumed wireless-testing
> updates since its merge window hiatus, with tag wt-2016-05-29.
>
> Please test and let me know of any issues.
>
> --
> Bob Copeland %% http://bobcopeland.com/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2016-06-02 at 02:02 -0600, Reinoud Koornstra wrote:
> On Wed, Jun 1, 2016 at 10:27 PM, Coelho, Luciano
> <[email protected]> wrote:
> > On Wed, 2016-06-01 at 16:08 -0600, Reinoud Koornstra wrote:
> > > On Wed, Jun 1, 2016 at 7:19 AM, Coelho, Luciano
> > > <[email protected]> wrote:
> > > > On Wed, 2016-06-01 at 08:54 -0400, Bob Copeland wrote:
> > > > > + Luca, Emmanuel
> > > >
> > > > Thanks, Bob!
> > > >
> > > >
> > > > > On Tue, May 31, 2016 at 10:06:57PM -0600, Reinoud Koornstra
> > > > > wrote:
> > > > > > Today I compiled 4.6+ and pulled sources today
> > > > > > iwlwifi isn't super smooth.
> > > > >
> > > > > I assume you mean wireless-testing, based on 4.7-rc1 (as this
> > > > > email
> > > > > is
> > > > > in reply to my announcement of same).
> > > >
> > > > Yes, we need to know exactly what kernel you're using so we know
> > > > what
> > > > we're debugging.
> > > >
> > >
> > > Yesterday this is what I did to obtain the latest source:
> > >
> > > git clone
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > > kernel_current
> > >
> > > This is the latest commit in that tree:
> > >
> > > commit 367d3fd50566a313946fa9c5b2116a81bf3807e4
> > > Merge: 5eca831 cf0d44d
> > > Author: Linus Torvalds <[email protected]>
> > > Date: Tue May 31 09:43:24 2016 -0700
> > >
> > > Merge branch 'for-linus' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
> > >
> > > Pull s390 fixes from Martin Schwidefsky:
> > > "Three bugs fixes and an update for the default configuration"
> > >
> > > * 'for-linus' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
> > > s390: fix info leak in do_sigsegv
> > > s390/config: update default configuration
> > > s390/bpf: fix recache skb->data/hlen for skb_vlan_push/pop
> > > s390/bpf: reduce maximum program size to 64 KB
> >
> > Ah, okay. This has nothing to do with the wireless-testing tree. This
> > is random commit in Linus' tree. I suggest that you use a release tag
> > or such. For instance you could do this in Linus' tree to get the
> > current release candidate for 4.7:
> >
> > git checkout v4.7-rc1
> >
> > Or you could use the wireless-testing tree that Bob is maintaining,
> > which is always based on an official release candidate (currently the
> > above mentioned v4.7-rc1 release) plus the latest and greatest (and
> > probably "brokenest" :P) wireless changes:
> >
> > git clone git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-testing.git
> >
>
> Ok, i got this tree.
> From the start it didn't work.
>
> [ 0.000000] Linux version 4.7.0-rc1-wt+
> [SNIP]
> [ 2.156875] iwlwifi 0000:04:00.0: Direct firmware load for
> iwlwifi-7260-17.ucode failed with error -2
> [ 2.157681] iwlwifi 0000:04:00.0: Direct firmware load for
> iwlwifi-7260-16.ucode failed with error -2
> [ 2.158438] iwlwifi 0000:04:00.0: no suitable firmware found!
This is happening pretty early, did you compile the iwlwifi driver into
the kernel (instead of compiling them as modules)? There have been
problems when it's in-kernel, so we recommend that you compile them as
modules (unless strictly necessary).
> I've attached the dmesg in it's entirety.
> Booting back to 4.6:
>
> [ 17.987698] iwlwifi 0000:04:00.0: loaded firmware version
> 16.242414.0 op_mode iwlmvm
> [ 18.269667] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band
> Wireless AC 7260, REV=0x144
This shows that you have iwlwifi-7260-16.ucode in your file system.
But here we are reading it much later. So it's possible that the
kernel cannot access the firmware at a very early stage (because the
filesystem that contains it is not mounted yet) when you use in-kernel.
So, first of all, please make sure they're built as modules. We can
continue from there then.
--
Cheers,
Luca.
On Thu, Jun 2, 2016 at 11:59 PM, Luca Coelho <[email protected]> wrote:
> On Thu, 2016-06-02 at 23:09 -0600, Reinoud Koornstra wrote:
>> On Thu, Jun 2, 2016 at 2:16 AM, Luca Coelho <[email protected]> wrote:
>> > This shows that you have iwlwifi-7260-16.ucode in your file system.
>> > But here we are reading it much later. So it's possible that the
>> > kernel cannot access the firmware at a very early stage (because
>> > the
>> > filesystem that contains it is not mounted yet) when you use in-
>> > kernel.
>> >
>> > So, first of all, please make sure they're built as modules. We
>> > can
>> > continue from there then.
>>
>> Your suggestion worked. When it's compiled as module, the
>> iwlwifi-7260-16.ucode loads fine.
>> No problems detected so far.
>
> Great! :)
It is. :)
I git pulled again and build it again.
This time with gcc 6.1.0
I couldn't find warning specific to iwlwifi with gcc 6, so that's great.
Didn't find anything worrysome yet, in addition I am running the cake
qdisc as well from Dave Taht.
objdump --full-contents --section=.comment vmlinux
vmlinux: file format elf64-x86-64
Contents of section .comment:
0000 4743433a 2028474e 55292036 2e312e30 GCC: (GNU) 6.1.0
0010 00
reinoud@router-dev:~/Downloads/wireless-testing$ objdump
--full-contents --section=.comment
/lib/modules/4.7.0-rc1-wt+/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko
/lib/modules/4.7.0-rc1-wt+/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko:
file format elf64-x86-64
Contents of section .comment:
0000 00474343 3a202847 4e552920 362e312e .GCC: (GNU) 6.1.
0010 30000047 43433a20 28474e55 2920362e 0..GCC: (GNU) 6.
[SNIP]
0180 28474e55 2920362e 312e3000 (GNU) 6.1.0.
>
>
>> It does make me think whether this is desired behavior though that
>> due
>> to the later reading we cannot have iwlwifi build in the kernel.
>
> It should work, but then you have to make sure the firmware is
> available at very early stages of boot. If you add it to the proper
> place in your initrd, the kernel should find it when the driver
> requests it.
>
> I didn't want to go into the details of this, because in most cases the
> best option is to have the driver as a module. If you really need it
> in-kernel, then you need to make sure all the needed pieces are
> available very early as well.
Ah, thanks, I'll study this as how to have it inside initrd at the right place.
Any pointers would be great.
Btw, I did build gcc 6.1.0 like this, if you have hints or ways I
should build it differently I would like to know.
reinoud@router-dev:~/Downloads/wireless-testing$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/reinoud/GCC/libexec/gcc/x86_64-linux-gnu/6.1.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../gcc-6.1.0/configure -v
--enable-languages=c,c++,go,fortran,objc,obj-c++
--prefix=/home/reinoud/GCC --enable-shared --enable-linker-build-id
--without-included-gettext --enable-threads=posix --enable-nls
--with-sysroot=/ --enab
le-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin
--with-system-zlib --disable-browser-plugin --with-arch-direct
ory=amd64 --enable-objc-gc --enable-multiarch --disable-werror
--with-abi=m64 --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.1.0 (GCC)
The --with-tune=skylake didn't work as it didn't know it. unfortunately.
>
> --
> Cheers,
> Luca.
Thanks,
Reinoud.
On Thu, 2016-06-02 at 23:09 -0600, Reinoud Koornstra wrote:
> On Thu, Jun 2, 2016 at 2:16 AM, Luca Coelho <[email protected]> wrote:
> > This shows that you have iwlwifi-7260-16.ucode in your file system.
> > But here we are reading it much later. So it's possible that the
> > kernel cannot access the firmware at a very early stage (because
> > the
> > filesystem that contains it is not mounted yet) when you use in-
> > kernel.
> >
> > So, first of all, please make sure they're built as modules. We
> > can
> > continue from there then.
>
> Your suggestion worked. When it's compiled as module, the
> iwlwifi-7260-16.ucode loads fine.
> No problems detected so far.
Great! :)
> It does make me think whether this is desired behavior though that
> due
> to the later reading we cannot have iwlwifi build in the kernel.
It should work, but then you have to make sure the firmware is
available at very early stages of boot. If you add it to the proper
place in your initrd, the kernel should find it when the driver
requests it.
I didn't want to go into the details of this, because in most cases the
best option is to have the driver as a module. If you really need it
in-kernel, then you need to make sure all the needed pieces are
available very early as well.
--
Cheers,
Luca.
T24gV2VkLCAyMDE2LTA2LTAxIGF0IDA4OjU0IC0wNDAwLCBCb2IgQ29wZWxhbmQgd3JvdGU6DQo+
ICsgTHVjYSwgRW1tYW51ZWwNCg0KVGhhbmtzLCBCb2IhDQoNCg0KPiBPbiBUdWUsIE1heSAzMSwg
MjAxNiBhdCAxMDowNjo1N1BNIC0wNjAwLCBSZWlub3VkIEtvb3Juc3RyYSB3cm90ZToNCj4gPiBU
b2RheSBJIGNvbXBpbGVkIDQuNisgYW5kIHB1bGxlZCBzb3VyY2VzIHRvZGF5DQo+ID4gaXdsd2lm
aSBpc24ndCBzdXBlciBzbW9vdGguDQo+IA0KPiBJIGFzc3VtZSB5b3UgbWVhbiB3aXJlbGVzcy10
ZXN0aW5nLCBiYXNlZCBvbiA0LjctcmMxIChhcyB0aGlzIGVtYWlsDQo+IGlzDQo+IGluIHJlcGx5
IHRvIG15IGFubm91bmNlbWVudCBvZiBzYW1lKS4NCg0KWWVzLCB3ZSBuZWVkIHRvIGtub3cgZXhh
Y3RseSB3aGF0IGtlcm5lbCB5b3UncmUgdXNpbmcgc28gd2Uga25vdyB3aGF0DQp3ZSdyZSBkZWJ1
Z2dpbmcuDQoNCj4gPiANCj4gPiBbwqDCoDExMi4zNDU0NTddIHdscDRzMDogYXV0aGVudGljYXRl
IHdpdGggMDA6MzA6NDQ6MWQ6Y2Y6MmINCj4gPiBbwqDCoDExMi4zNDkwMDJdIHdscDRzMDogc2Vu
ZCBhdXRoIHRvIDAwOjMwOjQ0OjFkOmNmOjJiICh0cnkgMS8zKQ0KPiA+IFvCoMKgMTEyLjM0OTY0
N10gd2xwNHMwOiBhdXRoZW50aWNhdGVkDQo+ID4gW8KgwqAxMTIuMzUyNDU2XSB3bHA0czA6IGFz
c29jaWF0ZSB3aXRoIDAwOjMwOjQ0OjFkOmNmOjJiICh0cnkgMS8zKQ0KPiA+IFvCoMKgMTEyLjM1
Mzc2NF0gd2xwNHMwOiBSWCBBc3NvY1Jlc3AgZnJvbSAwMDozMDo0NDoxZDpjZjoyYg0KPiA+IChj
YXBhYj0weDExDQo+ID4gc3RhdHVzPTAgYWlkPTMpDQo+ID4gW8KgwqAxMTIuMzU1MDM1XSB3bHA0
czA6IGFzc29jaWF0ZWQNCj4gPiBbwqDCoDExMi4zNTUzOTNdIElQdjY6IEFERFJDT05GKE5FVERF
Vl9DSEFOR0UpOiB3bHA0czA6IGxpbmsgYmVjb21lcw0KPiA+IHJlYWR5DQo+ID4gW8KgwqAxMTgu
NjE2MzI3XSB3bHA0czA6IGRlYXV0aGVudGljYXRlZCBmcm9tIDAwOjMwOjQ0OjFkOmNmOjJiDQo+
ID4gKFJlYXNvbjoNCj4gPiAxNT00V0FZX0hBTkRTSEFLRV9USU1FT1VUKQ0KPiA+IFvCoMKgMTI4
LjY3MzgxMl0gd2xwNHMwOiBhdXRoZW50aWNhdGUgd2l0aCAwMDozMDo0NDoxZDpjZjoyYg0KPiA+
IFvCoMKgMTI4LjY3Njk5N10gd2xwNHMwOiBzZW5kIGF1dGggdG8gMDA6MzA6NDQ6MWQ6Y2Y6MmIg
KHRyeSAxLzMpDQo+ID4gW8KgwqAxMjguNjc3NjQ4XSB3bHA0czA6IGF1dGhlbnRpY2F0ZWQNCj4g
PiBbwqDCoDEyOC42Nzg2OTFdIHdscDRzMDogYXNzb2NpYXRlIHdpdGggMDA6MzA6NDQ6MWQ6Y2Y6
MmIgKHRyeSAxLzMpDQo+ID4gW8KgwqAxMjguNjc5ODA3XSB3bHA0czA6IFJYIEFzc29jUmVzcCBm
cm9tIDAwOjMwOjQ0OjFkOmNmOjJiDQo+ID4gKGNhcGFiPTB4MTENCj4gPiBzdGF0dXM9MCBhaWQ9
MykNCj4gPiBbwqDCoDEyOC42ODExOThdIHdscDRzMDogYXNzb2NpYXRlZA0KPiA+IA0KPiA+IEkg
bmV2ZXIgZXhwZXJpZW5jZWQgdGhlIDQgd2F5IGhhbmRzaGFrZSA4MDIuMTFpIHRpbWVvdXQgaW4g
bXkgaG9tZQ0KPiA+IHNldHVwLg0KPiA+IFdpdGggb3RoZXIgc2V0dXBzIHBsZW50eSBvZiB0aW1l
cywgZXNwZWNpYWxseSB3aXRoIG1lZGlhdGVrDQo+ID4gZHJpdmVycy4gOikNCj4gPiBJZiB5b3Ug
d2lzaCBJIGNhbiBzbmlmZiBhbmQgc2VlIHdoaWNoIHNpZGUgaXMgYXQgZmF1bHQuDQo+IA0KPiBJ
IGhhdmUgbm90IG5vdGljZWQgYW55IHByb2JsZW1zIG9uIG15IGxhcHRvcCB3aXRoIGl3bGR2bSBv
biBhIDYyMDUsDQo+IHdpdGgNCj4gbGF0ZXN0IHdpcmVsZXNzLXRlc3RpbmcuwqDCoEJ1dCBtYXli
ZSBpbnRlbCBkZXZzIGNhbiB3ZWlnaCBpbi4NCg0KSSdtIG5vdCBnb2luZyB0byBwdXQgYWxsIG15
IHdlaWdodCBpbiBsZXN0IEkgYnJlYWsgdGhpbmdzIGV2ZW4gbW9yZS4gOlANCg0KSSBjYW4ndCBy
ZWFsbHkgc2VlIG11Y2ggZnJvbSB0aGUgbG9nIGV4dHJhY3QgeW91IHBvc3RlZC4gwqBDYW4geW91
IGdldA0Kc29tZSBsb2dzIChlc3BlY2lhbGx5IHRyYWNlLWNtZCBhbmQgYSBzbmlmZmVyIGNhcHR1
cmUpIGFuZCByZXBvcnQgYSBidWcNCmluIGJ1Z3ppbGxhPyBXZSBoYXZlIHNvbWUgaW5zdHJ1Y3Rp
b25zIG9uIGhvdyB0byBkbyBpdCBoZXJlOg0KDQpodHRwczovL3dpcmVsZXNzLndpa2kua2VybmVs
Lm9yZy9lbi91c2Vycy9kcml2ZXJzL2l3bHdpZmkvZGVidWdnaW5nDQoNClRoYW5rcyBmb3IgcmVw
b3J0aW5nIQ0KDQotLQ0KQ2hlZXJzLA0KTHVjYS4=
On Wed, Jun 1, 2016 at 7:19 AM, Coelho, Luciano
<[email protected]> wrote:
> On Wed, 2016-06-01 at 08:54 -0400, Bob Copeland wrote:
>> + Luca, Emmanuel
>
> Thanks, Bob!
>
>
>> On Tue, May 31, 2016 at 10:06:57PM -0600, Reinoud Koornstra wrote:
>> > Today I compiled 4.6+ and pulled sources today
>> > iwlwifi isn't super smooth.
>>
>> I assume you mean wireless-testing, based on 4.7-rc1 (as this email
>> is
>> in reply to my announcement of same).
>
> Yes, we need to know exactly what kernel you're using so we know what
> we're debugging.
>
Yesterday this is what I did to obtain the latest source:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel_current
This is the latest commit in that tree:
commit 367d3fd50566a313946fa9c5b2116a81bf3807e4
Merge: 5eca831 cf0d44d
Author: Linus Torvalds <[email protected]>
Date: Tue May 31 09:43:24 2016 -0700
Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 fixes from Martin Schwidefsky:
"Three bugs fixes and an update for the default configuration"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390: fix info leak in do_sigsegv
s390/config: update default configuration
s390/bpf: fix recache skb->data/hlen for skb_vlan_push/pop
s390/bpf: reduce maximum program size to 64 KB
>> >
>> > [ 112.345457] wlp4s0: authenticate with 00:30:44:1d:cf:2b
>> > [ 112.349002] wlp4s0: send auth to 00:30:44:1d:cf:2b (try 1/3)
>> > [ 112.349647] wlp4s0: authenticated
>> > [ 112.352456] wlp4s0: associate with 00:30:44:1d:cf:2b (try 1/3)
>> > [ 112.353764] wlp4s0: RX AssocResp from 00:30:44:1d:cf:2b
>> > (capab=0x11
>> > status=0 aid=3)
>> > [ 112.355035] wlp4s0: associated
>> > [ 112.355393] IPv6: ADDRCONF(NETDEV_CHANGE): wlp4s0: link becomes
>> > ready
>> > [ 118.616327] wlp4s0: deauthenticated from 00:30:44:1d:cf:2b
>> > (Reason:
>> > 15=4WAY_HANDSHAKE_TIMEOUT)
>> > [ 128.673812] wlp4s0: authenticate with 00:30:44:1d:cf:2b
>> > [ 128.676997] wlp4s0: send auth to 00:30:44:1d:cf:2b (try 1/3)
>> > [ 128.677648] wlp4s0: authenticated
>> > [ 128.678691] wlp4s0: associate with 00:30:44:1d:cf:2b (try 1/3)
>> > [ 128.679807] wlp4s0: RX AssocResp from 00:30:44:1d:cf:2b
>> > (capab=0x11
>> > status=0 aid=3)
>> > [ 128.681198] wlp4s0: associated
>> >
>> > I never experienced the 4 way handshake 802.11i timeout in my home
>> > setup.
>> > With other setups plenty of times, especially with mediatek
>> > drivers. :)
>> > If you wish I can sniff and see which side is at fault.
>>
>> I have not noticed any problems on my laptop with iwldvm on a 6205,
>> with
>> latest wireless-testing. But maybe intel devs can weigh in.
>
> I'm not going to put all my weight in lest I break things even more. :P
>
> I can't really see much from the log extract you posted. Can you get
> some logs (especially trace-cmd and a sniffer capture) and report a bug
> in bugzilla? We have some instructions on how to do it here:
>
> https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging
>
Ok, will do so, thanks,
Reinoud.
> Thanks for reporting!
>
> --
> Cheers,
> Luca.
On Thu, Jun 2, 2016 at 2:16 AM, Luca Coelho <[email protected]> wrote:
> On Thu, 2016-06-02 at 02:02 -0600, Reinoud Koornstra wrote:
>> On Wed, Jun 1, 2016 at 10:27 PM, Coelho, Luciano
>> <[email protected]> wrote:
>> > On Wed, 2016-06-01 at 16:08 -0600, Reinoud Koornstra wrote:
>> > > On Wed, Jun 1, 2016 at 7:19 AM, Coelho, Luciano
>> > > <[email protected]> wrote:
>> > > > On Wed, 2016-06-01 at 08:54 -0400, Bob Copeland wrote:
>> > > > > + Luca, Emmanuel
>> > > >
>> > > > Thanks, Bob!
>> > > >
>> > > >
>> > > > > On Tue, May 31, 2016 at 10:06:57PM -0600, Reinoud Koornstra
>> > > > > wrote:
>> > > > > > Today I compiled 4.6+ and pulled sources today
>> > > > > > iwlwifi isn't super smooth.
>> > > > >
>> > > > > I assume you mean wireless-testing, based on 4.7-rc1 (as this
>> > > > > email
>> > > > > is
>> > > > > in reply to my announcement of same).
>> > > >
>> > > > Yes, we need to know exactly what kernel you're using so we know
>> > > > what
>> > > > we're debugging.
>> > > >
>> > >
>> > > Yesterday this is what I did to obtain the latest source:
>> > >
>> > > git clone
>> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>> > > kernel_current
>> > >
>> > > This is the latest commit in that tree:
>> > >
>> > > commit 367d3fd50566a313946fa9c5b2116a81bf3807e4
>> > > Merge: 5eca831 cf0d44d
>> > > Author: Linus Torvalds <[email protected]>
>> > > Date: Tue May 31 09:43:24 2016 -0700
>> > >
>> > > Merge branch 'for-linus' of
>> > > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
>> > >
>> > > Pull s390 fixes from Martin Schwidefsky:
>> > > "Three bugs fixes and an update for the default configuration"
>> > >
>> > > * 'for-linus' of
>> > > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
>> > > s390: fix info leak in do_sigsegv
>> > > s390/config: update default configuration
>> > > s390/bpf: fix recache skb->data/hlen for skb_vlan_push/pop
>> > > s390/bpf: reduce maximum program size to 64 KB
>> >
>> > Ah, okay. This has nothing to do with the wireless-testing tree. This
>> > is random commit in Linus' tree. I suggest that you use a release tag
>> > or such. For instance you could do this in Linus' tree to get the
>> > current release candidate for 4.7:
>> >
>> > git checkout v4.7-rc1
>> >
>> > Or you could use the wireless-testing tree that Bob is maintaining,
>> > which is always based on an official release candidate (currently the
>> > above mentioned v4.7-rc1 release) plus the latest and greatest (and
>> > probably "brokenest" :P) wireless changes:
>> >
>> > git clone git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-testing.git
>> >
>>
>> Ok, i got this tree.
>> From the start it didn't work.
>>
>> [ 0.000000] Linux version 4.7.0-rc1-wt+
>> [SNIP]
>> [ 2.156875] iwlwifi 0000:04:00.0: Direct firmware load for
>> iwlwifi-7260-17.ucode failed with error -2
>> [ 2.157681] iwlwifi 0000:04:00.0: Direct firmware load for
>> iwlwifi-7260-16.ucode failed with error -2
>> [ 2.158438] iwlwifi 0000:04:00.0: no suitable firmware found!
>
> This is happening pretty early, did you compile the iwlwifi driver into
> the kernel (instead of compiling them as modules)? There have been
> problems when it's in-kernel, so we recommend that you compile them as
> modules (unless strictly necessary).
>
>
>> I've attached the dmesg in it's entirety.
>> Booting back to 4.6:
>>
>> [ 17.987698] iwlwifi 0000:04:00.0: loaded firmware version
>> 16.242414.0 op_mode iwlmvm
>> [ 18.269667] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band
>> Wireless AC 7260, REV=0x144
>
> This shows that you have iwlwifi-7260-16.ucode in your file system.
> But here we are reading it much later. So it's possible that the
> kernel cannot access the firmware at a very early stage (because the
> filesystem that contains it is not mounted yet) when you use in-kernel.
>
> So, first of all, please make sure they're built as modules. We can
> continue from there then.
Your suggestion worked. When it's compiled as module, the
iwlwifi-7260-16.ucode loads fine.
No problems detected so far.
It does make me think whether this is desired behavior though that due
to the later reading we cannot have iwlwifi build in the kernel.
Thanks,
Reinoud.
>
> --
> Cheers,
> Luca.
On Wed, Jun 1, 2016 at 10:27 PM, Coelho, Luciano
<[email protected]> wrote:
> On Wed, 2016-06-01 at 16:08 -0600, Reinoud Koornstra wrote:
>> On Wed, Jun 1, 2016 at 7:19 AM, Coelho, Luciano
>> <[email protected]> wrote:
>> > On Wed, 2016-06-01 at 08:54 -0400, Bob Copeland wrote:
>> > > + Luca, Emmanuel
>> >
>> > Thanks, Bob!
>> >
>> >
>> > > On Tue, May 31, 2016 at 10:06:57PM -0600, Reinoud Koornstra
>> > > wrote:
>> > > > Today I compiled 4.6+ and pulled sources today
>> > > > iwlwifi isn't super smooth.
>> > >
>> > > I assume you mean wireless-testing, based on 4.7-rc1 (as this
>> > > email
>> > > is
>> > > in reply to my announcement of same).
>> >
>> > Yes, we need to know exactly what kernel you're using so we know
>> > what
>> > we're debugging.
>> >
>>
>> Yesterday this is what I did to obtain the latest source:
>>
>> git clone
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>> kernel_current
>>
>> This is the latest commit in that tree:
>>
>> commit 367d3fd50566a313946fa9c5b2116a81bf3807e4
>> Merge: 5eca831 cf0d44d
>> Author: Linus Torvalds <[email protected]>
>> Date: Tue May 31 09:43:24 2016 -0700
>>
>> Merge branch 'for-linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
>>
>> Pull s390 fixes from Martin Schwidefsky:
>> "Three bugs fixes and an update for the default configuration"
>>
>> * 'for-linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
>> s390: fix info leak in do_sigsegv
>> s390/config: update default configuration
>> s390/bpf: fix recache skb->data/hlen for skb_vlan_push/pop
>> s390/bpf: reduce maximum program size to 64 KB
>
> Ah, okay. This has nothing to do with the wireless-testing tree. This
> is random commit in Linus' tree. I suggest that you use a release tag
> or such. For instance you could do this in Linus' tree to get the
> current release candidate for 4.7:
>
> git checkout v4.7-rc1
>
> Or you could use the wireless-testing tree that Bob is maintaining,
> which is always based on an official release candidate (currently the
> above mentioned v4.7-rc1 release) plus the latest and greatest (and
> probably "brokenest" :P) wireless changes:
>
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-testing.git
>
Ok, i got this tree.
>From the start it didn't work.
[ 0.000000] Linux version 4.7.0-rc1-wt+
[SNIP]
[ 2.156875] iwlwifi 0000:04:00.0: Direct firmware load for
iwlwifi-7260-17.ucode failed with error -2
[ 2.157681] iwlwifi 0000:04:00.0: Direct firmware load for
iwlwifi-7260-16.ucode failed with error -2
[ 2.158438] iwlwifi 0000:04:00.0: no suitable firmware found!
I've attached the dmesg in it's entirety.
Booting back to 4.6:
[ 17.987698] iwlwifi 0000:04:00.0: loaded firmware version
16.242414.0 op_mode iwlmvm
[ 18.269667] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band
Wireless AC 7260, REV=0x144
Hence, the trace-cmd commands won't do much either in the latest and greatest.
Thanks,
Reinoud.
>
>> > > >
>> > > > [ 112.345457] wlp4s0: authenticate with 00:30:44:1d:cf:2b
>> > > > [ 112.349002] wlp4s0: send auth to 00:30:44:1d:cf:2b (try 1/3)
>> > > > [ 112.349647] wlp4s0: authenticated
>> > > > [ 112.352456] wlp4s0: associate with 00:30:44:1d:cf:2b (try
>> > > > 1/3)
>> > > > [ 112.353764] wlp4s0: RX AssocResp from 00:30:44:1d:cf:2b
>> > > > (capab=0x11
>> > > > status=0 aid=3)
>> > > > [ 112.355035] wlp4s0: associated
>> > > > [ 112.355393] IPv6: ADDRCONF(NETDEV_CHANGE): wlp4s0: link
>> > > > becomes
>> > > > ready
>> > > > [ 118.616327] wlp4s0: deauthenticated from 00:30:44:1d:cf:2b
>> > > > (Reason:
>> > > > 15=4WAY_HANDSHAKE_TIMEOUT)
>> > > > [ 128.673812] wlp4s0: authenticate with 00:30:44:1d:cf:2b
>> > > > [ 128.676997] wlp4s0: send auth to 00:30:44:1d:cf:2b (try 1/3)
>> > > > [ 128.677648] wlp4s0: authenticated
>> > > > [ 128.678691] wlp4s0: associate with 00:30:44:1d:cf:2b (try
>> > > > 1/3)
>> > > > [ 128.679807] wlp4s0: RX AssocResp from 00:30:44:1d:cf:2b
>> > > > (capab=0x11
>> > > > status=0 aid=3)
>> > > > [ 128.681198] wlp4s0: associated
>> > > >
>> > > > I never experienced the 4 way handshake 802.11i timeout in my
>> > > > home
>> > > > setup.
>> > > > With other setups plenty of times, especially with mediatek
>> > > > drivers. :)
>> > > > If you wish I can sniff and see which side is at fault.
>> > >
>> > > I have not noticed any problems on my laptop with iwldvm on a
>> > > 6205,
>> > > with
>> > > latest wireless-testing. But maybe intel devs can weigh in.
>> >
>> > I'm not going to put all my weight in lest I break things even
>> > more. :P
>> >
>> > I can't really see much from the log extract you posted. Can you
>> > get
>> > some logs (especially trace-cmd and a sniffer capture) and report a
>> > bug
>> > in bugzilla? We have some instructions on how to do it here:
>> >
>> > https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging
>> >
>>
>> Ok, will do so, thanks,
>
> Great, thanks! Please use one of the more-well-known trees/tags I
> mentioned above and report if you still have trouble.
>
> --
> Cheers,
> Luca.
On Sun, 2016-06-05 at 19:09 -0600, Reinoud Koornstra wrote:
> On Thu, Jun 2, 2016 at 11:59 PM, Luca Coelho <[email protected]> wrote:
> > On Thu, 2016-06-02 at 23:09 -0600, Reinoud Koornstra wrote:
> > > On Thu, Jun 2, 2016 at 2:16 AM, Luca Coelho <[email protected]> wrote:
> > > > This shows that you have iwlwifi-7260-16.ucode in your file system.
> > > > But here we are reading it much later. So it's possible that the
> > > > kernel cannot access the firmware at a very early stage (because
> > > > the
> > > > filesystem that contains it is not mounted yet) when you use in-
> > > > kernel.
> > > >
> > > > So, first of all, please make sure they're built as modules. We
> > > > can
> > > > continue from there then.
> > >
> > > Your suggestion worked. When it's compiled as module, the
> > > iwlwifi-7260-16.ucode loads fine.
> > > No problems detected so far.
> >
> > Great! :)
>
> It is. :)
> I git pulled again and build it again.
> This time with gcc 6.1.0
> I couldn't find warning specific to iwlwifi with gcc 6, so that's great.
> Didn't find anything worrysome yet, in addition I am running the cake
> qdisc as well from Dave Taht.
> objdump --full-contents --section=.comment vmlinux
>
> vmlinux: file format elf64-x86-64
>
> Contents of section .comment:
> 0000 4743433a 2028474e 55292036 2e312e30 GCC: (GNU) 6.1.0
> 0010 00
>
> reinoud@router-dev:~/Downloads/wireless-testing$ objdump
> --full-contents --section=.comment
> /lib/modules/4.7.0-rc1-wt+/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko
>
> /lib/modules/4.7.0-rc1-wt+/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko:
> file format elf64-x86-64
>
> Contents of section .comment:
> 0000 00474343 3a202847 4e552920 362e312e .GCC: (GNU) 6.1.
> 0010 30000047 43433a20 28474e55 2920362e 0..GCC: (GNU) 6.
> [SNIP]
> 0180 28474e55 2920362e 312e3000 (GNU) 6.1.0.
>
>
> >
> >
> > > It does make me think whether this is desired behavior though that
> > > due
> > > to the later reading we cannot have iwlwifi build in the kernel.
> >
> > It should work, but then you have to make sure the firmware is
> > available at very early stages of boot. If you add it to the proper
> > place in your initrd, the kernel should find it when the driver
> > requests it.
> >
> > I didn't want to go into the details of this, because in most cases the
> > best option is to have the driver as a module. If you really need it
> > in-kernel, then you need to make sure all the needed pieces are
> > available very early as well.
>
> Ah, thanks, I'll study this as how to have it inside initrd at the right place.
> Any pointers would be great.
It should be really straightforward. It just depends on how your
distro creates and uses initrd images. You only need to add the
appropriate .ucode file to /lib/firmware in the initrd image, nothing
else. Google for it, I'm sure there is a lot of info on how to do it
readily available.
> Btw, I did build gcc 6.1.0 like this, if you have hints or ways I
> should build it differently I would like to know.
>
> reinoud@router-dev:~/Downloads/wireless-testing$ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/home/reinoud/GCC/libexec/gcc/x86_64-linux-gnu/6.1.0/lto-wrapper
> Target: x86_64-linux-gnu
> Configured with: ../gcc-6.1.0/configure -v
> --enable-languages=c,c++,go,fortran,objc,obj-c++
> --prefix=/home/reinoud/GCC --enable-shared --enable-linker-build-id
> --without-included-gettext --enable-threads=posix --enable-nls
> --with-sysroot=/ --enab
> le-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-vtable-verify --enable-libmpx --enable-plugin
> --with-system-zlib --disable-browser-plugin --with-arch-direct
> ory=amd64 --enable-objc-gc --enable-multiarch --disable-werror
> --with-abi=m64 --enable-checking=release --build=x86_64-linux-gnu
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 6.1.0 (GCC)
>
> The --with-tune=skylake didn't work as it didn't know it. unfortunately.
I'm sorry, but I have no clue. This is probably a question to some gcc
development mailing list. ;)
--
Cheers,
Luca.
Bob Copeland <[email protected]> writes:
> Since Linus released 4.7-rc1 today, I've resumed wireless-testing
> updates since its merge window hiatus, with tag wt-2016-05-29.
>
> Please test and let me know of any issues.
I also opened wireless-drivers-next tree for patches going to 4.8. And
wireless-drivers continues to be open for important fixes and
regressions to 4.7.
--
Kalle Valo
T24gV2VkLCAyMDE2LTA2LTAxIGF0IDE2OjA4IC0wNjAwLCBSZWlub3VkIEtvb3Juc3RyYSB3cm90
ZToNCj4gT24gV2VkLCBKdW4gMSwgMjAxNiBhdCA3OjE5IEFNLCBDb2VsaG8sIEx1Y2lhbm8NCj4g
PGx1Y2lhbm8uY29lbGhvQGludGVsLmNvbT4gd3JvdGU6DQo+ID4gT24gV2VkLCAyMDE2LTA2LTAx
IGF0IDA4OjU0IC0wNDAwLCBCb2IgQ29wZWxhbmQgd3JvdGU6DQo+ID4gPiArIEx1Y2EsIEVtbWFu
dWVsDQo+ID4gDQo+ID4gVGhhbmtzLCBCb2IhDQo+ID4gDQo+ID4gDQo+ID4gPiBPbiBUdWUsIE1h
eSAzMSwgMjAxNiBhdCAxMDowNjo1N1BNIC0wNjAwLCBSZWlub3VkIEtvb3Juc3RyYQ0KPiA+ID4g
d3JvdGU6DQo+ID4gPiA+IFRvZGF5IEkgY29tcGlsZWQgNC42KyBhbmQgcHVsbGVkIHNvdXJjZXMg
dG9kYXkNCj4gPiA+ID4gaXdsd2lmaSBpc24ndCBzdXBlciBzbW9vdGguDQo+ID4gPiANCj4gPiA+
IEkgYXNzdW1lIHlvdSBtZWFuIHdpcmVsZXNzLXRlc3RpbmcsIGJhc2VkIG9uIDQuNy1yYzEgKGFz
IHRoaXMNCj4gPiA+IGVtYWlsDQo+ID4gPiBpcw0KPiA+ID4gaW4gcmVwbHkgdG8gbXkgYW5ub3Vu
Y2VtZW50IG9mIHNhbWUpLg0KPiA+IA0KPiA+IFllcywgd2UgbmVlZCB0byBrbm93IGV4YWN0bHkg
d2hhdCBrZXJuZWwgeW91J3JlIHVzaW5nIHNvIHdlIGtub3cNCj4gPiB3aGF0DQo+ID4gd2UncmUg
ZGVidWdnaW5nLg0KPiA+IA0KPiANCj4gWWVzdGVyZGF5IHRoaXMgaXMgd2hhdCBJIGRpZCB0byBv
YnRhaW4gdGhlIGxhdGVzdCBzb3VyY2U6DQo+IA0KPiBnaXQgY2xvbmUNCj4gZ2l0Oi8vZ2l0Lmtl
cm5lbC5vcmcvcHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L3RvcnZhbGRzL2xpbnV4LmdpdA0KPiBr
ZXJuZWxfY3VycmVudA0KPiANCj4gVGhpcyBpcyB0aGUgbGF0ZXN0IGNvbW1pdCBpbiB0aGF0IHRy
ZWU6DQo+IA0KPiBjb21taXQgMzY3ZDNmZDUwNTY2YTMxMzk0NmZhOWM1YjIxMTZhODFiZjM4MDdl
NA0KPiBNZXJnZTogNWVjYTgzMSBjZjBkNDRkDQo+IEF1dGhvcjogTGludXMgVG9ydmFsZHMgPHRv
cnZhbGRzQGxpbnV4LWZvdW5kYXRpb24ub3JnPg0KPiBEYXRlOsKgwqDCoFR1ZSBNYXkgMzEgMDk6
NDM6MjQgMjAxNiAtMDcwMA0KPiANCj4gwqDCoMKgTWVyZ2UgYnJhbmNoICdmb3ItbGludXMnIG9m
DQo+IGdpdDovL2dpdC5rZXJuZWwub3JnL3B1Yi9zY20vbGludXgva2VybmVsL2dpdC9zMzkwL2xp
bnV4DQo+IA0KPiDCoMKgwqBQdWxsIHMzOTAgZml4ZXMgZnJvbSBNYXJ0aW4gU2Nod2lkZWZza3k6
DQo+IMKgwqDCoMKgIlRocmVlIGJ1Z3MgZml4ZXMgYW5kIGFuIHVwZGF0ZSBmb3IgdGhlIGRlZmF1
bHQgY29uZmlndXJhdGlvbiINCj4gDQo+IMKgwqDCoCogJ2Zvci1saW51cycgb2YNCj4gZ2l0Oi8v
Z2l0Lmtlcm5lbC5vcmcvcHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L3MzOTAvbGludXg6DQo+IMKg
wqDCoMKgwqBzMzkwOiBmaXggaW5mbyBsZWFrIGluIGRvX3NpZ3NlZ3YNCj4gwqDCoMKgwqDCoHMz
OTAvY29uZmlnOiB1cGRhdGUgZGVmYXVsdCBjb25maWd1cmF0aW9uDQo+IMKgwqDCoMKgwqBzMzkw
L2JwZjogZml4IHJlY2FjaGUgc2tiLT5kYXRhL2hsZW4gZm9yIHNrYl92bGFuX3B1c2gvcG9wDQo+
IMKgwqDCoMKgwqBzMzkwL2JwZjogcmVkdWNlIG1heGltdW0gcHJvZ3JhbSBzaXplIHRvIDY0IEtC
DQoNCkFoLCBva2F5LiDCoFRoaXMgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGUgd2lyZWxlc3Mt
dGVzdGluZyB0cmVlLiDCoFRoaXMNCmlzIHJhbmRvbSBjb21taXQgaW4gTGludXMnIHRyZWUuIMKg
SSBzdWdnZXN0IHRoYXQgeW91IHVzZSBhIHJlbGVhc2UgdGFnDQpvciBzdWNoLiDCoEZvciBpbnN0
YW5jZSB5b3UgY291bGQgZG8gdGhpcyBpbiBMaW51cycgdHJlZSB0byBnZXQgdGhlDQpjdXJyZW50
IHJlbGVhc2UgY2FuZGlkYXRlIGZvciA0Ljc6DQoNCmdpdCBjaGVja291dCB2NC43LXJjMQ0KDQpP
ciB5b3UgY291bGQgdXNlIHRoZSB3aXJlbGVzcy10ZXN0aW5nIHRyZWUgdGhhdCBCb2IgaXMgbWFp
bnRhaW5pbmcsDQp3aGljaCBpcyBhbHdheXMgYmFzZWQgb24gYW4gb2ZmaWNpYWwgcmVsZWFzZSBj
YW5kaWRhdGUgKGN1cnJlbnRseSB0aGUNCmFib3ZlIG1lbnRpb25lZCB2NC43LXJjMSByZWxlYXNl
KSBwbHVzIHRoZSBsYXRlc3QgYW5kIGdyZWF0ZXN0IChhbmQNCnByb2JhYmx5ICJicm9rZW5lc3Qi
IDpQKSB3aXJlbGVzcyBjaGFuZ2VzOg0KDQpnaXQgY2xvbmXCoGdpdDovL2dpdC5rZXJuZWwub3Jn
L3B1Yi9zY20vbGludXgva2VybmVsL2dpdC93aXJlbGVzcy93aXJlbGVzcy10ZXN0aW5nLmdpdA0K
DQoNCj4gPiA+ID4gDQo+ID4gPiA+IFvCoMKgMTEyLjM0NTQ1N10gd2xwNHMwOiBhdXRoZW50aWNh
dGUgd2l0aCAwMDozMDo0NDoxZDpjZjoyYg0KPiA+ID4gPiBbwqDCoDExMi4zNDkwMDJdIHdscDRz
MDogc2VuZCBhdXRoIHRvIDAwOjMwOjQ0OjFkOmNmOjJiICh0cnkgMS8zKQ0KPiA+ID4gPiBbwqDC
oDExMi4zNDk2NDddIHdscDRzMDogYXV0aGVudGljYXRlZA0KPiA+ID4gPiBbwqDCoDExMi4zNTI0
NTZdIHdscDRzMDogYXNzb2NpYXRlIHdpdGggMDA6MzA6NDQ6MWQ6Y2Y6MmIgKHRyeQ0KPiA+ID4g
PiAxLzMpDQo+ID4gPiA+IFvCoMKgMTEyLjM1Mzc2NF0gd2xwNHMwOiBSWCBBc3NvY1Jlc3AgZnJv
bSAwMDozMDo0NDoxZDpjZjoyYg0KPiA+ID4gPiAoY2FwYWI9MHgxMQ0KPiA+ID4gPiBzdGF0dXM9
MCBhaWQ9MykNCj4gPiA+ID4gW8KgwqAxMTIuMzU1MDM1XSB3bHA0czA6IGFzc29jaWF0ZWQNCj4g
PiA+ID4gW8KgwqAxMTIuMzU1MzkzXSBJUHY2OiBBRERSQ09ORihORVRERVZfQ0hBTkdFKTogd2xw
NHMwOiBsaW5rDQo+ID4gPiA+IGJlY29tZXMNCj4gPiA+ID4gcmVhZHkNCj4gPiA+ID4gW8KgwqAx
MTguNjE2MzI3XSB3bHA0czA6IGRlYXV0aGVudGljYXRlZCBmcm9tIDAwOjMwOjQ0OjFkOmNmOjJi
DQo+ID4gPiA+IChSZWFzb246DQo+ID4gPiA+IDE1PTRXQVlfSEFORFNIQUtFX1RJTUVPVVQpDQo+
ID4gPiA+IFvCoMKgMTI4LjY3MzgxMl0gd2xwNHMwOiBhdXRoZW50aWNhdGUgd2l0aCAwMDozMDo0
NDoxZDpjZjoyYg0KPiA+ID4gPiBbwqDCoDEyOC42NzY5OTddIHdscDRzMDogc2VuZCBhdXRoIHRv
IDAwOjMwOjQ0OjFkOmNmOjJiICh0cnkgMS8zKQ0KPiA+ID4gPiBbwqDCoDEyOC42Nzc2NDhdIHds
cDRzMDogYXV0aGVudGljYXRlZA0KPiA+ID4gPiBbwqDCoDEyOC42Nzg2OTFdIHdscDRzMDogYXNz
b2NpYXRlIHdpdGggMDA6MzA6NDQ6MWQ6Y2Y6MmIgKHRyeQ0KPiA+ID4gPiAxLzMpDQo+ID4gPiA+
IFvCoMKgMTI4LjY3OTgwN10gd2xwNHMwOiBSWCBBc3NvY1Jlc3AgZnJvbSAwMDozMDo0NDoxZDpj
ZjoyYg0KPiA+ID4gPiAoY2FwYWI9MHgxMQ0KPiA+ID4gPiBzdGF0dXM9MCBhaWQ9MykNCj4gPiA+
ID4gW8KgwqAxMjguNjgxMTk4XSB3bHA0czA6IGFzc29jaWF0ZWQNCj4gPiA+ID4gDQo+ID4gPiA+
IEkgbmV2ZXIgZXhwZXJpZW5jZWQgdGhlIDQgd2F5IGhhbmRzaGFrZSA4MDIuMTFpIHRpbWVvdXQg
aW4gbXkNCj4gPiA+ID4gaG9tZQ0KPiA+ID4gPiBzZXR1cC4NCj4gPiA+ID4gV2l0aCBvdGhlciBz
ZXR1cHMgcGxlbnR5IG9mIHRpbWVzLCBlc3BlY2lhbGx5IHdpdGggbWVkaWF0ZWsNCj4gPiA+ID4g
ZHJpdmVycy4gOikNCj4gPiA+ID4gSWYgeW91IHdpc2ggSSBjYW4gc25pZmYgYW5kIHNlZSB3aGlj
aCBzaWRlIGlzIGF0IGZhdWx0Lg0KPiA+ID4gDQo+ID4gPiBJIGhhdmUgbm90IG5vdGljZWQgYW55
IHByb2JsZW1zIG9uIG15IGxhcHRvcCB3aXRoIGl3bGR2bSBvbiBhDQo+ID4gPiA2MjA1LA0KPiA+
ID4gd2l0aA0KPiA+ID4gbGF0ZXN0IHdpcmVsZXNzLXRlc3RpbmcuwqDCoEJ1dCBtYXliZSBpbnRl
bCBkZXZzIGNhbiB3ZWlnaCBpbi4NCj4gPiANCj4gPiBJJ20gbm90IGdvaW5nIHRvIHB1dCBhbGwg
bXkgd2VpZ2h0IGluIGxlc3QgSSBicmVhayB0aGluZ3MgZXZlbg0KPiA+IG1vcmUuIDpQDQo+ID4g
DQo+ID4gSSBjYW4ndCByZWFsbHkgc2VlIG11Y2ggZnJvbSB0aGUgbG9nIGV4dHJhY3QgeW91IHBv
c3RlZC7CoMKgQ2FuIHlvdQ0KPiA+IGdldA0KPiA+IHNvbWUgbG9ncyAoZXNwZWNpYWxseSB0cmFj
ZS1jbWQgYW5kIGEgc25pZmZlciBjYXB0dXJlKSBhbmQgcmVwb3J0IGENCj4gPiBidWcNCj4gPiBp
biBidWd6aWxsYT8gV2UgaGF2ZSBzb21lIGluc3RydWN0aW9ucyBvbiBob3cgdG8gZG8gaXQgaGVy
ZToNCj4gPiANCj4gPiBodHRwczovL3dpcmVsZXNzLndpa2kua2VybmVsLm9yZy9lbi91c2Vycy9k
cml2ZXJzL2l3bHdpZmkvZGVidWdnaW5nDQo+ID4gDQo+IA0KPiBPaywgd2lsbCBkbyBzbywgdGhh
bmtzLA0KDQpHcmVhdCwgdGhhbmtzISBQbGVhc2UgdXNlIG9uZSBvZiB0aGUgbW9yZS13ZWxsLWtu
b3duIHRyZWVzL3RhZ3MgSQ0KbWVudGlvbmVkIGFib3ZlIGFuZCByZXBvcnQgaWYgeW91IHN0aWxs
IGhhdmUgdHJvdWJsZS4NCg0KLS0NCkNoZWVycywNCkx1Y2Eu
+ Luca, Emmanuel
On Tue, May 31, 2016 at 10:06:57PM -0600, Reinoud Koornstra wrote:
> Today I compiled 4.6+ and pulled sources today
> iwlwifi isn't super smooth.
I assume you mean wireless-testing, based on 4.7-rc1 (as this email is
in reply to my announcement of same).
>
> [ 112.345457] wlp4s0: authenticate with 00:30:44:1d:cf:2b
> [ 112.349002] wlp4s0: send auth to 00:30:44:1d:cf:2b (try 1/3)
> [ 112.349647] wlp4s0: authenticated
> [ 112.352456] wlp4s0: associate with 00:30:44:1d:cf:2b (try 1/3)
> [ 112.353764] wlp4s0: RX AssocResp from 00:30:44:1d:cf:2b (capab=0x11
> status=0 aid=3)
> [ 112.355035] wlp4s0: associated
> [ 112.355393] IPv6: ADDRCONF(NETDEV_CHANGE): wlp4s0: link becomes ready
> [ 118.616327] wlp4s0: deauthenticated from 00:30:44:1d:cf:2b (Reason:
> 15=4WAY_HANDSHAKE_TIMEOUT)
> [ 128.673812] wlp4s0: authenticate with 00:30:44:1d:cf:2b
> [ 128.676997] wlp4s0: send auth to 00:30:44:1d:cf:2b (try 1/3)
> [ 128.677648] wlp4s0: authenticated
> [ 128.678691] wlp4s0: associate with 00:30:44:1d:cf:2b (try 1/3)
> [ 128.679807] wlp4s0: RX AssocResp from 00:30:44:1d:cf:2b (capab=0x11
> status=0 aid=3)
> [ 128.681198] wlp4s0: associated
>
> I never experienced the 4 way handshake 802.11i timeout in my home setup.
> With other setups plenty of times, especially with mediatek drivers. :)
> If you wish I can sniff and see which side is at fault.
I have not noticed any problems on my laptop with iwldvm on a 6205, with
latest wireless-testing. But maybe intel devs can weigh in.
--
Bob Copeland %% http://bobcopeland.com/