Re: vxlan paper from AsiaBSDCon 2014

[Constantine A. Murenin]

On 28 April 2016 at 13:36, lists  wrote:
> Hello misc,
>
> I was looking for the slides of the presentation done by reyk@.
>
> I have checked http://www.openbsd.org/papers/index.html
>
> Thanks,
> Jim

Not sure about the slides, but the proceedings of the conference are
available from http://2014.asiabsdcon.org/papers/, more specifically,
https://2014.asiabsdcon.org/papers/abc2014-proc-all.pdf, and the vxlan
paper is included in said proceedings (pages 91 to 95).

Cheers,
Constantine.SU.

Re: Regina Rexx doesn't build on 5.9

[Jack J. Woehr]

Stuart Henderson wrote:
use cc, not ld, to link. 


works for me, thanks Stuart

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

permisson of .htpasswd of 5.9's nginx

[Tuyosi Takesima]

Hi all .

i do
chmod 777  /var/www/1/.htpasswd

and so
nginx works  with basic authentification.

but this setting is too open .
are there any idea ?

#
/etc/nginx/nginx.conf

events {
worker_connections  800;
   }
http {
include   mime.types;
default_type  application/octet-stream;
index index.html index.htm;
keepalive_timeout  65;
server_tokens off;
server {
listen   80;
server_name  localhost;#<-for test
root /var/www/d1;
  }
server {
listen   80;
server_name  abcxyz.jp;
root /var/www/d1;
auth_basic   "closed site";
auth_basic_user_file /var/www/1/.htpasswd;
  }
}
---
regards

Create a RAID5 with a disk marked as degraded

[Benton Lam]

Hi,

I currently have a 5.7 box, with 2 disk RAID1 (comprise of sd1a and sd2a)

Suppose I upgrade / install to 5.9. Is it possible for me to do the following:

bioctl -O /dev/sd2a sd3 # degrade the raid1 (sd3)
bioctl -c 5 -l /dev/sd1a,/dev/sd2a,/dev/sd4a -O /dev/sd1a softraid0 #
create a raid 5 with sd1a, sd2a and sd4a, but sd1a is degraded,
suppose that creates sd5


bioctl -d sd3
bioctl -R /dev/sd1a sd5 # swap the sd1a back into  the raid5

Is that possible? or should I be finding another 3TB drive, copy the
stuff onto that temporary drive and create the RAID5?

Thanks,
Benton Lam

Re: Regina Rexx doesn't build on 5.9

[Stuart Henderson]

On 2016-04-28, Jack J. Woehr  wrote:
> Regina Rexx ( svn checkout svn://svn.code.sf.net/p/regina-rexx/code/ 
> regina-rexx-code ), an admittedly aging body of 
> code, was successfully built under 5.8.
>
> It now fails under 5.9 as follows. Any tips?
>
> on i386:
>
> ld -Bdynamic -Bshareable  -o libregina.so funcs.so.o builtin.so.o error.so.o 
> variable.so.o interprt.so.o debug.so.o 

use cc, not ld, to link.

Re: FW: Re: watchdog suport for new hardware

[stan]

On Thu, Apr 28, 2016 at 02:18:25PM +0100, Stuart Henderson wrote:
> On 2016/04/28 08:56, stan wrote:
> > On Thu, Apr 28, 2016 at 08:44:49AM +0100, Stuart Henderson wrote:
> > > Stan, can you send the information that is output when you run
> > > sendbug -P as root? Just putting the whole thing inline in a
> > > reply-to-all to this mail would be fine. Please add "sysctl hw"
> > > output as well. Ideally we want a way to identify the watchdog
> > > itself rather than the general machine type etc. which is why
> > > I'm hoping they follow Microsoft's spec (which is the de-facto 
> > > standard for this).
> > 
> > 
> > Sorry got distracted and frgot to cc the list.
> 
> OK, pity, there doesn't seem to be anything to properly identify
> the watchdog in acpi tables. Just the vendor-specific thing which
> needs reading to figure things out further. If they had followed
> the usual spec then the driver would have been *very* generally
> useful.
> 
> In that case maybe the approach would be to do something similar
> to acpithinkpad, but matching SECD instead of MHKV, and then
> looking for the SEL0002 HID. But I only know a bit about how
> to find my way round the decompiled files, so ignore me if
> a real ACPI hacker steps in with a better idea ;)
> 
> > hw.vendor=Schweitzer Engineering Laboratories, Inc.
> > hw.product=SEL-3355
> 
> An alternative might be to match on vendor/product, see the last
> commit to sys/dev/ic/re.c for how to do this, but then you're
> having to look at fixed addresses which they seem to be providing
> via acpi.
> 

As I look at what the vendor did, I discover they were working in the
arch/i386 codebase. 2 questions. First should this not be in amd64, as this
is a 64 bit machine, and if so does that change any of the discussions as to
how to detect the hardware?


-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

vxlan paper from AsiaBSDCon 2014

[lists]

Hello misc,

I was looking for the slides of the presentation done by reyk@.

I have checked http://www.openbsd.org/papers/index.html

Thanks,
Jim

Regina Rexx doesn't build on 5.9

[Jack J. Woehr]

Regina Rexx ( svn checkout svn://svn.code.sf.net/p/regina-rexx/code/ regina-rexx-code ), an admittedly aging body of 
code, was successfully built under 5.8.


It now fails under 5.9 as follows. Any tips?

on i386:

ld -Bdynamic -Bshareable  -o libregina.so funcs.so.o builtin.so.o error.so.o variable.so.o interprt.so.o debug.so.o 
dbgfuncs.so.o memory.so.o parsing.so.o files.so.o misc.so.o unxfuncs.so.o cmsfuncs.so.o shell.so.o os2funcs.so.o 
rexxext.so.o stack.so.o tracing.so.o interp.so.o cmath.so.o convert.so.o strings.so.o library.so.o strmath.so.o 
signals.so.o macros.so.o envir.so.o expr.so.o extstack.so.o yaccsrc.so.o lexsrc.so.o wrappers.so.o options.so.o 
os_unx.so.o rexxbif.so.o drexx.so.o client.so.o rexxsaa.so.o   mt_posix.so.o instore.so.o arxfuncs.so.o   -lpthread 
-lpthread

funcs.so.o: In function `__regina_myatol':
./funcs.c:(.text+0x69c): undefined reference to `__guard_local'
./funcs.c:(.text+0x6d4): undefined reference to `__guard_local'
funcs.so.o: In function `__regina_atozpos':
./funcs.c:(.text+0x71d): undefined reference to `__guard_local'
./funcs.c:(.text+0x7b5): undefined reference to `__guard_local'
funcs.so.o: In function `__regina_atozposrx64':
./funcs.c:(.text+0x7fd): undefined reference to `__guard_local'
funcs.so.o:./funcs.c:(.text+0x898): more undefined references to 
`__guard_local' follow
ld: libregina.so: hidden symbol `__guard_local' isn't defined
ld: final link failed: Nonrepresentable section on output
Makefile:342: recipe for target 'libregina.so' failed
gmake: *** [libregina.so] Error 1

on amd64:

ld -Bdynamic -Bshareable  -o libregina.so funcs.so.o builtin.so.o error.so.o variable.so.o interprt.so.o debug.so.o 
dbgfuncs.so.o memory.so.o parsing.so.o files.so.o misc.so.o unxfuncs.so.o cmsfuncs.so.o shell.so.o os2funcs.so.o 
rexxext.so.o stack.so.o tracing.so.o interp.so.o cmath.so.o convert.so.o strings.so.o library.so.o strmath.so.o 
signals.so.o macros.so.o envir.so.o expr.so.o extstack.so.o yaccsrc.so.o lexsrc.so.o wrappers.so.o options.so.o 
os_unx.so.o rexxbif.so.o drexx.so.o client.so.o rexxsaa.so.o   mt_posix.so.o instore.so.o arxfuncs.so.o   -lpthread 
-lpthread

funcs.so.o: In function `__regina_myatol':
./funcs.c:(.text+0x64c): undefined reference to `__guard_local'
ld: funcs.so.o: relocation R_X86_64_PC32 against `__guard_local' can not be used when making a shared object; recompile 
with -fPIC

ld: final link failed: Bad value
Makefile:342: recipe for target 'libregina.so' failed
gmake: *** [libregina.so] Error 1

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

Installing py3-libtorrent

[Thuban]

Hello,
I need to install the python3 bindings for libtorrent. I doesn't seem to
be packaged, nor present in ports.

Because I need to install it on several machines, I wanted to ask if I
didn't miss it somewhere, before compiling it by hand again and angain.

Thanks.

--
/Thuban/

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

Re: FW: Re: watchdog suport for new hardware

[Mike Larkin]

On Thu, Apr 28, 2016 at 03:22:15PM +, Stuart Henderson wrote:
> On 2016-04-28, stan  wrote:
> > On Thu, Apr 28, 2016 at 02:18:25PM +0100, Stuart Henderson wrote:
> >> On 2016/04/28 08:56, stan wrote:
> >> > On Thu, Apr 28, 2016 at 08:44:49AM +0100, Stuart Henderson wrote:
> >> > > Stan, can you send the information that is output when you run
> >> > > sendbug -P as root? Just putting the whole thing inline in a
> >> > > reply-to-all to this mail would be fine. Please add "sysctl hw"
> >> > > output as well. Ideally we want a way to identify the watchdog
> >> > > itself rather than the general machine type etc. which is why
> >> > > I'm hoping they follow Microsoft's spec (which is the de-facto 
> >> > > standard for this).
> >> > 
> >> > 
> >> > Sorry got distracted and frgot to cc the list.
> >> 
> >> OK, pity, there doesn't seem to be anything to properly identify
> >> the watchdog in acpi tables. Just the vendor-specific thing which
> >> needs reading to figure things out further. If they had followed
> >> the usual spec then the driver would have been *very* generally
> >> useful.
> >> 
> >> In that case maybe the approach would be to do something similar
> >> to acpithinkpad, but matching SECD instead of MHKV, and then
> >> looking for the SEL0002 HID. But I only know a bit about how
> >> to find my way round the decompiled files, so ignore me if
> >> a real ACPI hacker steps in with a better idea ;)
> >> 
> >> > hw.vendor=Schweitzer Engineering Laboratories, Inc.
> >> > hw.product=SEL-3355
> >> 
> >> An alternative might be to match on vendor/product, see the last
> >> commit to sys/dev/ic/re.c for how to do this, but then you're
> >> having to look at fixed addresses which they seem to be providing
> >> via acpi.
> >> 
> >
> > Let me apologize right here for my lack of knowledge as to low level
> > hardware coding.
> >
> > So, given that, please help me to understand why reading the DSDT ACPI
> > table and finding the SEL0002 is not the correct solution here?  BTW, they
> > also identify an SEL0001 device, but I have not asked them what that is,
> > and )so far) I do not need to know. For what it is worth this hardware
> > vendor has been very helpful, and the corporate philosophy is to do things
> > "the right way". For instance, they released code to support this device for
> > Linux. When I talked to them, i brought up liscneing concerns with the
> > BSD's. The reply was, already been there, thought about that. It is dual
> > GPL, and BSD liscneced. Really a pleasant sunrise, as this is not in their
> > mainstream area of expertise. i was really pleased that the project team
> > had researched the OSS issues that well.
> 
> I was just chatting to mlarkin about this, he hasn't looked at the
> code but gave a few suggestions. 
> 
> I was wrong about the need to look for the SECD container - he gave an
> example of a better driver to crib from, sdhc_acpi, which is pretty
> simple in itself and shows the parts needed to find the device in the
> DSDT. Basically it just involves passing an array containing "SEL0002"
> to acpi_matchhids and it does the work.
> 

It does the work for the find and attach. After that, you'll need to plumb
the AML to find the device location and IRQ/etc. But sdhc_acpi is a simple
driver that has most of the system interface goo you need to get started.

-ml

Re: FW: Re: watchdog suport for new hardware

[Stuart Henderson]

On 2016-04-28, stan  wrote:
> On Thu, Apr 28, 2016 at 02:18:25PM +0100, Stuart Henderson wrote:
>> On 2016/04/28 08:56, stan wrote:
>> > On Thu, Apr 28, 2016 at 08:44:49AM +0100, Stuart Henderson wrote:
>> > > Stan, can you send the information that is output when you run
>> > > sendbug -P as root? Just putting the whole thing inline in a
>> > > reply-to-all to this mail would be fine. Please add "sysctl hw"
>> > > output as well. Ideally we want a way to identify the watchdog
>> > > itself rather than the general machine type etc. which is why
>> > > I'm hoping they follow Microsoft's spec (which is the de-facto 
>> > > standard for this).
>> > 
>> > 
>> > Sorry got distracted and frgot to cc the list.
>> 
>> OK, pity, there doesn't seem to be anything to properly identify
>> the watchdog in acpi tables. Just the vendor-specific thing which
>> needs reading to figure things out further. If they had followed
>> the usual spec then the driver would have been *very* generally
>> useful.
>> 
>> In that case maybe the approach would be to do something similar
>> to acpithinkpad, but matching SECD instead of MHKV, and then
>> looking for the SEL0002 HID. But I only know a bit about how
>> to find my way round the decompiled files, so ignore me if
>> a real ACPI hacker steps in with a better idea ;)
>> 
>> > hw.vendor=Schweitzer Engineering Laboratories, Inc.
>> > hw.product=SEL-3355
>> 
>> An alternative might be to match on vendor/product, see the last
>> commit to sys/dev/ic/re.c for how to do this, but then you're
>> having to look at fixed addresses which they seem to be providing
>> via acpi.
>> 
>
> Let me apologize right here for my lack of knowledge as to low level
> hardware coding.
>
> So, given that, please help me to understand why reading the DSDT ACPI
> table and finding the SEL0002 is not the correct solution here?  BTW, they
> also identify an SEL0001 device, but I have not asked them what that is,
> and )so far) I do not need to know. For what it is worth this hardware
> vendor has been very helpful, and the corporate philosophy is to do things
> "the right way". For instance, they released code to support this device for
> Linux. When I talked to them, i brought up liscneing concerns with the
> BSD's. The reply was, already been there, thought about that. It is dual
> GPL, and BSD liscneced. Really a pleasant sunrise, as this is not in their
> mainstream area of expertise. i was really pleased that the project team
> had researched the OSS issues that well.

I was just chatting to mlarkin about this, he hasn't looked at the
code but gave a few suggestions. 

I was wrong about the need to look for the SECD container - he gave an
example of a better driver to crib from, sdhc_acpi, which is pretty
simple in itself and shows the parts needed to find the device in the
DSDT. Basically it just involves passing an array containing "SEL0002"
to acpi_matchhids and it does the work.

Re: FW: Re: watchdog suport for new hardware

[stan]

On Thu, Apr 28, 2016 at 02:18:25PM +0100, Stuart Henderson wrote:
> On 2016/04/28 08:56, stan wrote:
> > On Thu, Apr 28, 2016 at 08:44:49AM +0100, Stuart Henderson wrote:
> > > Stan, can you send the information that is output when you run
> > > sendbug -P as root? Just putting the whole thing inline in a
> > > reply-to-all to this mail would be fine. Please add "sysctl hw"
> > > output as well. Ideally we want a way to identify the watchdog
> > > itself rather than the general machine type etc. which is why
> > > I'm hoping they follow Microsoft's spec (which is the de-facto 
> > > standard for this).
> > 
> > 
> > Sorry got distracted and frgot to cc the list.
> 
> OK, pity, there doesn't seem to be anything to properly identify
> the watchdog in acpi tables. Just the vendor-specific thing which
> needs reading to figure things out further. If they had followed
> the usual spec then the driver would have been *very* generally
> useful.
> 
> In that case maybe the approach would be to do something similar
> to acpithinkpad, but matching SECD instead of MHKV, and then
> looking for the SEL0002 HID. But I only know a bit about how
> to find my way round the decompiled files, so ignore me if
> a real ACPI hacker steps in with a better idea ;)
> 
> > hw.vendor=Schweitzer Engineering Laboratories, Inc.
> > hw.product=SEL-3355
> 
> An alternative might be to match on vendor/product, see the last
> commit to sys/dev/ic/re.c for how to do this, but then you're
> having to look at fixed addresses which they seem to be providing
> via acpi.
> 

Let me apologize right here for my lack of knowledge as to low level
hardware coding.

So, given that, please help me to understand why reading the DSDT ACPI
table and finding the SEL0002 is not the correct solution here?  BTW, they
also identify an SEL0001 device, but I have not asked them what that is,
and )so far) I do not need to know. For what it is worth this hardware
vendor has been very helpful, and the corporate philosophy is to do things
"the right way". For instance, they released code to support this device for
Linux. When I talked to them, i brought up liscneing concerns with the
BSD's. The reply was, already been there, thought about that. It is dual
GPL, and BSD liscneced. Really a pleasant sunrise, as this is not in their
mainstream area of expertise. i was really pleased that the project team
had researched the OSS issues that well.




-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: FW: Re: watchdog suport for new hardware

[stan]

On Thu, Apr 28, 2016 at 08:44:49AM +0100, Stuart Henderson wrote:
> Stan, can you send the information that is output when you run
> sendbug -P as root? Just putting the whole thing inline in a
> reply-to-all to this mail would be fine. Please add "sysctl hw"
> output as well. Ideally we want a way to identify the watchdog
> itself rather than the general machine type etc. which is why
> I'm hoping they follow Microsoft's spec (which is the de-facto 
> standard for this).


Sorry got distracted and frgot to cc the list.


Script started on Thu Apr 28 08:45:28 2016
# sendbug -P
SENDBUG: -*- sendbug -*-
SENDBUG: Lines starting with `SENDBUG' will be removed automatically.
SENDBUG:
SENDBUG: Choose from the following categories:
SENDBUG:
SENDBUG: system user library documentation kernel alpha amd64 arm hppa i386 
m88k mips64 powerpc sh sparc sparc64 vax
SENDBUG:
SENDBUG:
To: b...@openbsd.org
Subject: 
From: root
Cc: root
Reply-To: root

>Synopsis:  
>Category:  
>Environment:
System  : OpenBSD 5.9
Details : OpenBSD 5.9 (GENERIC.MP) #0: Wed Apr 27 18:40:39 EDT 2016
 
r...@test.power.charleston.kapstonepaper.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:

>How-To-Repeat:

>Fix:


SENDBUG: dmesg, pcidump, acpidump and usbdevs are attached.
SENDBUG: Feel free to delete or use the -D flag if they contain sensitive 
information.

dmesg:
OpenBSD 5.9 (GENERIC.MP) #0: Wed Apr 27 18:40:39 EDT 2016

r...@test.power.charleston.kapstonepaper.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16991633408 (16204MB)
avail mem = 16472473600 (15709MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0840 (59 entries)
bios0: vendor Schweitzer Engineering Laboratories, Inc. version "B_1.5.49152.2 
X64" date 12/18/2015
bios0: Schweitzer Engineering Laboratories, Inc. SEL-3355
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP SSDT HPET APIC MCFG FPDT ASF! SSDT SSDT SSDT SSDT UEFI 
POAT SSDT BERT HEST EINJ ERST UEFI UEFI DBG2
acpi0: wakeup devices P0P1(S0) GLAN(S0) EHC1(S0) EHC2(S0) HDEF(S0) PXSX(S0) 
PXSX(S0) PXSX(S0) PXSX(S0) PXSX(S0) RP08(S0) PEG1(S0) PEG3(S0)
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-3612QE CPU @ 2.10GHz, 2095.58 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,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 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) i7-3612QE CPU @ 2.10GHz, 2095.24 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,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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) i7-3612QE CPU @ 2.10GHz, 2095.24 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,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,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) i7-3612QE CPU @ 2.10GHz, 2095.24 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,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
cpu4 at mainbus0: apid 4 (application processor)
cpu4: Intel(R) Core(TM) i7-3612QE CPU @ 2.10GHz, 2095.24 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT

Re: FW: Re: watchdog suport for new hardware

[Stuart Henderson]

On 2016/04/28 08:56, stan wrote:
> On Thu, Apr 28, 2016 at 08:44:49AM +0100, Stuart Henderson wrote:
> > Stan, can you send the information that is output when you run
> > sendbug -P as root? Just putting the whole thing inline in a
> > reply-to-all to this mail would be fine. Please add "sysctl hw"
> > output as well. Ideally we want a way to identify the watchdog
> > itself rather than the general machine type etc. which is why
> > I'm hoping they follow Microsoft's spec (which is the de-facto 
> > standard for this).
> 
> 
> Sorry got distracted and frgot to cc the list.

OK, pity, there doesn't seem to be anything to properly identify
the watchdog in acpi tables. Just the vendor-specific thing which
needs reading to figure things out further. If they had followed
the usual spec then the driver would have been *very* generally
useful.

In that case maybe the approach would be to do something similar
to acpithinkpad, but matching SECD instead of MHKV, and then
looking for the SEL0002 HID. But I only know a bit about how
to find my way round the decompiled files, so ignore me if
a real ACPI hacker steps in with a better idea ;)

> hw.vendor=Schweitzer Engineering Laboratories, Inc.
> hw.product=SEL-3355

An alternative might be to match on vendor/product, see the last
commit to sys/dev/ic/re.c for how to do this, but then you're
having to look at fixed addresses which they seem to be providing
via acpi.

HEADS-UP: Firefox 46 now uses Gtk+3, WebRTC is enabled

[Landry Breuil]

Hi,

for those who dont follow ports-changes@, i've updated
www/mozilla-firefox to version 46.0, and following upstream this now
defaults to use Gtk+3 toolkit. There were issues with Gtk 3.20, but
most/all have been solved by taking a jumbo patch from Fedora (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1234158 among others) -
so besides theme changes and graphics glitches, this change should be
transparent to end-users.

If you want to stay with Gtk+2, install firefox-esr, but the latter will
move to Gtk+3 when it is updated to 52. I *might* provide the
infrastructure to build gtk2 FLAVORs like it was possible for gtk3 since
firefox 30, but this is not done, and i wont spend time on this unless
there's a real need.

At the same time, i've enabled (well, stopped disabling) WebRTC code -
nothing in it has changed OpenBSD-wise in the past months, but i'm not
in a position to debug/test it much myself nowadays, so end-users get to
dogfood it. Since it works on Linux/etc, it should mostly work on
OpenBSD, besides sound needing more love (ping ratchov@)- webcam sortof
worked last i tried, as data channels. If you want to test it, there are
plenty of example sites around, start with the ones linked on
https://mozilla.github.io/webrtc-landing/

If you have issues/crashes, direct your reports to
https://bugzilla.mozilla.org/ and cc me there.

If you dont like it or have security concerns for the paranoids, set
media.peerconnection.enabled to false in about:config.

Landry

Fwd: about rc.subr

[johnw]

Hi, dbus also not working after upgrade to  today current.

CVSROOT: /cvs Module name: src Changes by: ajacou...@cvs.openbsd.org 2016/04/28 
03:15:16 Modified files: etc/rc.d : rc.subr sndiod Log message: Experiment on 
matching on the daemon_user is over. It needs more work. portmap isn't happy 
with it as reported by naddy@
-- 
Sent from my Android phone.

Re: FW: Re: watchdog suport for new hardware

[stan]

On Thu, Apr 28, 2016 at 08:44:49AM +0100, Stuart Henderson wrote:
> Stan, can you send the information that is output when you run
> sendbug -P as root? Just putting the whole thing inline in a
> reply-to-all to this mail would be fine. Please add "sysctl hw"
> output as well. Ideally we want a way to identify the watchdog
> itself rather than the general machine type etc. which is why
> I'm hoping they follow Microsoft's spec (which is the de-facto 
> standard for this).

Absolutely. I am in the process of bailing a 5.9 machine to install this
on, so hopefully I can send this today.

Thanks for the interest in our issues.


-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: MacBook 9,1 or 8,1

[Joerg Jung]

> On 28 Apr 2016, at 09:00, Marcus MERIGHI  wrote:
> 
> m...@umaxx.net (Joerg Jung), 2016.04.27 (Wed) 21:53 (CEST):
>> On Wed, Apr 27, 2016 at 09:41:50AM -0400, Bryan Everly wrote:
>>> 
>>> Has anyone had success with either of the new 12" Retina MacBooks?  My
>>> search of marc.info came up empty.
>> 
>> I own a MacBook8,2 and efiboot as well as inteldrm graphics seems to
>> work fine.  However, internal nvme(4) ssd is not detected and the SPI
> 
> Before or after this one?

After of course, with an additional diff to enable it (see below), 
but the controller does not work (yet).

> http://marc.info/?l=openbsd-cvs=146069961907725
> Log message:
> enable nvme(4)
> ok dlg@
> 
> Bye, Marcus
> 
> 
>> connected trackpad/mouse also does not work.  The built-in WLAN might
>> never work.  A standard USB3 HUB (connected via adapter), I tested was
>> not really working. So you you can either only attach a USB keyboard or
>> disk or wlan card to the single USB-C port, your choice :) 
>> 
>> Due to this fact I can not provide a copy dmesg.
>> Linux support seems not much better [1].
>> 
>> I have no idea about the 9,x but would like to see a dmesg. 
>> Newer MacbookAir might have the same nvme(4) problem.
>> 
>> Regards,
>> Joerg
>> 
>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=99891
>> 
>> 
>> !DSPAM:57211a01134006737330760!

Index: sys/dev/pci/nvme_pci.c
===
RCS file: /cvs/src/sys/dev/pci/nvme_pci.c,v
retrieving revision 1.3
diff -u -p -r1.3 nvme_pci.c
--- sys/dev/pci/nvme_pci.c  14 Apr 2016 11:18:32 -  1.3
+++ sys/dev/pci/nvme_pci.c  20 Apr 2016 22:10:22 -
@@ -70,6 +70,10 @@ nvme_pci_match(struct device *parent, vo
PCI_INTERFACE(pa->pa_class) == NVME_PCI_INTERFACE)
return (1);

+   if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_APPLE &&
+   PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_APPLE_NVME)
+   return (1);
+
return (0);
}

Index: sys/dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1792
diff -u -p -r1.1792 pcidevs
--- sys/dev/pci/pcidevs 8 Apr 2016 09:59:47 -   1.1792
+++ sys/dev/pci/pcidevs 20 Apr 2016 22:10:22 -
@@ -923,6 +923,7 @@ product APPLE INTREPID2_ATA 0x0069  Intre
product APPLE INTREPID2_FW  0x006a  Intrepid 2 FireWire
product APPLE INTREPID2_GMAC0x006b  Intrepid 2 GMAC
product APPLE BCM5701   0x1645  BCM5701
+product APPLE NVME 0x2001  NVM Express Controller

/* Aralion products */
product ARALION ARS106S 0x0301  ARS106S
Index: sys/dev/pci/pcidevs.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
retrieving revision 1.1786
diff -u -p -r1.1786 pcidevs.h
--- sys/dev/pci/pcidevs.h   8 Apr 2016 10:00:24 -   1.1786
+++ sys/dev/pci/pcidevs.h   20 Apr 2016 22:10:22 -
@@ -928,6 +928,7 @@
#define PCI_PRODUCT_APPLE_INTREPID2_FW  0x006a  /* Intrepid 2 FireWire 
*/
#define PCI_PRODUCT_APPLE_INTREPID2_GMAC0x006b  /* Intrepid 2 
GMAC */
#define PCI_PRODUCT_APPLE_BCM5701   0x1645  /* BCM5701 */
+#definePCI_PRODUCT_APPLE_NVME  0x2001  /* NVM Express 
Controller */

/* Aralion products */
#define PCI_PRODUCT_ARALION_ARS106S 0x0301  /* ARS106S */
Index: sys/dev/pci/pcidevs_data.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
retrieving revision 1.1781
diff -u -p -r1.1781 pcidevs_data.h
--- sys/dev/pci/pcidevs_data.h  8 Apr 2016 10:00:24 -   1.1781
+++ sys/dev/pci/pcidevs_data.h  20 Apr 2016 22:10:23 -
@@ -2024,6 +2024,10 @@ static const struct pci_known_product pc
"BCM5701",
},
{
+   PCI_VENDOR_APPLE, PCI_PRODUCT_APPLE_NVME,
+   "NVM Express Controller",
+   },
+   {
PCI_VENDOR_ARALION, PCI_PRODUCT_ARALION_ARS106S,
"ARS106S",
},

