ThinkPad W541 resume doesn't work.

[Christoph R. Murauer]

Hello !

Don't tread this post as bug. If it works nice - if not also no
problem because I don't need it really.

I have a W541 where suspend works but resume not.

The machine has no serial port. But beside the i7 a nVidia optimus
which can't be switched off in the bios.

If I close the lid after a normal installation it suspends but, if I
open the display it doesn't resume. Even not, if I press some keys,
the power button is blinking and, the display stays black. The only
way is, to press the power button till it switches off. If I switch it
on again, it doesn't boot. Instead I have to press and hold the power
button again, till it is really off.

If I set in rc.conf.local apmd_flags="-C" I can reproduce it using zzz
and ZZZ. In booth the same. The only difference is, that in one of
them (I can't remember which one but I think you know which it is) I
have only press the power butten once to switch it off.

At the moment I set in sysctl.conf machdep.lidsuspend=0 and, can
confirm, that the display switch on after I open it for something like
1 centimeter.

If someone is interested to look at it and, more informations are
needed, let me know.

Regards,


Christoph

dmesg :

OpenBSD 5.8-current (GENERIC.MP) #1527: Sun Oct 18 14:40:13 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 33939300352 (32367MB)
avail mem = 32906575872 (31382MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7cd2d000 (69 entries)
bios0: vendor LENOVO version "GNET73WW (2.21 )" date 03/12/2015
bios0: LENOVO 20EFS00B00
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP DBGP ECDT HPET APIC MCFG SSDT SSDT SSDT SSDT
SSDT SSDT SSDT PCCT SSDT TCPA UEFI POAT ASF! BATB FPDT UEFI
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) EXP3(S4)
XHCI(S3) EHC1(S3) EHC2(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
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-4810MQ CPU @ 2.80GHz, 798.33 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,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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.2.4, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz, 798.15 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,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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-4810MQ CPU @ 2.80GHz, 798.15 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,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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-4810MQ CPU @ 2.80GHz, 798.15 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,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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-4810MQ CPU @ 2.80GHz, 798.15 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,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 0, core 2, package 0
cpu5 at mainbus0: apid 5 (application processor)
cpu5: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz, 798.15 MHz
cpu5:

Re: bgpd+ospfd configuration question

[John E.P. Hynes]

Thanks Claudio - that clears it up.

-John

On 10/21/2015 02:06 AM, Claudio Jeker wrote:
> On Tue, Oct 20, 2015 at 11:07:12AM -0400, John E.P. Hynes wrote:
>> Hi list,
>>
>> I've read through the docs and Claudio's guide, but something isn't
>> clear to me I'm hoping to get some direction on:
>>
>> I am about to multihome.  My uplinks to my ISPs terminate on different
>> OpenBSD routers.  The class C network behind them includes one internal
>> OpenBSD gateway performing NAT for connections leaving the internal
>> private network.
>>
>> My understanding is that I would configure OpenBGPD on the two border
>> routers with iBGP between them, like this:
>>
>> /etc/bgpd.conf
>>
>> # Global Config
>> AS MyASN
>> router-id 1.2.3.4
>>
>> # Announce Our Network Space
>> network 1.2.3/24
>>
>> # Neighbor Config
>> neighbor 9.8.7.6 {
>>  descr   "My ISP 1"
>>  remote-as TheirASN
>> }
>>
>> # iBGP
>> group IBGP {
>>  remote-as MyASN
>>  neighbor 1.2.3.5 {
>>  descr   "MyOtherBorderGateway"
>>  }
>> }
>>
>> ...Essentially, since no host in my public network would be aware of
>> which border gateway to leave through, I need an IGP such as OpenOSPFd
>> as well.  Something like this on the border gateways:
>>
>> /etc/ospfd.conf
>>
>> # Global Config
>> router-id 0.0.0.1
>> redistribute connected
>>
>> # Areas
>> area 0.0.0.0 {
>>  auth-type crypt
>>  auth-md 1 "SomePW"
>>  auth-md 2 "SomeDifferentPW"
>>  auth-md-keyid 1
>>
>>  # Main Link (DMZ)
>>  interface em1
>> }
>>
>> ...and then something like this on all hosts on my public network,
>> including the NAT firewall:
>>
>> /etc/ospfd.conf
>>
>> # Global Config
>> router-id 0.0.0.3
>>
>> # Areas
>> area 0.0.0.0 {
>>  auth-type crypt
>>  auth-md 1 "SomePW"
>>  auth-md 2 "SomeDifferentPW"
>>  auth-md-keyid 1
>>
>>  # Main Link (DMZ)
>>  interface em1
>> }
>>
>>
>> My questions are:
>>
>> 1) Claudio's guide suggests to me that iBGP needs to be run on the NAT
>> firewall as well, but I don't understand *why* that would be necessary
>> and I think I'm mis-reading it.  Clarification please?
> 
> By running BGP on the internal FW allows you to send out the traffic to
> the correct broder router and so you get better control over which path
> you reach the internet.
>  
>> 2) Do I really want "redistribute connected" in the ospfd.conf on the
>> border routers, or "redistribute default"?
>>
> 
> If you feed the BGP table to your FW than you most probably need
> redistribute connected. In such a simple setup as yours you can also skip
> using OSPF and just use "set nexthop self" in bgpd since all your routers
> & firewalls are directly connected.
> 
> In short the IGP (OSPF) is required for incoming traffic to find its
> destination in your network whereas iBGP is required to take the optimal
> way out of your network.

