Re: touchpad input driver: testing needed
Feedback report --- Hardware: Thinkpad X220. Results:Excellent! wsconsctl configuration changes:None. mouse.type=synaptics mouse.rawmode=0 mouse.scale=1472,5768,1408,5062,0,65,136 mouse.tp.tapping=0 mouse.tp.scaling=0.163 mouse.tp.swapsides=0 mouse.tp.disable=0 mouse1.type=ps2 mouse2.type=usb OpenBSD 6.1-current (GENERIC.MP) #23: Sun Jul 30 17:07:49 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error 80 real mem = 8451125248 (8059MB) avail mem = 8188645376 (7809MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (66 entries) bios0: vendor LENOVO version "8DET73WW (1.43 )" date 10/12/2016 bios0: LENOVO 4291G26 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT SSDT DMAR UEFI UEFI UEFI acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.30 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 2492296960 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.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus -1 (EXP4) acpiprt5 at acpi0: bus 13 (EXP5) acpiprt6 at acpi0: bus -1 (EXP7) acpicpu0 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS acpicpu1 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS acpicpu2 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS acpicpu3 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS acpipwrres0 at acpi0: PUBS, resource for EHC1, EHC2 acpitz0 at acpi0: critical temperature is 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB "PNP0303" at acpi0 not configured "LEN0020" at acpi0 not configured "SMO1200" at acpi0 not configured acpibat0 at acpi0: BAT0 model "42T4875" serial94 type LION oem "Panasonic" acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured acpidock0 at acpi0: GDCK not docked (0) acpivideo0 at acpi0: VID_ acpivout at acpivideo0 not configured acpivideo1 at acpi0: VID_ cpu0: Enhanced SpeedStep 2492 MHz: speeds: 2501, 2500, 2200, 2000, 1800, 1600, 1400, 1200, 1000, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 3000" rev 0x09 drm0 at inteldrm0 inteldrm0: msi inteldrm0: 1366x768, 32bpp wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 "Intel 82579LM" rev
Re: touchpad input driver: testing needed
On Mon, Jul 31, 2017 at 11:02:28PM +0200, Ulf Brosziewski wrote: > for you. As always, a dmesg would be appreciated. The output of > # wsconsctl | grep 'mouse' > could also be of interest here (you must run it as root). Here is another report from a Lenovo N22. This system has a Synaptics touchpad as well and works perfectly with the new driver. # wsconsctl | grep mouse mouse.type=synaptics mouse.rawmode=0 mouse.scale=1472,5788,1408,4966,0,58,94 mouse.tp.tapping=0 mouse.tp.scaling=0.164 mouse.tp.swapsides=0 mouse.tp.disable=0 Bryan OpenBSD 6.1-current (GENERIC.MP) #27: Mon Jul 31 12:56:47 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4117872640 (3927MB) avail mem = 3986718720 (3802MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0840 (61 entries) bios0: vendor Lenovo version "0YCN17WW" date 03/31/2016 bios0: LENOVO 80S6 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI MCFG SSDT SSDT SSDT SSDT SSDT APIC UEFI MSDM BATB FPDT UEFI BGRT tCSR acpi0: wakeup devices XHC1(S4) BRC1(S0) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 addr 0xe000, bus 0-63 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU N3050 @ 1.60GHz, 1600.36 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 1600363400 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 80MHz 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 N3050 @ 1.60GHz, 1600.01 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 1 pa 0xfec0, version 20, 115 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus -1 (RP02) acpiprt3 at acpi0: bus 2 (RP03) acpiprt4 at acpi0: bus -1 (RP04) acpiec0 at acpi0 acpicpu0 at acpi0 C2: state 6: substate 8 >= num 3 C3: state 7: substate 4 >= num 3: C1(1000@1 mwait.1), PSS acpicpu1 at acpi0 C2: state 6: substate 8 >= num 3 C3: state 7: substate 4 >= num 3: C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: CLK0 acpipwrres1 at acpi0: CLK1 acpipwrres2 at acpi0: ID3C, resource for ISP3 acpipwrres3 at acpi0: USBC, resource for XHC1 acpipwrres4 at acpi0: FN00, resource for FAN0 acpitz0 at acpi0: critical temperature is 90 degC acpibat0 at acpi0: BAT1 model "Harris Beach" serial 123456789 type LION oem "Intel SR 1" "VPC2004" at acpi0 not configured "MSFT0001" at acpi0 not configured "SYN2F02" at acpi0 not configured sdhc0 at acpi0: SDHA addr 0x91319000/0x1000 irq 45 sdhc0: SDHC 3.0, 200 MHz base clock sdmmc0 at sdhc0: 8-bit, sd high-speed, mmc high-speed, dma sdhc1 at acpi0: SDHB addr 0x91317000/0x1000 irq 46 sdhc1: SDHC 3.0, 200 MHz base clock sdmmc1 at sdhc1: 4-bit, sd high-speed, mmc high-speed, dma acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: PWRB "INT3400" at acpi0 not configured "INT3403" at acpi0 not configured "PNP0C0B" at acpi0 not configured acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD1F cpu0: Enhanced SpeedStep 1600 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 0x21 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x21 drm0 at inteldrm0 inteldrm0: msi inteldrm0: 1366x768, 32bpp wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel Braswell Power" rev 0x21 at pci0 dev 11 function 0 not configured sdhc2 at pci0 dev 18 function 0 vendor "Intel", unknown product 0x2296 rev 0x21: apic 1 int 18 sdhc2: SDHC 3.0, 200 MHz base clock sdmmc2 at sdhc2: 4-bit, sd high-speed, mmc high-speed, dma ahci0 at pci0 dev 19 function 0 "Intel Braswell AHCI" rev 0x21: msi, AHCI 1.3.1 ahci0: PHY offline on port 0 ahci0: PHY offline on port 1 scsibus1 at ahci0: 32 targets xhci0 at pci0 dev 20 function 0 "Intel Braswell xHCI" rev 0x21: msi usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 "Intel Braswell TXE" rev 0x21 at pci0 dev 26 function
Re: touchpad input driver: testing needed
On Mon, Jul 31, 2017 at 08:09:31PM -0400, Ted Unangst wrote: > Bryan Vyhmeister wrote: > > On Mon, Jul 31, 2017 at 11:02:28PM +0200, Ulf Brosziewski wrote: > > > for you. As always, a dmesg would be appreciated. The output of > > > # wsconsctl | grep 'mouse' > > > could also be of interest here (you must run it as root). > > > > This report is from a MacBookAir7,2 which is a 2015 13-inch MacBook Air. > > Anything more than a regular click is not working as can be seen from > > the wsconsctl output. I was using synclient to configure previously > > which did allow the other settings. > > Can you also share your synclient settings? Sure. I was using synclient(1) with the following settings but synclient(1) no longer works with this driver. synclient ClickFinger2=2 ClickFinger3=3 PalmDetect=0 PalmMinWidth=4 PalmMinZ=100 Bryan
Re: touchpad input driver: testing needed
Bryan Vyhmeister wrote: > On Mon, Jul 31, 2017 at 11:02:28PM +0200, Ulf Brosziewski wrote: > > for you. As always, a dmesg would be appreciated. The output of > > # wsconsctl | grep 'mouse' > > could also be of interest here (you must run it as root). > > This report is from a MacBookAir7,2 which is a 2015 13-inch MacBook Air. > Anything more than a regular click is not working as can be seen from > the wsconsctl output. I was using synclient to configure previously > which did allow the other settings. Can you also share your synclient settings?
Re: Calculate the frequency of the tsc timecounter
On Tue, Aug 1, 2017 at 7:26 AM, Adam Steen wrote:
> Mike Belopuhov wrote:
>
>> To be able to use TSC as a timecounter source on OpenBSD or Solo5
>> you'd have to improve the in-kernel measurement of the TSC frequency
>> first. I've tried to perform 10 measurements and take an average and
>> it does improve accuracy, however I believe we need to poach another
>> bit from Linux and re-calibrate TSC via HPET:
>>
>>
>> http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L409
>>
>> I think this is the most sane thing we can do. Here's a complete
>> procedure that Linux kernel undertakes:
>>
>>
>> http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L751
>>
>> Regards,
>> Mike
>
> Looks like i have more sort out!
>
> Mike Larkin wrote:
>> If you point me to a bootable image that causes this failure, I might be
>> able to figure out what vmm(4) doesn't like.
>>
>> Nothing in lines 122-134 of the file indicated above should cause this.
>
> This is where things get a little more interesting, Solo5
> (https://github.com/adamsteen/solo5) is actually two parts Solo5 the
> Unikernel and ukvm the userland side of a hypervisor (currently
> running with kvm and bhyve), I have been porting to run ukvm directly
> with vmm. I expect the cause of "vmx_handle_exit: unhandled exit
> 2147483681 (unknown)" is the register setup in
> https://github.com/adamsteen/solo5/blob/master/ukvm/ukvm_hv_openbsd_x86_64.c,
> lines 118-147
>
> the constants are ukvm constants.
>
> struct vm_resetcpu_params vrp = {
> .vrp_vm_id = hvb->vcp_id,
> .vrp_vcpu_id = hvb->vcpu_id,
> .vrp_init_state = {
> .vrs_gprs[VCPU_REGS_RFLAGS] = X86_RFLAGS_INIT,
> .vrs_gprs[VCPU_REGS_RIP] = gpa_ep,
> .vrs_gprs[VCPU_REGS_RSP] = hv->mem_size - 8,
> .vrs_gprs[VCPU_REGS_RDI] = X86_BOOT_INFO_BASE,
> .vrs_crs[VCPU_REGS_CR0] = X86_CR0_INIT,
> .vrs_crs[VCPU_REGS_CR3] = X86_CR3_INIT,
> .vrs_crs[VCPU_REGS_CR4] = X86_CR4_INIT,
> .vrs_sregs[VCPU_REGS_CS] = sreg_to_vsi(&ukvm_x86_sreg_code),
> .vrs_sregs[VCPU_REGS_DS] = sreg_to_vsi(&ukvm_x86_sreg_data),
> .vrs_sregs[VCPU_REGS_ES] = sreg_to_vsi(&ukvm_x86_sreg_data),
> .vrs_sregs[VCPU_REGS_FS] = sreg_to_vsi(&ukvm_x86_sreg_data),
> .vrs_sregs[VCPU_REGS_GS] = sreg_to_vsi(&ukvm_x86_sreg_data),
> .vrs_sregs[VCPU_REGS_SS] = sreg_to_vsi(&ukvm_x86_sreg_data),
> .vrs_gdtr = { 0x0, X86_GDTR_LIMIT, 0x0, X86_GDT_BASE},
> .vrs_idtr = { 0x0, 0x, 0x0, 0x0},
> .vrs_sregs[VCPU_REGS_LDTR] = sreg_to_vsi(&ukvm_x86_sreg_unusable),
> .vrs_sregs[VCPU_REGS_TR] = sreg_to_vsi(&ukvm_x86_sreg_tr),
> .vrs_msrs[VCPU_REGS_EFER] = X86_EFER_INIT,
> .vrs_msrs[VCPU_REGS_STAR] = 0ULL,
> .vrs_msrs[VCPU_REGS_LSTAR] = 0ULL,
> .vrs_msrs[VCPU_REGS_CSTAR] = 0ULL,
> .vrs_msrs[VCPU_REGS_SFMASK] = 0ULL,
> .vrs_msrs[VCPU_REGS_KGSBASE] = 0ULL,
> .vrs_crs[VCPU_REGS_XCR0] = XCR0_X87
> }
> };
>
> the three specific OpenBSD files are
> https://github.com/adamsteen/solo5/blob/master/ukvm/ukvm_hv_openbsd.h
> https://github.com/adamsteen/solo5/blob/master/ukvm/ukvm_hv_openbsd.c
> https://github.com/adamsteen/solo5/blob/master/ukvm/ukvm_hv_openbsd_x86_64.c
> with small changes in ukvm/ukvm_elf.c and ukvm/ukvm_module_net.c
>
> I could upload a binary image for you but It won't run with vmd its
> has ukvm specific hypercalls designed to simplify things.
>
> Cheers
> Adam
>
> ps i am currently trying to document the differences in what vmm is
> expecting and ukvm is expecting.
One more thing
Please note currently i have to build the bootable binary image of
solo5 with a cross compiler as i have not figured out the
discrepancies between OpenBSD's ld and solo5's linker script.
Cheers
Adam
Re: Calculate the frequency of the tsc timecounter
Mike Belopuhov wrote:
> To be able to use TSC as a timecounter source on OpenBSD or Solo5
> you'd have to improve the in-kernel measurement of the TSC frequency
> first. I've tried to perform 10 measurements and take an average and
> it does improve accuracy, however I believe we need to poach another
> bit from Linux and re-calibrate TSC via HPET:
>
>
> http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L409
>
> I think this is the most sane thing we can do. Here's a complete
> procedure that Linux kernel undertakes:
>
>
> http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L751
>
> Regards,
> Mike
Looks like i have more sort out!
Mike Larkin wrote:
> If you point me to a bootable image that causes this failure, I might be
> able to figure out what vmm(4) doesn't like.
>
> Nothing in lines 122-134 of the file indicated above should cause this.
This is where things get a little more interesting, Solo5
(https://github.com/adamsteen/solo5) is actually two parts Solo5 the
Unikernel and ukvm the userland side of a hypervisor (currently
running with kvm and bhyve), I have been porting to run ukvm directly
with vmm. I expect the cause of "vmx_handle_exit: unhandled exit
2147483681 (unknown)" is the register setup in
https://github.com/adamsteen/solo5/blob/master/ukvm/ukvm_hv_openbsd_x86_64.c,
lines 118-147
the constants are ukvm constants.
struct vm_resetcpu_params vrp = {
.vrp_vm_id = hvb->vcp_id,
.vrp_vcpu_id = hvb->vcpu_id,
.vrp_init_state = {
.vrs_gprs[VCPU_REGS_RFLAGS] = X86_RFLAGS_INIT,
.vrs_gprs[VCPU_REGS_RIP] = gpa_ep,
.vrs_gprs[VCPU_REGS_RSP] = hv->mem_size - 8,
.vrs_gprs[VCPU_REGS_RDI] = X86_BOOT_INFO_BASE,
.vrs_crs[VCPU_REGS_CR0] = X86_CR0_INIT,
.vrs_crs[VCPU_REGS_CR3] = X86_CR3_INIT,
.vrs_crs[VCPU_REGS_CR4] = X86_CR4_INIT,
.vrs_sregs[VCPU_REGS_CS] = sreg_to_vsi(&ukvm_x86_sreg_code),
.vrs_sregs[VCPU_REGS_DS] = sreg_to_vsi(&ukvm_x86_sreg_data),
.vrs_sregs[VCPU_REGS_ES] = sreg_to_vsi(&ukvm_x86_sreg_data),
.vrs_sregs[VCPU_REGS_FS] = sreg_to_vsi(&ukvm_x86_sreg_data),
.vrs_sregs[VCPU_REGS_GS] = sreg_to_vsi(&ukvm_x86_sreg_data),
.vrs_sregs[VCPU_REGS_SS] = sreg_to_vsi(&ukvm_x86_sreg_data),
.vrs_gdtr = { 0x0, X86_GDTR_LIMIT, 0x0, X86_GDT_BASE},
.vrs_idtr = { 0x0, 0x, 0x0, 0x0},
.vrs_sregs[VCPU_REGS_LDTR] = sreg_to_vsi(&ukvm_x86_sreg_unusable),
.vrs_sregs[VCPU_REGS_TR] = sreg_to_vsi(&ukvm_x86_sreg_tr),
.vrs_msrs[VCPU_REGS_EFER] = X86_EFER_INIT,
.vrs_msrs[VCPU_REGS_STAR] = 0ULL,
.vrs_msrs[VCPU_REGS_LSTAR] = 0ULL,
.vrs_msrs[VCPU_REGS_CSTAR] = 0ULL,
.vrs_msrs[VCPU_REGS_SFMASK] = 0ULL,
.vrs_msrs[VCPU_REGS_KGSBASE] = 0ULL,
.vrs_crs[VCPU_REGS_XCR0] = XCR0_X87
}
};
the three specific OpenBSD files are
https://github.com/adamsteen/solo5/blob/master/ukvm/ukvm_hv_openbsd.h
https://github.com/adamsteen/solo5/blob/master/ukvm/ukvm_hv_openbsd.c
https://github.com/adamsteen/solo5/blob/master/ukvm/ukvm_hv_openbsd_x86_64.c
with small changes in ukvm/ukvm_elf.c and ukvm/ukvm_module_net.c
I could upload a binary image for you but It won't run with vmd its
has ukvm specific hypercalls designed to simplify things.
Cheers
Adam
ps i am currently trying to document the differences in what vmm is
expecting and ukvm is expecting.
Re: touchpad input driver: testing needed
On Mon, Jul 31, 2017 at 11:02:28PM +0200, Ulf Brosziewski wrote: > for you. As always, a dmesg would be appreciated. The output of > # wsconsctl | grep 'mouse' > could also be of interest here (you must run it as root). This report is from a MacBookAir7,2 which is a 2015 13-inch MacBook Air. Anything more than a regular click is not working as can be seen from the wsconsctl output. I was using synclient to configure previously which did allow the other settings. # wsconsctl | grep mouse mouse.type=usb mouse.rawmode=1 mouse.scale=0,0,0,0,0,0,0 mouse1.type=elantech mouse1.rawmode=0 mouse1.scale=-4620,5140,-150,6600,0,0,0 Bryan OpenBSD 6.1-current (GENERIC.MP) #27: Mon Jul 31 12:56:47 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error ff real mem = 8469352448 (8077MB) avail mem = 8206315520 (7826MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x8afad000 (32 entries) bios0: vendor Apple Inc. version "MBA71.88Z.0166.B26.1703211638" date 03/21/2017 bios0: Apple Inc. MacBookAir7,2 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT DMAR MCFG acpi0: wakeup devices PEG0(S3) EC__(S3) HDEF(S3) RP01(S3) RP02(S3) RP03(S4) ARPT(S4) RP05(S3) RP06(S3) SPIT(S3) XHC1(S3) ADP1(S3) LID0(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-5650U CPU @ 2.20GHz, 2200.37 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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 2200371760 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz 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-5650U CPU @ 2.20GHz, 2200.00 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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,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-5650U CPU @ 2.20GHz, 2200.00 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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,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-5650U CPU @ 2.20GHz, 2200.00 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,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,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpiec0 at acpi0 acpimcfg0 at acpi0 addr 0xe000, bus 0-155 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus 2 (RP02) acpiprt4 at acpi0: bus 3 (RP03) acpiprt5 at acpi0: bus 5 (RP05) acpiprt6 at acpi0: bus 4 (RP06) acpicpu0 at acpi0: C3(200@530 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@530 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@530 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(200@530 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpisbs0 at acpi0: SBS0 model "bq20z451" serial 36068 type LION oem "DP" "APP0001" at acpi0 not configured "ACPI0008" at acpi0 not configured "ACPI0001" at acpi0 not configured "APP000D" at acpi0 not configur
Re: touchpad input driver: testing needed
On Mon, Jul 31, 2017 at 11:02:28PM +0200, Ulf Brosziewski wrote: > for you. As always, a dmesg would be appreciated. The output of > # wsconsctl | grep 'mouse' > could also be of interest here (you must run it as root). Here is another report. This one is from a Lenovo LaVie Z with an Elantech touchpad. So far seems to work just fine as well. # wsconsctl | grep mouse mouse.type=elantech mouse.rawmode=0 mouse.scale=0,2800,0,1820,0,0,0 mouse.tp.tapping=0 mouse.tp.scaling=0.275 mouse.tp.swapsides=0 mouse.tp.disable=0 Thanks again! Bryan OpenBSD 6.1-current (GENERIC.MP) #27: Mon Jul 31 12:56:47 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8485908480 (8092MB) avail mem = 8222367744 (7841MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xdcef (23 entries) bios0: vendor LENOVO version "/763A0400" date 04/02/2015 bios0: LENOVO 20FG0013US acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT ECDT MCFG HPET SSDT UEFI SSDT ASF! MSDM SSDT SSDT SSDT BGRT SSDT acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) LID0(S3) PXSX(S3) RP01(S4) PXSX(S3) RP02(S4) PXSX(S3) RP03(S4) PXSX(S3) RP04(S4) PXSX(S3) [...] 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-5500U CPU @ 2.40GHz, 2394.86 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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 2394859830 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.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz, 2394.47 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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,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-5500U CPU @ 2.40GHz, 2394.47 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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,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-5500U CPU @ 2.40GHz, 2394.47 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,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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimadt0: bogus nmi for apid 2 acpimadt0: bogus nmi for apid 1 acpimadt0: bogus nmi for apid 3 acpiec0 at acpi0 acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus 1 (RP01) acpiprt5 at acpi0: bus -1 (RP02) acpiprt6 at acpi0: bus 2 (RP03) acpiprt7 at acpi0: bus 3 (RP04) acpiprt8 at acpi0: bus -1 (RP05) acpiprt9 at acpi0: bus -1 (RP06) acpiprt10 at acpi0: bus -1 (RP07) acpiprt11 at acpi0: bus -1 (RP08) acpiec at acpi0 not configured acpiec at acpi0 not configured acpicpu0 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PG00, resource for
Re: touchpad input driver: testing needed
On Mon, Jul 31, 2017 at 11:02:28PM +0200, Ulf Brosziewski wrote: > for you. As always, a dmesg would be appreciated. The output of > # wsconsctl | grep 'mouse' > could also be of interest here (you must run it as root). This is from a Lenovo ThinkPad X1 Carbon (4th Gen) which has a Synaptics touchpad which has been working fine otherwise and appears to continue to work fine with your driver. # wsconsctl | grep mouse mouse.type=synaptics mouse.rawmode=0 mouse.scale=1472,5678,1408,4754,0,46,68 mouse.tp.tapping=0 mouse.tp.scaling=0.171 mouse.tp.swapsides=0 mouse.tp.disable=0 mouse1.type=ps2 Thanks for your work on this! Bryan OpenBSD 6.1-current (GENERIC.MP) #26: Mon Jul 31 08:42:35 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17011994624 (16223MB) avail mem = 16490065920 (15726MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xb705e000 (65 entries) bios0: vendor LENOVO version "N1FET49W (1.23 )" date 02/08/2017 bios0: LENOVO 20FBCTO1WW acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI SSDT SSDT ECDT HPET APIC MCFG SSDT SSDT DBGP DBG2 BOOT BATB SSDT SSDT MSDM DMAR ASF! FPDT UEFI acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP9(S4) XHCI(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 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-6600U CPU @ 2.60GHz, 2808.00 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: TSC frequency 280800 Hz 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-6600U CPU @ 2.60GHz, 2808.00 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-6600U CPU @ 2.60GHz, 2808.00 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-6600U CPU @ 2.60GHz, 2808.00 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,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 cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus 2 (EXP1) acpiprt5 at acpi0: bus 4 (EXP3) acpiprt6 at acpi0: bus 5 (EXP5) acpiprt7 at acpi0: bus -1 (EXP9) acpicpu0 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PUBS, resource for XHCI acpipwrres1 at acpi0: PG00, resource for PEG0 acpipwrres2 at acpi0: PG01, resource for PEG1 acpipwrres3 at acpi0: PG02, resource for PEG2 acpi
touchpad input driver: testing needed
In the long run the synaptics driver, which handles touchpad inputs in X, may be a dead end of the input framework, and it's time to prepare an alternative. The kernel contains an internal touchpad input driver now, it's a part of wsmouse(4). It provides standard features - two-finger/edge scrolling, software buttons for clickpads, tapping - and various kinds of plankton required for usability. If you have a new snapshot (from July 27 or later) on a laptop with a Synaptics, Apple, Alps, or Elantech-4 touchpad, you could help with tests, more tests, and tests. In order to activate the driver, add the following entry to /etc/xorg.conf and restart X (if the file isn't present, simply create it with this content): Section "InputClass" Identifier "wsmouse touchpad" Driver "ws" MatchIsTouchpad "on" EndSection While I dont't expect bugs in the input processing part of the driver ;-), it is difficult to assess how well the automatic configuration covers the zoo of models out there, presumably it will need some more fine-grained distinctions of hardware properties. I would like to know where it works, works only halfway, or doesn't work for you. As always, a dmesg would be appreciated. The output of # wsconsctl | grep 'mouse' could also be of interest here (you must run it as root). For now, X will treat the device like a mouse, please don't look for touchpad-specific configuration options there. Tapping can be enabled by the command # wsconsctl mouse.tp.tapping=1 If there is more than one wsmouse device, you should look up which one has the "tp" fields and if it's not the first one (wsmouse0), add the index to the prefix, e.g. # wsconsctl mouse2.tp.tapping=1 The base speed of the pointer can be adjusted by increasing or decreasing the value of # wsconsctl mouse.tp.scaling Please don't confuse it with the 'mouse.scale' field. # wsconsctl mouse.tp.swapsides=1 will invert the order of software buttons areas (swapping external buttons must still be configured in X). If edge scrolling is enabled, the scroll area will be at the left edge of the touchpad. If you are using an external mouse device or a trackpoint, the command # wsconsctl mouse.tp.disable=1 may be helpful. It will disable pointer movement, scrolling, and tapping. External buttons and software buttons remain enabled.
Re: permission denied local nfs mount
On Fri, Jul 28, 2017 at 7:36 PM, Allan Streib wrote: > $ cat /etc/exports > /home/astreib/work/new-site.org -ro -network=127.0.0.1 > > Everyhing works if I remove the "-network=" from /etc/exports, i.e.: > > /home/astreib/work/new-site.org -ro 127.0.0.1 > > I don't really understand why? If you don't specify -network, then 127.0.0.1 is treated as the address (or name) of a specific host. Since you are going to be mounting this via 127.0.0.1, that counts as a host address and everything works. If you do specify -network, then 127.0.0.1 is treated as a network number, and the default netmask would be 255.0.0.0. I don't know why that's not working, but (a) I always specify -mask whenever I use -network, and (b) I always ensure that the host portion of the network number is all zeros. So if I were to do it I would use: /home/astreib/work/new-site.org -ro -network 127.0.0.0 -mask 255.0.0.0 (I would use 255.0.0.0 as the mask simply because that's the mask the actual loopback interface is using, but I don't think it actually matters as far as /etc/exports is concerned -- if you want to use an unusual mask to allow access to a subset of a network then as far as I know you should be able to). Unless you are binding multiple addresses on your loopback interface, I would just use 127.0.0.1 without -network or -mask and be done with it. Why open up the mount to an entire network when you really just need to open it up to a single host (yourself)? This is what I do in a similar situation (serving both ftpd and httpd from the same directory): relevant line from /etc/exports: /nfs/archive/dist/OpenBSD -maproot=root -ro 127.0.0.1 relevant line from /etc/fstab: localhost:/nfs/archive/dist/OpenBSD /var/www/ftp/pub/OpenBSD nfs ro,nodev,nosuid 0 0 Works fine for me. -ken
Re: Split zone DNS?
On Fri, Jul 28, 2017 at 9:58 AM, Steve Williams wrote: > I would like to run a local resolver on my internal network that will > resolve all my hosts on my local network to IP addresses on my local > network(s) rather than resolving to their public IP addresses. > > What is the best tool to accomplish this these days? Is NSD the "modern" > tool to be using on OpenBSD? > > Are there any hooks for dhcpd to update records? I have found the readily available documentation unclear on how to handle dynamic DNS updates when DHCP is in use. The advice I've seen has basically been either to not bother, or to have DHCP assign fixed addresses (i.e. don't do dynamic DNS). It's not totally clear whether it's even possible using nsd/unbound and the base dhcpd, but what I've seen indicates that it is not. So, what I am doing instead is I'm using isc-dhcp-server and isc-bind (from packages). Note that I provide DNS/DHCP service on my internal network only (I do not provide any DNS name resolution of any kind on my Internet-facing interfaces) so it's not really "split-horizon". If I were to provide split-horizon DNS I would probably use two separate machines, one providing internal service (using isc-dhcp-server and isc-bind) and another providing external service (using nsd). -ken
Re: starting cwm and terminal font
On 2017-07-30 23.37.07 -0700, jungle boogie wrote: > $ cat .xinitrc > xsetroot -solid gray40 (does the 40 actually do anything? I've seen a few > examples with numbers after it) That color name comes from /usr/X11R6/share/X11/rgb.txt : $ grep gray40 /usr/X11R6/share/X11/rgb.txt 102 102 102 gray40
Re: Question about pf tables and limitation of addresses 0.0.0.0/0 or 0/0
On Thu, Jul 27, 2017 at 12:52 PM, Donald Clark Jackson
wrote:
> table const { !10/8 !172.16/12 !192.168/16 0/0 }
> guest_hq_if = "em3"
> guest_hq_net = $guest_hq_if:network
> pass log (matches) from $guest_hq_net to keep state
>
> match out log (matches) on $external_if inet from $guest_hq_net nat-to
> ($external_if)
I'm not sure this ruleset is doing what you think it's doing. Try
running the following command to verify that your table
contains what you think it should:
# pfctl -t public -T show
Putting aside for the moment whether 0/0 works or not, I think you
have another problem with the ! marks. To explain the problem, let's
pretend the entire Internet consists of just 3 class A networks: 1/8,
2/8 and 3/8. So what does { !1/8 !2/8 } mean? It's a table
containing all the addresses not in 1/8 (i.e. 2/8 3/8), plus all the
addresses not in 2/8 (i.e. 1/8 3/8):
{ 2/8 3/8 1/8 3/8 } simplifies to { 1/8 2/8 3/8 }, which matches
everything and is probably not what you intended.
I don't think you can even use ! in a table, even though "pfctl -nf"
doesn't appear to complain about it at all. When I try it in
5.9/amd64 the tables end up being not defined.
If you want to provide an Internet-only guest network, I recommend you
try something like this:
table { 10/8, 172.16/12, 192.168/16 }
guest_if = "em3"
ext_if = "em0" # or whatever your egress interface is
pass in log on $guest_if from $guest_if:network to any
block in log quick on $guest_if to $guest_if # note 1
block out log quick on $ext_if from $guest_if:network to # note 2
pass out log on $ext_if from $guest_if:network nat-to ($ext_if)
This lets guest traffic into the router, then relies on your routing
table to decide which outbound interface the traffic should then be
forwarded to. Traffic to the Internet (going out through $ext_if) is
passed with an explicit "pass out" rule (and NAT is applied at the
same time). Traffic attempting to reach your other internal networks
is not forwarded because there is no "pass out" rule on any other
interface allowing it.
note 1: Connections *to* your router rather than *through* your router
are dropped, to prevent guests from trying to ssh into your router.
If you want to allow guests to connect to your router for certain
services (e.g. dns) then you will want to be more selective.
note 2: Internet traffic to "unrouteable" Internet addresses is
dropped. Note that this rule explicitly applies only to traffic "from
$guest_if:network" because other outbound traffic might legitimately
need to send to such an address. For example, some ISP's will provide
a 10/8 address as your default route, and blocking 10/8
unconditionally will prevent you from doing things like pinging that
router.
As you have discovered, once you have more than two networks (internal
and external) things can start to get complicated, which means the
opportunity to make mistakes goes up dramatically. What I do to make
things clearer (and to reduce the impact of mistakes) is to use tags
to categorize traffic:
### BEGIN ###
private = "em0"
guest = "em1"
inet = "em2"
table const { 10/8, 172.16/12, 192.168/16 }
# Inbound traffic is blocked by default and tagged TBD until it can be
categorized
block in log all tag TBD
# Inbound / ACCEPT - traffic that should be accepted by this router
(not forwarded)
pass in log quick on $private inet proto tcp from $private:network to
$private port ssh tagged TBD tag ACCEPT
pass in log quick on $private inet proto icmp from $private:network to
(self) icmp-type echoreq tagged TBD tag ACCEPT
pass in log quick on $guest inet proto icmp from $guest:network to
(self) icmp-type echoreq tagged TBD tag ACCEPT
pass in log quick on $private inet proto {udp tcp} from
$private:network to em0 port {domain ntp} tagged TBD tag ACCEPT
pass in log quick on $guest inet proto {udp tcp} from $guest:network
to $guest port {domain ntp} tagged TBD tag ACCEPT
pass in log quick on $private inet proto tcp from $private:network to
port ftp divert-to 127.0.0.1 port 8021 tagged TBD tag ACCEPT
pass in log quick on $guest inet proto tcp from $guest:network to port
ftp divert-to 127.0.0.1 port 8021 tagged TBD tag ACCEPT
anchor "ftp-proxy/*"
# Inbound / FORWARD - traffic that should be forwarded by this router
pass in log quick on $private from $private:network tagged TBD tag FORWARD
block in log quick on $guest from $guest:network to $private:network
tagged TBD tag BLOCK
pass in log quick on $guest from $guest:network tagged TBD tag FORWARD
# Outbound / FORWARD
block out log all # by default block all outbound traffic not explicitly allowed
pass out log quick on $private tagged FORWARD
pass out log quick on $guest tagged FORWARD
block out log quick on $inet to tag BLOCK
pass out log quick on $inet nat-to ($inet) tagged FORWARD
# Outbound - traffic that may originate from this router (even this is
blocked by default)
pass out log quick on $inet inet proto udp from ($inet) port bootpc to
any port bootps # ISP DHCP service
p
Re: Changing default compiler for usr/ports buiding
On Mon, Jul 31, 2017 at 05:47:59PM +0300, Denis wrote: > I'm trying to change default compiler to build some ports. > Tried to do it using bsd.port.mk and by system variables CXX=eg++ > CPP=egcc, but nothing changes while building a port. > > How can I force the default gcc 4.2 to egcc (gcc 4.9)? > > Thanks You can't. Things generally won't work. Current uses clang on i386 and amd64. And that's wildly incompatible with gcc 4.2 or 4.9...
Opensmtpd-extras documentation
Hi there, Is there some documentation on the ldapFilter ? It's kinda frustrating to see a 535 Auth failed even you are sure you got the right credentials. I have openldap running but without some basic info on how to pass looked up information on to smtpd I'm lost here Regards Markus Von meinem Samsung Gerät gesendet.
Re: Calculate the frequency of the tsc timecounter
On Mon, Jul 31, 2017 at 07:19:36AM +0800, Adam Steen wrote:
> Sorry, i sent that before i had finished.
>
> I am trying to find an equivalent of the following code for FreeBSD
>
> size_t outsz = sizeof bi->cpu.tsc_freq;
> int ret = sysctlbyname("machdep.tsc_freq", &bi->cpu.tsc_freq, &outsz,
> NULL,
> 0);
> if (ret == -1)
> err(1, "sysctl(machdep.tsc_freq)");
> int invariant_tsc = 0;
> outsz = sizeof invariant_tsc;
> ret = sysctlbyname("kern.timecounter.invariant_tsc", &invariant_tsc,
> &outsz,
> NULL, 0);
> if (ret == -1)
> err(1, "sysctl(kern.timecounter.invariant_tsc");
> if (invariant_tsc != 1)
> errx(1, "Host TSC is not invariant, cannot continue");
>
>
> line 122-134 of
> https://github.com/adamsteen/solo5/blob/master/ukvm/ukvm_hv_freebsd_x86_64.c
>
> Currently the port fails with "vmx_handle_exit: unhandled exit
> 2147483681 (unknown)" (0x8021 in hex), I am setting up the
> registers to incorrect values, but need to read more to understand
> what OpenBSD vmm and ukvm are expecting from each other.
>
If you point me to a bootable image that causes this failure, I might be
able to figure out what vmm(4) doesn't like.
Nothing in lines 122-134 of the file indicated above should cause this.
-ml
> Cheers
> Adam
>
> > Hi Mike
> >
> > In short i don't want to calculate the TSC frequency, i would like to
> > get it from the kernel if possible? (also checking if it was
> > invariant.) I knew my code was inaccurate, but didn't know another
> > way.
> >
> > I did check the output of dmesg: "cpu0: TSC frequency 2492310500 Hz',
> > but couldn't find a away to get this programmatically, eg via sysctl
> >
> > Long story, i am in the process of porting Solo5 to OpenBSD (see
> > https://github.com/adamsteen/solo5) and need the tsc frequency to
> > support the ukvm tsc clock.
> >
> > Is there currently a way to get the TSC frequency programmatically?
> > and is CPUID the best way to check if the tsc is invariant?
> > (CPUID.8007H:EDX[8], Intel's Designer's vol3b, section 16.11.1
> > Invariant TSC)
> >
> > On Mon, Jul 31, 2017 at 1:57 AM, Mike Belopuhov wrote:
> >> On Wed, Jul 26, 2017 at 19:24 +0800, Adam Steen wrote:
> >>> Hi
> >>>
> >>> Is there an easy/accurate way to calculate the tsc timecounter frequency?
> >>> like Time Stamp Counters on Linux. (on a
> >>> Sandy Bridge cpu)
> >>>
> >>> Another reference Converting Sandy Bridge TSC to wall clock time
> >>> .
> >>>
> >>> The code below works but i don't really know how accurate it is, at best
> >>> 10,000 Hz.
> >>>
> >>> Cheers
> >>> Adam
> >>>
> >>
> >> Hi,
> >>
> >> First of all it's not clear why do you want to calculate TSC
> >> frequency in the userland program? The kernel does it and
> >> prints the result to the system message buffer (viewed with
> >> the dmesg command).
> >>
> >> The second thing worth pointing out is that gettimeofday is a
> >> syscall that queries the timestamp from the timecounter code
> >> (updated every 10ms) with a current delta read directly from
> >> the hardware so that you get an accurate reading, but then
> >> it's adjusted according to the system time adjustment rules
> >> imposed by things like NTP and settimeofday, so essentially
> >> it's not monotonic (unless you can ensure there is no actor
> >> present that is adjusting the time while you're performing
> >> your measurement). There's also a way for userland to query
> >> a precise monotonically increasing timestamp: clock_gettime
> >> with CLOCK_MONOTONIC as the clock_id. In this case the
> >> returned timestamp is relative to the moment the system was
> >> brought up but this doesn't matter if all you need is
> >> difference.
> >>
> >> The third thing to know is where does this hardware reading
> >> comes from and what's its precision. Running "sysctl -n
> >> kern.timecounter.hardware" will tell you what is currently
> >> selected as the source and then you can locate that device
> >> your dmesg (with exception of i8254 -- that 1.19Mhz PIT).
> >> For instance on my laptop it's ACPI HPET that is proving a
> >> running counter with the frequency of 14 MHz. This is what's
> >> going to limit the precision of your measurement.
> >>
> >> To get a better reading you may try to take a series of say
> >> 10 measurements and calculate the average.
> >>
> >> The difference between RDTSC and RDTSCP is that the latter
> >> tells you on which CPU the instruction was executed. This
> >> poses a valid question: is TSC frequency the same on a multi-
> >> socket system. And I don't have an answer for that one.
> >> AFAIU, this boils down to the motherboard design and if the
> >> manufacturer has selected to use different quartz crystals
> >> for different sockets, then as we know for a fact that no two
> >> quartz crystals are created the same and thus frequency
> >> sourced fr
Re: permission denied local nfs mount
Todd writes: > Is there anything in the logs? Can you try adding the IP of your > network adapter to exports? I don't see anything in logs. Would they be anywhere other than in /var/log? I didn't try adding the network IP but really only want this "exported" on localhost. Essentially I want the effect of linux's "mount --bind" option. Are you suggesting that -network option only works with real network adaptors and not loopback? Allan
Changing default compiler for usr/ports buiding
I'm trying to change default compiler to build some ports. Tried to do it using bsd.port.mk and by system variables CXX=eg++ CPP=egcc, but nothing changes while building a port. How can I force the default gcc 4.2 to egcc (gcc 4.9)? Thanks
Re: syspatch question
On 07/31/2017 03:56 PM, Marko Cupać wrote:
> Hi,
>
> first of all, thanx for syspatch. One-liner to apply all the errata
> patches instead of syncing source and rebuilding stuff are welcomed on
> my fleet of geographically remote OpenBSD firewalls running on PC
> Engines' apu2d4, not only because of its speed and simplicity, but also
> because of SDcard tear&wear minimisation.
>
> Now, I know I'm in unsupported waters because I noticed this on a box
> with only / mounted read-only, and /dev /var and /tmp as writable mfs
> file systems described (warning! blatant self-promotion below!) here:
> [https://www.mimar.rs/blog/how-to-increase-openbsds-resilience-to-power-outages]
>
> ...but the problem I am facing is that syspatch -l shows installed
> patches up to 013:
>
> pacija@zemun:~ $ doas syspatch -l
> 001_dhcpd
> 002_vmmfpu
> 003_libressl
> 004_softraid_concat
> 005_pf_src_tracking
> 006_libssl
> 007_freetype
> 008_exec_subr
> 009_icmp_opts
> 010_perl
> 012_wsmux
> 013_icmp6_linklocal
>
> ...whereas syspatch -c returns zero, while I guess it should return
> 014_libcrypto at the time of writing this. Another identical box which
> was patched up to 012 shows correct information (-l up to 012, -c 013
> and 014).
>
> I'm not whining or anything, I trust my OpenBSD firewalls to be more
> secure than any other solution out there even without these patches.
> But maybe someone with more knowledge of syspatch finds this behaviour
> worth investigating, even on unsupported setup.
>
> Finally, my question: How does syspatch check current patchlevel? By
> checking contents of /var/syspatch or some other way? I guess I'm
> showing my ignorance here :)
>
> Best regards,
>
If you file(1) /usr/sbin/syspatch, you'll see it's just a shell script;
that should probably help you understand what's going on, though it's
fairly terse shell script. I'll be tracing the execution of -c.
$ file /usr/sbin/syspatch
/usr/sbin/syspatch: Korn shell script text executable
syspatch -c contacts the mirrors in /etc/installurl at
${_MIRROR}/syspatch/${_KERNV[0]}/$(machine), for example:
https://ftp.fau.de/pub/OpenBSD/syspatch/6.1/amd64/ -- $_MIRROR is
https://ftp.fau.de/pub/OpenBSD, $_KERNV[0] is 6.1 (obtained from sysctl
-n kern.version), machine(1) returned amd64 and downloads SHA256 and
SHA256.sig. Then it verifies SHA256 against SHA256.sig.
It then parses the filenames in the SHA256 file in a format that's
compatible with syspatch -l and checks that list against the list
returned by syspatch -l.
syspatch -l checks /var/syspatch and lists directories those that have a
rollback.tgz inside them. It then sorts them using sort -V.
I'm not 100% sure on the details since I'm not the most experienced
shell scripter in the world, but this ought to be accurate enough for
debugging. If I'm wrong, I hope someone will come along and me.
My guess is that the mirror in /etc/installurl is either down or points
at a local file or something along those lines.
syspatch question
Hi, first of all, thanx for syspatch. One-liner to apply all the errata patches instead of syncing source and rebuilding stuff are welcomed on my fleet of geographically remote OpenBSD firewalls running on PC Engines' apu2d4, not only because of its speed and simplicity, but also because of SDcard tear&wear minimisation. Now, I know I'm in unsupported waters because I noticed this on a box with only / mounted read-only, and /dev /var and /tmp as writable mfs file systems described (warning! blatant self-promotion below!) here: [https://www.mimar.rs/blog/how-to-increase-openbsds-resilience-to-power-outages] ...but the problem I am facing is that syspatch -l shows installed patches up to 013: pacija@zemun:~ $ doas syspatch -l 001_dhcpd 002_vmmfpu 003_libressl 004_softraid_concat 005_pf_src_tracking 006_libssl 007_freetype 008_exec_subr 009_icmp_opts 010_perl 012_wsmux 013_icmp6_linklocal ...whereas syspatch -c returns zero, while I guess it should return 014_libcrypto at the time of writing this. Another identical box which was patched up to 012 shows correct information (-l up to 012, -c 013 and 014). I'm not whining or anything, I trust my OpenBSD firewalls to be more secure than any other solution out there even without these patches. But maybe someone with more knowledge of syspatch finds this behaviour worth investigating, even on unsupported setup. Finally, my question: How does syspatch check current patchlevel? By checking contents of /var/syspatch or some other way? I guess I'm showing my ignorance here :) Best regards, -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
Re: starting cwm and terminal font
xterm popup menus: Ctrl + left mouse button Ctrl + right mouse button The latter gives font size options. On 31 July 2017 at 00:06, jungle boogie wrote: > Hello, > > > I have some cwm questions for you folks. > > cwm is launching, but it's not setting my background to gray. > I thought I made the change correctly. > > $ cat .xsession > > > /usr/X11R6/bin/cwm > xsetroot -solid grey & > oclock -geometry 75x75-0-0 & > > The clock is also not showing up. > > I've also put it in here: > $ cat .xinitrc > > > oclock -geometry 75x75-0-0 & > xsetroot -solid grey & > /usr/X11R6/bin/cwm > > Does it need to go in the .cwmrc? > $ cat .cwmrc > > > command firefox /usr/local/bin/firefox > #fontname "sans-serif:pixelsize=14:bold" > fontname "Courier:pixelsize=14:style=Regular" > > Is there a way to change the console font to something a little larger? > fontname seems to change for menus only. > > Thanks! > >
Re: after update imput/output error when I run terminal
Hey, On 07/31/17 06:57, Krzysztof Strzeszewski wrote: I update openbsd 6.1-current end is error. When I update, when I run terminal imput/output error on xfce. after upgrading to a clang snapshot you have to force pkg_add to reinstall all packages on your computer. pkg_add -D installed -uV This will do the trick. Greetings Leo
Re: smtpd vs. uw-imap locking
On Sun, Jul 30, 2017 at 07:47:15PM -0400, gwes wrote:
> smtpd locks user mailboxes in /var/mail using lockspool(1)
> uw-imapd locks using its own dotfile locker mlock(not the syscall)
>
Actually, it is mail.local that does the locking, smtpd knows nothing at
all regarding /var/mail as it is an MDA thing.
mailbox locking is complex to be done right with all the NFS horror, and
mail.local, which was already used with Sendmail, solved issue for us so
we decided not to introduce unnecessary bugs :-)
> Before I go into uw-imapd and do some nasty additions and
> if()s:
> does anyone else care?
> does anyone else use uw-imap?
> has anyone attacked this problem?
> is there anywhere else to ask these questions?
>
> switch(answers) {
> *, *, *, yes: go there
> no, *, *, no: go do ugly coding in the dark
> *, *, yes, *: may I please see what you did?
> yes, yes, no, *: please get in touch
> default: go do ugly coding
> }
>
> I'm not interested in any other server unless it is
> at least as lightweight as uw-imap. Courier, Cyrus,
> etc. are obese by comparison.
>
To be honest, after having used wu-imapd and courier, I'd give Dovecot a
go if only because of privileges separation and a more modern design for
such an exposed target.
Also, mbox is really a left-over from the past and unless you are forced
to use it, switching to maildir has many advantages ranging from being a
lock-less delivery method to being easier to manage as an admin.
That being said: no, no, no, * because I'm curious.
--
Gilles Chehade
https://www.poolp.org @poolpOrg
Re: starting cwm and terminal font
On July 31, 2017 8:37:07 AM GMT+02:00, jungle boogie wrote: >Thus said Jungle Boogie on Sun, 30 Jul 2017 16:06:06 -0700 >> Hello, >> >> >> I have some cwm questions for you folks. >> >> cwm is launching, but it's not setting my background to gray. >> I thought I made the change correctly. >> >> $ cat .xsession >> >> >> /usr/X11R6/bin/cwm >> xsetroot -solid grey & >> oclock -geometry 75x75-0-0 & >> > >I've learned much from all these posts - thank you all! > >Now using .Xdefaults: >XTerm*faceName: Momo:style=Regular:size=9 >XTerm.vt100.saveLines: 1000 >XTerm.vt100.scrollBar: true >XTerm.vt100.scrollbar.width: 8 >XTerm*selectToClipboard:true > >Also some color stuff below. Is everything above accurate to use with >openbsd? > >My xinitrc: >$ cat .xinitrc > > > >xsetroot -solid gray40 (does the 40 actually do anything? I've seen a >few examples with numbers after it) >#xclock -d -geometry 180x30-0-0 >exec cwm > > >I have the digit xclock commented out, because when it was enabled, it >seem to have locked the system. Any hints? Add an & at the end of the command to background it. /Alexander > >My cwmrc: >$ cat .cwmrc > > > >command firefox /usr/local/bin/firefox >fontname "Courier:pixelsize=12:style=Regular" > > >So it's coming along and I'm liking it! > >I have links installed as the browser (and firefox as you see above). >Is links a favorite low resources browser with you folks? > >Thanks for all the responses so far!
Re: Calculate the frequency of the tsc timecounter
On Mon, Jul 31, 2017 at 09:48 +0800, Adam Steen wrote: > Ted Unangst wrote: > > we don't currently export this info, but we could add some sysctls. there's > > some cpufeatures stuff there, but generally stuff isn't exported until > > somebody finds a use for it... it shouldn't be too hard to add something to > > amd64/machdep.c sysctl if you're interested. > > I am interested, as i need the info, i will look into it and hopefully > come back with a patch. This is a bad idea because TSC as the time source is only usable by OpenBSD on Skylake and Kaby Lake CPUs since they encode the TSC frequency in the CPUID. All older CPUs have their TSCs measured against the PIT. Currently the measurement done by the kernel isn't very precise and if TSC is selected as a timecounter, the machine would be gaining time on a pace that cannot be corrected by our NTP daemon. (IIRC, about an hour a day on my Haswell running with NTP). To be able to use TSC as a timecounter source on OpenBSD or Solo5 you'd have to improve the in-kernel measurement of the TSC frequency first. I've tried to perform 10 measurements and take an average and it does improve accuracy, however I believe we need to poach another bit from Linux and re-calibrate TSC via HPET: http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L409 I think this is the most sane thing we can do. Here's a complete procedure that Linux kernel undertakes: http://elixir.free-electrons.com/linux/v4.12.4/source/arch/x86/kernel/tsc.c#L751 Regards, Mike
Re: starting cwm and terminal font
>xsetroot -solid gray40 (does the 40 actually do anything? I've seen a >few examples with numbers after it) I think you can pass an 8-bit color value \ (the ones you see on HTML/CSS, like "#EE") Thanks, Muhammad Kaisar Arkhan
Re: OpenBSD 6.1 installation, on dedicated server, using qemu not working.
On 07/28/2017 08:47 PM, Stefan Fritsch wrote: > On Tuesday, 25 July 2017 21:30:08 CEST Mxher wrote: >> I'm renting a dedicated server from a web host that unfortunately does >> not propose OpenBSD installation. >> >> So I'm installing OpenBSD using qemu from my host rescue mode (which use >> FreeBSD). >> >> >> Usually it works like a charm but this time, on this server/hardware, it >> does not work: OpenBSD does not seem to start at all. >> Indeed when I boot with qemu I do not see any logs of the "normal" boot >> of the server (I only see qemu's boots in the logs). > > Maybe I misunderstand what you are trying to do, but: There is sgabios for > redirecting vga text output to serial console in qemu. Maybe that could help > somehow? Or try using VNC console in qemu. Are you seeing the openbsd > bootloader prompt? Are you then setting the console correctly in the openbsd > bootloader? > Sorry for being unclear because of my poor english. Actually I have no issue at all with qemu. I want to use OpenBSD on my dedicated server, to do so I'm booting the server on a live CD and then I'm using qemu to install OpenBSD on the real HDD. After that, I can use OpenBSD on qemu without any issue, everything works. But when I reboot the server, to use OpenBSD on the real hardware, it's not working and I have no console to verify what is the error. So, to debug, I boot again with a livecd, use qemu to start OpenBSD but I see no logs from the "real" boot, only logs from qemu's boots. So I guess the issue is with the bootloader itself. I tried many things (including using /dev/sd0 instead of /dev/wd0, etc) but nothing works. I used this method quite a few times to install OpenBSD on my servers but I can't make it work on this one. Thanks for helping.
