Re: urtwn(4) gets wedged periodically

2019-11-16 Thread Stefan Sperling
On Sat, Nov 16, 2019 at 05:24:37PM +0800, Kevin Lo wrote:
> Despite our USB issues, there are minor problems with the urtwn(4) for
> RTL8188C/RTL8192C:
> 
> - we don't need to enable/disable efuse access protection; it may prevent
>   incorrect mac address read from efuse.
> - disable BB/RF is not needed.

ok stsp@

> Index: sys/dev/ic/rtwn.c
> ===
> RCS file: /cvs/src/sys/dev/ic/rtwn.c,v
> retrieving revision 1.46
> diff -u -p -u -p -r1.46 rtwn.c
> --- sys/dev/ic/rtwn.c 25 Apr 2019 01:52:13 -  1.46
> +++ sys/dev/ic/rtwn.c 16 Nov 2019 09:23:07 -
> @@ -529,7 +529,9 @@ rtwn_efuse_read(struct rtwn_softc *sc, u
>   uint32_t reg;
>   int i, len;
>  
> - rtwn_write_1(sc, R92C_EFUSE_ACCESS, R92C_EFUSE_ACCESS_ON);
> + if (!(sc->chip & (RTWN_CHIP_92C | RTWN_CHIP_88C)))
> + rtwn_write_1(sc, R92C_EFUSE_ACCESS, R92C_EFUSE_ACCESS_ON);
> +
>   rtwn_efuse_switch_power(sc);
>  
>   memset(rom, 0xff, size);
> @@ -571,7 +573,8 @@ rtwn_efuse_read(struct rtwn_softc *sc, u
>   printf("\n");
>   }
>  #endif
> - rtwn_write_1(sc, R92C_EFUSE_ACCESS, R92C_EFUSE_ACCESS_OFF);
> + if (!(sc->chip & (RTWN_CHIP_92C | RTWN_CHIP_88C)))
> + rtwn_write_1(sc, R92C_EFUSE_ACCESS, R92C_EFUSE_ACCESS_OFF);
>  }
>  
>  void
> Index: sys/dev/usb/if_urtwn.c
> ===
> RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
> retrieving revision 1.84
> diff -u -p -u -p -r1.84 if_urtwn.c
> --- sys/dev/usb/if_urtwn.c12 Sep 2019 12:55:07 -  1.84
> +++ sys/dev/usb/if_urtwn.c16 Nov 2019 09:23:07 -
> @@ -1704,21 +1704,6 @@ urtwn_r92c_power_on(struct urtwn_softc *
>   urtwn_write_2(sc, R92C_SYS_ISO_CTRL,
>   urtwn_read_2(sc, R92C_SYS_ISO_CTRL) & ~R92C_SYS_ISO_CTRL_DIOR);
>  
> - /* Initialize MAC. */
> - urtwn_write_1(sc, R92C_APSD_CTRL,
> - urtwn_read_1(sc, R92C_APSD_CTRL) & ~R92C_APSD_CTRL_OFF);
> - for (ntries = 0; ntries < 200; ntries++) {
> - if (!(urtwn_read_1(sc, R92C_APSD_CTRL) &
> - R92C_APSD_CTRL_OFF_STATUS))
> - break;
> - DELAY(5);
> - }
> - if (ntries == 200) {
> - printf("%s: timeout waiting for MAC initialization\n",
> - sc->sc_dev.dv_xname);
> - return (ETIMEDOUT);
> - }
> -
>   /* Enable MAC DMA/WMAC/SCHEDULE/SEC blocks. */
>   reg = urtwn_read_2(sc, R92C_CR);
>   reg |= R92C_CR_HCI_TXDMA_EN | R92C_CR_HCI_RXDMA_EN |
> 
> 



Re: urtwn(4) gets wedged periodically

2019-11-16 Thread Kevin Lo
On Wed, Nov 13, 2019 at 01:41:28AM -0500, Brennan Vincent wrote:
> Hello,
> 
> I have a Wi-Fi USB adapter. urtwn(4) normally works fine, but it's a bit 
> flaky... 
> 
> The issue happens both on 6.6 and on -current.
> 
> When my adapter gets into the bad state, it appears (from dmesg output) that
> the driver is scanning for access points over and over, never
> finding any. When I get into this wedged state, I don't know any way
> to bring the card back up other than unplugging it and re-inserting.
> (`ifconfig urtwn0 down && sleep 10 && sh /etc/netstart urtwn0`
> is no help).
> 
> I am attaching the relevant snippets of the dmesg output
> (Kernel built with URTWN_DEBUG and urtwn_debug level set to 3).
> 
> Another interesting thing is these "RX status=6" error messages in the
> output. Apparently, "6" corresponds to "USBD_CANCELLED"
> in sys/dev/usb/usbdi.h .
> 
> I don't think this is a hardware issue because the device is
> working fine on Ubuntu.
> 
> Please let me know if there is anything more I can do to help debug this.
> I am a beginner with OpenBSD so I'm not sure exactly what is relevant.

Despite our USB issues, there are minor problems with the urtwn(4) for
RTL8188C/RTL8192C:

- we don't need to enable/disable efuse access protection; it may prevent
  incorrect mac address read from efuse.
- disable BB/RF is not needed.

Index: sys/dev/ic/rtwn.c
===
RCS file: /cvs/src/sys/dev/ic/rtwn.c,v
retrieving revision 1.46
diff -u -p -u -p -r1.46 rtwn.c
--- sys/dev/ic/rtwn.c   25 Apr 2019 01:52:13 -  1.46
+++ sys/dev/ic/rtwn.c   16 Nov 2019 09:23:07 -
@@ -529,7 +529,9 @@ rtwn_efuse_read(struct rtwn_softc *sc, u
uint32_t reg;
int i, len;
 
-   rtwn_write_1(sc, R92C_EFUSE_ACCESS, R92C_EFUSE_ACCESS_ON);
+   if (!(sc->chip & (RTWN_CHIP_92C | RTWN_CHIP_88C)))
+   rtwn_write_1(sc, R92C_EFUSE_ACCESS, R92C_EFUSE_ACCESS_ON);
+
rtwn_efuse_switch_power(sc);
 
memset(rom, 0xff, size);
@@ -571,7 +573,8 @@ rtwn_efuse_read(struct rtwn_softc *sc, u
printf("\n");
}
 #endif
-   rtwn_write_1(sc, R92C_EFUSE_ACCESS, R92C_EFUSE_ACCESS_OFF);
+   if (!(sc->chip & (RTWN_CHIP_92C | RTWN_CHIP_88C)))
+   rtwn_write_1(sc, R92C_EFUSE_ACCESS, R92C_EFUSE_ACCESS_OFF);
 }
 
 void
Index: sys/dev/usb/if_urtwn.c
===
RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
retrieving revision 1.84
diff -u -p -u -p -r1.84 if_urtwn.c
--- sys/dev/usb/if_urtwn.c  12 Sep 2019 12:55:07 -  1.84
+++ sys/dev/usb/if_urtwn.c  16 Nov 2019 09:23:07 -
@@ -1704,21 +1704,6 @@ urtwn_r92c_power_on(struct urtwn_softc *
urtwn_write_2(sc, R92C_SYS_ISO_CTRL,
urtwn_read_2(sc, R92C_SYS_ISO_CTRL) & ~R92C_SYS_ISO_CTRL_DIOR);
 
-   /* Initialize MAC. */
-   urtwn_write_1(sc, R92C_APSD_CTRL,
-   urtwn_read_1(sc, R92C_APSD_CTRL) & ~R92C_APSD_CTRL_OFF);
-   for (ntries = 0; ntries < 200; ntries++) {
-   if (!(urtwn_read_1(sc, R92C_APSD_CTRL) &
-   R92C_APSD_CTRL_OFF_STATUS))
-   break;
-   DELAY(5);
-   }
-   if (ntries == 200) {
-   printf("%s: timeout waiting for MAC initialization\n",
-   sc->sc_dev.dv_xname);
-   return (ETIMEDOUT);
-   }
-
/* Enable MAC DMA/WMAC/SCHEDULE/SEC blocks. */
reg = urtwn_read_2(sc, R92C_CR);
reg |= R92C_CR_HCI_TXDMA_EN | R92C_CR_HCI_RXDMA_EN |



Re: urtwn(4) gets wedged periodically

2019-11-14 Thread Roderick



On Wed, 13 Nov 2019, Theo de Raadt wrote:


The mailing lists are full of discussions of bugs in usb.


This could explain, why devices that have problems in OpenBSD have
no problem in FreeBSD, although they ported the driver from OpenBSD.


But no, let's keep concluding these problems is narrowly restricted
to a specific brand of device...


But there is indeed diferences on brands. And I have run(4) devices
that works and other that do not work.

Rodrigo.



Re: urtwn(4) gets wedged periodically

2019-11-14 Thread Stefan Sperling
On Wed, Nov 13, 2019 at 12:30:23PM -0700, Theo de Raadt wrote:
> These are usb devices.  There are multiple usb bus drivers, with
> usb2 and usb3 variations, and the usb subsystem itself.  The mailing
> lists are full of discussions of bugs in usb.
> 
> But no, let's keep concluding these problems is narrowly restricted
> to a specific brand of device...

I have given up on trying to figure out non-obvious bugs in USB wifi
drivers for this reason. We need someone to look into USB issues in
order to make progress on the various hangs and power consumption
problems people have been reporting against drivers such as urtwn(4).

Granted, there could always be a bug in the wifi driver, but not having
reliable USB drivers beneath does not exactly help with debugging.

xhci(4) has problems on certain host controller models for instance.
We don't even have all the quirks and workarounds which other operating
systems apply to various host controller chipsets in our xhci(4) driver.
And then there are bugs specific to our implementation, such as this one
which was recently discovered by gerhard@:
https://marc.info/?l=openbsd-tech=157355206323832=2
We need more research into this area of bugs but we don't currently have
people who do it.

I also believe that bus power management in xhci(4) and ehci(4) is broken.
I cannot prove it, but it would be great if somebody looked into this to
find answers. athn(4) on USB seems to be suffering from something like this.



Re: urtwn(4) gets wedged periodically

2019-11-13 Thread Theo de Raadt
Ian Darwin  wrote:

> On Wed, Nov 13, 2019 at 01:25:46PM -0500, Ted Unangst wrote:
> > > Can you give me the exact model of the one you bought recently? I have 
> > > half a mind to just write
> > > off mine as a loss and buy something else.
> > 
> > I am using this one: (the TL-WN725N N150 single band one)
> > 
> > https://www.amazon.com/TP-Link-wireless-network-Adapter-SoftAP/dp/B008IFXQFU/
> 
> I have that one and it wedges occasionally (on a MacBook Pro
> with 6.6-current), though infrequently.

Something keeps not being mentioned.

These are usb devices.  There are multiple usb bus drivers, with
usb2 and usb3 variations, and the usb subsystem itself.  The mailing
lists are full of discussions of bugs in usb.

But no, let's keep concluding these problems is narrowly restricted
to a specific brand of device...



Re: urtwn(4) gets wedged periodically

2019-11-13 Thread Brennan Vincent



> On Nov 13, 2019, at 2:24 PM, Ian Darwin  wrote:
> 
> On Wed, Nov 13, 2019 at 01:25:46PM -0500, Ted Unangst wrote:
>>> Can you give me the exact model of the one you bought recently? I have 
>>> half a mind to just write
>>> off mine as a loss and buy something else.
>> 
>> I am using this one: (the TL-WN725N N150 single band one)
>> 
>> https://www.amazon.com/TP-Link-wireless-network-Adapter-SoftAP/dp/B008IFXQFU/
> 
> I have that one and it wedges occasionally (on a MacBook Pro
> with 6.6-current), though infrequently.

That’s fine. Mine wedges every few hours or less. If “infrequently” means less 
than once a day, I am okay with it.

Do you need to reboot when it gets screwed up, or does a remove+reinsert get 
you up and running again?



Re: urtwn(4) gets wedged periodically

2019-11-13 Thread Ian Darwin
On Wed, Nov 13, 2019 at 01:25:46PM -0500, Ted Unangst wrote:
> > Can you give me the exact model of the one you bought recently? I have 
> > half a mind to just write
> > off mine as a loss and buy something else.
> 
> I am using this one: (the TL-WN725N N150 single band one)
> 
> https://www.amazon.com/TP-Link-wireless-network-Adapter-SoftAP/dp/B008IFXQFU/

I have that one and it wedges occasionally (on a MacBook Pro
with 6.6-current), though infrequently.



Re: urtwn(4) gets wedged periodically

2019-11-13 Thread Ted Unangst
Brennan Vincent wrote:
> 
> On 11/13/19 1:56 AM, Ted Unangst wrote:
> > Brennan Vincent wrote:
> >> Hello,
> >>
> >> I have a Wi-Fi USB adapter. urtwn(4) normally works fine, but it's a bit
> >> flaky...
> >> I don't think this is a hardware issue because the device is
> >> working fine on Ubuntu.
> > I think this is and isn't a hardware issue? I had the same problem with an
> > edimax a few years ago. I lost it and recently replaced it with a TP Link
> > model and it works a little better?
> >
> > There doesn't seem to be much variation in hardware designs, but I noticed
> > the old one was frequently very hot, and the new one is not.
> Ah, I think I am in a similar boat. Mine is an Edimax also, and it does 
> frequently get hot.
> 
> Can you give me the exact model of the one you bought recently? I have 
> half a mind to just write
> off mine as a loss and buy something else.

I am using this one: (the TL-WN725N N150 single band one)

https://www.amazon.com/TP-Link-wireless-network-Adapter-SoftAP/dp/B008IFXQFU/



Re: urtwn(4) gets wedged periodically

2019-11-12 Thread Brennan Vincent



On 11/13/19 1:56 AM, Ted Unangst wrote:

Brennan Vincent wrote:

Hello,

I have a Wi-Fi USB adapter. urtwn(4) normally works fine, but it's a bit
flaky...
I don't think this is a hardware issue because the device is
working fine on Ubuntu.

I think this is and isn't a hardware issue? I had the same problem with an
edimax a few years ago. I lost it and recently replaced it with a TP Link
model and it works a little better?

There doesn't seem to be much variation in hardware designs, but I noticed
the old one was frequently very hot, and the new one is not.
Ah, I think I am in a similar boat. Mine is an Edimax also, and it does 
frequently get hot.


Can you give me the exact model of the one you bought recently? I have 
half a mind to just write

off mine as a loss and buy something else.




Re: urtwn(4) gets wedged periodically

2019-11-12 Thread Brennan Vincent

On 11/13/19 1:41 AM, Brennan Vincent wrote:

Hello,

I have a Wi-Fi USB adapter. urtwn(4) normally works fine, but it's a bit
flaky...

The issue happens both on 6.6 and on -current.

When my adapter gets into the bad state, it appears (from dmesg output) that
the driver is scanning for access points over and over, never
finding any. When I get into this wedged state, I don't know any way
to bring the card back up other than unplugging it and re-inserting.
(`ifconfig urtwn0 down && sleep 10 && sh /etc/netstart urtwn0`
is no help).

I am attaching the relevant snippets of the dmesg output
(Kernel built with URTWN_DEBUG and urtwn_debug level set to 3).

Another interesting thing is these "RX status=6" error messages in the
output. Apparently, "6" corresponds to "USBD_CANCELLED"
in sys/dev/usb/usbdi.h .

I don't think this is a hardware issue because the device is
working fine on Ubuntu.

Please let me know if there is anything more I can do to help debug this.
I am a beginner with OpenBSD so I'm not sure exactly what is relevant.
Just to clarify: the parts of that dmesg output where the device is 
wedged is where you see tons of lines of `urtwn0: SCAN -> SCAN` and 
little else. The parts where it's actually printing out access point 
names and so on are when things are working fine.




Re: urtwn(4) gets wedged periodically

2019-11-12 Thread Ted Unangst
Brennan Vincent wrote:
> Hello,
> 
> I have a Wi-Fi USB adapter. urtwn(4) normally works fine, but it's a bit 
> flaky... 

> I don't think this is a hardware issue because the device is
> working fine on Ubuntu.

I think this is and isn't a hardware issue? I had the same problem with an
edimax a few years ago. I lost it and recently replaced it with a TP Link
model and it works a little better?

There doesn't seem to be much variation in hardware designs, but I noticed
the old one was frequently very hot, and the new one is not.



urtwn(4) gets wedged periodically

2019-11-12 Thread Brennan Vincent
Hello,

I have a Wi-Fi USB adapter. urtwn(4) normally works fine, but it's a bit 
flaky... 

The issue happens both on 6.6 and on -current.

When my adapter gets into the bad state, it appears (from dmesg output) that
the driver is scanning for access points over and over, never
finding any. When I get into this wedged state, I don't know any way
to bring the card back up other than unplugging it and re-inserting.
(`ifconfig urtwn0 down && sleep 10 && sh /etc/netstart urtwn0`
is no help).

I am attaching the relevant snippets of the dmesg output
(Kernel built with URTWN_DEBUG and urtwn_debug level set to 3).

Another interesting thing is these "RX status=6" error messages in the
output. Apparently, "6" corresponds to "USBD_CANCELLED"
in sys/dev/usb/usbdi.h .

I don't think this is a hardware issue because the device is
working fine on Ubuntu.

Please let me know if there is anything more I can do to help debug this.
I am a beginner with OpenBSD so I'm not sure exactly what is relevant.
OpenBSD 6.6-current (GENERIC.MP) #5: Tue Nov 12 23:44:31 EST 2019
bren...@washington.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16867749888 (16086MB)
avail mem = 16344203264 (15587MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xe7450 (96 entries)
bios0: vendor Dell Inc. version "1.7.1" date 07/07/2019
bios0: Dell Inc. XPS 15 9575
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT BOOT SSDT SSDT HPET SSDT 
UEFI SSDT LPIT SSDT SSDT SSDT SSDT DBGP DBG2 SSDT SSDT MSDM SLIC SSDT NHLT BGRT 
TPM2 SSDT ASF! DMAR
acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) 
RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) 
RP13(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-8705G CPU @ 3.10GHz, 3692.80 MHz, 06-9e-09
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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
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 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz, 3691.41 MHz, 06-9e-09
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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
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-8705G CPU @ 3.10GHz, 3691.41 MHz, 06-9e-09
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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
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-8705G CPU @ 3.10GHz, 3691.41 MHz, 06-9e-09
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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
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-8705G CPU @ 3.10GHz, 3691.40 MHz, 06-9e-09
cpu4: