Re: athn: device timeout
On Sun, May 19, 2019 at 07:09:00PM +, Lévai, Dániel wrote: > On Sunday, 19 May 2019 20:42, Stefan Sperling wrote: > > On Sun, May 19, 2019 at 05:38:03PM +, Lévai, Dániel wrote: > > > > > > And for some reason -- and this is really strange, I know --, sometimes > > > it gets into a state where no client can connect/auth to the AP, and > > > nothing seems to be able to fix it other than a hard reset of the AP. On > > > a Linux client machine with wpa_supplicant(8) these are the log messages > > > when this latter happens: > > > May 19 19:08:38 serenity kernel: wlan0: authenticate with > > > May 19 19:08:38 serenity kernel: wlan0: send auth to (try 1/3) > > > May 19 19:08:38 serenity kernel: wlan0: authenticated > > > May 19 19:08:38 serenity kernel: wlan0: associate with (try 1/3) > > > May 19 19:08:38 serenity kernel: wlan0: RX AssocResp from > > > (capab=0x411 status=0 aid=2) > > > May 19 19:08:38 serenity kernel: wlan0: associated > > > May 19 19:08:39 serenity kernel: wlan0: deauthenticated from > > > (Reason: 15=4WAY_HANDSHAKE_TIMEOUT) > > > This just goes on and on and on. > > > > > And what do you see with 'ifconfig athn0 debug' on the AP? > > I get a lot of these: > May 19 21:03:02 firefly /bsd: athn0: station purged from node cache > May 19 21:03:02 firefly /bsd: athn0: station purged from node cache > May 19 21:03:02 firefly /bsd: athn0: station purged from node cache > May 19 21:03:13 firefly /bsd: athn0: sending auth to on channel > 36 mode 11n > May 19 21:03:13 firefly /bsd: athn0: station already > authenticated (open) > May 19 21:03:13 firefly /bsd: athn0: sending assoc_resp to on > channel 36 mode 11n > May 19 21:03:13 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake > to > May 19 21:03:13 firefly last message repeated 2 times > May 19 21:03:13 firefly /bsd: athn0: station deauthenticate > (reason 15) > May 19 21:03:13 firefly /bsd: athn0: sending deauth to on > channel 36 mode 11n > May 19 21:03:14 firefly /bsd: athn0: sending auth to on channel > 36 mode 11n > May 19 21:03:14 firefly /bsd: athn0: station already > authenticated (open) > May 19 21:03:14 firefly /bsd: athn0: sending assoc_resp to on > channel 36 mode 11n > May 19 21:03:14 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake > to > May 19 21:03:14 firefly last message repeated 2 times > May 19 21:03:14 firefly /bsd: athn0: station deauthenticate > (reason 15) > May 19 21:03:14 firefly /bsd: athn0: sending deauth to on > channel 36 mode 11n > May 19 21:03:15 firefly /bsd: athn0: sending auth to on channel > 36 mode 11n > May 19 21:03:15 firefly /bsd: athn0: station already > authenticated (open) > May 19 21:03:15 firefly /bsd: athn0: sending assoc_resp to on > channel 36 mode 11n > May 19 21:03:15 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake > to > May 19 21:03:16 firefly last message repeated 2 times > May 19 21:03:16 firefly /bsd: athn0: station deauthenticate > (reason 15) > May 19 21:03:16 firefly /bsd: athn0: sending deauth to on > channel 36 mode 11n > May 19 21:03:17 firefly /bsd: athn0: sending auth to on channel > 36 mode 11n > May 19 21:03:17 firefly /bsd: athn0: station already > authenticated (open) > May 19 21:03:17 firefly /bsd: athn0: sending assoc_resp to on > channel 36 mode 11n > May 19 21:03:17 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake > to > May 19 21:03:17 firefly last message repeated 2 times > May 19 21:03:17 firefly /bsd: athn0: station deauthenticate > (reason 15) > May 19 21:03:17 firefly /bsd: athn0: sending deauth to on > channel 36 mode 11n > May 19 21:03:18 firefly /bsd: athn0: sending auth to on channel > 36 mode 11n > May 19 21:03:18 firefly /bsd: athn0: station already > authenticated (open) > May 19 21:03:18 firefly /bsd: athn0: sending assoc_resp to on > channel 36 mode 11n > May 19 21:03:18 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake > to > May 19 21:03:18 firefly last message repeated 2 times > May 19 21:03:18 firefly /bsd: athn0: station deauthenticate > (reason 15) > May 19 21:03:18 firefly /bsd: athn0: sending deauth to on > channel 36 mode 11n > May 19 21:03:20 firefly /bsd: athn0: sending auth to on channel > 36 mode 11n > May 19 21:03:20 firefly /bsd: athn0: station already > authenticated (open) > May 19 21:03:20 firefly /bsd: athn0: sending assoc_resp to on > channel 36 mode 11n > May 19 21:03:20 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake > to > May 19 21:03:20 firefly last message repeated 2 times > > Both with and Android phone and a Linux (wpa_supplicant) client. This looks like your client devices were not responding to the WPA handshake. I can't explain why. The client side log says nothing about WPA -- is that expected?
Re: athn: device timeout
On Sunday, 19 May 2019 20:42, Stefan Sperling wrote: > On Sun, May 19, 2019 at 05:38:03PM +, Lévai, Dániel wrote: > > > And for some reason -- and this is really strange, I know --, sometimes it > > gets into a state where no client can connect/auth to the AP, and nothing > > seems to be able to fix it other than a hard reset of the AP. On a Linux > > client machine with wpa_supplicant(8) these are the log messages when this > > latter happens: > > May 19 19:08:38 serenity kernel: wlan0: authenticate with > > May 19 19:08:38 serenity kernel: wlan0: send auth to (try 1/3) > > May 19 19:08:38 serenity kernel: wlan0: authenticated > > May 19 19:08:38 serenity kernel: wlan0: associate with (try 1/3) > > May 19 19:08:38 serenity kernel: wlan0: RX AssocResp from (capab=0x411 > > status=0 aid=2) > > May 19 19:08:38 serenity kernel: wlan0: associated > > May 19 19:08:39 serenity kernel: wlan0: deauthenticated from (Reason: > > 15=4WAY_HANDSHAKE_TIMEOUT) > > This just goes on and on and on. > > And what do you see with 'ifconfig athn0 debug' on the AP? I get a lot of these: May 19 21:03:02 firefly /bsd: athn0: station purged from node cache May 19 21:03:02 firefly /bsd: athn0: station purged from node cache May 19 21:03:02 firefly /bsd: athn0: station purged from node cache May 19 21:03:13 firefly /bsd: athn0: sending auth to on channel 36 mode 11n May 19 21:03:13 firefly /bsd: athn0: station already authenticated (open) May 19 21:03:13 firefly /bsd: athn0: sending assoc_resp to on channel 36 mode 11n May 19 21:03:13 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake to May 19 21:03:13 firefly last message repeated 2 times May 19 21:03:13 firefly /bsd: athn0: station deauthenticate (reason 15) May 19 21:03:13 firefly /bsd: athn0: sending deauth to on channel 36 mode 11n May 19 21:03:14 firefly /bsd: athn0: sending auth to on channel 36 mode 11n May 19 21:03:14 firefly /bsd: athn0: station already authenticated (open) May 19 21:03:14 firefly /bsd: athn0: sending assoc_resp to on channel 36 mode 11n May 19 21:03:14 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake to May 19 21:03:14 firefly last message repeated 2 times May 19 21:03:14 firefly /bsd: athn0: station deauthenticate (reason 15) May 19 21:03:14 firefly /bsd: athn0: sending deauth to on channel 36 mode 11n May 19 21:03:15 firefly /bsd: athn0: sending auth to on channel 36 mode 11n May 19 21:03:15 firefly /bsd: athn0: station already authenticated (open) May 19 21:03:15 firefly /bsd: athn0: sending assoc_resp to on channel 36 mode 11n May 19 21:03:15 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake to May 19 21:03:16 firefly last message repeated 2 times May 19 21:03:16 firefly /bsd: athn0: station deauthenticate (reason 15) May 19 21:03:16 firefly /bsd: athn0: sending deauth to on channel 36 mode 11n May 19 21:03:17 firefly /bsd: athn0: sending auth to on channel 36 mode 11n May 19 21:03:17 firefly /bsd: athn0: station already authenticated (open) May 19 21:03:17 firefly /bsd: athn0: sending assoc_resp to on channel 36 mode 11n May 19 21:03:17 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake to May 19 21:03:17 firefly last message repeated 2 times May 19 21:03:17 firefly /bsd: athn0: station deauthenticate (reason 15) May 19 21:03:17 firefly /bsd: athn0: sending deauth to on channel 36 mode 11n May 19 21:03:18 firefly /bsd: athn0: sending auth to on channel 36 mode 11n May 19 21:03:18 firefly /bsd: athn0: station already authenticated (open) May 19 21:03:18 firefly /bsd: athn0: sending assoc_resp to on channel 36 mode 11n May 19 21:03:18 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake to May 19 21:03:18 firefly last message repeated 2 times May 19 21:03:18 firefly /bsd: athn0: station deauthenticate (reason 15) May 19 21:03:18 firefly /bsd: athn0: sending deauth to on channel 36 mode 11n May 19 21:03:20 firefly /bsd: athn0: sending auth to on channel 36 mode 11n May 19 21:03:20 firefly /bsd: athn0: station already authenticated (open) May 19 21:03:20 firefly /bsd: athn0: sending assoc_resp to on channel 36 mode 11n May 19 21:03:20 firefly /bsd: athn0: sending msg 1/4 of the 4-way handshake to May 19 21:03:20 firefly last message repeated 2 times Both with and Android phone and a Linux (wpa_supplicant) client. Dani publickey - leva@ecentrum.hu - 0x66E1F716.asc Description: application/pgp-keys
Re: athn: device timeout
On Sun, May 19, 2019 at 05:38:03PM +, Lévai, Dániel wrote: > And for some reason -- and this is really strange, I know --, sometimes it > gets into a state where no client can connect/auth to the AP, and nothing > seems to be able to fix it other than a hard reset of the AP. On a Linux > client machine with wpa_supplicant(8) these are the log messages when this > latter happens: > > May 19 19:08:38 serenity kernel: wlan0: authenticate with > May 19 19:08:38 serenity kernel: wlan0: send auth to (try 1/3) > May 19 19:08:38 serenity kernel: wlan0: authenticated > May 19 19:08:38 serenity kernel: wlan0: associate with (try 1/3) > May 19 19:08:38 serenity kernel: wlan0: RX AssocResp from (capab=0x411 > status=0 aid=2) > May 19 19:08:38 serenity kernel: wlan0: associated > May 19 19:08:39 serenity kernel: wlan0: deauthenticated from (Reason: > 15=4WAY_HANDSHAKE_TIMEOUT) > > This just goes on and on and on. And what do you see with 'ifconfig athn0 debug' on the AP?
Re: athn: device timeout
On Sunday, 19 May 2019 18:48, Stefan Sperling wrote: > On Sun, May 19, 2019 at 02:30:25PM +, Lévai, Dániel wrote: > > > Hi everyone! > > I wonder if this 0 particular issue is what I'm experiencing. Judging from > > the fact that the only thing needed for this to happen is a full-bandwidth > > (~1MB/s) throughput via athn0 for about 20 seconds, I'm inclined to say yes. > > I wanted to ask if this 1 commit should've fixed these kind of issues, or > > that "recalibration" is something else. > > What is your reason for asking? > > These timeouts should be infrequent and the driver should recover > without intervention. If that matches your case, there is nothing > critical to fix, though it would of course be nice to understand > and perhaps fix the problem. > > Are these device timeouts causing you actual problems or are you > just curious why these messages are appearing? Well, in my experience here, there are two different kinds of consequences that can happen when these timeouts occur. The first (that happens let's say 90% of the time) can be fixed with a swift: # /sbin/ifconfig athn0 down; sleep 1; /sbin/ifconfig athn0 up It needs to be done, but at least it's fixable -- otherwise no client can connect the AP. And for some reason -- and this is really strange, I know --, sometimes it gets into a state where no client can connect/auth to the AP, and nothing seems to be able to fix it other than a hard reset of the AP. On a Linux client machine with wpa_supplicant(8) these are the log messages when this latter happens: May 19 19:08:38 serenity kernel: wlan0: authenticate with May 19 19:08:38 serenity kernel: wlan0: send auth to (try 1/3) May 19 19:08:38 serenity kernel: wlan0: authenticated May 19 19:08:38 serenity kernel: wlan0: associate with (try 1/3) May 19 19:08:38 serenity kernel: wlan0: RX AssocResp from (capab=0x411 status=0 aid=2) May 19 19:08:38 serenity kernel: wlan0: associated May 19 19:08:39 serenity kernel: wlan0: deauthenticated from (Reason: 15=4WAY_HANDSHAKE_TIMEOUT) This just goes on and on and on. But e.g. Android phones cannot connect to the AP either in this case, and they say "Check password and try again" in the Wi-Fi settings menu, after trying to reconnect quickly a number of times -- these are really rapid, max 1 sec in between the retries. Bear in mind that I didn't not change the password on the AP or the phone. Now I'm gradually trying to lower the allowed bandwidth of the athn(4) devices with pf(4) to see if there's any setting where it wouldn't fail (lowered from around the default/max 1MB/s, in the 800KB/s range this still happened). > The latter is hard to say without sitting in front of your box. > Device timeouts mean the hardware failed to send one frame. > Which can happen for any number of reasons. Hm, is it worth trying to switch around e.g. antennas? Dani
Re: athn: device timeout
On Sun, May 19, 2019 at 02:30:25PM +, Lévai, Dániel wrote: > Hi everyone! > > I wonder if this [0] particular issue is what I'm experiencing. Judging from > the fact that the only thing needed for this to happen is a full-bandwidth > (~1MB/s) throughput via athn0 for about 20 seconds, I'm inclined to say yes. > I wanted to ask if this [1] commit should've fixed these kind of issues, or > that "recalibration" is something else. What is your reason for asking? These timeouts should be infrequent and the driver should recover without intervention. If that matches your case, there is nothing critical to fix, though it would of course be nice to understand and perhaps fix the problem. Are these device timeouts causing you actual problems or are you just curious why these messages are appearing? The latter is hard to say without sitting in front of your box. Device timeouts mean the hardware failed to send one frame. Which can happen for any number of reasons. > I'm using a wle200nx (9280) in a PC Engines apu4c4 running 6.5 now and > interestingly enough, I didn't experience these timeouts with 6.4 (although > with the same wle200nx in a different hardware). > Also, I'm running with this [2] patch over -stable, I don't know if that > should make a difference. Irrelevant. That patch fixes 1T2R devices; you have a 2T2R device. > [0]: https://marc.info/?l=openbsd-misc=151782917217806=2 > [1]: > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/athn.c.diff?r1=1.100=1.101 > [2]: > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/athn.c.diff?r1=1.102=1.103 > > Any insight is appreciated! > > Thanks, > Dani > > > dmesg: > OpenBSD 6.5-stable (GENERIC.MP) #1: Thu May 16 16:36:18 CEST 2019 > daniell@firefly:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 4261203968 (4063MB) > avail mem = 4122423296 (3931MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdffd7020 (7 entries) > bios0: vendor coreboot version "v4.0.24" date 02/04/2019 > bios0: PC Engines apu4 > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S1 S2 S3 S4 S5 > acpi0: tables DSDT FACP SSDT APIC HEST SSDT SSDT HPET > acpi0: wakeup devices PWRB(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) > UOH1(S3) UOH3(S3) UOH5(S3) XHC0(S4) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD GX-412TC SOC, 998.25 MHz, 16-30-01 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT > cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line > 16-way L2 cache > cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative > cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: AMD GX-412TC SOC, 998.14 MHz, 16-30-01 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT > cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line > 16-way L2 cache > cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative > cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 2 (application processor) > cpu2: AMD GX-412TC SOC, 998.14 MHz, 16-30-01 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT > cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line > 16-way L2 cache > cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative > cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 3 (application processor) > cpu3: AMD GX-412TC SOC, 998.23 MHz, 16-30-01 > cpu3: >
athn: device timeout
Hi everyone! I wonder if this [0] particular issue is what I'm experiencing. Judging from the fact that the only thing needed for this to happen is a full-bandwidth (~1MB/s) throughput via athn0 for about 20 seconds, I'm inclined to say yes. I wanted to ask if this [1] commit should've fixed these kind of issues, or that "recalibration" is something else. I'm using a wle200nx (9280) in a PC Engines apu4c4 running 6.5 now and interestingly enough, I didn't experience these timeouts with 6.4 (although with the same wle200nx in a different hardware). Also, I'm running with this [2] patch over -stable, I don't know if that should make a difference. [0]: https://marc.info/?l=openbsd-misc=151782917217806=2 [1]: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/athn.c.diff?r1=1.100=1.101 [2]: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/athn.c.diff?r1=1.102=1.103 Any insight is appreciated! Thanks, Dani dmesg: OpenBSD 6.5-stable (GENERIC.MP) #1: Thu May 16 16:36:18 CEST 2019 daniell@firefly:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4261203968 (4063MB) avail mem = 4122423296 (3931MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdffd7020 (7 entries) bios0: vendor coreboot version "v4.0.24" date 02/04/2019 bios0: PC Engines apu4 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S2 S3 S4 S5 acpi0: tables DSDT FACP SSDT APIC HEST SSDT SSDT HPET acpi0: wakeup devices PWRB(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) UOH3(S3) UOH5(S3) XHC0(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD GX-412TC SOC, 998.25 MHz, 16-30-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD GX-412TC SOC, 998.14 MHz, 16-30-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD GX-412TC SOC, 998.14 MHz, 16-30-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD GX-412TC SOC, 998.23 MHz, 16-30-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins ioapic1 at mainbus0: apid 5 pa 0xfec2, version 21, 32 pins, remapped acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PBR4) acpiprt2 at acpi0: bus 2 (PBR5) acpiprt3 at acpi0: bus 3 (PBR6) acpiprt4 at acpi0: bus 4 (PBR7) acpiprt5 at acpi0: bus 5 (PBR8) acpicpu0 at acpi0: C2(0@400
Re: frequently wifi athn device timeout
On Wed, Apr 08, 2015 at 01:17:01PM +0200, Stefan Sperling wrote: On Tue, Mar 17, 2015 at 03:36:03PM -0300, Henrique Lengler wrote: My intenert falled again, but with this option I didn't received device timeout, I received this: Hi Henrique, The output you sent shows things are working fine, it doesn't show any problem. So we're still at square 1 with this issue. Can somebody please try to provide a recipe that triggers the problem reliably? Note that a device timeout implies the device has failed to send a frame. This could happen because: - there is some transmission problem with the device itself - some USB problem is preventing transmission - some USB problem is preventing notification of successfull transmission to the driver - the AP failed to ACK the frame, either because it did not receive it (out of range, interference, ...) or because the athn device could not receive the ACK from the AP Without more information it's difficult to say what's going on. If you're in a position to run tcpdump -y IEEE802_11_RADIO on the AP please watch for frames sent from the USB device and try to figure out where the frame is lost. Please also see http://marc.info/?l=openbsd-miscm=141501277608157w=2 which is about the same driver on PCI instead of USB. As long as running 'ifconfig athn0 down up' restores connectivity on USB I have more important issues to look at and won't spend more of my time trying to reproduce this problem unless more information is provided. So I said I am receiving less timeouts, thats true. But yesterday and today again something happened, that could not be solved by simply running 'ifconfig athn0 down up'. This is what I received (messages from dmesg). athn0: device timeout athn0: device timeout athn0: device timeout athn0: device timeout athn0: firmware command 0x17 timed out athn0: firmware command 0x18 timed out athn0: firmware command 0x3 timed out athn0: firmware command 0x17 timed out athn0: firmware command 0x17 timed out athn0: firmware command 0x18 timed out athn0: firmware command 0x17 timed out athn0: firmware command 0x17 timed out athn0: firmware command 0x18 timed out athn0: firmware command 0x17 timed out athn0: firmware command 0x17 timed out athn0: firmware command 0x18 timed out athn0: firmware command 0x17 timed out athn0: firmware command 0x17 timed out athn0: firmware command 0x18 timed out athn0: firmware command 0x17 timed out athn0: firmware command 0x17 timed out athn0: firmware command 0x18 timed out athn0: firmware command 0x17 timed out athn0: firmware command 0x17 timed out athn0: firmware command 0x18 timed out athn0: firmware command 0x17 timed out athn0: firmware command 0x17 timed out The four first messages are normal, and can be solved by reseting connections. But a new type appeared, and these I couldn't solve running ifconfig. When I ran 'ifconfig athn0 down up' it didn't anything, and I wasn't able to close the process. Reboot was the only option. I ran this (don't know if it gives good information): # tcpdump -L tcpdump: WARNING: snaplen raised from 116 to 160 tcnk type supported: PFLOG # tcpdump -y PFLOG tcpdump: WARNING: snaplen raised from 116 to 160 tcpdump: listening on pflog0, link-type PFLOG pdump: WARNING: snaplen raised from 116 to 160 -- Regards Henrique Lengler
Re: frequently wifi athn device timeout
On Tue, Mar 17, 2015 at 03:36:03PM -0300, Henrique Lengler wrote: My intenert falled again, but with this option I didn't received device timeout, I received this: Hi Henrique, The output you sent shows things are working fine, it doesn't show any problem. So we're still at square 1 with this issue. Can somebody please try to provide a recipe that triggers the problem reliably? Note that a device timeout implies the device has failed to send a frame. This could happen because: - there is some transmission problem with the device itself - some USB problem is preventing transmission - some USB problem is preventing notification of successfull transmission to the driver - the AP failed to ACK the frame, either because it did not receive it (out of range, interference, ...) or because the athn device could not receive the ACK from the AP Without more information it's difficult to say what's going on. If you're in a position to run tcpdump -y IEEE802_11_RADIO on the AP please watch for frames sent from the USB device and try to figure out where the frame is lost. Please also see http://marc.info/?l=openbsd-miscm=141501277608157w=2 which is about the same driver on PCI instead of USB. As long as running 'ifconfig athn0 down up' restores connectivity on USB I have more important issues to look at and won't spend more of my time trying to reproduce this problem unless more information is provided.
Re: frequently wifi athn device timeout
On Wed, Apr 08, 2015 at 01:17:01PM +0200, Stefan Sperling wrote: Hi Henrique, The output you sent shows things are working fine, it doesn't show any problem. So we're still at square 1 with this issue. I would say that lately I am receiving less timeouts, last day I got only about one or two, it is not perfect, but the system is usable. I am suspecting about some other device connected to my network, but also think that this could also be a software problem, since I had no problem with this device on Linux. Maybe it is the capacity of it recover automatically from a fall. Can somebody please try to provide a recipe that triggers the problem reliably? I will look for a way to systematically reproduce this problem. Note that a device timeout implies the device has failed to send a frame. This could happen because: - there is some transmission problem with the device itself - some USB problem is preventing transmission - some USB problem is preventing notification of successfull transmission to the driver - the AP failed to ACK the frame, either because it did not receive it (out of range, interference, ...) or because the athn device could not receive the ACK from the AP Without more information it's difficult to say what's going on. If you're in a position to run tcpdump -y IEEE802_11_RADIO on the AP please watch for frames sent from the USB device and try to figure out where the frame is lost. I will look at this. Please also see http://marc.info/?l=openbsd-miscm=141501277608157w=2 which is about the same driver on PCI instead of USB. As long as running 'ifconfig athn0 down up' restores connectivity on USB I have more important issues to look at and won't spend more of my time trying to reproduce this problem unless more information is provided. This is understandable, I will try to get more information, and discover the cause. Thanks; -- Regards Henrique Lengler
Re: frequently wifi athn device timeout
Yes, I do use Irssi and chromium all the time. On Thu, Mar 19, 2015 at 6:02 AM, Henrique Lengler henriquel...@opmbx.org wrote: On Tue, Mar 17, 2015 at 11:12:34AM +0300, Evgeny Zhavoronkov wrote: I have the same problem with the latest snapshot and yes, the problem is with any AP and they are in range 1-5 meters. Do you use irssi and/or chromium? To me looks like when I am running these apps, I get more timeouts. -- Regards Henrique Lengler
Re: frequently wifi athn device timeout
On Thu, Mar 19, 2015 at 12:02:29AM -0300, Henrique Lengler wrote: Do you use irssi and/or chromium? To me looks like when I am running these apps, I get more timeouts. Could a app be the problem? I deleted all the packages and I am running withou chromium for 3 hours and I get no timeout. -- Regards Henrique Lengler
Re: frequently wifi athn device timeout
On Tue, Mar 17, 2015 at 11:12:34AM +0300, Evgeny Zhavoronkov wrote: I have the same problem with the latest snapshot and yes, the problem is with any AP and they are in range 1-5 meters. Do you use irssi and/or chromium? To me looks like when I am running these apps, I get more timeouts. -- Regards Henrique Lengler
Re: frequently wifi athn device timeout
On Mon, Mar 16, 2015 at 07:01:56PM -0300, Henrique Lengler wrote: I have a tl-wn722n wifi usb adapter. It uses the athn0 driver. My connection is frequently getting down, and I am receiving a message athn0: device timeout. So to solve I need to run $ sudo sh /etc/netstart I am running -current and I already had this problem, with 5.6 -release and -stable too. I have applied this patch: https://marc.info/?l=openbsd-techm=142591741103252w=2 But anything changed. This is my /etc/hostname.athn0 nwid linksys wpakey foobar dhcp the dmesg is attached. Does this happen with any access point or just one? If it's just one, are you sure you're in range of the AP?
Re: frequently wifi athn device timeout
I have the same problem with the latest snapshot and yes, the problem is with any AP and they are in range 1-5 meters. On Tue, Mar 17, 2015 at 10:22 AM, Stefan Sperling s...@stsp.name wrote: On Mon, Mar 16, 2015 at 07:01:56PM -0300, Henrique Lengler wrote: I have a tl-wn722n wifi usb adapter. It uses the athn0 driver. My connection is frequently getting down, and I am receiving a message athn0: device timeout. So to solve I need to run $ sudo sh /etc/netstart I am running -current and I already had this problem, with 5.6 -release and -stable too. I have applied this patch: https://marc.info/?l=openbsd-techm=142591741103252w=2 But anything changed. This is my /etc/hostname.athn0 nwid linksys wpakey foobar dhcp the dmesg is attached. Does this happen with any access point or just one? If it's just one, are you sure you're in range of the AP?
Re: frequently wifi athn device timeout
On Tue, Mar 17, 2015 at 11:12:34AM +0300, Evgeny Zhavoronkov wrote: I have the same problem with the latest snapshot and yes, the problem is with any AP and they are in range 1-5 meters. I have the same adapter and I don't see the issue. What mode/channel are you using? Please provide output of ifconfig that clearly shows how you're connected. If you run 'ifconfig athn0 debug' do you then see any particular message when the timeout happens?
Re: frequently wifi athn device timeout
On Tue, Mar 17, 2015 at 10:15:13AM +0100, Stefan Sperling wrote: On Tue, Mar 17, 2015 at 11:12:34AM +0300, Evgeny Zhavoronkov wrote: I have the same problem with the latest snapshot and yes, the problem is with any AP and they are in range 1-5 meters. I have the same adapter and I don't see the issue. What mode/channel are you using? The router config site says it is channel 1 - 2.412GHz Please provide output of ifconfig that clearly shows how you're connected. /home/henri $ ifconfig athn0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr f4:ec:38:90:cd:63 priority: 4 groups: wlan egress media: IEEE802.11 autoselect (DS1 mode 11g) status: active ieee80211: nwid linksys chan 1 bssid 00:23:69:fd:6d:8a -67dBm wpakey not displayed wpaprotos wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp wpagroupcipher tkip inet 192.168.1.104 netmask 0xff00 broadcast 192.168.1.255 pflog0: flags=141UP,RUNNING,PROMISC mtu 33144 priority: 0 groups: pflog If you run 'ifconfig athn0 debug' do you then see any particular message when the timeout happens? My intenert falled again, but with this option I didn't received device timeout, I received this: athn0: AR9271 rev 1 (1T1R), ROM rev 13, address f4:ec:38:90:cd:63 athn0: begin active scan athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 2 mode 11g athn0: received probe_resp from 00:23:69:fd:6d:8a rssi -67 mode 11g athn0: received probe_resp from 00:23:69:fd:6d:8a rssi -69 mode 11g athn0: received beacon from 00:23:69:fd:6d:8a rssi -67 mode 11g athn0: received beacon from 00:23:69:fd:6d:8a rssi -67 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 3 mode 11g athn0: received beacon from 00:23:69:fd:6d:8a rssi -73 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 4 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 5 mode 11g athn0: received beacon from ec:f0:0e:04:f2:94 rssi -89 mode 11g athn0: received beacon from 00:26:5a:66:ef:32 rssi -87 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 6 mode 11g athn0: received beacon from 00:26:5a:66:ef:32 rssi -87 mode 11g athn0: received beacon from ec:f0:0e:04:f2:94 rssi -91 mode 11g athn0: received beacon from 10:fe:ed:3d:33:b0 rssi -86 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 7 mode 11g athn0: received beacon from 10:fe:ed:3d:33:b0 rssi -86 mode 11g athn0: received beacon from 00:26:5a:66:ef:32 rssi -85 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 8 mode 11g athn0: received beacon from 00:0c:42:66:e9:de rssi -88 mode 11g athn0: received beacon from 00:0c:42:66:e9:de rssi -88 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 9 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 10 mode 11g athn0: received beacon from 0c:96:bf:7f:98:2f rssi -85 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 11 mode 11g athn0: received beacon from dc:9f:db:54:7a:d4 rssi -88 mode 11g athn0: received beacon from 0c:96:bf:7f:98:2f rssi -82 mode 11g athn0: received beacon from 0c:96:bf:7f:98:2f rssi -83 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 12 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 13 mode 11g athn0: received beacon from dc:9f:db:58:91:a9 rssi -74 mode 11g athn0: received beacon from dc:9f:db:58:91:a9 rssi -79 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 14 mode 11g athn0: sending probe_req to ff:ff:ff:ff:ff:ff on channel 1 mode 11g athn0: received probe_resp from 00:23:69:fd:6d:8a rssi -65 mode 11g athn0: received beacon from 00:23:69:fd:6d:8a rssi -65 mode 11g athn0: received beacon from 18:17:25:1d:fd:72 rssi -90 mode 11g athn0: received beacon from 00:23:69:fd:6d:8a rssi -65 mode 11g athn0: end active scan athn0: sending auth to 00:23:69:fd:6d:8a on channel 1 mode 11g athn0: received auth from 00:23:69:fd:6d:8a rssi -65 mode 11g athn0: sending assoc_req to 00:23:69:fd:6d:8a on channel 1 mode 11g athn0: received assoc_resp from 00:23:69:fd:6d:8a rssi -66 mode 11g athn0: associated with 00:23:69:fd:6d:8a ssid linksys channel 1 start 1Mb long p reamble short slot time athn0: received msg 1/4 of the 4-way handshake from 00:23:69:fd:6d:8a athn0: sending msg 2/4 of the 4-way handshake to 00:23:69:fd:6d:8a athn0: received msg 3/4 of the 4-way handshake from 00:23:69:fd:6d:8a athn0: sending msg 4/4 of the 4-way handshake to 00:23:69:fd:6d:8a athn0: received msg 1/2 of the group key handshake from 00:23:69:fd:6d:8a athn0: sending msg 2/2 of the group key handshake to 00:23:69:fd:6d:8a athn0: received msg 1/2 of the group key handshake from 00:23:69:fd:6d:8a athn0: sending msg 2/2 of the group key handshake to 00:23:69:fd:6d:8a -- Regards Henrique Lengler
frequently wifi athn device timeout
I have a tl-wn722n wifi usb adapter. It uses the athn0 driver. My connection is frequently getting down, and I am receiving a message athn0: device timeout. So to solve I need to run $ sudo sh /etc/netstart I am running -current and I already had this problem, with 5.6 -release and -stable too. I have applied this patch: https://marc.info/?l=openbsd-techm=142591741103252w=2 But anything changed. This is my /etc/hostname.athn0 nwid linksys wpakey foobar dhcp the dmesg is attached. -- Regards Henrique Lengler OpenBSD 5.7 (GENERIC.MP) #1: Fri Mar 13 21:11:13 BRT 2015 r...@henrique-pc.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8439386112 (8048MB) avail mem = 8210812928 (7830MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec1f0 (82 entries) bios0: vendor American Megatrends Inc. version 1401 date 07/29/2014 bios0: ASUS All Series acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT LPIT SSDT SSDT MCFG HPET SSDT SSDT BGRT acpi0: wakeup devices UAR1(S4) PS2K(S4) PS2M(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz, 3498.41 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz, 3497.97 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz, 3497.97 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz, 3497.97 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz, 3497.97 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 1, core 0, package 0 cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz, 3497.97 MHz cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu5: 256KB 64b/line 8-way L2 cache cpu5: smt 1, core 1, package 0 cpu6 at mainbus0: apid 5 (application processor) cpu6: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz, 3497.97 MHz cpu6:
