Re: anoncvs instructions
> The following instructions state to unpack the Xenocara sources in > /usr, but should be done instead from the /usr/xenocara directory as > the preceding directory for contents is ./ (whereas ports.tar.gz > unpacks into ports/)? > > The following commands assume you have followed these instructions > to give a non-root > user write access to the src, ports and xenocara directories. > > $ cd /usr/src > $ tar xzf /tmp/src.tar.gz > $ tar xzf /tmp/sys.tar.gz > $ cd /usr > $ tar xzf /tmp/ports.tar.gz > $ tar xzf /tmp/xenocara.tar.gz Funny. I've been running 6.3 since it was released and never noticed I had extracted (by my script) right into /usr. Guess I haven't needed to look at X source since April... Those instructions worked pre-6.3. Martin $ ftp http://ftp.usa.openbsd.org/pub/OpenBSD/6.3/xenocara.tar.gz Trying 192.43.244.161... Requesting http://ftp.usa.openbsd.org/pub/OpenBSD/6.3/xenocara.tar.gz 0% | | 896 KB07:05 ETA^C http fetch aborted. $ tar tzf xenocara.tar.gz | head -3 . ./CVS ./CVS/Root gzip: stdin: Input/output error tar: End of archive volume 1 reached $ ftp http://ftp.usa.openbsd.org/pub/OpenBSD/6.2/xenocara.tar.gz Trying 192.43.244.161... Requesting http://ftp.usa.openbsd.org/pub/OpenBSD/6.2/xenocara.tar.gz 0% | | 1152 KB05:32 ETA^C http fetch aborted. $ tar tzf xenocara.tar.gz | head -3 xenocara xenocara/CVS xenocara/CVS/Root gzip: stdin: Input/output error tar: End of archive volume 1 reached
anoncvs instructions
https://www.openbsd.org/anoncvs.html The following instructions state to unpack the Xenocara sources in /usr, but should be done instead from the /usr/xenocara directory as the preceding directory for contents is ./ (whereas ports.tar.gz unpacks into ports/)? The following commands assume you have followed these instructions to give a non-root user write access to the src, ports and xenocara directories. $ cd /usr/src $ tar xzf /tmp/src.tar.gz $ tar xzf /tmp/sys.tar.gz $ cd /usr $ tar xzf /tmp/ports.tar.gz $ tar xzf /tmp/xenocara.tar.gz -- Darren Spruell phatbuck...@gmail.com
Another Lock Order Reversal with amd64 snapshot
Not quite the same as earlier reports. Also not sure if this qualifies as something reportable to bugs@ or not. The system appears to be working normally otherwise. scott #sysctl kern.version kern.version=OpenBSD 6.3-current (GENERIC.MP) #90: Thu Jun 7 09:08:25 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP scott #dmesg OpenBSD 6.3-current (GENERIC.MP) #90: Thu Jun 7 09:08:25 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1020133376 (972MB) avail mem = 965754880 (921MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (38 entries) bios0: vendor Award Software International, Inc. version "F3" date 04/09/2009 bios0: Gigabyte Technology Co., Ltd. G41M-ES2L acpi0 at bios0: rev 0 acpi0: TAMG checksum error acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET MCFG TAMG APIC SSDT acpi0: wakeup devices PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5) HUB0(S5) UAR1(S3) UAR2(S3) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USBE(S3) AZAL(S5) PCI0(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 addr 0xc000, bus 0-255 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU E3200 @ 2.40GHz, 1700.25 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 1MB 64b/line 4-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Celeron(R) CPU E3200 @ 2.40GHz, 1699.96 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 1MB 64b/line 4-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins , remapped to apid 2 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PEX0) acpiprt2 at acpi0: bus 2 (PEX1) acpiprt3 at acpi0: bus -1 (PEX2) acpiprt4 at acpi0: bus -1 (PEX3) acpiprt5 at acpi0: bus -1 (PEX4) acpiprt6 at acpi0: bus -1 (PEX5) acpiprt7 at acpi0: bus 3 (HUB0) acpicpu0 at acpi0: C1(@1 halt!), FVS, 1600, 1200 MHz acpicpu1 at acpi0: C1(@1 halt!), FVS, 1600, 1200 MHz acpibtn0 at acpi0: PWRB acpicmos0 at acpi0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel G41 Host" rev 0x03 inteldrm0 at pci0 dev 2 function 0 "Intel G41 Video" rev 0x03 drm0 at inteldrm0 intagp0 at inteldrm0 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0: msi inteldrm0: 1280x1024, 32bpp wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x01: msi azalia0: codecs: Realtek/0x0887 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: msi pci1 at ppb0 bus 1 ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x01: msi pci2 at ppb1 bus 2 re0 at pci2 dev 0 function 0 "Realtek 8168" rev 0x02: RTL8168C/8111C (0x3c00), msi, address 00:24:1d:86:28:95 rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 2 uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: apic 2 int 23 uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 2 int 19 uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 2 int 18 uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 2 int 16 ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 2 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb2 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xe1 pci3 at ppb2 bus 3 pcib0 at pci0 dev 31 function 0 "Intel 82801GB LPC" rev 0x01 pciide0 at pci0 dev 31 function 2 "Intel 82801GB SATA" rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 476938MB, 976771055 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6 atapiscsi0 at pciide0 channel 1 drive 0 scsibus1 at atapiscsi0: 2 targets cd0 at scsibus1 targ 0 lun 0: ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 ichiic0 at pci0 dev 31 function 3 "Intel 82801GB SMBus" rev 0x01: apic 2 int 19 iic0 at ichiic0 spdmem0 at iic0 addr 0x50: 1GB DDR2 SDRAM non-parity PC2-5300CL5 usb1 at uhci0: USB revision 1.0 uhub1 at usb1 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at
Re: rtadvd bug ?
On Thu, Jun 07, 2018 at 04:02:34PM +0200, Bastien Durel wrote: > shouldn't it check the rtm_priority to be RTP_LOCAL or RTP_CONNECTED ?? > it make no sense to start advertising prefix on an interface if the > prefix is over a gateway. > Why RTP_LOCAL ?
Re: OpenBSD performance upgrade
It uses AVX2, so... thanks for the extra seconds. :D Cheers. Elias. 2018-06-09 0:43 GMT-03:00 Philip Guenther : > On Fri, Jun 8, 2018 at 10:13 AM Elias M. Mariani > wrote: >> >> I usually run long computations on OpenBSD-current, in the last few >> days I see an upgrade in the performance of the process (in this case >> I have 6 threads running a very optimized assembler code). >> Each iteration of the code was about 14 sec. and now is around 13 sec. >> Don't mind the computation, the question is more about if something >> was changed (and if so what) to hit the performance so much, the >> compilation is the same as before, so the code did not change and the >> software does not use anything from ports, only the standard C >> library. >> >> A more accurate description would be that the threads are more >> homogeneous in relation with the iterations time, maybe one thread >> suddenly give a 11 sec. result, and another 15, probably related with >> thread reallocations, now I have a steady time in all the threads and >> in average the numbers are better. >> Anyways... Better is better. Just curious to know why is working better. >> :D > > > If the "optimized assembler" that the threads are running uses AVX or > similar "extended CPU state" extensions then the improvement is almost > certainly from my switch amd64 from "lazy FPU switching" to what I'll call > "semi-eager switching", where the current thread's registers are always > ensured to be loaded before returning to userspace, eliminating the need for > extra userspace->kernel->userspace transitions and IPIs to load the > registers in the current CPU. > > Glad to hear it's such a large improvement for your processing. Enjoy, and > remember to tip your OS vendor! > > > Philip Guenther >
Re: WEP broken
On Saturday, June 9, 2018 4:34:11 PM -04 Kevin Chadwick wrote: > On Sat, 9 Jun 2018 15:24:14 +0200 > > > I just "fixed" anther system (this time amd64) for WEP and used again > > fresh tarballs and it went fine. Perhaps the mirror updated or had > > another issue. > > I am glad you are making progress but I just want to be sure that you > know that WEP can be decrypted in seconds? OP knows that already, but he has other reasons. See the first reply by Stefan Sperling and OP's answer. ;-) Cheers Eike
Re: WEP broken
On Sat, 9 Jun 2018 15:24:14 +0200 > I just "fixed" anther system (this time amd64) for WEP and used again > fresh tarballs and it went fine. Perhaps the mirror updated or had > another issue. I am glad you are making progress but I just want to be sure that you know that WEP can be decrypted in seconds?
Re: WEP broken
Hi Stuart, On 04/06/2018 22:35, Stuart Henderson wrote: On 2018-06-04, Riccardo Mottola wrote: just an update, it took me a while. I had issues with the sources on certain mirrors. Can you provide more details please? If there are anoncvs mirrors with bad source code that needs fixing. I did not use anoncvs, I downloaded sys.tar.gz and src.tar.gz fron the 6.3 release from a mirror, I believe the french mirror. I just "fixed" anther system (this time amd64) for WEP and used again fresh tarballs and it went fine. Perhaps the mirror updated or had another issue. Riccardo
vmm support in QEMU to run Win7 virtually?
Does QEMU support vmm on OpenBSD without windows setup on HDD directly? Thanks
