Re: vxlan paper from AsiaBSDCon 2014
On 28 April 2016 at 13:36, listswrote: > 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
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
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
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
On 2016-04-28, Jack J. Woehrwrote: > 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
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
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
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
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
On Thu, Apr 28, 2016 at 03:22:15PM +, Stuart Henderson wrote: > On 2016-04-28, stanwrote: > > 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
On 2016-04-28, stanwrote: > 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
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
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
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
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
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
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
> On 28 Apr 2016, at 09:00, Marcus MERIGHIwrote: > > 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
On 2016-04-26, lilit-aibolitwrote: > 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
On 2016-04-26, Daniel Boydwrote: > 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
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
On 2016-04-28, Ultramedia Libertadwrote: > 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
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!