Re: Change MTU for IPSec

[Stuart Henderson]

On 2016-04-26, lilit-aibolit  wrote:
> On 04/25/2016 06:13 PM, Marc Peters wrote:
>> Am 04/25/16 um 16:00 schrieb lilit-aibolit:
>>> Hi list.
>>> I've typical site-to-site IPsec tunnel.
>>> On rare occasions users got infinite loop in their browser
>>> while opening web-sites in opposite endpoints, however
>>> in same time ping works well from one network to other.
>>> SSH connection to remote hosts looks like you're almost
>>> entered, but it freezes and can only interrupt connection.
>> I had similar issues some years ago with branch offices and a simple
>>
>> """
>> match in all scrub (random-id no-df)
>> """
>>
>> in the /etc/pf.conf on each host solved this for me (the no-df part was
>> the important bit).
>>
>> HTH,
>> Marc
>>
> Thanks for your answer.
> I already have this line in pf.conf on all machines:
>
> >>match in all scrub (no-df)<<
>
>

If your problem is with TCP packets, you can add "max-mss 1300" or
similar.

If it's with other protocols and the no-df approach doesn't help, you
may need to reduce MTU on all machines.

Re: Can't use sshfs as user

[Stuart Henderson]

On 2016-04-26, Daniel Boyd  wrote:
> Any idea how to get it to map the uid?  Once I mount the folder, I can't
> access it.
>
> I've tried -o idmap=user, -o uid=1000, etc. None of that seems to work.

iirc that's not supported in OpenBSD's FUSE implementation yet.

Re: FW: Re: watchdog suport for new hardware

[Stuart Henderson]

Stan, can you send the information that is output when you run
sendbug -P as root? Just putting the whole thing inline in a
reply-to-all to this mail would be fine. Please add "sysctl hw"
output as well. Ideally we want a way to identify the watchdog
itself rather than the general machine type etc. which is why
I'm hoping they follow Microsoft's spec (which is the de-facto 
standard for this).

Re: upgrade OpenBSD 5.8 to 5.9 daemon: unknown class

[Stuart Henderson]

On 2016-04-28, Ultramedia Libertad  wrote:
> with this file that comes by default it worked perfectly, I think the
> login.conf file does not work without the first line or comments, or I had
> some syntax error'll never know something like that happened to someone in
> this thread the which along with their answers of you helped me solve it.

login.conf is fragile, it's not hard to get the format wrong and it's
easy to lock yourself out after a bad edit. I recommend leaving a
spare root shell open when editing it, and test that it works - make
sure you can still login (if it's remote) or su (if it's local) before
closing the shell.

Re: MacBook 9,1 or 8,1

[Marcus MERIGHI]

m...@umaxx.net (Joerg Jung), 2016.04.27 (Wed) 21:53 (CEST):
> On Wed, Apr 27, 2016 at 09:41:50AM -0400, Bryan Everly wrote:
> > 
> > Has anyone had success with either of the new 12" Retina MacBooks?  My
> > search of marc.info came up empty.
> 
> I own a MacBook8,2 and efiboot as well as inteldrm graphics seems to
> work fine.  However, internal nvme(4) ssd is not detected and the SPI

Before or after this one?

http://marc.info/?l=openbsd-cvs=146069961907725
Log message:
enable nvme(4)
ok dlg@

Bye, Marcus


> connected trackpad/mouse also does not work.  The built-in WLAN might
> never work.  A standard USB3 HUB (connected via adapter), I tested was
> not really working. So you you can either only attach a USB keyboard or
> disk or wlan card to the single USB-C port, your choice :) 
> 
> Due to this fact I can not provide a copy dmesg.
> Linux support seems not much better [1].
> 
> I have no idea about the 9,x but would like to see a dmesg. 
> Newer MacbookAir might have the same nvme(4) problem.
> 
> Regards,
> Joerg
> 
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=99891
> 
> 
> !DSPAM:57211a01134006737330760!