Re: sysctl(3): HW_PERFPOLICY
On Thu, Mar 12, 2015 at 08:42:31AM +0100, Theo Buehler wrote: I am confused by the new documentation of HW_PERFPOLICY. Is this bound to change? Looking at the function sysctl_hwperfpolicy() in sys/kern/sched_bsd.c, I think the following is more accurate, although I don't know what has to go wrong that the string is actually set to `unknown'. For consistency with the rest of the manual page, I used .Dq instead of .Qq. $ apm -L $ sysctl hw.perfpolicy hw.perfpolicy=manual $ apm -A $ sysctl hw.perfpolicy hw.perfpolicy=auto $ apm -H $ sysctl hw.perfpolicy hw.perfpolicy=high i couldn;t actually work out how to extract the possible values, so i asked tedu. in his defense, he didn;t say my diff was correct - only that it was good enough. perhaps his own perfpolicy was set to high ;) i think the unknown will be a catchall for errors, and we shouldn;t suggest to users that they can set it. so my suggestion is below. i'll commit later if no one has yelled too much. jmc Index: sysctl.3 === RCS file: /cvs/src/lib/libc/gen/sysctl.3,v retrieving revision 1.248 diff -u -r1.248 sysctl.3 --- sysctl.311 Mar 2015 19:42:38 - 1.248 +++ sysctl.312 Mar 2015 08:20:10 - @@ -332,9 +332,10 @@ .It Dv HW_PERFPOLICY The performance policy for power management. Can be one of -.Qq manual +.Dq manual , +.Dq automatic , or -.Qq automatic . +.Dq high . .It Dv HW_PHYSMEM The total physical memory, in bytes. This variable is deprecated; use @@ -377,6 +378,10 @@ .It Dv HW_SETPERF Current CPU performance .Pq percentage . +It is only modifiable if +.Dv HW_PERFPOLICY +is set to +.Dq manual . .It Dv HW_USERMEM The amount of available non-kernel memory in bytes. This variable is deprecated; use
sysctl(3): HW_PERFPOLICY
I am confused by the new documentation of HW_PERFPOLICY. Is this bound to change? Looking at the function sysctl_hwperfpolicy() in sys/kern/sched_bsd.c, I think the following is more accurate, although I don't know what has to go wrong that the string is actually set to `unknown'. For consistency with the rest of the manual page, I used .Dq instead of .Qq. $ apm -L $ sysctl hw.perfpolicy hw.perfpolicy=manual $ apm -A $ sysctl hw.perfpolicy hw.perfpolicy=auto $ apm -H $ sysctl hw.perfpolicy hw.perfpolicy=high Index: lib/libc/gen/sysctl.3 === RCS file: /cvs/src/lib/libc/gen/sysctl.3,v retrieving revision 1.248 diff -u -p -r1.248 sysctl.3 --- lib/libc/gen/sysctl.3 11 Mar 2015 19:42:38 - 1.248 +++ lib/libc/gen/sysctl.3 12 Mar 2015 07:32:20 - @@ -332,9 +332,11 @@ The software page size. .It Dv HW_PERFPOLICY The performance policy for power management. Can be one of -.Qq manual +.Dq manual , +.Dq auto , +.Dq high , or -.Qq automatic . +.Dq unknown . .It Dv HW_PHYSMEM The total physical memory, in bytes. This variable is deprecated; use @@ -377,6 +379,9 @@ The serial number of the machine. .It Dv HW_SETPERF Current CPU performance .Pq percentage . +Only modifiable if +.Dv HW_PERFPOLICY is set to +.Dq manual . .It Dv HW_USERMEM The amount of available non-kernel memory in bytes. This variable is deprecated; use
vlan+bridge stack integration
I'm progressively changing how pseudo-drivers are plugged into our
network stack with the goal to turning them MP-safe.
The diff below is a simple refactoring and should not introduce any
behavior change. It moves a bridge-specific vlan-related chunk of
code into the bridge(4) driver.
I'd like to hear from people with a simple, complicated or even weird
bridge+vlan setup :)
I also appreciate comments and oks!
Index: net/if_bridge.c
===
RCS file: /cvs/src/sys/net/if_bridge.c,v
retrieving revision 1.232
diff -u -p -r1.232 if_bridge.c
--- net/if_bridge.c 6 Feb 2015 22:10:43 - 1.232
+++ net/if_bridge.c 11 Mar 2015 14:32:05 -
@@ -117,6 +117,8 @@ voidbridge_localbroadcast(struct bridge
struct ether_header *, struct mbuf *);
void bridge_span(struct bridge_softc *, struct ether_header *,
struct mbuf *);
+struct mbuf *bridge_dispatch(struct bridge_iflist *, struct ifnet *,
+struct ether_header *, struct mbuf *);
void bridge_stop(struct bridge_softc *);
void bridge_init(struct bridge_softc *);
intbridge_bifconf(struct bridge_softc *, struct ifbifconf *);
@@ -1299,10 +1301,10 @@ struct mbuf *
bridge_input(struct ifnet *ifp, struct ether_header *eh, struct mbuf *m)
{
struct bridge_softc *sc;
- int s;
- struct bridge_iflist *ifl, *srcifl;
- struct arpcom *ac;
- struct mbuf *mc;
+ struct bridge_iflist *ifl;
+#if NVLAN 0
+ uint16_t etype = ntohs(eh-ether_type);
+#endif /* NVLAN 0 */
/*
* Make sure this interface is a bridge member.
@@ -1328,6 +1330,31 @@ bridge_input(struct ifnet *ifp, struct e
bridge_span(sc, eh, m);
+ m = bridge_dispatch(ifl, ifp, eh, m);
+
+#if NVLAN 0
+ if ((m != NULL) ((m-m_flags M_VLANTAG) ||
+ etype == ETHERTYPE_VLAN || etype == ETHERTYPE_QINQ)) {
+ /* The bridge did not want the vlan frame either, drop it. */
+ ifp-if_noproto++;
+ m_freem(m);
+ m = NULL;
+ }
+#endif /* NVLAN 0 */
+
+ return (m);
+}
+
+struct mbuf *
+bridge_dispatch(struct bridge_iflist *ifl, struct ifnet *ifp,
+struct ether_header *eh, struct mbuf *m)
+{
+ struct bridge_softc *sc = ifl-bridge_sc;
+ struct bridge_iflist *srcifl;
+ struct arpcom *ac;
+ struct mbuf *mc;
+ int s;
+
if (m-m_flags (M_BCAST | M_MCAST)) {
/*
* Reserved destination MAC addresses (01:80:C2:00:00:0x)
@@ -1377,6 +1404,7 @@ bridge_input(struct ifnet *ifp, struct e
IF_ENQUEUE(sc-sc_if.if_snd, mc);
splx(s);
schednetisr(NETISR_BRIDGE);
+#if NGIF 0
if (ifp-if_type == IFT_GIF) {
TAILQ_FOREACH(ifl, sc-sc_iflist, next) {
if (ifl-ifp-if_type == IFT_ETHER)
@@ -1396,6 +1424,7 @@ bridge_input(struct ifnet *ifp, struct e
m = NULL;
}
}
+#endif /* NGIF */
return (m);
}
@@ -1446,11 +1475,13 @@ bridge_input(struct ifnet *ifp, struct e
m-m_pkthdr.rcvif = ifl-ifp;
m-m_pkthdr.ph_rtableid = ifl-ifp-if_rdomain;
+#if NGIF 0
if (ifp-if_type == IFT_GIF) {
m-m_flags |= M_PROTO1;
ether_input(ifl-ifp, eh, m);
m = NULL;
}
+#endif /* NGIF */
return (m);
}
if (bcmp(ac-ac_enaddr, eh-ether_shost, ETHER_ADDR_LEN) == 0
Index: net/if_ethersubr.c
===
RCS file: /cvs/src/sys/net/if_ethersubr.c,v
retrieving revision 1.189
diff -u -p -r1.189 if_ethersubr.c
--- net/if_ethersubr.c 16 Feb 2015 18:24:02 - 1.189
+++ net/if_ethersubr.c 11 Mar 2015 11:06:54 -
@@ -563,16 +563,6 @@ ether_input(struct ifnet *ifp0, void *hd
}
#endif
-#if NVLAN 0
- if ((m-m_flags M_VLANTAG) || etype == ETHERTYPE_VLAN ||
- etype == ETHERTYPE_QINQ) {
- /* The bridge did not want the vlan frame either, drop it. */
- ifp-if_noproto++;
- m_freem(m);
- return (1);
- }
-#endif /* NVLAN 0 */
-
#if NCARP 0
if (ifp-if_carp) {
if (ifp-if_type != IFT_CARP (carp_input(ifp, eh, m) == 0))
[PATCH 1/6] Close extended discovery socket on exit.
--- ldpe.c | 1 + 1 file changed, 1 insertion(+) diff --git a/ldpe.c b/ldpe.c index afba919..f643272 100644 --- a/ldpe.c +++ b/ldpe.c @@ -279,6 +279,7 @@ ldpe_shutdown(void) } close(leconf-ldp_discovery_socket); + close(leconf-ldp_ediscovery_socket); close(leconf-ldp_session_socket); /* clean up */ -- 1.9.1
keyboard and mouse problems
Two related problems regarding mice and keyboards came to my attention
during s2k15 in Brisbane and I worked with jcs@ on solutions.
The first problem is some newer machines (such as the thinkpad x1)
have keyboard repeat or stuttering during install -- this issue only
happes on the RAMDISK kernel. Eventually we figured out that this is
due to the large touchpad! Even a light brush against it would mess
up the pckbc driver subtly, causing 10 second pauses. This happens
because the RAMDISK media lacks the pms driver.
The solution is to forcibly reset the mouse port at attach. We
initially thought this change would only be needed for RAMDISK, but
it looks like this sequence was always missing in the past, and we
need it.
The second related issue is that boot -c on some machines has never
worked. The keyboard would be unresponsive. It turns out this is
also related to mouse ports which have not been reset.
These changes did not make the cut for 5.7, because there are a
plethora of keyboard contoller models, on PCs and non-PCs. We need
lots of testing before it goes in.
Index: dev/ic/pckbc.c
===
RCS file: /cvs/src/sys/dev/ic/pckbc.c,v
retrieving revision 1.43
diff -u -r1.43 pckbc.c
--- dev/ic/pckbc.c 19 Dec 2014 07:23:57 - 1.43
+++ dev/ic/pckbc.c 11 Feb 2015 03:52:01 -
@@ -41,6 +41,7 @@
#include dev/ic/i8042reg.h
#include dev/ic/pckbcvar.h
+#include dev/pckbc/pmsreg.h
#include pckbd.h
@@ -277,6 +278,12 @@
if (t-t_slotdata[slot] == NULL)
return 0;
pckbc_init_slotdata(t-t_slotdata[slot]);
+ } else if (!found slot == PCKBC_AUX_SLOT) {
+ u_char cmd[1] = { PMS_RESET };
+
+ (void) pckbc_poll_cmd(t, PCKBC_AUX_SLOT, cmd, sizeof cmd,
+ 0, NULL, 1);
+ pckbc_slot_enable(t, PCKBC_AUX_SLOT, 0);
}
return (found);
}
Index: pckbd.c
===
RCS file: /cvs/src/sys/dev/pckbc/pckbd.c,v
retrieving revision 1.38
diff -u -p -u -r1.38 pckbd.c
--- pckbd.c 24 Jul 2014 22:38:19 - 1.38
+++ pckbd.c 11 Feb 2015 04:57:35 -
@@ -79,6 +79,7 @@
#include dev/ic/pckbcvar.h
#include dev/pckbc/pckbdreg.h
#include dev/pckbc/pckbdvar.h
+#include dev/pckbc/pmsreg.h
#include dev/wscons/wsconsio.h
#include dev/wscons/wskbdvar.h
@@ -1033,6 +1034,8 @@ pckbd_cnpollc(void *v, int on)
/* Just to be sure. */
cmd[0] = KBC_ENABLE;
pckbc_poll_cmd(t-t_kbctag, PCKBC_KBD_SLOT, cmd, 1, 0, NULL, 0);
+ cmd[0] = PMS_RESET;
+ pckbc_poll_cmd(t-t_kbctag, PCKBC_AUX_SLOT, cmd, 1, 0, NULL, 0);
}
}
Re: sysctl(3): HW_PERFPOLICY
On Thu, Mar 12, 2015 at 08:20:30AM +, Jason McIntyre wrote: i think the unknown will be a catchall for errors, and we shouldn;t suggest to users that they can set it. This makes sense. They actually can't set it to unknown. so my suggestion is below. i'll commit later if no one has yelled too much. I like your wording of the second part better than mine. However, `automatic' really should be a literal `auto'. $ sudo sysctl hw.perfpolicy=automatic sysctl: hw.perfpolicy: Invalid argument $ sudo sysctl hw.perfpolicy=auto hw.perfpolicy: manual - auto $ jmc Index: sysctl.3 === RCS file: /cvs/src/lib/libc/gen/sysctl.3,v retrieving revision 1.248 diff -u -r1.248 sysctl.3 --- sysctl.3 11 Mar 2015 19:42:38 - 1.248 +++ sysctl.3 12 Mar 2015 08:20:10 - @@ -332,9 +332,10 @@ .It Dv HW_PERFPOLICY The performance policy for power management. Can be one of -.Qq manual +.Dq manual , +.Dq automatic , or -.Qq automatic . +.Dq high . .It Dv HW_PHYSMEM The total physical memory, in bytes. This variable is deprecated; use @@ -377,6 +378,10 @@ .It Dv HW_SETPERF Current CPU performance .Pq percentage . +It is only modifiable if +.Dv HW_PERFPOLICY +is set to +.Dq manual . .It Dv HW_USERMEM The amount of available non-kernel memory in bytes. This variable is deprecated; use
[PATCH 2/6] Don't assign labels for BGP routes.
Although RFC 5036 is not explicit about this, LDP should not assign
labels for BGP routes. Doing that would be very resource consuming in
some scenarios and unnecessary. The goal is generally only to establish
LSPs among all PEs in the AS since LDP is not used as an end in itself
but as a means to implement advanced solutions like MPLS L2/L3 VPNs. Some
implementations (e.g. JunOS) go further and only assign labels for /32
loopback routes advertised in the IGP.
If Inter-AS LSPs are necessary, BGP itself should be used for distributing
IPv4 labeled routes (e.g. option C. of section 10 in RFC 4364).
---
kroute.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kroute.c b/kroute.c
index f5772e7..679f66d 100644
--- a/kroute.c
+++ b/kroute.c
@@ -1250,6 +1250,8 @@ rtmsg_process(char *buf, size_t len)
if (rtm-rtm_flags RTF_MPATH)
mpath = 1;
prio = rtm-rtm_priority;
+ if (prio == RTP_BGP)
+ continue;
switch (sa-sa_family) {
case AF_INET:
--
1.9.1
Re: dmesg(8) incomplete?
Hi, I am a pretty new user so please forgive any uninformed statements. I just spent a few hours trying to figure out why my dmesg displays an old kernel (May 5th), when I just compiled a new one (for recent -stable patches). I've looked pretty much everywhere and retraced every step until finally giving up and starting to compose a mail to get help. Then, when pasting my dmesg output into the mail I realized that there were multiple system messages from multiple startups in the dmesg output, and that everything was fine with my system. Now, except for a few threads from 200[367], even now that I know what I'm looking for I don't see this behaviour documented anywhere. Since there is no other record of this behaviour my knowldge is probably incomplete but attached is a patch - I borrowed some wordings from a mail from Theo[1] - that adds this information to the dmesg manpage. Or perhaps more succinctly? Index: dmesg.8 === RCS file: /cvs/src/sbin/dmesg/dmesg.8,v retrieving revision 1.15 diff -u -p -u -r1.15 dmesg.8 --- dmesg.8 13 Jan 2015 10:07:58 - 1.15 +++ dmesg.8 13 Mar 2015 03:37:45 - @@ -45,6 +45,8 @@ .Nm displays the contents of the system message buffer. It is most commonly used to review system startup messages. +On some systems the message buffer can survive reboot and be +retained (in the hope of exposing information from a crash). .Pp The options are as follows: .Bl -tag -width Ds
Re: ksh version lies
On Fri, Mar 13, 2015 at 10:48:56AM +0900, Pascal Stumpf wrote:
On Thu, 12 Mar 2015 15:25:48 + (UTC), Christian Weisgerber wrote:
On 2015-03-12, Patrik Lundin patrik.lundin@gmail.com wrote:
===
elif [ -n $KSH_VERSION ]; then
HACKING_DIR=$(dirname ${.sh.file})
===
.sh.file and related dot variables are a ksh93 extension. I don't
think ksh88 supports this, so this is unportable even within the
ksh family. ... Actually, ksh88 doesn't have KSH_VERSION either if
I am to believe the comments in Sven Mascheck's famous script:
http://www.in-ulm.de/~mascheck/various/whatshell/whatshell.sh.comments.html
Exactly. The bug is that the script seems to equate the presence of
KSH_VERSION to 'this is ksh93' without looking at its contents.
If ksh88 neither has KSH_VERSION or the .sh variables, could the
presence of KSH_VERSION mean this shell is at least ksh93 equivalent?
Maby this is an added incentive for tedu's patch that removes the
variable? If it had not have been set at all ansible would have been
happy :).
Anyway, I understand that removing such a variable could lead to other
fallout as the previous messages in this thread discusses. The sensible
way forward would be for me to look into how to decide if the version
string more specifically belongs to a ksh93 inspired ksh if present.
Thanks for your input!
--
Patrik Lundin
dmesg(8) incomplete?
Hi, I am a pretty new user so please forgive any uninformed statements. I just spent a few hours trying to figure out why my dmesg displays an old kernel (May 5th), when I just compiled a new one (for recent -stable patches). I've looked pretty much everywhere and retraced every step until finally giving up and starting to compose a mail to get help. Then, when pasting my dmesg output into the mail I realized that there were multiple system messages from multiple startups in the dmesg output, and that everything was fine with my system. Now, except for a few threads from 200[367], even now that I know what I'm looking for I don't see this behaviour documented anywhere. Since there is no other record of this behaviour my knowldge is probably incomplete but attached is a patch - I borrowed some wordings from a mail from Theo[1] - that adds this information to the dmesg manpage. Best Regards, Thomas [1] http://marc.info/?l=openbsd-miscm=115272548814461w=2 Index: src/sbin/dmesg/dmesg.8 === RCS file: /cvs/src/sbin/dmesg/dmesg.8,v retrieving revision 1.15 diff -u -p -u -r1.15 dmesg.8 --- src/sbin/dmesg/dmesg.8 13 Jan 2015 10:07:58 - 1.15 +++ src/sbin/dmesg/dmesg.8 13 Mar 2015 03:14:45 - @@ -45,6 +45,11 @@ .Nm displays the contents of the system message buffer. It is most commonly used to review system startup messages. +If the kernel finds that the +.Nm +buffer in the kernel address space is still intact after reboot, it does +not clear it, but appends to it, resulting in the output of messages from +multiple startups. This is so that crash-related data will be retained. .Pp The options are as follows: .Bl -tag -width Ds
Re: ksh version lies
On 2015-03-12, Patrik Lundin patrik.lundin@gmail.com wrote:
===
elif [ -n $KSH_VERSION ]; then
HACKING_DIR=$(dirname ${.sh.file})
===
.sh.file and related dot variables are a ksh93 extension. I don't
think ksh88 supports this, so this is unportable even within the
ksh family. ... Actually, ksh88 doesn't have KSH_VERSION either if
I am to believe the comments in Sven Mascheck's famous script:
http://www.in-ulm.de/~mascheck/various/whatshell/whatshell.sh.comments.html
--
Christian naddy Weisgerber na...@mips.inka.de
Re: keyboard and mouse problems
On Thu, 12 Mar 2015, at 04:11 AM, Theo de Raadt wrote: Two related problems regarding mice and keyboards came to my attention during s2k15 in Brisbane and I worked with jcs@ on solutions. The first problem is some newer machines (such as the thinkpad x1) have keyboard repeat or stuttering during install -- this issue only happes on the RAMDISK kernel. Eventually we figured out that this is due to the large touchpad! Even a light brush against it would mess up the pckbc driver subtly, causing 10 second pauses. This happens because the RAMDISK media lacks the pms driver. Had a similar problem with the ramdisk kernel on my Thinkpad T440p; any slight bump of the nipple mouse in the centre of the keyboard would cause the keyboard to start repeating characters. With this patch applied the problem goes away. Thanks a lot :-) dmesg, in case it's useful to see the hardware I tested it on: OpenBSD 5.7-current (GENERIC.MP) #6: Fri Mar 13 04:30:46 NZDT 2015 car...@vorpal.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16835846144 (16055MB) avail mem = 16321662976 (15565MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xacd3d000 (66 entries) bios0: vendor LENOVO version GLET70WW (2.24 ) date 05/21/2014 bios0: LENOVO 20ANCTO1WW 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 MSDM 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-4710MQ CPU @ 2.50GHz, 2494.55 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID 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-4710MQ CPU @ 2.50GHz, 2494.22 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID 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-4710MQ CPU @ 2.50GHz, 2494.22 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID 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-4710MQ CPU @ 2.50GHz, 2494.23 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID 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-4710MQ CPU @ 2.50GHz, 2494.22 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,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID 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-4710MQ CPU @ 2.50GHz, 2494.23 MHz cpu5: 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID cpu5: 256KB 64b/line 8-way L2 cache cpu5: smt 1, core 2, package 0
Re: [PATCH 5/6] Remove interface finite state machine.
2015-03-11 22:30 GMT-03:00 Claudio Jeker cje...@diehard.n-r-g.com:
On Wed, Mar 11, 2015 at 04:41:08PM -0300, Renato Westphal wrote:
In the name of simplicity, remove the interface FSM that was inherited
from ospfd. In ldpd interfaces are just up or down, so keeping a FSM
for that is an overkill. Now instead of calling if_fsm(), just call
if_update() whenever a relevant event occurs (status change, address
addition/removal).
Additional notes:
1 - s/if_act_/if_/
2 - Remove the IMSG_IFUP and IMSG_IFDOWN events. Now whenever an
interface changes its state a IMSG_IFSTATUS event will be generated
with the new status.
---
interface.c | 118
+---
kroute.c| 13 ---
ldpd.h | 19 --
ldpe.c | 21 ++-
ldpe.h | 4 ++-
5 files changed, 28 insertions(+), 147 deletions(-)
diff --git a/interface.c b/interface.c
index 7c80d1e..62c2766 100644
--- a/interface.c
+++ b/interface.c
@@ -41,98 +41,9 @@
extern struct ldpd_conf*leconf;
-int if_act_start(struct iface *);
-int if_act_reset(struct iface *);
-int if_act_update(struct iface *);
void if_hello_timer(int, short, void *);
void if_start_hello_timer(struct iface *);
void if_stop_hello_timer(struct iface *);
-struct nbr *if_elect(struct nbr *, struct nbr *);
-
-struct {
- int state;
- enum iface_eventevent;
- enum iface_action action;
- int new_state;
-} iface_fsm[] = {
-/* current state event that happened action to take resulting
state */
-{IF_STA_DOWN,IF_EVT_DOWN,IF_ACT_NOTHING, 0},
-{IF_STA_DOWN,IF_EVT_UP, IF_ACT_UPDATE, 0},
-{IF_STA_DOWN,IF_EVT_NEWADDR, IF_ACT_UPDATE, 0},
-{IF_STA_DOWN,IF_EVT_DELADDR, IF_ACT_NOTHING, 0},
-{IF_STA_ACTIVE, IF_EVT_DOWN,IF_ACT_RST, IF_STA_DOWN},
-{IF_STA_ACTIVE, IF_EVT_NEWADDR, IF_ACT_NOTHING, 0},
-{IF_STA_ACTIVE, IF_EVT_DELADDR, IF_ACT_UPDATE, 0},
-{-1, IF_EVT_NOTHING, IF_ACT_NOTHING, 0},
-};
-
-const char * const if_event_names[] = {
- NOTHING,
- UP,
- DOWN,
- NEWADDR,
- DELADDR
-};
-
-const char * const if_action_names[] = {
- NOTHING,
- UPDATE,
- RESET
-};
-
-int
-if_fsm(struct iface *iface, enum iface_event event)
-{
- int old_state;
- int new_state = 0;
- int i, ret = 0;
-
- old_state = iface-state;
-
- for (i = 0; iface_fsm[i].state != -1; i++)
- if ((iface_fsm[i].state old_state)
- (iface_fsm[i].event == event)) {
- new_state = iface_fsm[i].new_state;
- break;
- }
-
- if (iface_fsm[i].state == -1) {
- /* event outside of the defined fsm, ignore it. */
- log_debug(if_fsm: interface %s,
- event %s not expected in state %s, iface-name,
- if_event_names[event], if_state_name(old_state));
- return (0);
- }
-
- switch (iface_fsm[i].action) {
- case IF_ACT_UPDATE:
- ret = if_act_update(iface);
- break;
- case IF_ACT_RST:
- ret = if_act_reset(iface);
- break;
- case IF_ACT_NOTHING:
- /* do nothing */
- break;
- }
-
- if (ret) {
- log_debug(if_fsm: error changing state for interface %s,
- event %s, state %s, iface-name, if_event_names[event],
- if_state_name(old_state));
- return (-1);
- }
-
- if (new_state != 0)
- iface-state = new_state;
-
- log_debug(if_fsm: event %s resulted in action %s and changing
- state for interface %s from %s to %s,
- if_event_names[event], if_action_names[iface_fsm[i].action],
- iface-name, if_state_name(old_state),
if_state_name(iface-state));
-
- return (ret);
-}
struct iface *
if_new(struct kif *kif)
@@ -168,7 +79,7 @@ if_del(struct iface *iface)
struct if_addr *if_addr;
if (iface-state == IF_STA_ACTIVE)
- if_act_reset(iface);
+ if_reset(iface);
log_debug(if_del: interface %s, iface-name);
@@ -237,13 +148,14 @@ if_stop_hello_timer(struct iface *iface)
fatal(if_stop_hello_timer);
}
-/* actions */
int
-if_act_start(struct iface *iface)
+if_start(struct iface *iface)
{
struct in_addr addr;
struct timeval now;
+ log_debug(if_start: %s, iface-name);
+
gettimeofday(now, NULL);
iface-uptime = now.tv_sec;
@@ -257,11 +169,13 @@ if_act_start(struct iface *iface)
}
int
-if_act_reset(struct iface *iface)
+if_reset(struct iface *iface)
Re: [PATCH 2/6] Don't assign labels for BGP routes.
2015-03-11 22:18 GMT-03:00 Claudio Jeker cje...@diehard.n-r-g.com:
On Wed, Mar 11, 2015 at 04:41:05PM -0300, Renato Westphal wrote:
Although RFC 5036 is not explicit about this, LDP should not assign
labels for BGP routes. Doing that would be very resource consuming in
some scenarios and unnecessary. The goal is generally only to establish
LSPs among all PEs in the AS since LDP is not used as an end in itself
but as a means to implement advanced solutions like MPLS L2/L3 VPNs. Some
implementations (e.g. JunOS) go further and only assign labels for /32
loopback routes advertised in the IGP.
If Inter-AS LSPs are necessary, BGP itself should be used for distributing
IPv4 labeled routes (e.g. option C. of section 10 in RFC 4364).
---
kroute.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kroute.c b/kroute.c
index f5772e7..679f66d 100644
--- a/kroute.c
+++ b/kroute.c
@@ -1250,6 +1250,8 @@ rtmsg_process(char *buf, size_t len)
if (rtm-rtm_flags RTF_MPATH)
mpath = 1;
prio = rtm-rtm_priority;
+ if (prio == RTP_BGP)
+ continue;
switch (sa-sa_family) {
case AF_INET:
--
1.9.1
A few comments:
- I would prefer that check to be a bit further up as in above the
RTF_MPATH check and so next to all the other continues.
- Add a comment why we skip RTP_BGP
Ok.
- Shouldn't this be a more generic kind of filter (since the prio can be
changed in bgpd)? Or is this overkill?
- Would be nice to use something like the ROUTE_MSGFILTER to filter these
unwanted messages already in the kernel (esp since bgpd can be a very
chatty companion)
I agree with you, filtering by the priority sounds more like a hack
than a real solution. Yes, we could create a new sockopt like
ROUTE_PROTOFILTER to filter the unwanted routes already in the kernel,
but that doesn't address the real issue: how to identify the BGP
routes? In Linux the fib_info structure has a field called
fib_protocol (RTPROT_*) which stores the type of the route. AFAIK we
don't have anything like that in OpenBSD.
--
Renato Westphal
Re: ksh version lies
On Sun, Feb 15, 2015 at 09:00:27PM -0500, Ted Unangst wrote:
ksh (and sh) have a version string embedded in them:
@(#)PD KSH v5.2.14 99/07/13.2
This is clearly a lie. We've added, removed, and fixed bugs and features since
then. I first noticed the lie in the man page, then saw that it's also
exported via the environment and other places.
I recently ran into a related problem when pulling the latest ansible
sources and trying to run ansible directly from a checkout:
===
$ . hacking/env-setup
ksh: hacking/env-setup[23]: ${.sh.file}: bad substitution
[...]
===
The script (env-setup) does this:
===
elif [ -n $KSH_VERSION ]; then
HACKING_DIR=$(dirname ${.sh.file})
===
It seems the ksh in OpenBSD base does not contain the .sh.stuff that
some other versions have. Looking at http://www.manpagez.com/man/1/ksh/
there seems to be several listed under Parameter Expansion.
Before trying to hack around this myself, would there be any specific
desired paths to solve the problem? I realize this is possibly not a
discussion well suited for tech@, but since I recall this discussion
mentioning the removal of $KSH_VERSION it seemed close enough.
Sorry for the noise otherwise.
--
Patrik Lundin
