Re: [WIP] new sysctl hw.gpuperf
I can test it this weekend. I have a Thinkpad T420. On Fri, Jun 28, 2019 at 04:46:02PM +0200, Benjamin Baier wrote: > On Mon, 24 Jun 2019 13:02:52 +0200 > Benjamin Baier wrote: > > > Hi, > > > > this is wip for a new sysctl that implements gpu throttling. > > Only implemented for inteldrm right now, and tested on a single amd64 > > laptop. Helps to keep the GPU/CPU cooler and save some energy. > > > > Most of the diff is for sensors to verify if the sysctl works, and will > > be removed once i'm confident enought. > > > > Some notes from my x220 with integrated intel graphics (HD3000): > > - min gpu freq: 650 MHz > > - max gpu freq: 1300 MHz > > Setting hw.gpuperf to anything > 10 (max. 700 MHz) will eventually run > > into thermal throttling (GPU temp 96 deg C). > > Setting hw.gpuperf=0 (650MHz) will run Youtube video and browser games > > together fine, and reduce GPU/CPU temp from 96 deg C to about 80 - 86 deg C. > > > > thoughts? tests? > > > > Greetings Ben > > Thanks, for the feedback. > > Updated diff below. Seems to work without regressions so far on at least > HD3000 (Sandy Bridge), HD4400 (Haswell), HD510 (Skylake), HD405 (Atom x7). > My findings of reduced temps where also replicated. > > === > > This implements a new sysctl hw.gpuperf. > This will throttle down your graphic card for > better thermal and energy management. > Unlike hw.setperf which sets a fixed CPU clock, > hw.gpuperf will limit the max. clock the GPU is > allowed to reach. So it will still downclock while > idle even at hw.gpuperf=100. > > Patch Version 2 > Patch apply directions have changed > Includes man page change > Header cleanup > Patch Version 1 > Throttle down to base freq on haswell & broadwell > Remove sensors, use debug printf > Need: > OpenBSD-current source code > Only implemented for intel graphic (atm.) > To apply: > cd /usr/src && patch < gpuperf.diff > Rebuild and install a new kernel: > KK=`sysctl -n kern.osversion | cut -d# -f1` > cd /usr/src/sys/arch/`machine`/compile/$KK > make obj > make config > make > make install > Rebuild and install a new sysctl: > cp /usr/src/sys/sys/sysctl.h /usr/include/sys/ > cd /usr/src/sbin/sysctl > make obj > make > make install > Test various sysctl hw.gpuperf settings (0, 10, ..., 100) > Send output of: dmesg | grep -e gpuperf -e inteldrm -e cpu0 > and test results/feedback to program...@netzbasis.de > > Wed Jun 26 12:16:25 CEST 2019 > /home/cvsgit/hellfish/src > Index: lib/libc/sys/sysctl.2 > === > RCS file: /cvs/src/lib/libc/sys/sysctl.2,v > retrieving revision 1.27 > diff -u -p -r1.27 sysctl.2 > --- lib/libc/sys/sysctl.2 9 May 2019 15:05:47 - 1.27 > +++ lib/libc/sys/sysctl.2 26 Jun 2019 10:09:56 - > @@ -282,6 +282,7 @@ privileges may change the value. > .It Dv HW_DISKCOUNT Ta "integer" Ta "no" > .It Dv HW_DISKNAMES Ta "string" Ta "no" > .It Dv HW_DISKSTATS Ta "struct" Ta "no" > +.It Dv HW_GPUPERF Ta "integer" Ta "yes" > .It Dv HW_MACHINE Ta "string" Ta "no" > .It Dv HW_MODEL Ta "string" Ta "no" > .It Dv HW_NCPU Ta "integer" Ta "no" > @@ -324,6 +325,10 @@ A comma-separated list of disk names. > An array of > .Vt struct diskstats > structures containing disk statistics. > +.It Dv HW_GPUPERF Pq Va hw.gpuperf > +Maximum GPU performance > +.Pq percentage . > +Only for supported hardware. > .It Dv HW_MACHINE Pq Va hw.machine > The machine class. > .It Dv HW_MODEL Pq Va hw.model > Index: sys/conf/files > === > RCS file: /cvs/src/sys/conf/files,v > retrieving revision 1.671 > diff -u -p -r1.671 files > --- sys/conf/files4 May 2019 11:34:47 - 1.671 > +++ sys/conf/files25 Jun 2019 20:21:29 - > @@ -710,6 +710,7 @@ file kern/subr_autoconf.c > file kern/subr_disk.c > file kern/subr_evcount.c > file kern/subr_extent.c > +file kern/subr_gpuperf.c inteldrm > file kern/subr_hibernate.c hibernate > file kern/subr_kubsan.c kubsan > file kern/subr_log.c > Index: sys/dev/pci/drm/i915/i915_drv.c > === > RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_drv.c,v > retrieving revision 1.118 > diff -u -p -r1.118 i915_drv.c > --- sys/dev/pci/drm/i915/i915_drv.c 8 May 2019 15:55:56 - 1.118 > +++ sys/dev/pci/drm/i915/i915_drv.c 25 Jun 2019 20:21:29 - > @@ -46,6 +46,10 @@ > #include > #include > > +#ifdef __OpenBSD__ > +#include > +#endif /* __OpenBSD__ */ > + > #include "i915_drv.h" > #include "i915_trace.h" > #include "i915_pmu.h" > @@ -3668,12 +3672,54 @@ inteldrm_attachhook(struct device *self) > > config_found_sm(self, , wsemuldisplaydevprint, > wsemuldisplaydevsubmatch); > + > +#ifdef __OpenBSD__ > + gpuperf_register(dev_priv->sc_dev.dv_xname, > +
Does ssh need sendfd in pledge() call?
Hi all, I posted this question to the OpenBSD bugs list last week, however I have had no reply and it was suggested on IRC that I post to openssh-unix-dev, however they suggested I post to tech instead. So I must apologize if this is not appropriate. For a reference here is my previous post to bugs: https://marc.info/?l=openbsd-bugs=156080681530337=2 I am running OpenBSD 6.5-stable (also tested on -current). When I ssh somewhere I get a sig abort from pledge(). I use a Yubikey with GPG and use gpg-agent as my ssh-agent. I also remote forward this agent. For example my .ssh/config has the following (please note the RemoteForward is actually all on one line, I have split it here to keep it below 80 chars): Host www Hostname 192.168.1.100 RemoteForward /home/tbrown/.gnupg/S.gpg-agent \ /home/tbrown/.gnupg/S.gpg-agent.extra ExitOnForwardFailure yes Host * ForwardX11 no Compression yes ServerAliveInterval 30 ServerAliveCountMax 4 ControlMaster auto ControlPath ~/.ssh/mux/%h_%p_%r ControlPersist 4h If I ssh, for example: xps ~$ ssh www Abort trap (core dumped) xps ~$ I have attached output for when I crank up there verbosity (ssh_verbose.txt), as it contains long lines. Dmesg contains: sh[28960]: pledge "sendfd", syscall 28 If I `ktrace` ssh, I get the following: 28960 ssh PLDG sendmsg, "sendfd", errno 1 Operation not permitted 28960 ssh PSIG SIGABRT SIG_DFL 28960 ssh NAMI "ssh.core" If I add sendfd to the pledge() call, it works. Please see the attached patch (ssh.patch). However I do not know if this is an acceptable solution. I guess I have to ask if I am doing something wrong? As in I thought I would not be the first to hit this error. Does anybody have any thoughts or ideas? Many thanks. Timothy Authenticated to 192.168.1.100 ([192.168.1.100]:22). debug1: Remote connections from /home/tbrown/.gnupg/S.gpg-agent:-2 forwarded to local address /home/tbrown/.gnupg/S.gpg-agent.extra:-2 debug3: send packet: type 80 debug1: setting up multiplex master socket debug3: muxserver_listen: temporary control path /home/tbrown/.ssh/mux/192.168.1.100_22_tbrown.2EvGYCjVoPNdAIrh debug2: fd 4 setting O_NONBLOCK debug3: fd 4 is O_NONBLOCK debug3: fd 4 is O_NONBLOCK debug1: channel 0: new [/home/tbrown/.ssh/mux/192.168.1.100_22_tbrown] debug3: muxserver_listen: mux listener channel 0 fd 4 debug2: fd 3 setting TCP_NODELAY debug3: ssh_packet_set_tos: set IP_TOS 0x20 debug1: deferring postauth fork until remote forward confirmation received debug1: Entering interactive session. debug1: pledge: id debug2: set_control_persist_exit_time: schedule exit in 14400 seconds debug3: receive packet: type 80 debug1: client_input_global_request: rtype hostkeys...@openssh.com want_reply 0 debug3: receive packet: type 4 debug1: Remote: /home/tbrown/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding debug3: receive packet: type 4 debug1: Remote: /home/tbrown/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding debug3: receive packet: type 81 debug1: remote forward success for: listen /home/tbrown/.gnupg/S.gpg-agent:-2, connect /home/tbrown/.gnupg/S.gpg-agent.extra:-2 debug1: All remote forwarding requests processed debug1: control_persist_detach: backgrounding master process debug2: control_persist_detach: background process is 85607 debug2: fd 4 setting O_NONBLOCK debug1: forking to background debug1: multiplexing control connection debug3: fd 5 is O_NONBLOCK debug3: fd 5 is O_NONBLOCK debug1: channel 1: new [mux-control] debug3: channel_post_mux_listener: new mux channel 1 fd 5 debug3: mux_master_read_cb: channel 1: hello sent debug2: set_control_persist_exit_time: cancel scheduled exit debug3: mux_master_read_cb: channel 1 packet type 0x0001 len 4 debug2: mux_master_process_hello: channel 1 slave version 4 debug2: mux_client_hello_exchange: master version 4 debug3: mux_client_forwards: request forwardings: 0 local, 1 remote debug1: Requesting forwarding of remote forward /home/tbrown/.gnupg/S.gpg-agent:-2 -> /home/tbrown/.gnupg/S.gpg-agent.extra:-2 debug3: mux_master_read_cb: channel 1 packet type 0x1006 len 92 debug2: mux_master_process_open_fwd: channel 1: request remote forward /home/tbrown/.gnupg/S.gpg-agent:-2 -> /home/tbrown/.gnupg/S.gpg-agent.extra:-2 debug2: mux_master_process_open_fwd: found existing forwarding debug3: mux_client_request_session: entering debug3: mux_client_request_alive: entering debug3: mux_master_read_cb: channel 1 packet type 0x1004 len 4 debug2: mux_master_process_alive_check: channel 1: alive check debug3: mux_client_request_alive: done pid = 806 debug3: mux_master_read_cb: channel 1 packet type 0x1002 len 57 debug2: mux_master_process_new_session: channel 1: request tty 1, X 0, agent 0, subsys 0, term "rxvt-unicode-256color", cmd "", env 0 debug3: mm_receive_fd: recvmsg: Resource temporarily unavailable mm_receive_fd:
Re: [WIP] new sysctl hw.gpuperf
On Mon, 24 Jun 2019 13:02:52 +0200
Benjamin Baier wrote:
> Hi,
>
> this is wip for a new sysctl that implements gpu throttling.
> Only implemented for inteldrm right now, and tested on a single amd64
> laptop. Helps to keep the GPU/CPU cooler and save some energy.
>
> Most of the diff is for sensors to verify if the sysctl works, and will
> be removed once i'm confident enought.
>
> Some notes from my x220 with integrated intel graphics (HD3000):
> - min gpu freq: 650 MHz
> - max gpu freq: 1300 MHz
> Setting hw.gpuperf to anything > 10 (max. 700 MHz) will eventually run
> into thermal throttling (GPU temp 96 deg C).
> Setting hw.gpuperf=0 (650MHz) will run Youtube video and browser games
> together fine, and reduce GPU/CPU temp from 96 deg C to about 80 - 86 deg C.
>
> thoughts? tests?
>
> Greetings Ben
Thanks, for the feedback.
Updated diff below. Seems to work without regressions so far on at least
HD3000 (Sandy Bridge), HD4400 (Haswell), HD510 (Skylake), HD405 (Atom x7).
My findings of reduced temps where also replicated.
===
This implements a new sysctl hw.gpuperf.
This will throttle down your graphic card for
better thermal and energy management.
Unlike hw.setperf which sets a fixed CPU clock,
hw.gpuperf will limit the max. clock the GPU is
allowed to reach. So it will still downclock while
idle even at hw.gpuperf=100.
Patch Version 2
Patch apply directions have changed
Includes man page change
Header cleanup
Patch Version 1
Throttle down to base freq on haswell & broadwell
Remove sensors, use debug printf
Need:
OpenBSD-current source code
Only implemented for intel graphic (atm.)
To apply:
cd /usr/src && patch < gpuperf.diff
Rebuild and install a new kernel:
KK=`sysctl -n kern.osversion | cut -d# -f1`
cd /usr/src/sys/arch/`machine`/compile/$KK
make obj
make config
make
make install
Rebuild and install a new sysctl:
cp /usr/src/sys/sys/sysctl.h /usr/include/sys/
cd /usr/src/sbin/sysctl
make obj
make
make install
Test various sysctl hw.gpuperf settings (0, 10, ..., 100)
Send output of: dmesg | grep -e gpuperf -e inteldrm -e cpu0
and test results/feedback to program...@netzbasis.de
Wed Jun 26 12:16:25 CEST 2019
/home/cvsgit/hellfish/src
Index: lib/libc/sys/sysctl.2
===
RCS file: /cvs/src/lib/libc/sys/sysctl.2,v
retrieving revision 1.27
diff -u -p -r1.27 sysctl.2
--- lib/libc/sys/sysctl.2 9 May 2019 15:05:47 - 1.27
+++ lib/libc/sys/sysctl.2 26 Jun 2019 10:09:56 -
@@ -282,6 +282,7 @@ privileges may change the value.
.It Dv HW_DISKCOUNT Ta "integer" Ta "no"
.It Dv HW_DISKNAMES Ta "string" Ta "no"
.It Dv HW_DISKSTATS Ta "struct" Ta "no"
+.It Dv HW_GPUPERF Ta "integer" Ta "yes"
.It Dv HW_MACHINE Ta "string" Ta "no"
.It Dv HW_MODEL Ta "string" Ta "no"
.It Dv HW_NCPU Ta "integer" Ta "no"
@@ -324,6 +325,10 @@ A comma-separated list of disk names.
An array of
.Vt struct diskstats
structures containing disk statistics.
+.It Dv HW_GPUPERF Pq Va hw.gpuperf
+Maximum GPU performance
+.Pq percentage .
+Only for supported hardware.
.It Dv HW_MACHINE Pq Va hw.machine
The machine class.
.It Dv HW_MODEL Pq Va hw.model
Index: sys/conf/files
===
RCS file: /cvs/src/sys/conf/files,v
retrieving revision 1.671
diff -u -p -r1.671 files
--- sys/conf/files 4 May 2019 11:34:47 - 1.671
+++ sys/conf/files 25 Jun 2019 20:21:29 -
@@ -710,6 +710,7 @@ file kern/subr_autoconf.c
file kern/subr_disk.c
file kern/subr_evcount.c
file kern/subr_extent.c
+file kern/subr_gpuperf.c inteldrm
file kern/subr_hibernate.c hibernate
file kern/subr_kubsan.ckubsan
file kern/subr_log.c
Index: sys/dev/pci/drm/i915/i915_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_drv.c,v
retrieving revision 1.118
diff -u -p -r1.118 i915_drv.c
--- sys/dev/pci/drm/i915/i915_drv.c 8 May 2019 15:55:56 - 1.118
+++ sys/dev/pci/drm/i915/i915_drv.c 25 Jun 2019 20:21:29 -
@@ -46,6 +46,10 @@
#include
#include
+#ifdef __OpenBSD__
+#include
+#endif /* __OpenBSD__ */
+
#include "i915_drv.h"
#include "i915_trace.h"
#include "i915_pmu.h"
@@ -3668,12 +3672,54 @@ inteldrm_attachhook(struct device *self)
config_found_sm(self, , wsemuldisplaydevprint,
wsemuldisplaydevsubmatch);
+
+#ifdef __OpenBSD__
+ gpuperf_register(dev_priv->sc_dev.dv_xname,
+ inteldrm_set_gpuperf, dev_priv);
+#endif /* __OpenBSD__ */
+
return;
fail:
inteldrm_fatal_error = 1;
inteldrm_forcedetach(dev_priv);
}
+
+#ifdef __OpenBSD__
+#define GPUPERF_DEBUG
+#ifdef GPUPERF_DEBUG
+#define PPRINTF(x...) do { printf(x); } while(0)
+#else
+#define PPRINTF(x...)
+#endif /* GPUPERF_DEBUG */
+int
+inteldrm_set_gpuperf(int level,
Re: anoncvs.html: tell reader to use -d if updating first time from tgz
On Fri, Jun 28, 2019 at 01:19:30PM +0200, Solene Rapenne wrote: > Hi > > in anoncvs.html, if the user choose to use tgz sources instead of a > checkout, the update examples won't work because no cvs server will be > set without passing -d parameter to the cvs command. > > Not sure about the wording, if a good english speaker can word it > better, go on :) > > Index: build/mirrors/anoncvs.html.head > === > RCS file: /data/cvs/www/build/mirrors/anoncvs.html.head,v > retrieving revision 1.77 > diff -u -p -r1.77 anoncvs.html.head > --- build/mirrors/anoncvs.html.head 27 May 2019 22:55:27 - 1.77 > +++ build/mirrors/anoncvs.html.head 28 Jun 2019 11:16:24 - > @@ -109,7 +109,8 @@ For more information on the flavors of O > Choose the Anonymous CVS server you are going to use from the > list of servers below, then you can start using cvs. > If you begin with src.tar.gz and sys.tar.gz as > mentioned > -above, you can skip the initial checkout and proceed to updating. > +above, you can skip the initial checkout and proceed to updating, > if you do > +so, the first time you update you must specify a cvs server as in the > checkout example. > > > Warning: > nand1 from irc told me it's already written later in the page. If you are updating a source tree that you initially fetched from a different server, or from a tar file, you must add the -d [cvsroot] option to cvs. not sure if this could be moved under "Updating an existin tree", this would make more sense to tell this before people need it
anoncvs.html: tell reader to use -d if updating first time from tgz
Hi in anoncvs.html, if the user choose to use tgz sources instead of a checkout, the update examples won't work because no cvs server will be set without passing -d parameter to the cvs command. Not sure about the wording, if a good english speaker can word it better, go on :) Index: build/mirrors/anoncvs.html.head === RCS file: /data/cvs/www/build/mirrors/anoncvs.html.head,v retrieving revision 1.77 diff -u -p -r1.77 anoncvs.html.head --- build/mirrors/anoncvs.html.head 27 May 2019 22:55:27 - 1.77 +++ build/mirrors/anoncvs.html.head 28 Jun 2019 11:16:24 - @@ -109,7 +109,8 @@ For more information on the flavors of O Choose the Anonymous CVS server you are going to use from the list of servers below, then you can start using cvs. If you begin with src.tar.gz and sys.tar.gz as mentioned -above, you can skip the initial checkout and proceed to updating. +above, you can skip the initial checkout and proceed to updating, if you do +so, the first time you update you must specify a cvs server as in the checkout example. Warning:
Re: TSC synchronization on MP machines
Hi, Thanks for the report! This does not look correct. TSC skew=-6129185140 drift=170 TSC skew=-6129184900 drift=-10 TSC skew=-6129184890 drift=-20 TSC skew=-6129184910 drift=30 TSC skew=-6129184910 drift=10 TSC skew=-6129184900 drift=20 TSC skew=-6129184910 drift=30 I'll be back with some printf's. Paul
fix for spinning bgpd session engine
It is possible that a session is going down while peer->rpending (the flag indicating that there is more data to process) is set. If that is happening the session engine is spinning until the session comes back up or the neighbor is removed. Fix is obvious, clear the flag when the read buffer rbuf is set to NULL. Additionally ensure that the timeout is only set to 0 if there is something in the read buffer to process. -- :wq Claudio Index: session.c === RCS file: /cvs/src/usr.sbin/bgpd/session.c,v retrieving revision 1.386 diff -u -p -r1.386 session.c --- session.c 22 Jun 2019 05:36:40 - 1.386 +++ session.c 28 Jun 2019 07:43:11 - @@ -422,7 +422,7 @@ session_main(int debug, int verbose) if (p->wbuf.queued > 0 || p->state == STATE_CONNECT) events |= POLLOUT; /* is there still work to do? */ - if (p->rpending) + if (p->rpending && p->rbuf && p->rbuf->wpos) timeout = 0; /* poll events */ @@ -888,6 +888,7 @@ change_state(struct peer *peer, enum ses msgbuf_clear(>wbuf); free(peer->rbuf); peer->rbuf = NULL; + peer->rpending = 0; bzero(>capa.peer, sizeof(peer->capa.peer)); if (!peer->template) imsg_compose(ibuf_main, IMSG_PFKEY_RELOAD, @@ -2959,6 +2960,7 @@ getpeerbyip(struct bgpd_config *c, struc newpeer->state = newpeer->prev_state = STATE_NONE; newpeer->reconf_action = RECONF_KEEP; newpeer->rbuf = NULL; + newpeer->rpending = 0; init_peer(newpeer); bgp_fsm(newpeer, EVNT_START); if (RB_INSERT(peer_head, >peers, newpeer) != NULL)
Re: rt_ifa_add rtable vs rtlabel confusion
On Mon, Jun 24, 2019 at 10:12:11AM -0300, Martin Pieuchot wrote:
> On 24/06/19(Mon) 10:10, Claudio Jeker wrote:
> > rt_ifa_add() and rt_ifs_del() confused rtableid and rtlabelid and so the
> > code does not correcly set RTAX_LABEL. It makes no sense to try to compare
> > rdoamin against if_rtlabelid since those are two different things.
> >
> > This should probably make 'ifconfig em0 rtlabel foo' work the way it is
> > intended. OK?
>
> Was the intend to check if `rdomain' passed as an argument is the one of
> the `ifp'? Should the check be changed to (rdomain == ifp->if_rdomain)?
You are talking about the KASSERT() I guess?
> The only places where this isn't true is MPLS code. David do you
> remember why you added this check?
Indeed for MPLS edge interfaces (mpe(4) and friends) the rdomain of the
interface and of the MPLS stack can differ. So the MPLS labels are
added to a different routing domain than the actual interface rdomain.
For example:
ifconfig mpe10 rdomain 10
ifconfig mpe10 mplslabel 42 tunneldomain 7
The mpe10 device is in rdomain 10 but the MPLS traffic arrives on table 7.
So the rt_ifa_add is called with rdomain 7 even though the device is in
table 10.
It is a bit of an abuse of rt_ifa_add() but it makes the code simpler.
> > Index: net/route.c
> > ===
> > RCS file: /cvs/src/sys/net/route.c,v
> > retrieving revision 1.386
> > diff -u -p -r1.386 route.c
> > --- net/route.c 21 Jun 2019 17:11:42 - 1.386
> > +++ net/route.c 24 Jun 2019 07:57:50 -
> > @@ -1094,6 +1094,8 @@ rt_ifa_add(struct ifaddr *ifa, int flags
> > uint8_t prio = ifp->if_priority + RTP_STATIC;
> > int error;
> >
> > + KASSERT(rdomain == rtable_l2(rdomain));
> > +
> > memset(, 0, sizeof(info));
> > info.rti_ifa = ifa;
> > info.rti_flags = flags;
> > @@ -1102,12 +1104,7 @@ rt_ifa_add(struct ifaddr *ifa, int flags
> > info.rti_info[RTAX_GATEWAY] = sdltosa(ifp->if_sadl);
> > else
> > info.rti_info[RTAX_GATEWAY] = ifa->ifa_addr;
> > -
> > - KASSERT(rdomain == rtable_l2(rdomain));
> > - if (rdomain == rtable_l2(ifp->if_rtlabelid)) {
> > - info.rti_info[RTAX_LABEL] =
> > - rtlabel_id2sa(ifp->if_rtlabelid, _rl);
> > - }
> > + info.rti_info[RTAX_LABEL] = rtlabel_id2sa(ifp->if_rtlabelid, _rl);
> >
> > #ifdef MPLS
> > if ((flags & RTF_MPLS) == RTF_MPLS)
> > @@ -1151,6 +1148,8 @@ rt_ifa_del(struct ifaddr *ifa, int flags
> > uint8_t prio = ifp->if_priority + RTP_STATIC;
> > int error;
> >
> > + KASSERT(rdomain == rtable_l2(rdomain));
> > +
> > if ((flags & RTF_HOST) == 0 && ifa->ifa_netmask) {
> > m = m_get(M_DONTWAIT, MT_SONAME);
> > if (m == NULL)
> > @@ -1166,11 +1165,7 @@ rt_ifa_del(struct ifaddr *ifa, int flags
> > info.rti_info[RTAX_DST] = dst;
> > if ((flags & RTF_LLINFO) == 0)
> > info.rti_info[RTAX_GATEWAY] = ifa->ifa_addr;
> > -
> > - if (rdomain == rtable_l2(ifp->if_rtlabelid)) {
> > - info.rti_info[RTAX_LABEL] =
> > - rtlabel_id2sa(ifp->if_rtlabelid, _rl);
> > - }
> > + info.rti_info[RTAX_LABEL] = rtlabel_id2sa(ifp->if_rtlabelid, _rl);
> >
> > if ((flags & RTF_HOST) == 0)
> > info.rti_info[RTAX_NETMASK] = ifa->ifa_netmask;
> >
>
--
:wq Claudio
