Re: pkg using "6.3" instead of "snapshots"

[Thomas Weinbrenner]

> Am 24.03.2018 um 08:21 schrieb Tony Boston :
> 
> am using -current on my x230 for a while now which was working okay
> since today. When I downloaded the new bsd.rd and did an upgrade, it
> said that it would download from /pub/OpenBSD/6.3/amd64 which I had to
> change to s/6.3/snaptshots here. The problem is, pkg now always uses
> "6.3" when I try to update packages or install new ones. Is there a
> switch I have to set? I didn't need to do anything like that before.
> 

This question was last answered 5 days ago.

https://marc.info/?l=openbsd-misc=152145991212654=2

Re: tor inside vmm, horribly slow?!

[Thomas Weinbrenner]

> Am 14.02.2018 um 02:09 schrieb Chris Cappuccio :
> 
> Revert uipc_socket.c rev 1.90. Does tor work properly again?

Because of https://marc.info/?l=openbsd-ports=151855574502582
I tried a newer snapshot and now tor works properly again.


signature.asc
Description: Message signed with OpenPGP

Re: tor inside vmm, horribly slow?!

[Thomas Weinbrenner]

> Am 12.02.2018 um 00:38 schrieb Jiri B :
> 
> Hi,
> 
> has anybody tried to run tor inside vmm guest?
> 
> it's horrible slow, just doing 'tor-resolve $dnsname' takes
> sometimes ages.

Perhaps this has nothing to do with vmm.

I am not a computer expert, just a normal user (so please don't ask me
to difficult questions), but I run tor on my computer at home (so it's
real hardware and no vmm).

Since upgrading OpenBSD from

| OpenBSD 6.2-current (GENERIC.MP) #399: Fri Feb  2 18:28:58 MST 2018
|dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

to

| OpenBSD 6.2-current (GENERIC.MP) #4: Sat Feb 10 18:04:19 MST 2018
|dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

my tor server also has problems.


/var/log/daemon:
| Feb 11 20:15:50 server Tor[54286]: Your system clock just jumped 115 seconds 
forward; assuming established circuits no longer work.
| Feb 11 20:16:02 server Tor[54286]: Tor has successfully opened a circuit. 
Looks like client functionality is working.
| Feb 11 20:16:02 server Tor[54286]: Tor has successfully opened a circuit. 
Looks like client functionality is working.
| Feb 11 20:24:43 server Tor[54286]: Your system clock just jumped 299 seconds 
forward; assuming established circuits no longer work.
| Feb 11 20:26:24 server Tor[54286]: tor_assertion_failed_: Bug: 
src/or/channel.c:1503: channel_closed: Assertion CHANNEL_CONDEMNED(chan) 
failed; aborting. (on Tor 0.3.2.9 9e8b762fcecfece6)
| Feb 11 20:26:24 server Tor[54286]: Bug: Assertion CHANNEL_CONDEMNED(chan) 
failed in channel_closed at src/or/channel.c:1503. (Stack trace not available) 
(on Tor 0.3.2.9 9e8b762fcecfece6)

dmesg:

OpenBSD 6.2-current (GENERIC.MP) #4: Sat Feb 10 18:04:19 MST 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8351621120 (7964MB)
avail mem = 8091496448 (7716MB)
enter_shared_special_pages: entered idt page va 0x8001 pa 0x1d5c000
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 kutext page va 0x81835000 pa 
0x1835000
enter_shared_special_pages: entered kudata page va 0x81acb000 pa 
0x1acb000
cpu_enter_pages: entered tss+gdt page at va 0x81aa2000 pa 0x1aa2000
cpu_enter_pages: entered t.stack page at va 0x81aa3000 pa 0x1aa3000
cpu_enter_pages: cif_tss.tss_rsp0 = 0x81aa33e0
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xedc10 (87 entries)
bios0: vendor LENOVO version "FBKTCQAUS" date 12/16/2017
bios0: LENOVO ThinkServer TS140
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC FPDT FIDT TCPA DBGP LUFT SSDT SSDT MCFG
HPET SSDT SSDT ASF! DMAR EINJ ERST HEST BERT BGRT
acpi0: wakeup devices UAR1(S0) PXSX(S0) RP01(S0) PXSX(S0) PXSX(S0)
PXSX(S0) RP04(S0) PXSX(S0) PXSX(S0) PXSX(S0) PXSX(S0) GLAN(S0)
EHC1(S0) EHC2(S0) XHC_(S0) HDEF(S0) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
lapic_map: entered lapic page va 0x81aa6000 pa 0xfee0
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E3-1226 v3 @ 3.30GHz, 3492.47 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,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
acpitimer0: recalibrated TSC frequency 3292379149 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 0x10f184000
cpu_enter_pages: entered t.stack page at va 0x800022001000 pa 0x10f185000
cpu_enter_pages: cif_tss.tss_rsp0 = 0x8000220013e0
: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1226 v3 @ 3.30GHz, 3491.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,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,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0cpu_enter_pages: entered tss+gdt page at va
0x800022011000 pa 0x10f18f000
cpu_enter_pages: entered t.stack page at va 0x800022012000 pa 0x10f19
cpu_enter_pages: cif_tss.tss_rsp0 = 

Re: Firefox: Recenty instable

[Thomas Weinbrenner]

On Sun, Mar 12, 2017 at 11:19:18PM +0100, Stefan Wollny wrote:
> Hi there,
> 
> for the last 3~4 days (always running the latest of public
> amd64-current) firefox behaviour was kind of "unfamiliar" - regular
> crashes after a few minutes.

[...]
 
> Am I right supposing that the most likely answer will be "Wait for the
> next snap!"? :-)

I found this quite helpful.

https://marc.info/?l=openbsd-ports=148925156914633

Since raising datasize-cur in /etc/login.conf my firefox has stopped
crashing.

Re: VESA mode

[Thomas Weinbrenner]

Am Mon, 28 Dec 2015 17:53:45 +
schrieb Sébastien Morand :

> I'm using the snapshots version in my computer and for about 2 weeks
> now I'm stuck in VESA mode.
>
> I was working pretty well since 26th september for "Intel HD Graphics
> 5500" but not anymore, any information about this?

http://marc.info/?l=openbsd-cvs=145068713628147

|CVSROOT:   /cvs
|Module name:   xenocara
|Changes by:kette...@cvs.openbsd.org2015/12/21 01:37:11
|
|Modified files:
|   xserver/hw/xfree86/common: xf86pciBus.c
|
|Log message:
|On Broadwell, default to using the modesetting driver.  Our KMS support
|on Broadwell is still a bit weak and the modesetting driver seems to
|work better than the intel driver, while still providing 3D
|acceleration and video playback support.
|
|ok phessler@, matthieu@, jsg@

You can of course override this in you xorg.conf

I prefer the Intel driver too (even if it isn't always stable) so I
created a small /etc/X11/xorg.conf:

 Section "Device"
Identifier "Intel"
Driver "intel"
 EndSection