Re: T470s power-cycles itself/hangs with/when plugged to ThinkPad Ultra Dock
I bet this will fix it. https://marc.info/?l=openbsd-tech&m=151695604403648&w=2 On Wed, Feb 14, 2018 at 12:37:45PM -0500, Jiri B wrote: > Hello, > > Lenovo T470s hangs when being plugged into docking station - ThinkPad > Ultra Dock (40A20)[1][2] - just hangs, no output, nothing. > > When it does boot inside docking station it boots and it power cycle > itself after following lines (transcripted from video): > > FYA, I can get couple of these docking stations and send them for free to > interested developers for hacking. I could probably get also other > ones (for T420s...). Let me know, I can ask for them at work. > > ... > efifb at mainbus0 not configured > error: [drm:pid17531:intel_dp_link_training_clock_recovery] *ERROR* too many > voltage retries, give up > error: [drm:pid17531:intel_wait_ddi_buf_idle] *ERROR* Timeout waiting for DDI > BUF C idle bit > error: [drm:pid17531:intel_dp_link_training_clock_recovery] *ERROR* too many > voltage retries, give up > error: [drm:pid17531:intel_wait_ddi_buf_idle] *ERROR* Timeout waiting for DDI > BUF C idle bit > error: [drm:pid17531:intel_dp_link_training_clock_recovery] *ERROR* too many > voltage retries, give up > error: [drm:pid17531:intel_wait_ddi_buf_idle] *ERROR* Timeout waiting for DDI > BUF C idle bit > error: [drm:pid17531:intel_dp_link_training_clock_recovery] *ERROR* too many > voltage retries, give up > error: [drm:pid17531:intel_wait_ddi_buf_idle] *ERROR* Timeout waiting for DDI > BUF C idle bit > error: [drm:pid17531:intel_dp_link_training_clock_recovery] *ERROR* too many > voltage retries, give up > error: [drm:pid17531:intel_wait_ddi_buf_idle] *ERROR* Timeout waiting for DDI > BUF C idle bit > error: [drm:pid17531:intel_dp_link_training_clock_recovery] *ERROR* too many > voltage retries, give up > error: [drm:pid17531:intel_wait_ddi_buf_idle] *ERROR* Timeout waiting for DDI > BUF C idle bit > error: [drm:pid17531:intel_dp_link_training_clock_recovery] *ERROR* too many > voltage retries, give up > error: [drm:pid17531:intel_dp_set_idle_link_train] *ERROR* Time out waiting > for DP idle patterns > > ^^ last line, then laptop power cycles itself > > Jiri > > [1] > https://www3.lenovo.com/us/en/accessories-and-monitors/docking/mechanical-docks/ThinkPad-Ultra-Dock-90-W/p/40A20090US > [2] http://www.thinkwiki.org/wiki/ThinkPad_Ultra_Dock (although they probably > have older model here) > > - full dmesg when not being inside ThinkPad Ultra Dock. > > OpenBSD 6.2-current (GENERIC.MP) #6: Tue Feb 13 20:16:11 MST 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 17032802304 (16243MB) > avail mem = 16509579264 (15744MB) > enter_shared_special_pages: entered idt page va 0x8001 pa > 0x1d64000 > enter_shared_special_pages: entered kutext page va 0x81832000 pa > 0x1832000 > enter_shared_special_pages: entered kutext page va 0x81833000 pa > 0x1833000 > enter_shared_special_pages: entered kutext page va 0x81834000 pa > 0x1834000 > enter_shared_special_pages: entered kudata page va 0x81ac9000 pa > 0x1ac9000 > cpu_enter_pages: entered tss+gdt page at va 0x81ab7000 pa 0x1ab7000 > cpu_enter_pages: entered t.stack page at va 0x81ab8000 pa 0x1ab8000 > cpu_enter_pages: cif_tss.tss_rsp0 = 0x81ab83e0 > 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 > lapic_map: entered lapic page va 0x81ab2000 pa 0xfee0 > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz, 1597.01 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,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 23MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE > cpu1 at mainbus0cpu_enter_pages: entered tss+gdt page at va >
Re: vmctl(8) pause never returns
* Abel Abraham Camarillo Ojeda [2018-02-15 06:06:50 -0600]:
Synopsis: vmctl(8) pause never returns
This should fix it. It checks if vm id is valid before sending to vmm
for pausing. The 'lock' is caused by vmm sending back ENOENT for a non
existent vm but vmd drops the message because it doesn't recogize the
vmid vmm is talking about. This is an artifact of the 'policy' don't
trust any imsg from a sibling priv sep processes and do your own
checking.
Index: usr.sbin/vmd/vmd.c
===
RCS file: /home/pdvyas/cvs/src/usr.sbin/vmd/vmd.c,v
retrieving revision 1.79
diff -u -p -a -u -r1.79 vmd.c
--- usr.sbin/vmd/vmd.c 10 Jan 2018 14:59:59 - 1.79
+++ usr.sbin/vmd/vmd.c 16 Feb 2018 17:06:20 -
@@ -186,6 +186,10 @@ vmd_dispatch_control(int fd, struct priv
} else {
vid.vid_id = vm->vm_vmid;
}
+ } else if (vm_getbyid(vid.vid_id) == NULL) {
+ res = ENOENT;
+ cmd = IMSG_VMDOP_PAUSE_VM_RESPONSE;
+ break;
}
proc_compose_imsg(ps, PROC_VMM, -1, imsg->hdr.type,
imsg->hdr.peerid, -1, &vid, sizeof(vid));
Re: vmctl(8) pause never returns
* Pratik Vyas [2018-02-16 09:15:07 -0800]:
* Abel Abraham Camarillo Ojeda [2018-02-15 06:06:50 -0600]:
Synopsis: vmctl(8) pause never returns
This should fix it. It checks if vm id is valid before sending to vmm
for pausing. The 'lock' is caused by vmm sending back ENOENT for a non
existent vm but vmd drops the message because it doesn't recogize the
vmid vmm is talking about. This is an artifact of the 'policy' don't
trust any imsg from a sibling priv sep processes and do your own
checking.
Index: usr.sbin/vmd/vmd.c
===
RCS file: /home/pdvyas/cvs/src/usr.sbin/vmd/vmd.c,v
retrieving revision 1.79
diff -u -p -a -u -r1.79 vmd.c
--- usr.sbin/vmd/vmd.c 10 Jan 2018 14:59:59 - 1.79
+++ usr.sbin/vmd/vmd.c 16 Feb 2018 17:06:20 -
@@ -186,6 +186,10 @@ vmd_dispatch_control(int fd, struct priv
} else {
vid.vid_id = vm->vm_vmid;
}
+ } else if (vm_getbyid(vid.vid_id) == NULL) {
+ res = ENOENT;
+ cmd = IMSG_VMDOP_PAUSE_VM_RESPONSE;
+ break;
}
proc_compose_imsg(ps, PROC_VMM, -1, imsg->hdr.type,
imsg->hdr.peerid, -1, &vid, sizeof(vid));
Forgot to mention: asking for ok :)
Re: vmctl(8) pause never returns
On Fri, Feb 16, 2018 at 09:15:07AM -0800, Pratik Vyas wrote:
> * Abel Abraham Camarillo Ojeda [2018-02-15 06:06:50
> -0600]:
>
> > > Synopsis: vmctl(8) pause never returns
>
> This should fix it. It checks if vm id is valid before sending to vmm
> for pausing. The 'lock' is caused by vmm sending back ENOENT for a non
> existent vm but vmd drops the message because it doesn't recogize the
> vmid vmm is talking about. This is an artifact of the 'policy' don't
> trust any imsg from a sibling priv sep processes and do your own
> checking.
>
ok mlarkin
>
> Index: usr.sbin/vmd/vmd.c
> ===
> RCS file: /home/pdvyas/cvs/src/usr.sbin/vmd/vmd.c,v
> retrieving revision 1.79
> diff -u -p -a -u -r1.79 vmd.c
> --- usr.sbin/vmd/vmd.c10 Jan 2018 14:59:59 - 1.79
> +++ usr.sbin/vmd/vmd.c16 Feb 2018 17:06:20 -
> @@ -186,6 +186,10 @@ vmd_dispatch_control(int fd, struct priv
> } else {
> vid.vid_id = vm->vm_vmid;
> }
> + } else if (vm_getbyid(vid.vid_id) == NULL) {
> + res = ENOENT;
> + cmd = IMSG_VMDOP_PAUSE_VM_RESPONSE;
> + break;
> }
> proc_compose_imsg(ps, PROC_VMM, -1, imsg->hdr.type,
> imsg->hdr.peerid, -1, &vid, sizeof(vid));
>
Re: Vertical lines present on fonts (FreeType update related)
CCing dcoppa@ Ping? Can anyone else reproduce the vertical lines I'm seeing with the new FreeType update, or can I assume that there's something weird going on with just my machine that doesn't affect others? -- Bryan On 2018-02-11 22:05:54, Bryan Linton wrote: > >Synopsis:Asian fonts are rendering with vertical bars after recent > >FreeType update > >Category:system > >Environment: > System : OpenBSD 6.2 > Details : OpenBSD 6.2-current (GENERIC.MP) #408: Thu Feb 8 > 04:09:33 MST 2018 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > I noticed after upgrading to a newer snapshot that > vertical lines are now displayed when Asian fonts are > rendered. The example (and screenshot) is from mutt in an > xterm, but I see the same thing in Firefox. > > I've attached a screenshot of mutt (please ignore the date > in the email itself, I've had OpenBSD installed for a long > time). Notice how "Theo de Raadt" renders more like "Thθa > dθ Raadt", the following left angle bracket looks more > like a triangle, and the date in the line above looks like > it says "2101017" instead of "2007". > > While this is only mildly annoying when reading the Latin > alphabet, it causes considerably more confusion when > reading Asian (specifically Japanese) scripts. For > example, the difference between リ and 川 > is quite significant. (One is simply a phonetic character > with the reading of "ri", the other is a kanji meaning > "river" with the reading of "kawa"). > > It also appears to be specifically limited to embolded > fonts. I do not see it occur on regular (non-italic, > non-embolded) fonts. > > >How-To-Repeat: > pkg_add mutt ja-sazanami-ttf-20040629p3 > env LC_ALL=ja_JP.UTF-8 xterm -fa "Sazanami Gothic" -fs 16 mutt > > > --- or --- > > pkg_add firefox-esr ja-sazanami-ttf-20040629p3 > > > > >Fix: > Reverting FreeType 2.8.1 back to FreeType 2.8.0 resolves > all issues for me. > > > dmesg: > OpenBSD 6.2-current (GENERIC.MP) #408: Thu Feb 8 04:09:33 MST 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 12539572224 (11958MB) > avail mem = 12152545280 (11589MB) > enter_shared_special_pages: entered idt page va 0x8001 pa > 0x1d5a000 > enter_shared_special_pages: entered kutext page va 0x8183 pa > 0x183 > enter_shared_special_pages: entered kutext page va 0x81831000 pa > 0x1831000 > enter_shared_special_pages: entered kutext page va 0x81832000 pa > 0x1832000 > enter_shared_special_pages: entered kudata page va 0x81ac6000 pa > 0x1ac6000 > cpu_enter_pages: entered tss+gdt page at va 0x81a93000 pa 0x1a93000 > cpu_enter_pages: entered t.stack page at va 0x81a94000 pa 0x1a94000 > cpu_enter_pages: cif_tss.tss_rsp0 = 0x81a943e0 > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbcc0d000 (67 entries) > bios0: vendor LENOVO version "GLET92WW (2.46 )" date 12/11/2017 > bios0: LENOVO 20AWS27D00 > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SLIC DBGP ECDT HPET APIC MCFG SSDT SSDT SSDT SSDT > SSDT SSDT SSDT PCCT SSDT TCPA UEFI MSDM ASF! BATB FPDT UEFI DMAR > acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) EXP3(S4) XHCI(S3) > EHC1(S3) EHC2(S3) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpiec0 at acpi0 > acpihpet0 at acpi0: 14318179 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > lapic_map: entered lapic page va 0x81ac4000 pa 0xfee0 > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz, 2694.09 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,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,INSECURE > cpu0: 256KB 64b/line 8-way L2 cache > acpihpet0: recalibrated TSC frequency 2693764628 Hz > 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 mainbus0cpu_enter_pages: entered tss+gdt page at va > 0x80002200 pa 0x116a8c000 > cpu_enter_pages: entered t.stack page at va 0x800022001000 pa 0x116a8d000 > cpu_enter_pages: cif_tss.tss_rsp0 = 0x8000220013e0 > : apid 1 (application processor) > cpu1: Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz, 2693.77 MHz
Re: vmctl(8) pause never returns
On Fri, Feb 16, 2018 at 01:18:31PM -0800, Pratik Vyas wrote:
> * Pratik Vyas [2018-02-16 09:15:07 -0800]:
>
> > * Abel Abraham Camarillo Ojeda [2018-02-15 06:06:50
> > -0600]:
> >
> > > > Synopsis: vmctl(8) pause never returns
> >
> > This should fix it. It checks if vm id is valid before sending to vmm
> > for pausing. The 'lock' is caused by vmm sending back ENOENT for a non
> > existent vm but vmd drops the message because it doesn't recogize the
> > vmid vmm is talking about. This is an artifact of the 'policy' don't
> > trust any imsg from a sibling priv sep processes and do your own
> > checking.
> >
> >
> > Index: usr.sbin/vmd/vmd.c
> > ===
> > RCS file: /home/pdvyas/cvs/src/usr.sbin/vmd/vmd.c,v
> > retrieving revision 1.79
> > diff -u -p -a -u -r1.79 vmd.c
> > --- usr.sbin/vmd/vmd.c 10 Jan 2018 14:59:59 - 1.79
> > +++ usr.sbin/vmd/vmd.c 16 Feb 2018 17:06:20 -
> > @@ -186,6 +186,10 @@ vmd_dispatch_control(int fd, struct priv
> > } else {
> > vid.vid_id = vm->vm_vmid;
> > }
> > + } else if (vm_getbyid(vid.vid_id) == NULL) {
> > + res = ENOENT;
> > + cmd = IMSG_VMDOP_PAUSE_VM_RESPONSE;
> > + break;
> > }
> > proc_compose_imsg(ps, PROC_VMM, -1, imsg->hdr.type,
> > imsg->hdr.peerid, -1, &vid, sizeof(vid));
>
> Forgot to mention: asking for ok :)
ok ccardenas@
+--+
Carlos
laptop keyboard repeats all presses after autoconfig
>Synopsis: laptop keyboard repeats all presses after autoconfig >Category: amd64 >Environment: System : OpenBSD 6.2 Details : OpenBSD 6.2 (GENERIC.MP) #134: Tue Oct 3 21:22:29 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 (Samsung Chromebook 3) >Description: Keyboard works as expected in BIOS and at boot> prompt, UKC, and ddb (if started from boot>). After autoconf, however, each keypress is followed by a slight delay, character appears on screen, another slight delay, and 5 more characters appear on screen, as though key is slightly delayed then held down for approximately 900ms. Intentionally holding down key for typematic behavior yields this multiplied by what would be the appropriate number of repeats (e.g., holding down key to expect 5 characters to appear yields 30). External USB keyboard works appropriately. Keyboard appears to be detected by OpenBSD as a pc-xt (ps2) keyboard, i8042 per other systems. >How-To-Repeat: Boot and type. >Fix: Setting typematic delay ridiculously long with wsconsctl(8) allows meticulous typing to workaround, but not generally usable. Using an external keyboard works fine. dmesg: OpenBSD 6.2 (GENERIC.MP) #134: Tue Oct 3 21:22:29 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4221259776 (4025MB) avail mem = 4086300672 (3897MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7cd05020 (14 entries) bios0: vendor coreboot version "MrChromebox" date 02/04/2018 bios0: GOOGLE Celes acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT MCFG TCPA APIC HPET BGRT acpi0: wakeup devices XHCI(S3) ATPA(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU N3060 @ 1.60GHz, 1596.35 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu0: 1MB 64b/line 16-way L2 cache cpu0: TSC frequency 1596349200 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 79MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE cpu1 at mainbus0: apid 4 (application processor) cpu1: Intel(R) Celeron(R) CPU N3060 @ 1.60GHz, 1599.92 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT cpu1: 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 2, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 115 pins , remapped to apid 2 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiec0 at acpi0 acpicpu0 at acpi0: C3(1@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(1@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PLPE "INT33BD" at acpi0 not configured acpibtn0 at acpi0: LID0 acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT0 model "4352D44" serial 03E1 type LION oem "SDI" "GOOG0004" at acpi0 not configured "PNP0A05" at acpi0 not configured "GGL0303" at acpi0 not configured "INTL9C60" at acpi0 not configured "INTL9C60" at acpi0 not configured dwiic0 at acpi0: I2C5 addr 0xd1323000/0x1000 irq 36 iic0 at dwiic0 "10EC5650" at acpi0 not configured dwiic1 at acpi0: I2C6 addr 0xd1325000/0x1000 irq 37 iic1 at dwiic1 "ATML" at acpi0 not configured "8086228E" at acpi0 not configured "8086228A" at acpi0 not configured "808622A8" at acpi0 not configured chvgpio0 at acpi0: GPSW uid 1 addr 0xfed8/0x8000 irq 49, 56 pins chvgpio1 at acpi0: GPNC uid 2 addr 0xfed88000/0x8000 irq 48, 59 pins chvgpio2 at acpi0: GPEC uid 3 addr 0xfed9/0x8000 irq 50, 24 pins chvgpio3 at acpi0: GPSE uid 4 addr 0xfed98000/0x8000 irq 91, 55 pins "INT3400" at acpi0 not configured "INT3403" at acpi0 not configured "INT3403" at acpi0 not configured "INT3403" at acpi0 not configured "INT3403" at acpi0 not configured acpibtn1 at acpi0: PWRB "BOOT" at acpi0 not configured acpivideo0 at acpi0: GFX0 cpu0: Enhanced SpeedStep 1596 MHz: speeds: 1601, 1600, 1520, 1440, 1360, 1280, 1200, 1120, 1040, 960, 880, 800, 720, 640, 560, 480 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Braswell Host" rev 0x35 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x35 drm0 at inteldrm0 inteldrm0: msi inteldrm0: 1366x768, 32bpp wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) w
