Re: Hang since inteldrm works when stopping X or running xrandr

[Mark Kettenis]

> Date: Wed, 12 Jul 2017 21:14:47 +0200
> From: Frank Groeneveld 
> 
> Mark Kettenis  schreef op 12 juli 2017 19:50:50 CEST:
> >> Date: Wed, 12 Jul 2017 10:08:42 +0200 (CEST)
> >> From: fr...@frankgroeneveld.nl
> >> 
> >> >Synopsis: System hangs when X is stopped or xrandr is run after
> >disabling builtin screen
> >> >Category: system
> >> >Environment:
> >>System  : OpenBSD 6.1
> >>Details : OpenBSD 6.1-current (GENERIC.MP) #93: Thu Jul  6
> >15:41:21 MDT 2017
> >>
> >dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> >> 
> >>Architecture: OpenBSD.amd64
> >>Machine : amd64
> >> >Description:
> >>Since the inteldrm update I now have a much better working display
> >on this system, thanks!
> >>I'm only experiencing one problem. When I have attached an external
> >monitor to my laptop,
> >>I disable the builtin screen using: xrandr --output eDP-1 --off
> >>After that, the whole systems hangs when I shutdown X (halt -p or
> >pkill X) or when I run any xrandr command
> >> >How-To-Repeat:
> >>xrandr --output eDP-1 --off
> >>pkill X
> >> >Fix:
> >>I haven't found any workarounds
> >
> >Unfortunately I don't have a hardware setup that could reproduce this.
> 
> Is there anything I can try or send you to debug it?

Unless you have a serial console (possibly through Intel AMT), there's
probably not much you can do yourself.  Given the CPU model, I don't
think your machine has Intel AMT support.

If you have a displayport (male) to mini displayport (female) convert
or a displayport to VGA converter lying around I might be able to test
this myself.

Re: static PIE & corrupted trace

[Mark Kettenis]

> Date: Wed, 12 Jul 2017 19:54:11 +0200
> From: Martin Pieuchot 
> 
> On 12/07/17(Wed) 19:06, Mark Kettenis wrote:
> > > Date: Tue, 11 Jul 2017 14:45:36 +0200
> > > From: Martin Pieuchot 
> > > 
> > > Binaries linked with '-static -pie' produce unusable core dumps at least
> > > on amd64.  This is a real problem to debug isakmpd(8)/iked(8) crashing on
> > > production machines.
> > 
> > Did you try using the gdb from ports?
> 
> It works with egdb.  Any idea of the amount of effort to backport the
> fix?

I think I decided that it was too much effort.

Re: static PIE & corrupted trace

[Martin Pieuchot]

On 12/07/17(Wed) 19:06, Mark Kettenis wrote:
> > Date: Tue, 11 Jul 2017 14:45:36 +0200
> > From: Martin Pieuchot 
> > 
> > Binaries linked with '-static -pie' produce unusable core dumps at least
> > on amd64.  This is a real problem to debug isakmpd(8)/iked(8) crashing on
> > production machines.
> 
> Did you try using the gdb from ports?

It works with egdb.  Any idea of the amount of effort to backport the
fix?

Re: Hang since inteldrm works when stopping X or running xrandr

[Mark Kettenis]

> Date: Wed, 12 Jul 2017 10:08:42 +0200 (CEST)
> From: fr...@frankgroeneveld.nl
> 
> >Synopsis:System hangs when X is stopped or xrandr is run after disabling 
> >builtin screen
> >Category:system
> >Environment:
>   System  : OpenBSD 6.1
>   Details : OpenBSD 6.1-current (GENERIC.MP) #93: Thu Jul  6 15:41:21 
> MDT 2017
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   Since the inteldrm update I now have a much better working display on 
> this system, thanks!
>   I'm only experiencing one problem. When I have attached an external 
> monitor to my laptop,
>   I disable the builtin screen using: xrandr --output eDP-1 --off
>   After that, the whole systems hangs when I shutdown X (halt -p or pkill 
> X) or when I run any xrandr command
> >How-To-Repeat:
>   xrandr --output eDP-1 --off
>   pkill X
> >Fix:
>   I haven't found any workarounds

Unfortunately I don't have a hardware setup that could reproduce this.

Re: static PIE & corrupted trace

[Mark Kettenis]

> Date: Tue, 11 Jul 2017 14:45:36 +0200
> From: Martin Pieuchot 
> 
> Binaries linked with '-static -pie' produce unusable core dumps at least
> on amd64.  This is a real problem to debug isakmpd(8)/iked(8) crashing on
> production machines.

Did you try using the gdb from ports?

> With the diff below, I trigger a NULL-dereference in ntpd(8).  When
> compiled with '-static -pie' I obtain the following trace:
> 
>   # gdb /sbin/ntpd /var/crash/ntpd/34857.core
>   #0  0x10249cd0ca32 in ?? ()
>   (gdb) bt
>   #0  0x10249cd0ca32 in ?? ()
>   #1  0x10276a411300 in ?? ()
>   #2  0x10249d0e9540 in ?? ()
>   #3  0x4000 in ntp_main (nconf=0x3, pw=0x8f5, argc=Variable 
> "argc" is not available.) at /usr/src/usr.sbin/ntpd/ntp.c:215
>   #4  0x38efae2bb7a38b39 in ?? ()
>   #5  0x10270b35ec00 in ?? ()
>   #6  0x16f6 in dispatch_imsg (lconf=0x38efae2bb7a38b39, 
> argc=-1664058825, argv=0x10270b35ec00) at /usr/src/usr.sbin/ntpd/ntpd.c:393
>   #7  0x5959fe2b in ?? ()
>   #8  0x372f8819 in ?? ()
>   #9  0x5959a297 in ?? ()
>   #10 0x in ?? ()
> 
> When compiled with '-static -nopie' or by default, I obtain the correct
> trace:
> 
>   # gdb /sbin/ntpd /var/crash/ntpd/94479.core
>   (gdb) bt
>   #0  constraint_query (cstr=0x0) at /usr/src/usr.sbin/ntpd/constraint.c:151
>   #1  0x0040413c in ntp_main (nconf=Variable "nconf" is not 
> available.) at /usr/src/usr.sbin/ntpd/ntp.c:336
>   #2  0x00402079 in main (argc=0, argv=Variable "argv" is not 
> available.) at /usr/src/usr.sbin/ntpd/ntpd.c:193
> 
> 
> Index: Makefile
> ===
> RCS file: /cvs/src/usr.sbin/ntpd/Makefile,v
> retrieving revision 1.16
> diff -u -p -r1.16 Makefile
> --- Makefile  20 Nov 2015 18:53:42 -  1.16
> +++ Makefile  11 Jul 2017 12:33:24 -
> @@ -16,4 +16,5 @@ DPADD+= ${LIBUTIL} ${LIBCRYPTO} ${LIBSSL
>  LINKS=   ${BINDIR}/ntpd ${BINDIR}/ntpctl
>  MAN= ntpd.8 ntpd.conf.5 ntpctl.8
>  
> +LDSTATIC=${STATIC}
>  .include 
> Index: ntp.c
> ===
> RCS file: /cvs/src/usr.sbin/ntpd/ntp.c,v
> retrieving revision 1.146
> diff -u -p -r1.146 ntp.c
> --- ntp.c 30 May 2017 23:30:48 -  1.146
> +++ ntp.c 11 Jul 2017 12:28:50 -
> @@ -331,6 +331,8 @@ ntp_main(struct ntpd_conf *nconf, struct
>   ctls = i;
>  
>   TAILQ_FOREACH(cstr, >constraints, entry) {
> + if (arc4random() % 2)
> + cstr = NULL;
>   if (constraint_query(cstr) == -1)
>   continue;
>   }
> 
> 

Re: regression using vncviewer (net/ssvnc) on inteldrm

[Stuart Henderson]

On 2017/07/12 07:46, Paul de Weerd wrote:
> Note that vncviewer was never really blazing fast, but at least it was
> workable.  Obviously, vncviewer is doing something weird because other
> programs don't seem affected by whatever changed (I'm guessing it's
> the switch to using the modesetting driver on my hardware).

Confirmed here. Switching back to the intel driver fixes it:

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

inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics P4600" rev 0x06

OpenBSD 6.1-current (GENERIC.MP) #77: Sun Jul  2 19:57:16 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8477265920 (8084MB)
avail mem = 8214556672 (7834MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec400 (90 entries)
bios0: vendor Dell Inc. version "A12" date 05/11/2017
bios0: Dell Inc. PowerEdge T20
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG SSDT 
ASF! DMAR
acpi0: wakeup devices UAR1(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) 
RP03(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) 
XHC_(S4) HDEF(S4) [...]
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) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3193.09 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 3193087240 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3192.60 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3192.60 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3192.60 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP02)
acpiprt3 at acpi0: bus 4 (RP03)
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: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpitz0 at acpi0: critical temperature is 105 degC
acpitz1 at acpi0: critical temperature is 105 degC
"INT3F0D" at acpi0 not configured
"PNP0501" at acpi0 not configured
acpibtn0 at acpi0: PWRB
"PNP0C14" at acpi0 not configured
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: Enhanced SpeedStep 3193 MHz: speeds: 3201, 3200, 3000, 2900, 2700, 2500, 
2300, 2200, 2000, 1800, 1700, 1500, 1300, 1100, 1000, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Xeon E3-1200 v3 Host" rev 0x06
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics P4600" 

Re: ifconfig carpX a.b.c.d -> arpresolve: route contains no arp information

[Remi Locherer]

On 2017-07-12 11:34, Martin Pieuchot wrote:

On 11/07/17(Tue) 13:55, Remi Locherer wrote:

On 2017-07-11 13:23, Remi Locherer wrote:
> On 2017-07-11 11:32, Martin Pieuchot wrote:
> > Hello and thanks for the detailed bug report.
> >
> > On 10/07/17(Mon) 17:52, Remi Locherer wrote:
> > > >Synopsis:ifconfig carpX a.b.c.d -> arpresolve: route contains no arp 
information
> > > >Category:kernel
> > > >Environment:
> > >  System  : OpenBSD 6.1
> > >  Details : OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr  1 13:45:56
> > > MDT 2017
> > >
> > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > >
> > >  Architecture: OpenBSD.amd64
> > >  Machine : amd64
> > >
> > > >Description:
> > >  After reconfiguring an existing carp interface with the same ip
> > > the gateway stops forwarding traffic (forwarding to directly
> > > connected hosts still works).
> > > In /var/log/messages this can be found:
> > >
> > > Jul 10 12:54:27 gw1 /bsd: arpresolve: 10.0.20.10: route contains
> > > no arp information
> >
> > How does the routing table looks like when you see such message?  And
> > the ARP table?


Somehow a route attached to vio2 is removed from the routing table when
you modify carp2.

Could you run 'route monitor' then do 'ifconfig carp2 delete'?  This
should hopefully reproduce the problem and the output of 'route 
monitor'

will give us more infos.


This is the output captured on 6.1-stable:

gw1# route monitor
got message of size 144 on Wed Jul 12 16:02:07 2017
RTM_DELETE: Delete Route: len 144, priority 3, table 0, ifidx 3, pid: 0, 
seq 0, errno 0

flags:
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: 
 10.0.20.10 08:00:27:6b:9a:c1
got message of size 192 on Wed Jul 12 16:02:07 2017
RTM_DELETE: Delete Route: len 192, priority 19, table 0, ifidx 7, pid: 
0, seq 0, errno 0

flags:
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: 
 10.0.20.0 10.0.20.1 255.255.255.0 00:00:5e:00:01:17 10.0.20.1
got message of size 176 on Wed Jul 12 16:02:07 2017
RTM_DELETE: Delete Route: len 176, priority 1, table 0, ifidx 7, pid: 0, 
seq 0, errno 0

flags:
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: 
 10.0.20.255 10.0.20.1 00:00:5e:00:01:17 10.0.20.1
got message of size 192 on Wed Jul 12 16:02:07 2017
RTM_DELETE: Delete Route: len 192, priority 1, table 0, ifidx 7, pid: 0, 
seq 0, errno 0

flags:
fmask:
use:0   mtu:0expire:0
locks:  inits:
sockaddrs: 
 10.0.20.1 00:00:5e:00:01:17 00:00:5e:00:01:17 10.0.20.1
got message of size 96 on Wed Jul 12 16:02:07 2017
RTM_DELADDR: address being removed from iface: len 96, metric 0, flags:
sockaddrs: 
 255.255.255.0 00:00:5e:00:01:17 10.0.20.1 10.0.20.255
got message of size 168 on Wed Jul 12 16:02:08 2017
RTM_IFINFO: iface status change: len 168, if# 7, name: carp2, link: 
invalid, mtu: 1500, flags:

Hang since inteldrm works when stopping X or running xrandr

[frank]

>Synopsis:  System hangs when X is stopped or xrandr is run after disabling 
>builtin screen
>Category:  system
>Environment:
System  : OpenBSD 6.1
Details : OpenBSD 6.1-current (GENERIC.MP) #93: Thu Jul  6 15:41:21 
MDT 2017
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
Since the inteldrm update I now have a much better working display on 
this system, thanks!
I'm only experiencing one problem. When I have attached an external 
monitor to my laptop,
I disable the builtin screen using: xrandr --output eDP-1 --off
After that, the whole systems hangs when I shutdown X (halt -p or pkill 
X) or when I run any xrandr command
>How-To-Repeat:
xrandr --output eDP-1 --off
pkill X
>Fix:
I haven't found any workarounds


dmesg:
OpenBSD 6.1-current (GENERIC.MP) #93: Thu Jul  6 15:41:21 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17028767744 (16239MB)
avail mem = 16506888192 (15742MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xd705d000 (65 entries)
bios0: vendor LENOVO version "R02ET56W (1.29 )" date 05/02/2017
bios0: LENOVO 20F6CTO1WW
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT ECDT HPET APIC MCFG SSDT SSDT DBGP DBG2 
BOOT BATB SSDT SSDT MSDM DMAR ASF! FPDT UEFI
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP8(S4) XHCI(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz, 2592.00 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 259200 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
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) i7-6500U CPU @ 2.50GHz, 2592.00 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,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) i7-6500U CPU @ 2.50GHz, 2592.00 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,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) i7-6500U CPU @ 2.50GHz, 2592.00 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus 2 (EXP1)
acpiprt5 at acpi0: bus 4 (EXP3)
acpiprt6 at acpi0: bus -1 (EXP4)
acpiprt7 at acpi0: bus -1 (EXP5)
acpiprt8 at acpi0: bus -1 (EXP8)
acpicpu0 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), 
C1(1000@1 mwait.1), 

Re: ifconfig carpX a.b.c.d -> arpresolve: route contains no arp information

[Martin Pieuchot]

On 11/07/17(Tue) 13:55, Remi Locherer wrote:
> On 2017-07-11 13:23, Remi Locherer wrote:
> > On 2017-07-11 11:32, Martin Pieuchot wrote:
> > > Hello and thanks for the detailed bug report.
> > > 
> > > On 10/07/17(Mon) 17:52, Remi Locherer wrote:
> > > > >Synopsis:  ifconfig carpX a.b.c.d -> arpresolve: route contains no 
> > > > >arp information
> > > > >Category:  kernel
> > > > >Environment:
> > > > System  : OpenBSD 6.1
> > > > Details : OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr  1 13:45:56
> > > > MDT 2017
> > > > 
> > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > > 
> > > > Architecture: OpenBSD.amd64
> > > > Machine : amd64
> > > > 
> > > > >Description:
> > > > After reconfiguring an existing carp interface with the same ip
> > > > the gateway stops forwarding traffic (forwarding to directly
> > > > connected hosts still works).
> > > > In /var/log/messages this can be found:
> > > > 
> > > > Jul 10 12:54:27 gw1 /bsd: arpresolve: 10.0.20.10: route contains
> > > > no arp information
> > > 
> > > How does the routing table looks like when you see such message?  And
> > > the ARP table?

Somehow a route attached to vio2 is removed from the routing table when
you modify carp2.

Could you run 'route monitor' then do 'ifconfig carp2 delete'?  This
should hopefully reproduce the problem and the output of 'route monitor'
will give us more infos.