Re: update pcidevs for thinkpad e475 devices
On Sun, Feb 25, 2018 at 09:26:43PM -0800, Carlos Cardenas wrote: > On Mon, Feb 26, 2018 at 03:25:26PM +1100, Jonathan Gray wrote: > > On Sun, Feb 25, 2018 at 06:27:11PM -0800, Carlos Cardenas wrote: > > > Howdy. > > > > > > Attached is a patch for pcidevs for thinkpad e475 with an > > > AMD A10-9600P R5 (Carrizo) along with the dmesg output. > > > Items added: > > > * O2 Micro SD/MMC > > > * various AMD 15h/6xh devs > > > * Carrizo video > > > > A10-9600P is 'Bristol Ridge' which seems to be a tweaked Carrizo design. > > Most of the devices mentioned would have first appeared in Carrizo > > so it is right to use that name instead. > > > > And just to confuse things Carrizo-L is a quite different family 16h apu... > > My head's about to implode with trying to keep those code names straight ;-) > > Attached is an updated patch with your suggestions. > > +--+ > Carlos > Index: pcidevs > === > RCS file: /home/los/cvs/src/sys/dev/pci/pcidevs,v > retrieving revision 1.1836 > diff -u -p -r1.1836 pcidevs > --- pcidevs 23 Feb 2018 07:04:57 - 1.1836 > +++ pcidevs 26 Feb 2018 05:22:44 - > @@ -395,6 +395,7 @@ product O2MICRO OZ71340x7134 OZ711MP1 > product O2MICRO OZ7135 0x7135 OZ711EZ1 CardBus > product O2MICRO OZ7136 0x7136 OZ711SP1 CardBus > product O2MICRO OZ7223 0x7223 OZ711E0 CardBus > +product O2MICRO OZ8621 0x8621 0Z8621 SD/MMC > > /* 3Com Products */ > product 3COM 3C985 0x0001 3c985 > @@ -732,6 +733,19 @@ product AMD AMD64_16_HB 0x1536 AMD64 16 > product AMD CCP 0x1537 CCP > product AMD AMD64_16_3X_RC 0x1566 AMD64 16h Root Complex > product AMD AMD64_16_3X_HB 0x156b AMD64 16h Host > +product AMD AMD64_15_6X_LINK 0x1570 AMD64 15h Link Cfg > +product AMD AMD64_15_6X_ADDR 0x1571 AMD64 15h Address Map > +product AMD AMD64_15_6X_DRAM 0x1572 AMD64 15h DRAM Cfg > +product AMD AMD64_15_6X_MISC 0x1573 AMD64 15h Misc Cfg > +product AMD AMD64_15_6X_CPU_PM 0x1574 AMD64 15h CPU Power > +product AMD AMD64_15_6X_MISC_2 0x1575 AMD64 15h Misc Cfg > +product AMD AMD64_15_6X_RC 0x1576 AMD64 15h Root Complex > +product AMD AMD64_15_6X_IOMMU0x1577 AMD64 15h IOMMU > +product AMD AMD64_15_6X_PSP 0x1578 AMD64 15h PSP 2.0 > +product AMD AMD64_15_6X_AUDIO0x157a AMD64 15h HD Audio > +product AMD AMD64_15_6X_HB 0x157b AMD64 15h Host AMD64_15_6X_HB -> AMD64_15_6X_HB_1 > +product AMD AMD64_15_6X_PCIE_1 0x157c AMD64 15h PCIE > +product AMD AMD64_15_6X_HB_2 0x157d AMD64 15h Host > product AMD AMD64_16_3X_LINK 0x1580 AMD64 16h Link Cfg > product AMD AMD64_16_3X_ADDR 0x1581 AMD64 16h Address Map > product AMD AMD64_16_3X_DRAM 0x1582 AMD64 16h DRAM Cfg > @@ -843,6 +857,15 @@ product AMD HUDSON2_PCI 0x780f Hudson-2 > product AMD HUDSON2_XHCI 0x7812 Hudson-2 xHCI > product AMD BOLTON_SDMMC 0x7813 Bolton SD/MMC > product AMD BOLTON_XHCI 0x7814 Bolton xHCI > +product AMD CARRIZO_SATA_1 0x7900 Carrizo SATA > +product AMD CARRIZO_SATA_2 0x7901 Carrizo AHCI > +product AMD CARRIZO_SATA_3 0x7902 Carrizo RAID > +product AMD CARRIZO_SATA_4 0x7903 Carrizo RAID > +product AMD CARRIZO_SATA_5 0x7904 Carrizo AHCI CARRIZO_SATA_2 -> CARRIZO_AHCI_1 CARRIZO_SATA_5 -> CARRIZO_AHCI_2 CARRIZO_SATA_3 -> CARRIZO_RAID_1 CARRIZO_SATA_4 -> CARRIZO_RAID_2 ok jsg@ with those changes > +product AMD CARRIZO_EHCI 0x7908 Carrizo USB2 > +product AMD CARRIZO_SMB 0x790b Carrizo SMBus > +product AMD CARRIZO_LPC 0x790e Carrizo LPC > +product AMD CARRIZO_XHCI 0x7914 Carrizo xHCI > product AMD RS780_HB 0x9600 RS780 Host > product AMD RS880_HB 0x9601 RS880 Host > product AMD RS780_PCIE_1 0x9602 RS780 PCIE > @@ -1782,6 +1805,11 @@ product ATI RADEON_HD7310 0x9809 Radeon > product ATI RADEON_HD72900x980a Radeon HD 7290 > product ATI RADEON_HDA 0x9840 Radeon HD Audio > product ATI MULLINS_10x9854 Mullins > +product ATI CARRIZO_10x9870 Carrizo > +product ATI CARRIZO_20x9874 Carrizo > +product ATI CARRIZO_30x9875 Carrizo > +product ATI CARRIZO_40x9876 Carrizo > +product ATI CARRIZO_50x9877 Carrizo > product ATI ARUBA_1 0x9900 Aruba > product ATI RADEON_HD7660D 0x9901 Radeon HD 7660D > product ATI RADEON_HD7640G_1 0x9903 Radeon HD 7640G
Re: update pcidevs for thinkpad e475 devices
On Mon, Feb 26, 2018 at 03:25:26PM +1100, Jonathan Gray wrote: > On Sun, Feb 25, 2018 at 06:27:11PM -0800, Carlos Cardenas wrote: > > Howdy. > > > > Attached is a patch for pcidevs for thinkpad e475 with an > > AMD A10-9600P R5 (Carrizo) along with the dmesg output. > > Items added: > > * O2 Micro SD/MMC > > * various AMD 15h/6xh devs > > * Carrizo video > > A10-9600P is 'Bristol Ridge' which seems to be a tweaked Carrizo design. > Most of the devices mentioned would have first appeared in Carrizo > so it is right to use that name instead. > > And just to confuse things Carrizo-L is a quite different family 16h apu... My head's about to implode with trying to keep those code names straight ;-) Attached is an updated patch with your suggestions. +--+ Carlos Index: pcidevs === RCS file: /home/los/cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.1836 diff -u -p -r1.1836 pcidevs --- pcidevs 23 Feb 2018 07:04:57 - 1.1836 +++ pcidevs 26 Feb 2018 05:22:44 - @@ -395,6 +395,7 @@ product O2MICRO OZ7134 0x7134 OZ711MP1 product O2MICRO OZ7135 0x7135 OZ711EZ1 CardBus product O2MICRO OZ7136 0x7136 OZ711SP1 CardBus product O2MICRO OZ7223 0x7223 OZ711E0 CardBus +product O2MICRO OZ8621 0x8621 0Z8621 SD/MMC /* 3Com Products */ product 3COM 3C985 0x0001 3c985 @@ -732,6 +733,19 @@ product AMD AMD64_16_HB0x1536 AMD64 16 product AMD CCP0x1537 CCP product AMD AMD64_16_3X_RC 0x1566 AMD64 16h Root Complex product AMD AMD64_16_3X_HB 0x156b AMD64 16h Host +product AMD AMD64_15_6X_LINK 0x1570 AMD64 15h Link Cfg +product AMD AMD64_15_6X_ADDR 0x1571 AMD64 15h Address Map +product AMD AMD64_15_6X_DRAM 0x1572 AMD64 15h DRAM Cfg +product AMD AMD64_15_6X_MISC 0x1573 AMD64 15h Misc Cfg +product AMD AMD64_15_6X_CPU_PM 0x1574 AMD64 15h CPU Power +product AMD AMD64_15_6X_MISC_2 0x1575 AMD64 15h Misc Cfg +product AMD AMD64_15_6X_RC 0x1576 AMD64 15h Root Complex +product AMD AMD64_15_6X_IOMMU 0x1577 AMD64 15h IOMMU +product AMD AMD64_15_6X_PSP0x1578 AMD64 15h PSP 2.0 +product AMD AMD64_15_6X_AUDIO 0x157a AMD64 15h HD Audio +product AMD AMD64_15_6X_HB 0x157b AMD64 15h Host +product AMD AMD64_15_6X_PCIE_1 0x157c AMD64 15h PCIE +product AMD AMD64_15_6X_HB_2 0x157d AMD64 15h Host product AMD AMD64_16_3X_LINK 0x1580 AMD64 16h Link Cfg product AMD AMD64_16_3X_ADDR 0x1581 AMD64 16h Address Map product AMD AMD64_16_3X_DRAM 0x1582 AMD64 16h DRAM Cfg @@ -843,6 +857,15 @@ product AMD HUDSON2_PCI0x780f Hudson-2 product AMD HUDSON2_XHCI 0x7812 Hudson-2 xHCI product AMD BOLTON_SDMMC 0x7813 Bolton SD/MMC product AMD BOLTON_XHCI0x7814 Bolton xHCI +product AMD CARRIZO_SATA_1 0x7900 Carrizo SATA +product AMD CARRIZO_SATA_2 0x7901 Carrizo AHCI +product AMD CARRIZO_SATA_3 0x7902 Carrizo RAID +product AMD CARRIZO_SATA_4 0x7903 Carrizo RAID +product AMD CARRIZO_SATA_5 0x7904 Carrizo AHCI +product AMD CARRIZO_EHCI 0x7908 Carrizo USB2 +product AMD CARRIZO_SMB0x790b Carrizo SMBus +product AMD CARRIZO_LPC0x790e Carrizo LPC +product AMD CARRIZO_XHCI 0x7914 Carrizo xHCI product AMD RS780_HB 0x9600 RS780 Host product AMD RS880_HB 0x9601 RS880 Host product AMD RS780_PCIE_1 0x9602 RS780 PCIE @@ -1782,6 +1805,11 @@ product ATI RADEON_HD73100x9809 Radeon product ATI RADEON_HD7290 0x980a Radeon HD 7290 product ATI RADEON_HDA 0x9840 Radeon HD Audio product ATI MULLINS_1 0x9854 Mullins +product ATI CARRIZO_1 0x9870 Carrizo +product ATI CARRIZO_2 0x9874 Carrizo +product ATI CARRIZO_3 0x9875 Carrizo +product ATI CARRIZO_4 0x9876 Carrizo +product ATI CARRIZO_5 0x9877 Carrizo product ATI ARUBA_10x9900 Aruba product ATI RADEON_HD7660D 0x9901 Radeon HD 7660D product ATI RADEON_HD7640G_1 0x9903 Radeon HD 7640G
Re: update pcidevs for thinkpad e475 devices
On Sun, Feb 25, 2018 at 06:27:11PM -0800, Carlos Cardenas wrote: > Howdy. > > Attached is a patch for pcidevs for thinkpad e475 with an > AMD A10-9600P R5 (Carrizo) along with the dmesg output. > Items added: > * O2 Micro SD/MMC > * various AMD 15h/6xh devs > * Carrizo video A10-9600P is 'Bristol Ridge' which seems to be a tweaked Carrizo design. Most of the devices mentioned would have first appeared in Carrizo so it is right to use that name instead. And just to confuse things Carrizo-L is a quite different family 16h apu... > > Comments? Ok? > > +--+ > Carlos > OpenBSD 6.2-current (GENERIC.MP) #0: Sun Feb 25 15:32:13 PST 2018 > los@bjorn.castle:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 16524206080 (15758MB) > avail mem = 16016396288 (15274MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xdb225000 (58 entries) > bios0: vendor LENOVO version "R0EET44W (1.18 )" date 11/17/2017 > bios0: LENOVO 20H4CTO1WW > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP UEFI HPET APIC MCFG SBST MSDM BATB SSDT IVRS CRAT > TPM2 SSDT SSDT SSDT SSDT FPDT SSDT UEFI > acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP2(S4) GPP3(S4) GPP4(S4) GFX0(S4) > GFX1(S4) GFX2(S4) GFX3(S4) GFX4(S4) XHC0(S3) EHC1(S3) SBAZ(S4) LID_(S3) > SLPB(S3) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpihpet0 at acpi0: 14318180 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 16 (boot processor) > cpu0: AMD A10-9600P RADEON R5, 10 COMPUTE CORES 4C+6G, 2395.80 MHz > 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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2 > cpu0: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line > 16-way L2 cache > cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative > cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > acpihpet0: recalibrated TSC frequency 2395505539 Hz > 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 17 (application processor) > cpu1: AMD A10-9600P RADEON R5, 10 COMPUTE CORES 4C+6G, 2395.51 MHz > 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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2 > cpu1: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line > 16-way L2 cache > cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative > cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 18 (application processor) > cpu2: AMD A10-9600P RADEON R5, 10 COMPUTE CORES 4C+6G, 2395.51 MHz > 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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2 > cpu2: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line > 16-way L2 cache > cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative > cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 19 (application processor) > cpu3: AMD A10-9600P RADEON R5, 10 COMPUTE CORES 4C+6G, 2395.51 MHz > 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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2 > cpu3: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line > 16-way L2 cache > cpu3: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative > cpu3: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu3: smt 0, core 3, package 0 > ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins > , remapped to apid 4 > ioapic1 at mainbus0: apid 5 pa 0xfec010
Re: vmctl: clarify console error message
On Sun, Feb 25, 2018 at 06:30:10PM -0800, Carlos Cardenas wrote: > Attached patch clears up an ambiguous error message when attaching to a > console fails. > > The vm id is not guaranteed to be populated. > > Comments? Ok? > > +--+ > Carlos > Index: vmctl.c > === > RCS file: /home/los/cvs/src/usr.sbin/vmctl/vmctl.c,v > retrieving revision 1.45 > diff -u -p -r1.45 vmctl.c > --- vmctl.c 3 Jan 2018 05:39:56 - 1.45 > +++ vmctl.c 20 Feb 2018 05:09:09 - > @@ -702,7 +702,7 @@ vm_console(struct vmop_info_result *list > } > } > > - errx(1, "console %d not found", info_id); > + errx(1, "console not found"); > } > > /* ok mlarkin
vmctl: clarify console error message
Attached patch clears up an ambiguous error message when attaching to a console fails. The vm id is not guaranteed to be populated. Comments? Ok? +--+ Carlos Index: vmctl.c === RCS file: /home/los/cvs/src/usr.sbin/vmctl/vmctl.c,v retrieving revision 1.45 diff -u -p -r1.45 vmctl.c --- vmctl.c 3 Jan 2018 05:39:56 - 1.45 +++ vmctl.c 20 Feb 2018 05:09:09 - @@ -702,7 +702,7 @@ vm_console(struct vmop_info_result *list } } - errx(1, "console %d not found", info_id); + errx(1, "console not found"); } /*
update pcidevs for thinkpad e475 devices
Howdy. Attached is a patch for pcidevs for thinkpad e475 with an AMD A10-9600P R5 (Carrizo) along with the dmesg output. Items added: * O2 Micro SD/MMC * various AMD 15h/6xh devs * Carrizo video Comments? Ok? +--+ Carlos OpenBSD 6.2-current (GENERIC.MP) #0: Sun Feb 25 15:32:13 PST 2018 los@bjorn.castle:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16524206080 (15758MB) avail mem = 16016396288 (15274MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xdb225000 (58 entries) bios0: vendor LENOVO version "R0EET44W (1.18 )" date 11/17/2017 bios0: LENOVO 20H4CTO1WW acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI HPET APIC MCFG SBST MSDM BATB SSDT IVRS CRAT TPM2 SSDT SSDT SSDT SSDT FPDT SSDT UEFI acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP2(S4) GPP3(S4) GPP4(S4) GFX0(S4) GFX1(S4) GFX2(S4) GFX3(S4) GFX4(S4) XHC0(S3) EHC1(S3) SBAZ(S4) LID_(S3) SLPB(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 16 (boot processor) cpu0: AMD A10-9600P RADEON R5, 10 COMPUTE CORES 4C+6G, 2395.80 MHz 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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2 cpu0: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line 16-way L2 cache cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative acpihpet0: recalibrated TSC frequency 2395505539 Hz 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 17 (application processor) cpu1: AMD A10-9600P RADEON R5, 10 COMPUTE CORES 4C+6G, 2395.51 MHz 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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2 cpu1: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line 16-way L2 cache cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 18 (application processor) cpu2: AMD A10-9600P RADEON R5, 10 COMPUTE CORES 4C+6G, 2395.51 MHz 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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2 cpu2: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line 16-way L2 cache cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 19 (application processor) cpu3: AMD A10-9600P RADEON R5, 10 COMPUTE CORES 4C+6G, 2395.51 MHz 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,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,CPCTR,DBKP,PERFTSC,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2 cpu3: 96KB 64b/line 3-way I-cache, 32KB 64b/line 8-way D-cache, 1MB 64b/line 16-way L2 cache cpu3: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu3: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins , remapped to apid 4 ioapic1 at mainbus0: apid 5 pa 0xfec01000, version 21, 32 pins , remapped to apid 5 acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (GPP0) acpiprt2 at acpi0: bus 1 (GPP1) acpiprt3 at acpi0: bus 3 (GPP2) acpiprt4 at acpi0: bus 4 (GPP3) acpiprt5 at acpi0: bus -1 (GPP4) acpiprt6 at acpi0: bus -1 (GFX0) acpiprt7 at acpi0: bus -1 (GFX1) acpiprt8 at acpi0: bus -1 (GFX2) acpiprt9 at acpi0: bus -1 (GFX3) acpiprt10 at acpi0: bus -1 (GFX4) acpiec0 at acpi0 acpicpu0 at
mgre(4): point-to-multipoint gre tunnels
mgre(4) is a basic driver that starts to implement point to multipoint
gre ip tunnels. these are annoyingly hard to explain.
the main difference between gre(4) and mgre(4) is that it is not a
point to point interface (obviously, cos of the name). when configuring
gre(4), you give it a source and destination address for the outer
tunnel, and give it a source and destination address inside the
tunnel. eg:
configuring the gre tunnel addresses:
# ifconfig gre0 tunnel 192.0.2.1 198.51.100.1
configuring the point to point addresses inside the tunne:
# ifconfig gre0 inet 192.168.0.1/32 192.168.0.2
if you have a gre interface on the other side with the swapped
addresses, then pinging from 192.168.0.1 to 192.168.02 will have
the packets encapsulated by gre in packets from 192.0.2.1 to
198.51.100.1, and the replies come back with the addresses swapped:
09:06:33.815358 192.0.2.1 > 198.51.100.1: gre 192.168.0.1 > 192.168.0.2: icmp:
echo request
09:06:33.815652 198.51.100.1 > 192.0.2.1: gre 192.168.0.2 > 192.168.0.1: icmp:
echo reply
mgre on the other hand is more like an ethernet interface, but with
ip addresses instead of mac addresses. mgre(4) only needs configuration
of a local tunnel address (but takes src and dst at the moment cos
we have no way of only configuring a local address), and you configure
a subnet on the interface: eg, to configure mgre0 instead of gre0:
# ifconfig mgre0 tunnel 192.0.2.1 192.0.2.1 # dst is accepted but ignored
then you configure it on a subnet:
# ifconfig mgre0 inet 192.168.0.1/24
you'll see this in the routing table:
192.168.0/24 192.168.0.1UCn10 - 4 mgre0
192.168.0.1mgre0 UHl0 479 - 1 mgre0
so if you try to ping 192.168.0.2 with that config, it wont work
because there's no information stored anywhere to map 192.168.0.1
to the tunnel endpoing of 198.51.100.1. however, because it is like
a ethernet interface, the kernel has cloned a route for 192.168.0.2:
192.168.0/24 192.168.0.1UCn10 - 4 mgre0
192.168.0.1mgre0 UHl0 479 - 1 mgre0
192.168.0.2link#0 UHc01 - 3 mgre0
there's no arp or nd6 on mgre though, so right now we need to change
or add these entries by hand:
# route change -host 192.168.0.2 198.51.100.1 -iface -ifp mgre0
192.168.0/24 192.168.0.1UCn10 - 4 mgre0
192.168.0.1mgre0 UHl0 479 - 1 mgre0
192.168.0.2198.51.100.1 UHc01 - 3 mgre0
then we can ping:
09:16:44.336944 192.0.2.1 > 198.51.100.1: gre 192.168.0.1 > 192.168.0.2: icmp:
echo request
09:16:44.337176 198.51.100.1 > 192.0.2.1: gre 192.168.0.2 > 192.168.0.1: icmp:
echo reply
after that we could add routes instead of tunnels for more sites.
eg:
# route add -host 192.168.0.3 203.0.113.10 -iface -ifp mgre0
then we could ping 192.168.0.3 over mgre0, which would use 203.0.113.10
as the gre dest address:
09:24:31.057820 192.0.2.1 > 203.0.113.10: gre 192.168.0.1 > 192.168.0.3: icmp:
echo request
09:24:31.058011 203.0.113.10 > 192.0.2.1: gre 192.168.0.3 > 192.168.0.1: icmp:
echo reply
there are several uses mgre(4) interfaces. the one i am most
interested in now is building hub and spoke vpn topologies.
this would allow me to point gre interfaces on remote routers at
remote sites to a single mgre interface on a central firewall, which
would enforce policy centrally before allowing packets back out to
the spokes. because im looking at a dozen or so remote sites, each
with up to 6 networks to tunnel back to the central firewall, i
would welcome a way to configure less tunnels centrally.
mgre can also be used to build meshes of networks, or dynamic
multipoint vpns. this is a bit rought, but this is a good start.
ok?
Index: if_gre.c
===
RCS file: /cvs/src/sys/net/if_gre.c,v
retrieving revision 1.114
diff -u -p -r1.114 if_gre.c
--- if_gre.c25 Feb 2018 01:52:25 - 1.114
+++ if_gre.c25 Feb 2018 21:42:54 -
@@ -187,6 +187,9 @@ struct gre_tunnel {
};
static int
+ gre_cmp_src(const struct gre_tunnel *,
+ const struct gre_tunnel *);
+static int
gre_cmp(const struct gre_tunnel *, const struct gre_tunnel *);
static int gre_set_tunnel(struct gre_tunnel *, struct if_laddrreq *, int);
@@ -217,11 +220,11 @@ static intgre_tunnel_ioctl(struct ifnet
*/
struct gre_softc {
- struct ifnetsc_if;
-
- struct gre_tunnel sc_tunnel;
+ struct gre_tunnel sc_tunnel; /* must be first */
TAILQ_ENTRY(gre_softc) sc_entry;
+ struct ifnetsc_if;
+
struct timeout sc_ka_send;
struct timeout sc_ka_hold;
@@ -264,13 +267,48 @@ static void gre_link_state(struct gre_s
Re: shutdown: simplify countdown loop()
On Sun, Feb 25, 2018 at 10:42:04AM +0100, Theo Buehler wrote:
> On Sat, Feb 24, 2018 at 06:25:44PM -0600, Scott Cheloha wrote:
> > [...]
> >
> > If we treat tlist[] like an array instead of a list, we can
> > eliminate a lot of special cases and duplicate calls in shutdown(8)'s
> > countdown loop(). [...]
> >
> > ok?
>
> Yes, I think that's easier to follow. Two questions below.
>
> >
> > Index: sbin/shutdown/shutdown.c
> > ===
> > RCS file: /cvs/src/sbin/shutdown/shutdown.c,v
> > retrieving revision 1.48
> > diff -u -p -r1.48 shutdown.c
> > --- sbin/shutdown/shutdown.c24 Feb 2018 20:00:07 - 1.48
> > +++ sbin/shutdown/shutdown.c24 Feb 2018 23:57:54 -
> > @@ -64,8 +64,10 @@
> > #defineS *1
> > #defineNOLOG_TIME 5*60
> > struct interval {
> > - int timeleft, timetowait;
> > + time_t timeleft;
> > + time_t timetowait;
>
> Should we suffix a constant with LL in the multipliers H, M, S so
> we get correct overflow handling in the initializations below (not
> currently an issue).
If I'm understanding you correctly, no. We're nowhere near INT_MAX,
and these decimal constants are ints as they lack the suffix.
And even if we did something crazy, like add an interval like this:
{ 596524 H, 0 }
which just barely overflows a 32-bit type, on amd64 clang gives me:
cc -O2 -pipe -Werror-implicit-function-declaration -MD -MP -c
/usr/src/sbin/shutdown/shutdown.c
/usr/src/sbin/shutdown/shutdown.c:70:11: warning: overflow in
expression; result
is -2147480896 with type 'int' [-Winteger-overflow]
{ 596524 H,0 },
^
/usr/src/sbin/shutdown/shutdown.c:62:15: note: expanded from macro 'H'
#define H *60*60
^
1 warning generated.
cc -static -pie -o shutdown shutdown.o
and on macppc, gcc gives me:
cc -O2 -pipe -Werror-implicit-function-declaration -MD -MP -c
/usr/src/sbin/shutdown/shutdown.c
/usr/src/sbin/shutdown/shutdown.c:69: warning: integer overflow in
expression
cc -static -pie -o shutdown shutdown.o
which, while not as glaringly obvious as clang's warning, is
sufficient, I think.
> > [...]
> > @@ -273,7 +274,7 @@ static char *restricted_environ[] = {
> > };
> >
> > void
> > -timewarn(int timeleft)
> > +timewarn(time_t timeleft)
> > {
> > static char hostname[HOST_NAME_MAX+1];
> > static int first;
> > @@ -321,7 +322,7 @@ timewarn(int timeleft)
> > tm->tm_hour, tm->tm_min);
> > } else if (timeleft > 59)
> > dprintf(fd[1], "System going down in %d minute%s\n\n",
>
> Wouldn't it be better to use an %lld format and leave the next line as
> it is?
Yes, we ought to use %lld, if only because code tends to move around.
But we can't leave the expression uncasted. time_t has no dedicated
format specifier so we need an explicit cast. At least, I've never
seen one in base printed without a cast. And I suspect that such code
wouldn't be portable.
Updated diff attached.
--
Scott Cheloha
Index: sbin/shutdown/shutdown.c
===
RCS file: /cvs/src/sbin/shutdown/shutdown.c,v
retrieving revision 1.48
diff -u -p -r1.48 shutdown.c
--- sbin/shutdown/shutdown.c24 Feb 2018 20:00:07 - 1.48
+++ sbin/shutdown/shutdown.c25 Feb 2018 22:44:39 -
@@ -64,8 +64,10 @@
#defineS *1
#defineNOLOG_TIME 5*60
struct interval {
- int timeleft, timetowait;
+ time_t timeleft;
+ time_t timetowait;
} tlist[] = {
+ {0,0 },
{ 10 H, 5 H },
{ 5 H, 3 H },
{ 2 H, 1 H },
@@ -79,6 +81,7 @@ struct interval {
{ 30 S, 30 S },
{0,0 }
};
+const int tlistlen = sizeof(tlist) / sizeof(tlist[0]);
#undef H
#undef M
#undef S
@@ -96,7 +99,7 @@ void getoffset(char *);
void __dead loop(void);
void nolog(void);
void timeout(int);
-void timewarn(int);
+void timewarn(time_t);
void usage(void);
int
@@ -229,40 +232,38 @@ main(int argc, char *argv[])
void
loop(void)
{
- struct interval *tp;
- u_int sltime;
- int logged;
-
- if (offset <= NOLOG_TIME) {
- logged = 1;
- nolog();
- } else
- logged = 0;
- tp = tlist;
- if (tp->timeleft < offset)
- (void)sleep((u_int)(offset - tp->timeleft));
- else {
- while (offset < tp->timeleft)
- ++tp;
- /*
-* Warn now, if going to sleep more than a fifth of
-* the next wait time.
-*/
- if ((sltime = offset - tp->timeleft)) {
- if (sltime > tp->timetowait / 5)
- timewarn(offset);
-
Re: iwn(4): fix scan loop
On Sat, Feb 24 2018, Stefan Sperling wrote: > I made a mistake in my last commit to iwn and broke the scan loop. > > The problem happens if we don't find an AP to connect to after one scan > iteration. The stack then performs a SCAN -> SCAN transition to kick > off another scan, but iwn(4) code in -current always treats this transition > as a no-op. > > With ifconfig iwn0 debug enabled, it's evident that the driver never shows > another list of access points but the LED keeps blinking (this indicates > SCAN state). > > This diff makes iwn(4) start another scan during a SCAN->SCAN transition > if no scan is in progress. This behaviour matches what iwm(4) does. As advertized this seems to fix scans while not associated, using: iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev 0x34: msi, MIMO 2T2R, MoW, address xx:xx:xx:xx:xx:xx Thanks! -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: shutdown: simplify countdown loop()
On Sat, Feb 24, 2018 at 06:25:44PM -0600, Scott Cheloha wrote:
> Hey,
>
> If we treat tlist[] like an array instead of a list, we can
> eliminate a lot of special cases and duplicate calls in shutdown(8)'s
> countdown loop().
>
> We add a spare index at the beginning of tlist[] to accomodate
> offsets greater than 10 hours and insert our offset into tlist[]
> in an initial loop. With that done we can cut out all of the
> duplicate calls and most of the extra logic and invoke timewarn(),
> nolog(), and sleep() once each in a master countdown loop.
>
> While we're here I think we ought to make everything in tlist[] a
> time_t to eliminate the casting in loop(). offset is a time_t, so
> there's just less type friction. It also makes things simpler for
> some later diffs I have planned. But so, int -> time_t, hence
> sleep -> nanosleep.
>
> ok?
Yes, I think that's easier to follow. Two questions below.
>
> --
> Scott Cheloha
>
> Index: sbin/shutdown/shutdown.c
> ===
> RCS file: /cvs/src/sbin/shutdown/shutdown.c,v
> retrieving revision 1.48
> diff -u -p -r1.48 shutdown.c
> --- sbin/shutdown/shutdown.c 24 Feb 2018 20:00:07 - 1.48
> +++ sbin/shutdown/shutdown.c 24 Feb 2018 23:57:54 -
> @@ -64,8 +64,10 @@
> #define S *1
> #define NOLOG_TIME 5*60
> struct interval {
> - int timeleft, timetowait;
> + time_t timeleft;
> + time_t timetowait;
Should we suffix a constant with LL in the multipliers H, M, S so
we get correct overflow handling in the initializations below (not
currently an issue).
> } tlist[] = {
> + {0,0 },
> { 10 H, 5 H },
> { 5 H, 3 H },
> { 2 H, 1 H },
> @@ -79,6 +81,7 @@ struct interval {
> { 30 S, 30 S },
> {0,0 }
> };
> +const int tlistlen = { sizeof(tlist) / sizeof(tlist[0]) };
> #undef H
> #undef M
> #undef S
> @@ -96,7 +99,7 @@ void getoffset(char *);
> void __dead loop(void);
> void nolog(void);
> void timeout(int);
> -void timewarn(int);
> +void timewarn(time_t);
> void usage(void);
>
> int
> @@ -229,40 +232,38 @@ main(int argc, char *argv[])
> void
> loop(void)
> {
> - struct interval *tp;
> - u_int sltime;
> - int logged;
> -
> - if (offset <= NOLOG_TIME) {
> - logged = 1;
> - nolog();
> - } else
> - logged = 0;
> - tp = tlist;
> - if (tp->timeleft < offset)
> - (void)sleep((u_int)(offset - tp->timeleft));
> - else {
> - while (offset < tp->timeleft)
> - ++tp;
> - /*
> - * Warn now, if going to sleep more than a fifth of
> - * the next wait time.
> - */
> - if ((sltime = offset - tp->timeleft)) {
> - if (sltime > tp->timetowait / 5)
> - timewarn(offset);
> - (void)sleep(sltime);
> + struct timespec timeout;
> + int broadcast, i, logged;
> +
> + broadcast = 1;
> +
> + for (i = 0; i < tlistlen - 1; i++) {
> + if (offset > tlist[i + 1].timeleft) {
> + tlist[i].timeleft = offset;
> + tlist[i].timetowait = offset - tlist[i + 1].timeleft;
> + break;
> }
> }
> - for (;; ++tp) {
> - timewarn(tp->timeleft);
> - if (!logged && tp->timeleft <= NOLOG_TIME) {
> +
> + /*
> + * Don't spam the users: skip our offset's warning broadcast if
> + * there's a broadcast scheduled after ours and it's relatively
> + * imminent.
> + */
> + if (offset > 0 && tlist[i].timetowait < tlist[i + 1].timetowait / 5)
> + broadcast = 0;
> +
> + for (logged = 0; i < tlistlen; i++) {
> + if (broadcast)
> + timewarn(tlist[i].timeleft);
> + broadcast = 1;
> + if (!logged && tlist[i].timeleft <= NOLOG_TIME) {
> logged = 1;
> nolog();
> }
> - (void)sleep((u_int)tp->timetowait);
> - if (!tp->timeleft)
> - break;
> + timeout.tv_sec = tlist[i].timetowait;
> + timeout.tv_nsec = 0;
> + nanosleep(&timeout, NULL);
> }
> die_you_gravy_sucking_pig_dog();
> }
> @@ -273,7 +274,7 @@ static char *restricted_environ[] = {
> };
>
> void
> -timewarn(int timeleft)
> +timewarn(time_t timeleft)
> {
> static char hostname[HOST_NAME_MAX+1];
> static int first;
> @@ -321,7 +322,7 @@ timewarn(int timeleft)
> tm->tm_hour, tm->tm_min);
> } else if (timeleft > 59)
> dprintf(fd[1], "System going down in %d minute%s\n\n",
Wouldn't it be better to use an %lld format and leave the next line as
it is?
> - timeleft / 60, (timeleft > 60) ? "s" : "");
> + (in
Re: drm: DP update that fixes T460 external monitors through docks
On Wed, Feb 21, 2018 at 03:30:13PM +0200, Paul Irofti wrote:
> For the archives, here is a diff that fixes a locking warning with the
> earlier patch. So you have to apply it after the former one.
>
> diff --git sys/dev/pci/drm/drm_probe_helper.c
> sys/dev/pci/drm/drm_probe_helper.c
> index 936c0c1d3a7..84a0e585d32 100644
> --- sys/dev/pci/drm/drm_probe_helper.c
> +++ sys/dev/pci/drm/drm_probe_helper.c
> @@ -136,15 +136,27 @@ static int
> drm_helper_probe_single_connector_modes_merge_bits(struct drm_connect
> struct drm_display_mode *mode;
> const struct drm_connector_helper_funcs *connector_funcs =
> connector->helper_private;
> - int count = 0;
> + int count = 0, ret;
> int mode_flags = 0;
> bool verbose_prune = true;
> enum drm_connector_status old_status;
> + struct drm_modeset_acquire_ctx ctx;
>
> WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> connector->name);
> +
> + drm_modeset_acquire_init(&ctx, 0);
> +
> +retry:
> + ret = drm_modeset_lock(&dev->mode_config.connection_mutex, &ctx);
> + if (ret == -EDEADLK) {
> + drm_modeset_backoff(&ctx);
> + goto retry;
> + } else
> + WARN_ON(ret < 0);
> +
> /* set all modes to the unverified state */
> list_for_each_entry(mode, &connector->modes, head)
> mode->status = MODE_UNVERIFIED;
> @@ -248,6 +260,9 @@ static int
> drm_helper_probe_single_connector_modes_merge_bits(struct drm_connect
> prune:
> drm_mode_prune_invalid(dev, &connector->modes, verbose_prune);
>
> + drm_modeset_drop_locks(&ctx);
> + drm_modeset_acquire_fini(&ctx);
> +
> if (list_empty(&connector->modes))
> return 0;
>
>
I'm using it daily for couple of days, FDE and hibernating.
Although I still see some 'error's and 'WARNING's, see below:
OpenBSD 6.2-current (GENERIC.MP) #0: Fri Feb 23 22:40:24 CET 2018
ji...@t470s.example.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17032802304 (16243MB)
avail mem = 16509616128 (15744MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x9a2bb000 (62 entries)
bios0: vendor LENOVO version "N1WET41W (1.20 )" date 10/17/2017
bios0: LENOVO 20HGS22D0W
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT BOOT
BATB SSDT SSDT SSDT WSMT SSDT SSDT DBGP DBG2 POAT DMAR ASF! FPDT UEFI
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) RP02(S4)
RP04(S4) RP05(S4) RP06(S4) RP07(S4) RP08(S4) RP09(S4) RP10(S4) RP11(S4)
RP12(S4) RP13(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz, 2694.93 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,SMX,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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
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-7600U CPU @ 2.80GHz, 2693.74 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,SMX,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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz, 2693.73 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,SMX,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,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz, 2693.74 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,C