Re: recompile packages to include base / libressl errata?

[Stuart Henderson]

On 2015-10-21, Tim Kuijsten  wrote:
> I'm following 5.7-stable but I'm not confident if my dovecot server has 
> the recent OBJ_obj2txt fix (019) for it's tls connections. Should I 
> start using the dovecot port and recompile instead of using the dovecot 
> package in order to get the fix? I'm using dovecot with IMAP over tls.
>
> Furthermore, is ldd and the knowledge if a package uses tls enough to 
> determine if a package has to be recompiled or not? If so, am I correct 
> to conclude that postfix does not have to be recompiled because it 
> dynamically links libssl.so.32.0 and libcrypto.so.32.0?
>
> -Tim
>
>

Like most things in ports, Dovecot dynamically links to the SSL libraries,
but it's a bit more buried away due to the use of modules.

Postfix also dynamically links. Neither need to be recompiled for this.

$ cd /usr/local/lib/dovecot
$ objdump -p libdovecot-login.so.2.0 libssl_iostream_openssl.so 

libdovecot-login.so.2.0: file format elf64-x86-64

Program Header:
LOAD off0x vaddr 0x paddr 
0x align 2**20
 filesz 0x000153ee memsz 0x000153ee flags r-x
LOAD off0x00015400 vaddr 0x00115400 paddr 
0x00115400 align 2**20
 filesz 0x4cf0 memsz 0x4cf0 flags r--
LOAD off0x0001a0f0 vaddr 0x0021a0f0 paddr 
0x0021a0f0 align 2**20
 filesz 0x04e8 memsz 0x04e8 flags rw-
LOAD off0x0001a5d8 vaddr 0x0031a5d8 paddr 
0x0031a5d8 align 2**20
 filesz 0x0d78 memsz 0x0d78 flags rw-
LOAD off0x0001b360 vaddr 0x0041b360 paddr 
0x0041b360 align 2**20
 filesz 0x03c0 memsz 0x04b0 flags rw-
 DYNAMIC off0x0001a448 vaddr 0x0021a448 paddr 
0x0021a448 align 2**3
 filesz 0x0190 memsz 0x0190 flags rw-
NOTE off0x0001a0d8 vaddr 0x0011a0d8 paddr 
0x0011a0d8 align 2**2
 filesz 0x0018 memsz 0x0018 flags r--
EH_FRAME off0x00018000 vaddr 0x00118000 paddr 
0x00118000 align 2**2
 filesz 0x06c4 memsz 0x06c4 flags r--
OPENBSD_RANDOMIZE off0x0001a0f0 vaddr 0x0021a0f0 paddr 
0x0021a0f0 align 2**3
 filesz 0x0008 memsz 0x0008 flags rw-

Dynamic Section:
  NEEDED  libpthread.so.19.0
  NEEDED  libssl.so.37.0
  NEEDED  libcrypto.so.36.0
  NEEDED  libdovecot.so.2.0
  RPATH   /usr/local/lib/dovecot
  INIT0x8a00
  FINI0x153e0
  HASH0x2a8
  STRTAB  0x3aa8
  SYMTAB  0xe38
  STRSZ   0x215d
  SYMENT  0x18
  PLTGOT  0x31a5d8
  PLTRELSZ0x2460
  PLTREL  0x7
  JMPREL  0x6598
  RELA0x5c08
  RELASZ  0x990
  RELAENT 0x18
  RELACOUNT   0x42


libssl_iostream_openssl.so: file format elf64-x86-64

Program Header:
LOAD off0x vaddr 0x paddr 
0x align 2**20
 filesz 0x87ee memsz 0x87ee flags r-x
LOAD off0x8800 vaddr 0x00108800 paddr 
0x00108800 align 2**20
 filesz 0x1760 memsz 0x1760 flags r--
LOAD off0xa000 vaddr 0x0020a000 paddr 
0x0020a000 align 2**20
 filesz 0x0228 memsz 0x0228 flags rw-
LOAD off0xa228 vaddr 0x0030a228 paddr 
0x0030a228 align 2**20
 filesz 0x0680 memsz 0x0680 flags rw-
LOAD off0xa8a8 vaddr 0x0040a8a8 paddr 
0x0040a8a8 align 2**20
 filesz 0x001c memsz 0x0030 flags rw-
 DYNAMIC off0xa0c8 vaddr 0x0020a0c8 paddr 
0x0020a0c8 align 2**3
 filesz 0x0160 memsz 0x0160 flags rw-
NOTE off0x9f48 vaddr 0x00109f48 paddr 
0x00109f48 align 2**2
 filesz 0x0018 memsz 0x0018 flags r--
EH_FRAME off0x94a0 vaddr 0x001094a0 paddr 
0x001094a0 align 2**2
 filesz 0x022c memsz 0x022c flags r--
OPENBSD_RANDOMIZE off0xa000 vaddr 0x0020a000 paddr 
0x0020a000 align 2**3
 filesz 0x0008 memsz 0x0008 flags rw-

