Re: ws
PS: Oh, and wsrc stands for write to /usr/src, sorry: https://www.openbsd.org/faq/faq5.html#wsrc On 14/04/2019, ropers wrote: >> On Sun, Apr 14, 2019 at 11:31:33AM +0900, Jerome Pinot wrote: >>> I'm curious to know what is the origin of the "w(s)" prefix we have >>> on some OpenBSD specific places, like: >>> - wscons >>> -wsmoused >>> - wskbd >>> - wsrc >>> - wobj >>> etc >>> >>> It seems to be a quite old practice and common with other BSDs. >>> Anybody has the history for this? > > On 14/04/2019, Bryan Steele wrote: >> 'workstation console' at least sounds plausible. >> https://www.netbsd.org/docs/guide/en/chap-cons.html > > ws for workstation is correct. However, wobj is the odd one out in > that list, and it stands for write to /usr/obj: > https://www.openbsd.org/faq/faq5.html#Miscellanea >
Re: ws
> On Sun, Apr 14, 2019 at 11:31:33AM +0900, Jerome Pinot wrote: >> I'm curious to know what is the origin of the "w(s)" prefix we have >> on some OpenBSD specific places, like: >> - wscons >> -wsmoused >> - wskbd >> - wsrc >> - wobj >> etc >> >> It seems to be a quite old practice and common with other BSDs. >> Anybody has the history for this? On 14/04/2019, Bryan Steele wrote: > 'workstation console' at least sounds plausible. > https://www.netbsd.org/docs/guide/en/chap-cons.html ws for workstation is correct. However, wobj is the odd one out in that list, and it stands for write to /usr/obj: https://www.openbsd.org/faq/faq5.html#Miscellanea
Re: ws
On Sun, Apr 14, 2019 at 11:31:33AM +0900, Jerome Pinot wrote: > Hi, > > I'm curious to know what is the origin of the "w(s)" prefix we have > on some OpenBSD specific places, like: > - wscons > -wsmoused > - wskbd > - wsrc > - wobj > etc > > It seems to be a quite old practice and common with other BSDs. > Anybody has the history for this? > > Thanks! > > -- > Jerome Pinot 'workstation console' at least sounds plausible. https://www.netbsd.org/docs/guide/en/chap-cons.html
ws
Hi, I'm curious to know what is the origin of the "w(s)" prefix we have on some OpenBSD specific places, like: - wscons -wsmoused - wskbd - wsrc - wobj etc It seems to be a quite old practice and common with other BSDs. Anybody has the history for this? Thanks! -- Jerome Pinot
Problems with ASUS P9D WS (socket 1150, Haswell Xeon E3-1230V3)
Hi, I have problems booting OpenBSD from SATA hard drives with the ASUS P9D WS mainboard. I've successfully verified that OpenBSD can boot with this mainboard since booting OpenBSD works without problems via USB (see dmesg). However, OpenBSD doesn't boot from SATA hard drives at all (I've tested this with multiple SATA drives so it's definitely not a problem related to faulty drives). As soon as OpenBSD is installed on a SATA hard drive, the ASUS boot screen completely freezes such that it doesn't even reach the OpenBSD boot loader (diagnostic HDD LED shows a problem). In particular, I did the following tests: 1) blank hard drive - mainboard boots another disk/system without problems 2) SATA hard drive after fdisk -iy sd0 - mainboard boots another disk/system without problems 3) SATA hard drive after creating partitions via disklabel (no installboot(8)) -- ASUS boot screen freezes 4) SATA hard drive with freshly installed OpenBSD current system (via CDROM) -- ASUS boot screen freezes I suppose this is a (software) problem with the mainboard (BIOS/EFI/wtf...) and not with OpenBSD. So take this as a warning in case you're playing with the thought of buying this particular mainboard model for OpenBSD at this time. In case ASUS fixes this problem, I'll inform the list. I haven't tried booting OpenBSD via grub yet - maybe this will work around the problem. Did anyone experience similar problems in the past? Does anybody know a mainboard for Haswell E3-Xeons which works well with OpenBSD? Best Regards Andreas dmesg after booting OpenBSD via USB stick: OpenBSD 5.4-current (GENERIC.MP) #0: Sat Aug 24 11:04:26 CEST 2013 root@test:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8508362752 (8114MB) avail mem = 8273772544 (7890MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeba50 (87 entries) bios0: vendor ASUSTeK COMPUTER INC. (Licensed from AMI) version 1205 date 07/30/2013 bios0: ASUS All Series acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT SSDT SSDT MCFG HPET SSDT SSDT DMAR BGRT acpi0: wakeup devices UAR1(S4) PS2K(S4) PS2M(S4) PXSX(S4) RP01(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz, 3292.82 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 99MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz, 3292.38 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz, 3292.38 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz, 3292.38 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz, 3292.38 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu4: 256KB 64b/line 8-way L2 cache
Shutting down OpenBSD VM when closing VMWare WS or ESX
Hello, I use several OpenBSD/i386 (versions 4.3 and 4.4) VMs under VMWare Workstation and ESX. They work great for my purposes (few LAMP servers + 1 OpenVPN server), but there is one annoyance: when I close the VMWare or shutdown the host, then the OpenBSD VMs aren't shutdown properly. I've tried to install the FreeBSD-version of VMWare-Tools as described in http://www.linux.com/feature/56683 but still the proper shutdown doesn't happen even though I see the daemon being run in the VM: $ ps uawwwx | grep vmware root 26568 98.3 0.2 500 216 ?? Rs/0 12:24PM 607:02.63 /emul/freebsd/sbin/vmware-guestd --background /var/run/vmware-guestd.pid --halt-command /sbin/shutdown -p -h now I wonder how does this daemon work? Does it listen at some TCP or UDP port maybe? $ fstat |grep vmware root vmware-guestd 26568 wd / 2 drwxr-xr-x r 512 root vmware-guestd 265680 / 728803 crw-rw-rw- rw null root vmware-guestd 265681 / 728803 crw-rw-rw- rw null root vmware-guestd 265682 / 728803 crw-rw-rw- rw null root vmware-guestd 265683 pipe 0xd3e63048 state: root vmware-guestd 265684 pipe 0xd3e63048 state: $ netstat -an | grep LISTEN tcp0 0 127.0.0.1.5432 *.*LISTEN tcp0 0 *.139 *.*LISTEN tcp0 0 *.445 *.*LISTEN tcp0 0 *.22 *.*LISTEN tcp0 0 *.443 *.*LISTEN tcp0 0 *.37 *.*LISTEN tcp0 0 *.13 *.*LISTEN tcp0 0 *.113 *.*LISTEN tcp0 0 *.80 *.*LISTEN tcp0 0 127.0.0.1.587 *.*LISTEN tcp0 0 127.0.0.1.25 *.*LISTEN tcp6 0 0 ::1.5432 *.*LISTEN tcp6 0 0 *.22 *.*LISTEN tcp6 0 0 *.443 *.*LISTEN tcp6 0 0 *.37 *.*LISTEN tcp6 0 0 *.13 *.*LISTEN tcp6 0 0 *.113 *.*LISTEN tcp6 0 0 ::1.587*.*LISTEN tcp6 0 0 ::1.25 *.*LISTEN Does anybody know? The vmware-guestd daemon can't be that complicated, maybe I could replace it by a Perl-script, if I knew how does it get the signal that the host is about to shutdown... Regards Alex OpenBSD 4.3-stable (GENERIC.MP) #1: Tue Sep 16 17:02:42 CEST 2008 afar...@xxx.my.domain:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz (GenuineIntel 686-class) 2.50 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,SSE3,DS-CPL,CX16 real mem = 133722112 (127MB) avail mem = 121208832 (115MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 04/10/07, BIOS32 rev. 0 @ 0xfd880, SMBIOS rev. 2.31 @ 0xe0010 (45 entries) bios0: vendor Phoenix Technologies LTD version 6.00 date 04/10/2007 bios0: VMware, Inc. VMware Virtual Platform apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xfd880/0x780 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf30/176 (9 entries) pcibios0: PCI Interrupt Router at 000:07:0 (Intel 82371FB ISA rev 0x00) pcibios0: PCI bus #2 is the last bus bios0: ROM list: 0xc/0x8000 0xc8000/0x1000 0xdc000/0x4000! 0xe/0x4000! mainbus0: Intel MP Specification (Version 1.4) cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 66MHz mainbus0: bus 0 is type PCI mainbus0: bus 1 is type PCI mainbus0: bus 2 is type PCI mainbus0: bus 3 is type ISA ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82443BX AGP rev 0x01 ppb0 at pci0 dev 1 function 0 Intel 82443BX AGP rev 0x01 pci_intr_map: bus 0 dev 1 func 0 pin 1; line 5 pci_intr_map: no MP mapping found pci_intr_map: bus 0 dev 1 func 0 pin 2; line 11 pci_intr_map: no MP mapping found pci1 at ppb0 bus 1 piixpcib0 at pci0 dev 7 function 0 Intel 82371AB PIIX4 ISA rev 0x08 pciide0 at pci0 dev 7 function 1 Intel 82371AB IDE rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: VMware Virtual IDE Hard Drive wd0: 64-sector PIO, LBA, 20480MB, 41943040 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 atapiscsi0 at pciide0 channel 1 drive
Re: Shutting down OpenBSD VM when closing VMWare WS or ESX
* Alexander Farber alexander.far...@gmail.com [090411 16:42]: Hello, I use several OpenBSD/i386 (versions 4.3 and 4.4) VMs under VMWare Workstation and ESX. They work great for my purposes (few LAMP servers + 1 OpenVPN server), but there is one annoyance: when I close the VMWare or shutdown the host, then the OpenBSD VMs aren't shutdown properly. I've tried to install the FreeBSD-version of VMWare-Tools as described in http://www.linux.com/feature/56683 but still the proper shutdown doesn't happen even though I see the daemon being run in the VM: $ ps uawwwx | grep vmware root 26568 98.3 0.2 500 216 ?? Rs/0 12:24PM 607:02.63 /emul/freebsd/sbin/vmware-guestd --background /var/run/vmware-guestd.pid --halt-command /sbin/shutdown -p -h now I wonder how does this daemon work? Does it listen at some TCP or UDP port maybe? Take a look at the vmt driver dlg@ recently added to the tree. Last I tried it, it wasn't hooked to the build yet and didn't include the shutdown functionality. Just calling some attention to it in hopes that greases the skids for further development. Jim