Dynamic Section:
  NEEDED  libssl.so.37.0
  NEEDED  libcrypto.so.36.0
  INIT0x42d0
  FINI0x87e0
  HASH0x2a8
  STRTAB  0x1e98
  SYMTAB  0x950
  STRSZ   0xf43
  SYMENT  0x18
  PLTGOT  0x30a228
  PLTRELSZ0x1230
  PLTREL  0x7
  JMPREL  0x3098
  RELA0x2de0
  RELASZ  0x2b8
  RELAENT 0x18
  RELACOUNT   0x11

Re: ThinkPad W541 resume doesn't work.

[Jonathan Gray]

On Wed, Oct 21, 2015 at 05:07:32PM +0200, Christoph R. Murauer wrote:
> Hello !
> 
> Don't tread this post as bug. If it works nice - if not also no
> problem because I don't need it really.
> 
> I have a W541 where suspend works but resume not.
> 
> The machine has no serial port. But beside the i7 a nVidia optimus
> which can't be switched off in the bios.
> 
> If I close the lid after a normal installation it suspends but, if I
> open the display it doesn't resume. Even not, if I press some keys,
> the power button is blinking and, the display stays black. The only
> way is, to press the power button till it switches off. If I switch it
> on again, it doesn't boot. Instead I have to press and hold the power
> button again, till it is really off.
> 
> If I set in rc.conf.local apmd_flags="-C" I can reproduce it using zzz
> and ZZZ. In booth the same. The only difference is, that in one of
> them (I can't remember which one but I think you know which it is) I
> have only press the power butten once to switch it off.
> 
> At the moment I set in sysctl.conf machdep.lidsuspend=0 and, can
> confirm, that the display switch on after I open it for something like
> 1 centimeter.
> 
> If someone is interested to look at it and, more informations are
> needed, let me know.

If that's anything like the x250 and 2015 X1 Carbon you'll need
to disable the tpm in the bios:

https://bugzilla.redhat.com/show_bug.cgi?id=1164937

> 
> Regards,
> 
> 
> Christoph
> 
> dmesg :
> 
> OpenBSD 5.8-current (GENERIC.MP) #1527: Sun Oct 18 14:40:13 MDT 2015
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 33939300352 (32367MB)
> avail mem = 32906575872 (31382MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7cd2d000 (69 entries)
> bios0: vendor LENOVO version "GNET73WW (2.21 )" date 03/12/2015
> bios0: LENOVO 20EFS00B00
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP DBGP ECDT HPET APIC MCFG SSDT SSDT SSDT SSDT
> SSDT SSDT SSDT PCCT SSDT TCPA UEFI POAT ASF! BATB FPDT UEFI
> acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) EXP3(S4)
> XHCI(S3) EHC1(S3) EHC2(S3)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiec0 at acpi0
> 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-4810MQ CPU @ 2.80GHz, 798.33 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,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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.2.4, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz, 798.15 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,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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-4810MQ CPU @ 2.80GHz, 798.15 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,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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-4810MQ CPU @ 2.80GHz, 798.15 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,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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-4810MQ CPU @ 2.80GHz, 798.15 MHz
> cpu4:
> 

Re: anybody besides me trying to compile gpt-fdisk?

[Joel Rees]

Okay, here's my current set of diffs for gptfdisk:
-
diff --git a/diskio-unix.cc b/diskio-unix.cc
index af71cdb..83b60f9 100644
--- a/diskio-unix.cc
+++ b/diskio-unix.cc
@@ -248,6 +248,13 @@ int DiskIO::DiskSync(void) {
<< "You should reboot or remove the drive.\n";
   platformFound++;
 #endif
+#if defined (__OpenBSD__) // Shamelessly parroting the FreeBSD code.
+  sleep(2);
+  i = fsync(fd); // Is this how to force a flush on a disk device?
+  cout << "Warning: The kernel may continue to use old or deleted
partitions.\n"
+   << "You should reboot or remove the drive.\n";
+  platformFound++;
+#endif
 #ifdef __linux__
   sleep(1); // Theoretically unnecessary, but ioctl() fails
sometimes if omitted
   fsync(fd);
diff --git a/diskio.h b/diskio.h
index 631a43a..c198f29 100644

--- a/diskio.h
+++ b/diskio.h
@@ -29,7 +29,7 @@
 #include 
 #endif

-#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) || defined
(__APPLE__)
+#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) || defined
(__OpenBSD__) || defined (__APPLE__)
 #define fstat64 fstat
 #define stat64 stat
 #endif
diff --git a/guid.cc b/guid.cc
index 1e73ab7..0fd8bfe 100644
--- a/guid.cc
+++ b/guid.cc
@@ -147,6 +147,8 @@ void GUIDData::Randomize(void) {
ReverseBytes([4], 2);
ReverseBytes([6], 2);
uuidGenerated = 1;
+#else

+#  warning "not compiling in the uuid_generate()"
 #endif
 #if defined (_RPC_H) || defined (__RPC_H__)
UUID MsUuid;
diff --git a/support.h b/support.h
index b888d92..dd3ea03 100644
--- a/support.h
+++ b/support.h
@@ -10,7 +10,7 @@

 #define GPTFDISK_VERSION "1.0.1"

-#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) || defined
(__APPLE__)
+#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) ||
(__OpenBSD__) || defined (__APPLE__)
 // Darwin (Mac OS) & FreeBSD: disk IOCTLs are different, and there is
no lseek64
 #include 
 #define lseek64 lseek
-

Very lightly tested, but it seems to be functional, to some degree.

-- Joel Rees

Re: ThinkPad W541 resume doesn't work.

[Christoph R. Murauer]

Ops, typo in the email adress.

Answer is below.

>> Try *completely* disabling the Trusted Platform Module (TPM) in the
>> BIOS.
>
> Thanks @all for your answers.
> Yes, TPM which is named in BIOS Security Chip was enabled. Got the
> ThinkPad back on friday from Lenovo from a repair and don't checked
> the settings because everything worked.
>
> Machine resumes with a (my first) kernel panic and a ddb prompt. I
> have to read the related docs to report the needed things.

Using fsync instead of ioctl(fd, DIOCGFLUSH); (Re: anybody besides me trying to compile gpt-fdisk?)

[Joel Rees]

Is fsync an appropriate way to flush writes to the disk device? In the
FreeBSD code, it is


#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__)
  sleep(2);
  i = ioctl(fd, DIOCGFLUSH);
  cout << "Warning: The kernel may continue to use old or deleted
partitions.\n"
   << "You should reboot or remove the drive.\n";
  platformFound++;
#endif


On Wed, Oct 21, 2015 at 11:06 PM, Joel Rees  wrote:
> Okay, here's my current set of diffs for gptfdisk:
> -
> diff --git a/diskio-unix.cc b/diskio-unix.cc
> index af71cdb..83b60f9 100644
> --- a/diskio-unix.cc
> +++ b/diskio-unix.cc
> @@ -248,6 +248,13 @@ int DiskIO::DiskSync(void) {
> << "You should reboot or remove the drive.\n";
>platformFound++;
>  #endif

This is what I'm adding for the flush, since I couldn't find
DIOCGFLUSH or an equivalent:

> +#if defined (__OpenBSD__) // Shamelessly parroting the FreeBSD code.
> +  sleep(2);
> +  i = fsync(fd); // Is this how to force a flush on a disk device?
> +  cout << "Warning: The kernel may continue to use old or deleted
> partitions.\n"
> +   << "You should reboot or remove the drive.\n";
> +  platformFound++;
> +#endif
>  #ifdef __linux__
>sleep(1); // Theoretically unnecessary, but ioctl() fails
> sometimes if omitted
>fsync(fd);
> diff --git a/diskio.h b/diskio.h
> index 631a43a..c198f29 100644
>
> --- a/diskio.h
> +++ b/diskio.h
> @@ -29,7 +29,7 @@
>  #include 
>  #endif
>
> -#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) || defined
> (__APPLE__)
> +#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) || defined
> (__OpenBSD__) || defined (__APPLE__)
>  #define fstat64 fstat
>  #define stat64 stat
>  #endif
> diff --git a/guid.cc b/guid.cc
> index 1e73ab7..0fd8bfe 100644
> --- a/guid.cc
> +++ b/guid.cc
> @@ -147,6 +147,8 @@ void GUIDData::Randomize(void) {
> ReverseBytes([4], 2);
> ReverseBytes([6], 2);
> uuidGenerated = 1;
> +#else
>
> +#  warning "not compiling in the uuid_generate()"
>  #endif
>  #if defined (_RPC_H) || defined (__RPC_H__)
> UUID MsUuid;
> diff --git a/support.h b/support.h
> index b888d92..dd3ea03 100644
> --- a/support.h
> +++ b/support.h
> @@ -10,7 +10,7 @@
>
>  #define GPTFDISK_VERSION "1.0.1"
>
> -#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) || defined
> (__APPLE__)
> +#if defined (__FreeBSD__) || defined (__FreeBSD_kernel__) ||
> (__OpenBSD__) || defined (__APPLE__)
>  // Darwin (Mac OS) & FreeBSD: disk IOCTLs are different, and there is
> no lseek64
>  #include 
>  #define lseek64 lseek
> -
>
> Very lightly tested, but it seems to be functional, to some degree.
>
> -- Joel Rees



-- 
Joel Rees

Be careful when you look at conspiracy.
Arm yourself with knowledge of yourself, as well:
http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html

Re: how to partition routing namespace

[Chris Cappuccio]

Geoff Steckel [g...@oat.com] wrote:
> 
> On reading the latest if_bridge.c it looks like it will cross routing
> domains. No domain information is passed with the packet.
> A lot of it got rewritten between 5.7 and 5.8
> 

What does bridge have to do with it?

I thought you wanted to terminate a tunnel on a router.

Re: how to partition routing namespace

[Geoff Steckel]

On 10/20/2015 10:19 PM, Chris Cappuccio wrote:

Geoff Steckel [g...@oat.com] wrote:

I'm using sixxx.net as an IPv6 tunnel gateway.
They gave me 2001:::0111::0002 as my tunnel endpoint and
2001:::0111::1 as their end and router address.
They gave me 2001:::8111::/64 for my address space.
Note that the tunnel endpoint addresses are globally routeable.

The desired behavior is to partition the network space
inside the machine into the gateway section and the
rest of the machine >> as if they were connected by
a pair of interfaces and a cable << where the interfaces
had addresses in 2001...8111 so that locally generated
packets would go out with that source address.


If the tunnel endpoint x:0111::0002 is globally routeable, why do you
care about the machine's own traffic not appearing from that address?

None the less, if you must have traffic appear from x:8111::/64,
can't you just use that on your gif interface? As gif is a point-to-
point interface, there is no need for both participants to be within the
same subnet. Of course, if you do this, you can't then apply the
x:8111::/64 address to your ethernet interface facing your LAN,
which is where it was meant to go, and why it all works this way
anyways.

If you really must have both x:8111::/64 on the LAN and on the gif
interface, you could specify a /128 address for the gif interface
and only use one of your x:8111::/64 addresses away from your LAN
interface.

Thre is no ARP so even if the remote router knows your gif interface
as x:0111::0002 and routes to it, you can still use whatever address
you want. But I don't really understand why you would want to do this,
unless this tunnel router is the only machine you care to IPv6 on.

Chris

There are a number of reasons 0111::2 is not useful to me.

On reading the latest if_bridge.c it looks like it will cross routing
domains. No domain information is passed with the packet.
A lot of it got rewritten between 5.7 and 5.8

# desired global address
ifconfig vether1 inet6 2001:::8111::8
# synthetic router address
ifconfig vether2 inet6 2001:::8111::9 rdomain 1

# a synthetic wire between vether1 and 2
ifconfig bridge1 add vether1
ifconfig bridge1 add vether2

# system net routing to tunnel section
route add -ipv6 default 2001:::8111:9
# tunnel section routing to external router
route -T 1 add -ipv6 default 2001:::0111::1

(modulo typos & misplaced arguments)

I'll load -current on a machine, set up the configuration
as above & connect it to another machine via a tunnel.
If it doesn't work, it ought to. And I'll try to fix it.
My pf.conf might be comprehensible then.

Many thanks to the people who greatly improved if_bridge.c

Geoff Steckel

Re: requesting help working around boot failures with supermicro atom board

[lists]

Synopsis: if sensors show missing data then reset the BMC unit before
rebooting the system to prevent unable to boot long beep issue.

I found a reliably reproducible workaround for this problem retaining
control continuity without the need to trip the mains breaker.  This
entirely prevents the long beep issue and allows the system to be used
in headless remote environments without ensuring remote mains power
cycle capability and/or remote hands intervention.

I have not had to disable the lm(4) sensor as advised previously for
the workaround and reached the conclusion this problem is not caused
by the driver itself in the first place, but by a buggy BMC firmware.

For this it is advisable to contact again the technical support at
Supermicro and ask them for a reliable BMC firmware update which does
not manifest the problem.

After running for a longer period (non specific or deterministic, above
30min), the sensors start to display wrong (missing) values and can not
provide data points to the BMC firmware.  This is seen both in IPMI
direct and networked access and in the web based management interface.
At this point, a reboot would get the system unable to boot manifesting
the dreaded long beep.  Only a power cycle of mains (power supply
breaker or power distribution unit) for a couple of seconds unblocks
the system and it is capable of successfully booting up again.  This
however totally undermines the remote control capabilities of the
system effectively turning it into a continuous source of remote
management manual reboot requests via intervention events for mains
power cycle (stop and start).

The workaround for this is to reset the BMC before attempting to reboot
the system, and it works over the network directly over IPMI and also
via the web based BMC interface likewise.  This only reboots the IPMI
controller (not the system) and its embedded firmware, then after a
couple of minutes the sensors poll actual correct data and display it
properly.  At this point a system reboot issued succeeds as expected and
everything the system boots up and works properly, until some non
specific longer time passes again (from 1h to days) and the BMC
controller gets stuck again (with a certainty it gets stuck) for which
the indication is missing sensors data and no reboot capability with
the long beep indication.

This is NOT OS specific unless the driver polling the sensors causes
the sensors sub-system in the embedded controller OS to crash, the only
factor affecting it so far is found to be the time running the system
without mains power cycle.  It is a flaw of the BMC firmware for which
the solution for sure is to demand an updated firmware from Supermicro
without this fault.  It would help if more people voice their concerns
over this so an updated BMC firmware is issued from Supermicro technical
support and published on their web site.

Here is how it looks when the BMC is stuck:

$ ipmi-sensor 
System Temp  | no reading| ns
CPU Temp | no reading| ns
CPU FAN  | no reading| ns
SYS FAN  | no reading| ns
CPU Vcore| no reading| ns
Vichcore | no reading| ns
+3.3VCC  | no reading| ns
VDIMM| no reading| ns
+5 V | no reading| ns
+12 V| no reading| ns
+3.3VSB  | no reading| ns
VBAT | no reading| ns
Chassis Intru| no reading| ns
PS Status| 0x00  | ok

$ ipmi-sensor-detail  
System Temp  | na || na| na| na| na 
   | na| na| na
CPU Temp | na || na| na| na| na 
   | na| na| na
CPU FAN  | na || na| na| na| na 
   | na| na| na
SYS FAN  | na || na| na| na| na 
   | na| na| na
CPU Vcore| na || na| na| na| na 
   | na| na| na
Vichcore | na || na| na| na| na 
   | na| na| na
+3.3VCC  | na || na| na| na| na 
   | na| na| na
VDIMM| na || na| na| na| na 
   | na| na| na
+5 V | na || na| na| na| na 
   | na| na| na
+12 V| na || na| na| na| na 
   | na| na| na
+3.3VSB  | na || na| na| na

Re: requesting help working around boot failures with supermicro atom board

[Jack Peirce]

I have a great relationship with some SuperMicro engineers, if others can
provide part #'s and firmare/bios revs, I can bring this up with them.

From: owner-m...@openbsd.org
 on behalf of li...@wrant.com 
Sent:
Wednesday, October 21, 2015 8:50 PM
To: misc@openbsd.org
Subject: Re:
requesting help working around boot failures with supermicro atom board
Synopsis: if sensors show missing data then reset the BMC unit before
rebooting the system to prevent unable to boot long beep issue.

I found a
reliably reproducible workaround for this problem retaining
control continuity
without the need to trip the mains breaker.  This
entirely prevents the long
beep issue and allows the system to be used
in headless remote environments
without ensuring remote mains power
cycle capability and/or remote hands
intervention.

I have not had to disable the lm(4) sensor as advised
previously for
the workaround and reached the conclusion this problem is not
caused
by the driver itself in the first place, but by a buggy BMC firmware.
For this it is advisable to contact again the technical support at
Supermicro
and ask them for a reliable BMC firmware update which does
not manifest the
problem.

After running for a longer period (non specific or deterministic,
above
30min), the sensors start to display wrong (missing) values and can not
provide data points to the BMC firmware.  This is seen both in IPMI
direct and
networked access and in the web based management interface.
At this point, a
reboot would get the system unable to boot manifesting
the dreaded long beep.
Only a power cycle of mains (power supply
breaker or power distribution unit)
for a couple of seconds unblocks
the system and it is capable of successfully
booting up again.  This
however totally undermines the remote control
capabilities of the
system effectively turning it into a continuous source of
remote
management manual reboot requests via intervention events for mains
power cycle (stop and start).

The workaround for this is to reset the BMC
before attempting to reboot
the system, and it works over the network directly
over IPMI and also
via the web based BMC interface likewise.  This only
reboots the IPMI
controller (not the system) and its embedded firmware, then
after a
couple of minutes the sensors poll actual correct data and display it
properly.  At this point a system reboot issued succeeds as expected and
everything the system boots up and works properly, until some non
specific
longer time passes again (from 1h to days) and the BMC
controller gets stuck
again (with a certainty it gets stuck) for which
the indication is missing
sensors data and no reboot capability with
the long beep indication.

This is
NOT OS specific unless the driver polling the sensors causes
the sensors
sub-system in the embedded controller OS to crash, the only
factor affecting
it so far is found to be the time running the system
without mains power
cycle.  It is a flaw of the BMC firmware for which
the solution for sure is to
demand an updated firmware from Supermicro
without this fault.  It would help
if more people voice their concerns
over this so an updated BMC firmware is
issued from Supermicro technical
support and published on their web site.
Here is how it looks when the BMC is stuck:

$ ipmi-sensor
System Temp  |
no reading| ns
CPU Temp | no reading| ns
CPU FAN
| no reading| ns
SYS FAN  | no reading| ns
CPU Vcore
| no reading| ns
Vichcore | no reading| ns
+3.3VCC
| no reading| ns
VDIMM| no reading| ns
+5 V
| no reading| ns
+12 V| no reading| ns
+3.3VSB
| no reading| ns
VBAT | no reading| ns
Chassis
Intru| no reading| ns
PS Status| 0x00  | ok

$
ipmi-sensor-detail
System Temp  | na || na| na
| na| na| na| na| na
CPU Temp | na
|| na| na| na| na| na| na
| na
CPU FAN  | na || na| na| na
| na| na| na| na
SYS FAN  | na |
| na| na| na| na| na| na| na
CPU
Vcore| na || na| na| na| na
| na| na| na
Vichcore | na || na
| na| na| na| na| na| na
+3.3VCC
| na || na| na| na| na| na
| na| na
VDIMM| na || na| na
| na| na| na| na| na
+5 V | na
|| na| na| na| na| na| na
| na
+12 V| na || na| na| na
| na| na| na  

Re: PC Engine APU.1D4 installation stopper.

[Jonathan Gray]

On Tue, Oct 20, 2015 at 02:12:35PM +0200, Mark Kettenis wrote:
> > > For i386/amd64 you have to tell boot you want serial output
> > > either at the boot prompt or via boot.conf.
> > > 
> > > stty com0 115200
> > > set tty com0
> > 
> > 
> > OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > RTC BIOS diagnostic error
> > ff
> > real mem = 4246003712 (4049MB)
> > avail mem = 4113428480 (3922MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf16d820 (7 entries)
> > bios0: vendor coreboot version "4.0" date 09/08/2014
> > bios0: PC Engines APU
> > acpi0 at bios0: rev 0
> > acpi0: sleep states S0 S1 S3 S4 S5
> > acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT
> 
> Since the ACPI BIOS provides a SPCR table, we can actually tell that
> we're on a serial console.  Shouldn't be too difficult to add support
> to the kernel for this, although we'd probably miss the first part of
> the dmesg if we do that.  So a better place would be the bootloader,
> but then we'd have to add code to find and parse acpi tables there.
> And there might be space issues there.
> 

Interesting.  On a dell server from 2007 booted via glass console
the table is present with the address and baud set to 0.  I guess
that changes if I were to configure the bios to put the console
on serial.

On the other hand I have a machine from 2009 that only has serial
and there is no SPCR table "acpi0: tables DSDT FACP APIC MCFG HPET".

It seems there can be a DBGP/DBG2 table in some cases that indicates
if debug ports are available on serial/firewire/usb/network as well.

[028h 0040  12] Serial Port Register : [Generic Address Structure]
[028h 0040   1] Space ID : 00 [SystemMemory]
[029h 0041   1]Bit Width : 00
[02Ah 0042   1]   Bit Offset : 00
[02Bh 0043   1] Encoded Access Width : 00 [Undefined/Legacy]
[02Ch 0044   8]  Address : 

[034h 0052   1]   Interrupt Type : 03
[035h 0053   1]  PCAT-compatible IRQ : 04
[036h 0054   4]Interrupt : 0004
[03Ah 0058   1]Baud Rate : 00
[03Bh 0059   1]   Parity : 00
[03Ch 0060   1]Stop Bits : 01
[03Dh 0061   1] Flow Control : 02
[03Eh 0062   1]Terminal Type : 01
[04Ch 0076   1] Reserved : 00
[040h 0064   2]PCI Device ID : 
[042h 0066   2]PCI Vendor ID : 
[044h 0068   1]  PCI Bus : 00
[045h 0069   1]   PCI Device : 00
[046h 0070   1] PCI Function : 00
[047h 0071   4]PCI Flags : 
[04Bh 0075   1]  PCI Segment : 00
[04Ch 0076   4] Reserved : 

Re: how to partition routing namespace

[Stuart Henderson]

On 2015-10-21, Geoff Steckel  wrote:
> They gave me 2001:::0111::0002 as my tunnel endpoint and
> 2001:::0111::1 as their end and router address.
> They gave me 2001:::8111::/64 for my address space.
> Note that the tunnel endpoint addresses are globally routeable.
>
> So... if I say "route add -inet6 default ...0111::1",
> then the source address of any IPv6 connection from this machine
> defaults to 0111::2
>
> This isn't useful. I must use an address in 8xxx::/64
> for functions on the gateway machine.

Try adding 'pltime 0' to the ifconfig line where you configure the
tunnel endpoint address.

The 2001:...811 address can be configured on any interface.

recompile packages to include base / libressl errata?

[Tim Kuijsten]

I'm following 5.7-stable but I'm not confident if my dovecot server has 
the recent OBJ_obj2txt fix (019) for it's tls connections. Should I 
start using the dovecot port and recompile instead of using the dovecot 
package in order to get the fix? I'm using dovecot with IMAP over tls.


Furthermore, is ldd and the knowledge if a package uses tls enough to 
determine if a package has to be recompiled or not? If so, am I correct 
to conclude that postfix does not have to be recompiled because it 
dynamically links libssl.so.32.0 and libcrypto.so.32.0?


-Tim

Re: Diffie-Helman issue?

[Kimmo Paasiala]

On Tue, Oct 20, 2015 at 7:43 PM, Giancarlo Razzolini
 wrote:
> Em 20-10-2015 10:25, Kimmo Paasiala escreveu:
>> Someone correct me if I'm wrong but as far as I know the prime numbers
>> used in DH group exchange are not secret but must be known by everyone
>> (and couple other parameters are also public) for the key exchange to
>> be possible in the first place.
>
> How is that different from pre-shared keys then? You can generate your
> own primes. If you don't the defaults get used. And it are these
> defaults that can be precomputed, because almost everyone do not
> generate their own dh parameters.
>
>>  What NSA can do is to perform a
>> "pre-calculation" over the possible key exchange results and the
>> danger is in that too small DH group can be covered sufficiently by
>> them to be able to crack DH exchange on the fly.
>>
>> Hence the recommendation to increase the size of the group size used.
>
> The OpenSSH project regenerates the moduli file every release, AFAIK.
> And the DH parameters for IPSec on OpenBSD just got bumped to 3072 if
> I'm not mistaken. Bottom line, generate your own (big) parameters and
> keep them as safe as possible. The dh parameters are even more important
> than your private key. Specially if you do not change it after a key
> replacement.
>
> Cheers,
> Giancarlo Razzolini
>
>
>

There are probably some implementation details and the plain DH
exchange is not used alone because it's totally insecure against man
in the middle attacks but the basics should be the same, the prime
numbers are not keys but fixed parameters to the DH exchange
algorithm. Maybe someone who knows more can chime in?

-Kimmo

Re: bgpd+ospfd configuration question

[Claudio Jeker]

On Tue, Oct 20, 2015 at 11:07:12AM -0400, John E.P. Hynes wrote:
> Hi list,
> 
> I've read through the docs and Claudio's guide, but something isn't
> clear to me I'm hoping to get some direction on:
> 
> I am about to multihome.  My uplinks to my ISPs terminate on different
> OpenBSD routers.  The class C network behind them includes one internal
> OpenBSD gateway performing NAT for connections leaving the internal
> private network.
> 
> My understanding is that I would configure OpenBGPD on the two border
> routers with iBGP between them, like this:
> 
> /etc/bgpd.conf
> 
> # Global Config
> AS MyASN
> router-id 1.2.3.4
> 
> # Announce Our Network Space
> network 1.2.3/24
> 
> # Neighbor Config
> neighbor 9.8.7.6 {
>   descr   "My ISP 1"
>   remote-as TheirASN
> }
> 
> # iBGP
> group IBGP {
>   remote-as MyASN
>   neighbor 1.2.3.5 {
>   descr   "MyOtherBorderGateway"
>   }
> }
> 
> ...Essentially, since no host in my public network would be aware of
> which border gateway to leave through, I need an IGP such as OpenOSPFd
> as well.  Something like this on the border gateways:
> 
> /etc/ospfd.conf
> 
> # Global Config
> router-id 0.0.0.1
> redistribute connected
> 
> # Areas
> area 0.0.0.0 {
>   auth-type crypt
>   auth-md 1 "SomePW"
>   auth-md 2 "SomeDifferentPW"
>   auth-md-keyid 1
> 
>   # Main Link (DMZ)
>   interface em1
> }
> 
> ...and then something like this on all hosts on my public network,
> including the NAT firewall:
> 
> /etc/ospfd.conf
> 
> # Global Config
> router-id 0.0.0.3
> 
> # Areas
> area 0.0.0.0 {
>   auth-type crypt
>   auth-md 1 "SomePW"
>   auth-md 2 "SomeDifferentPW"
>   auth-md-keyid 1
> 
>   # Main Link (DMZ)
>   interface em1
> }
> 
> 
> My questions are:
> 
> 1) Claudio's guide suggests to me that iBGP needs to be run on the NAT
> firewall as well, but I don't understand *why* that would be necessary
> and I think I'm mis-reading it.  Clarification please?

By running BGP on the internal FW allows you to send out the traffic to
the correct broder router and so you get better control over which path
you reach the internet.
 
> 2) Do I really want "redistribute connected" in the ospfd.conf on the
> border routers, or "redistribute default"?
> 

If you feed the BGP table to your FW than you most probably need
redistribute connected. In such a simple setup as yours you can also skip
using OSPF and just use "set nexthop self" in bgpd since all your routers
& firewalls are directly connected.

In short the IGP (OSPF) is required for incoming traffic to find its
destination in your network whereas iBGP is required to take the optimal
way out of your network.

-- 
:wq Claudio

Error messages in dmesg output about intel_dp_set_link_train and i915_write32

[Jean-Philippe Provost]

Hi guys,

I just upgraded my laptop from 5.7 to 5.8 and I notice error messages in my
dmesg output.

Any ideas?


OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4178116608 (3984MB)
avail mem = 4047597568 (3860MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec720 (45 entries)
bios0: vendor Dell Inc. version "A03" date 05/27/2014
bios0: Dell Inc. Inspiron 5748
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT ASF! LPIT SSDT SLIC SSDT SSDT MCFG HPET
SSDT SSDT MSDM DMAR CSRT
acpi0: wakeup devices PXSX(S4) RP01(S3) PXSX(S4) RP02(S3) PXSX(S4) RP03(S3)
PXSX(S4) RP04(S3) PXSX(S4) RP05(S3) PXSX(S4) RP06(S3) PXSX(S4) RP07(S3)
PXSX(S4) RP08(S3) [...]
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) Core(TM) i3-4030U CPU @ 1.90GHz, 1895.86 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,
BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,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.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i3-4030U CPU @ 1.90GHz, 1895.61 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,
BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i3-4030U CPU @ 1.90GHz, 1895.61 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,
BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i3-4030U CPU @ 1.90GHz, 1895.61 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,
BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 40 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (RP01)
acpiprt2 at acpi0: bus 6 (RP03)
acpiprt3 at acpi0: bus 7 (RP04)
acpiprt4 at acpi0: bus -1 (PEG0)
acpiprt5 at acpi0: bus -1 (PEG1)
acpiprt6 at acpi0: bus -1 (PEG2)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: !C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: !C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: !C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: !C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpitz0 at acpi0: critical temperature is 99 degC
acpibat0 at acpi0: BAT0 model "DELL FW1MN31" serial 12909 type LION oem
"SMP-SDI2.8"
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SBTN
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: Enhanced SpeedStep 1895 MHz: speeds: 1900, 1800, 1700, 1600, 1500,
1400, 1300, 1200, 1100, 1000, 900, 800, 779 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 4G Host" rev 0x0b
vga1 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x0b
intagp at vga1 not configured
inteldrm0 at vga1
drm0 at inteldrm0
*error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register before
writing to 10*
*error: [drm:pid0:intel_dp_set_link_train] *ERROR* Timed out waiting for DP
idle patterns*
*error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register before
writing to 64040*
inteldrm0: 1600x900
wsdisplay0 at vga1 mux 1: console (std, vt100 

Re: pledge(2) problems on 18/x/ octeon snapshot

[Kim Zeitler]

Might be a stupid question, but I haven't found an answer to it yet
- how does one update to a new snapshot/kernel on an octeon system?


boot bsd.rd and select upgrade in the installer. (i hope.)


I'm afraid this is not as simple as this, yet. You will also need to
copy your kernel to the fat16 partition created during the install,
since this is the only filesystem #$%^@# u-boot can read.


Wouldn't this be a sensible addition to the INSTALL.octeon readme?

Something along the lines of:

--- INSTALL.octeon.new  Wed Oct 21 09:29:17 2015
+++ INSTALL.octeon  Wed Oct 21 09:34:50 2015
@@ -816,7 +816,8 @@
 helper script, since all components of your system may not function
 correctly until your files in `/etc' are updated.

-
+Note: Due to the limitations of U-Boot scripts/bootloader you need to
+copy your new bsd and bsd.rd to the MSDOS partition.

 Getting source code for your OpenBSD System: