Лучшие почтовые рассылки

2012-09-03 Thread Konstantin Rozhkov
ËÓ×ØÈÅ ÐÀÑÑÛËÊÈ ÏÎ ÓÊÐÀÈÍÅ

Âàì - ïî÷òîâàÿ ïîñûëêà
Ïðåäëàãàåòñÿ ðàññûëêà
Ìû êëèåíòîâ ïðèâåäåì
Ðàäîñòü ôèðìàì ïðèíåñåì

Ñòîèìîñòü ïî Óêðàèíå 800 ãðí, 3.9 ìëí ïîëó÷àòåëåé
Ñòîèìîñòü ïî Êèåâó 700 ãðí, 1.7 ìëí ïîëó÷àòåëåé
Ñòîèìîñòü ïî îáëàñòÿì Óêðàèíû - 400 ãðí

E-mail: mailair2...@aol.com , ICQ: ×9Ç-179-46Î, Skype: abus.host



We got to meet. Details inside

2012-09-03 Thread Leandra Surber
I saw u having journey here and became aroused? Yeah, it's absolutely truth
that I liked u from the first look. 
Usually I'm not calling or writing men
first but some stuff happened to me when I checked up ur account. 
Oh, name of
mine is Leandra. Write me about you. What's about your free time? What could
impress you? Which food do u prefer? 
Will u write me tomorrow?;)
I gonna be
available at 10 pm tomorrow. Interested in having chat with you!



ongoing work on make

2012-09-03 Thread Marc Espie
Some lucky people have been spammed with previous versions of this patch.
Caveat: this is work in progress, there might be bugs lurking.

Basically, I'm trying to achieve two goals:
- unify some more compat-make and make-j, so that there's less code duplication
and less weird semantics differences.
- give better, more precise error reports when things go wrong.


The main idea is that make-j used to spawn a subshell that would run commands.
This is all neat, except it gives main-make zero control over what's going
on, especially in case of trouble, and there was some ridiculously
complicated tail-optimization to avoid forking the last command when
possible.

Well, dpb does more or less the same work, but since I started it from scratch,
the architecture was radically different, with a single main process,
and a job data structure that would start each individual task in sequence,
continuation style.

In the process of the rewrite, I took apart the pipe stuff I added a few
years ago. Much to my surprise, it doesn't appear to be THAT useful now,
intermixed commands don't intermix so much, so I haven't put it back yet...
this also means that make-j now sees the terminal.

I also took apart the make as job control, since that's not really all
that useful either.

Right now, the error reports are probably TOO verbose, and there are probably
bugs to iron out. This seems to work thru make build without trouble.

Improvements you're likely to see with make-j:
- mentions the target being made in case of errors.
- pinpoints error location to the line of the command being run, instead
of a general in this target area.
- shows command last run in case of a fatal error and in case the command
was silent.


I have just kept compat-make running as it was, since the goal is to
remove its job-running code completely and use the same code as for jobs...


Index: engine.c
===
RCS file: /home/openbsd/cvs/src/usr.bin/make/engine.c,v
retrieving revision 1.30
diff -u -p -r1.30 engine.c
--- engine.c25 Aug 2012 08:12:56 -  1.30
+++ engine.c3 Sep 2012 11:30:03 -
@@ -66,13 +66,14 @@
 
 static void MakeTimeStamp(void *, void *);
 static int rewrite_time(const char *);
+typedef void (*psighandler)(int);
 static void setup_signal(int, psighandler);
+static void setup_all_signals(void);
+static void notice_signal(int);
 static void setup_meta(void);
 static char **recheck_command_for_shell(char **);
 
-static int setup_and_run_command(char *, GNode *, int);
-static void run_command(const char *, bool);
-static int run_prepared_gnode(GNode *);
+static int setup_and_run_command(char *, GNode *);
 static void handle_compat_interrupts(GNode *);
 
 bool
@@ -464,27 +465,8 @@ setup_signal(int sig, psighandler h)
(void)signal(sig, h);
 }
 
-void
-setup_all_signals(psighandler interrupt, psighandler jc)
-{
-   /*
-* Catch the four signals that POSIX specifies if they aren't ignored.
-* handle_signal will take care of calling JobInterrupt if appropriate.
-*/
-   setup_signal(SIGINT, interrupt);
-   setup_signal(SIGHUP, interrupt);
-   setup_signal(SIGQUIT, interrupt);
-   setup_signal(SIGTERM, interrupt);
-   setup_signal(SIGTSTP, jc);
-   setup_signal(SIGTTOU, jc);
-   setup_signal(SIGTTIN, jc);
-   setup_signal(SIGWINCH, jc);
-   setup_signal(SIGCONT, jc);
-   got_signal = 0;
-}
-
-void
-SigHandler(int sig)
+static void
+notice_signal(int sig)
 {
switch(sig) {
case SIGINT:
@@ -506,6 +488,20 @@ SigHandler(int sig)
}
 }
 
+void
+setup_all_signals(void)
+{
+   /*
+* Catch the four signals that POSIX specifies if they aren't ignored.
+* handle_signal will take care of calling JobInterrupt if appropriate.
+*/
+   setup_signal(SIGINT, notice_signal);
+   setup_signal(SIGHUP, notice_signal);
+   setup_signal(SIGQUIT, notice_signal);
+   setup_signal(SIGTERM, notice_signal);
+   got_signal = 0;
+}
+
 /* The following array is used to make a fast determination of which
  * characters are interpreted specially by the shell.  If a command
  * contains any of these characters, it is executed by the shell, not
@@ -544,7 +540,7 @@ recheck_command_for_shell(char **av)
return av;
 }
 
-static void
+void
 run_command(const char *cmd, bool errCheck)
 {
const char *p;
@@ -600,7 +596,7 @@ run_command(const char *cmd, bool errChe
  *---
  */
 static int
-setup_and_run_command(char *cmd, GNode *gn, int dont_fork)
+setup_and_run_command(char *cmd, GNode *gn)
 {
bool silent;/* Don't print command */
bool doExecute; /* Execute the command */
@@ -635,24 +631,14 @@ setup_and_run_command(char *cmd, GNode *
cmd++;
/* Print the command before echoing if we're not supposed to be quiet
 * for this one. We 

Re: ongoing work on make

2012-09-03 Thread Mark Kettenis
 Date: Mon, 3 Sep 2012 13:59:44 +0200
 From: Marc Espie es...@nerim.net

 In the process of the rewrite, I took apart the pipe stuff I added a few
 years ago. Much to my surprise, it doesn't appear to be THAT useful now,
 intermixed commands don't intermix so much, so I haven't put it back yet...
 this also means that make-j now sees the terminal.

This makes me worried.  I *don't* want to have make behave differently
if it thinks it runs on a terminal.



Re: ongoing work on make

2012-09-03 Thread Marc Espie
On Mon, Sep 03, 2012 at 02:20:34PM +0200, Mark Kettenis wrote:
  Date: Mon, 3 Sep 2012 13:59:44 +0200
  From: Marc Espie es...@nerim.net
 
  In the process of the rewrite, I took apart the pipe stuff I added a few
  years ago. Much to my surprise, it doesn't appear to be THAT useful now,
  intermixed commands don't intermix so much, so I haven't put it back yet...
  this also means that make-j now sees the terminal.
 
 This makes me worried.  I *don't* want to have make behave differently
 if it thinks it runs on a terminal.

With that diff, compatmake and make -j now behaves the same way.

You're worried ? you should have been worried ages ago, back when the
difference happened.



Re: ongoing work on make

2012-09-03 Thread Marc Espie
On Mon, Sep 03, 2012 at 02:20:34PM +0200, Mark Kettenis wrote:
  Date: Mon, 3 Sep 2012 13:59:44 +0200
  From: Marc Espie es...@nerim.net
 
  In the process of the rewrite, I took apart the pipe stuff I added a few
  years ago. Much to my surprise, it doesn't appear to be THAT useful now,
  intermixed commands don't intermix so much, so I haven't put it back yet...
  this also means that make-j now sees the terminal.
 
 This makes me worried.  I *don't* want to have make behave differently
 if it thinks it runs on a terminal.

More precisely, I'm talking about commands run within make.

With compatmake (make without -j): commands are run thru fork/exec, 
transparently.

With -current make -j4: commands are run with stdout and stderr directed to
a pipe (and in a separate process group).

With the -current work: commands are run the same way with/without -j.
Simply, fork/exec, transparently.

make doesn't care at all whether you run things in a terminal or not.
Commands run within make may care. make shouldn't interfere with that,
as far as possible !

The pipe stuff was an attempt at serializing output properly, at some
point we thought it would be difficult to make sense of multiple commands.
Turns out things are ways better than expected, so there's no reason to
do that.



Elaboración de Modelos Financieros con Excel

2012-09-03 Thread Lic. Jovell Lucero Thomas
Elaboración de Modelos Financieros con Excel - Análisis e Interpretación
Panama 12 de Septiembre, 2012
SHERATON PANAMA HOTEL  CONVENTION CENTER
Se demostrará paso a paso técnicas financieras con las herramientas o
características de Excel. Aprenderá a utilizar Excel con el propósito de
desarrollar sus habilidades en una amplia gama de situaciones de toma de
decisiones financieras entre las que figuran, cómo…
- Preparar pronósticos financieros y proyecciones de flujo de efectivo más
exactos
- Simplificar problemas complejos de negocios
- Elaborar estados financieros a partir de una balanza de comprobación
- Crear estados financieros comparativos
- Elaborar flujos de efectivo mediante información exportada de su portal
bancario
- Elaborar estados de resultados con factores variables
- Elaborar un modelo de cálculo del VAN y TIR para sus proyectos de inversión
- Usar hipervínculos para crear informes directivos en PowerPoint mediante
Excel
Reciba en este momento el folleto completo!
Únicamente responda con su Nombre, Puesto, Empresa y Teléfono, o Comuníquese
al (507) 279-1083 / 279-0258 / 279-0887 en donde con gusto le atenderé.
Reciba un muy cordial saludo!
Lic. Adriana Alvarez
Líder de Proyectos
Para des suscribirse de estas invitaciones, solo responda este correo con el
SUBJECT noinv y automáticamente quedará fuera de nuestras listas.



arc4random_buf in bcrypt

2012-09-03 Thread Ted Unangst
There's an easy way to do this now.

Index: bcrypt.c
===
RCS file: /cvs/src/lib/libc/crypt/bcrypt.c,v
retrieving revision 1.24
diff -u -p -r1.24 bcrypt.c
--- bcrypt.c2 Apr 2008 19:54:05 -   1.24
+++ bcrypt.c3 Sep 2012 17:29:48 -
@@ -148,15 +148,8 @@ char *
 bcrypt_gensalt(u_int8_t log_rounds)
 {
u_int8_t csalt[BCRYPT_MAXSALT];
-   u_int16_t i;
-   u_int32_t seed = 0;
 
-   for (i = 0; i  BCRYPT_MAXSALT; i++) {
-   if (i % 4 == 0)
-   seed = arc4random();
-   csalt[i] = seed  0xff;
-   seed = seed  8;
-   }
+   arc4random_buf(csalt, sizeof(csalt));
 
if (log_rounds  4)
log_rounds = 4;



Re: ThinkPad T60 x86emu panic on resume (w/patch)

2012-09-03 Thread Alexander Polakov
* Theo de Raadt dera...@cvs.openbsd.org [120903 00:13]:
  Index: vga_pci.c
  ===
  RCS file: /cvs/src/sys/dev/pci/vga_pci.c,v
  retrieving revision 1.68
  diff -u -r1.68 vga_pci.c
  --- vga_pci.c   22 Aug 2012 20:58:30 -  1.68
  +++ vga_pci.c   2 Sep 2012 17:42:09 -
  @@ -186,7 +186,13 @@
  {   0x, 0x, 0x, 0x }, 1, 0
  },
   
  -   {   /* All ATI video until further notice */
  +   {   
  +   {   PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_X1400,
  +   0x, 0x },
  +   {   0x, 0x, 0x, 0x}, 0, 0
  +   },
  +
  +   {   /* Other ATI video until further notice */
  {   PCI_VENDOR_ATI, 0x,
  0x, 0x },
  {   0x, 0x, 0x, 0x}, 1, 0
 
 
 That's a great patch, because it doesn't find or fix the underlying
 issues.

Thanks.

 Then, when the next person -- who's video did need this -- finds out
 it no longer works, they can submit the inverse of your diff -- once
 again not undercovering the real issue.  Of course, now it is their
 problem, not yours, right?

No, he'll add a record above mine with his subproduct/subvendor ids.

 Your diff can be summarized as make it work for me, me, me, me.
 Awesome work.  You know how to fix it just for yourself and submit a
 self-serving patch, hoping we'll commit it without looked deeper, so
 truly you are now an open source wizard.

I don't hope you'll commit it as is. I hope you'll send some useful
comments and suggestions to improve the patch (not insults).

Now back to underlying issues: x86emu executes some code which causes
parity check NMI (bit 7 set in port 0x61) to be generated, which causes
drop to the debugger (I mistook it for a panic).

Btw, is it intended to not include isa.h in i386/trap.c? (removed in r.1.35).
Code wrapped in #if NISA  0 is thrown out by cpp now.



Re: arc4random_buf in bcrypt

2012-09-03 Thread Theo de Raadt
Yup.

 There's an easy way to do this now.
 
 Index: bcrypt.c
 ===
 RCS file: /cvs/src/lib/libc/crypt/bcrypt.c,v
 retrieving revision 1.24
 diff -u -p -r1.24 bcrypt.c
 --- bcrypt.c  2 Apr 2008 19:54:05 -   1.24
 +++ bcrypt.c  3 Sep 2012 17:29:48 -
 @@ -148,15 +148,8 @@ char *
  bcrypt_gensalt(u_int8_t log_rounds)
  {
   u_int8_t csalt[BCRYPT_MAXSALT];
 - u_int16_t i;
 - u_int32_t seed = 0;
  
 - for (i = 0; i  BCRYPT_MAXSALT; i++) {
 - if (i % 4 == 0)
 - seed = arc4random();
 - csalt[i] = seed  0xff;
 - seed = seed  8;
 - }
 + arc4random_buf(csalt, sizeof(csalt));
  
   if (log_rounds  4)
   log_rounds = 4;



Re: ThinkPad T60 x86emu panic on resume (w/patch)

2012-09-03 Thread Theo de Raadt
 * Theo de Raadt dera...@cvs.openbsd.org [120903 00:13]:
   Index: vga_pci.c
   ===
   RCS file: /cvs/src/sys/dev/pci/vga_pci.c,v
   retrieving revision 1.68
   diff -u -r1.68 vga_pci.c
   --- vga_pci.c 22 Aug 2012 20:58:30 -  1.68
   +++ vga_pci.c 2 Sep 2012 17:42:09 -
   @@ -186,7 +186,13 @@
 {   0x, 0x, 0x, 0x }, 1, 0
 },

   - {   /* All ATI video until further notice */
   + {   
   + {   PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_X1400,
   + 0x, 0x },
   + {   0x, 0x, 0x, 0x}, 0, 0
   + },
   +
   + {   /* Other ATI video until further notice */
 {   PCI_VENDOR_ATI, 0x,
 0x, 0x },
 {   0x, 0x, 0x, 0x}, 1, 0
  
  
  That's a great patch, because it doesn't find or fix the underlying
  issues.
 
 Thanks.
 
  Then, when the next person -- who's video did need this -- finds out
  it no longer works, they can submit the inverse of your diff -- once
  again not undercovering the real issue.  Of course, now it is their
  problem, not yours, right?
 
 No, he'll add a record above mine with his subproduct/subvendor ids.

I do not agree with that process.

Basically in 10 years we'll have a table full of garbage entries,
which would help only a handful of people.  It is the wrong way to
approach this, and the cvs log already makes that clear.

There is code missing to handle all the types of video we need to
cleanup.  This code you are looking at is not the solution.  It is a
stupid quirk table.

  Your diff can be summarized as make it work for me, me, me, me.
  Awesome work.  You know how to fix it just for yourself and submit a
  self-serving patch, hoping we'll commit it without looked deeper, so
  truly you are now an open source wizard.
 
 I don't hope you'll commit it as is. I hope you'll send some useful
 comments and suggestions to improve the patch (not insults).

We won't commit it.



Re: ThinkPad T60 x86emu panic on resume (w/patch)

2012-09-03 Thread Ted Unangst
On Mon, Sep 03, 2012 at 21:18, Alexander Polakov wrote:

 Now back to underlying issues: x86emu executes some code which causes
 parity check NMI (bit 7 set in port 0x61) to be generated, which causes
 drop to the debugger (I mistook it for a panic).
 
 Btw, is it intended to not include isa.h in i386/trap.c? (removed in r.1.35).
 Code wrapped in #if NISA  0 is thrown out by cpp now.

Probably not, but after 11 years, it doesn't look like we used that
code much. :)  Putting the include back at the top of the file would
be a good diff to propose. (I guess it may have been deleted because
it looks funny in the middle of the file).



[clau...@openbsd.org: graceful restart diff]

2012-09-03 Thread Claudio Jeker
I never got any negative test results back about this change. I assume
that either nobody is interested or that it just works. Since this is
getting in my way of working on bgpd I would like to commit this. So
unless people scream in the next few days it will go in and I will handle
the fallout when it happens.

-- 
:wq Claudio


- Forwarded message from Claudio Jeker clau...@openbsd.org -

Date: Mon, 9 Jul 2012 15:39:17 +0200
From: Claudio Jeker clau...@openbsd.org
To: tech@openbsd.org
Subject: graceful restart diff
Mail-Followup-To: tech@openbsd.org

OK, this is a fixed version of the graceful restart diff I have brewing
for a long long long time. It seems to behave in my bgpd test network but
I would like some wider testing (esp. against routers that do GR).

This implements only the Restarting Client bits of the RFC -- in other
words bgpd will keep the FIB when the client restarts but it will not do GR
when restarting itself. The capability is still off by default (you need
announce restart yes to enable it) and the best is to test first without
GR and if there are no regressions restest with GR enabled.

Make sure to run this on current -current since this needs some of the
recent bgpd commits.
-- 
:wq Claudio

Index: bgpctl/bgpctl.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.c,v
retrieving revision 1.164
diff -u -p -r1.164 bgpctl.c
--- bgpctl/bgpctl.c 27 May 2012 18:53:50 -  1.164
+++ bgpctl/bgpctl.c 8 Jul 2012 10:48:01 -
@@ -52,6 +52,7 @@ intshow_summary_terse_msg(struct imsg
 int show_neighbor_terse(struct imsg *);
 int show_neighbor_msg(struct imsg *, enum neighbor_views);
 voidprint_neighbor_capa_mp(struct peer *);
+voidprint_neighbor_capa_restart(struct peer *);
 voidprint_neighbor_msgstats(struct peer *);
 voidprint_timer(const char *, time_t);
 static char*fmt_timeframe(time_t t);
@@ -168,7 +169,7 @@ main(int argc, char *argv[])
case NONE:
case IRRFILTER:
usage();
-   /* not reached */
+   /* NOTREACHED */
case SHOW:
case SHOW_SUMMARY:
imsg_compose(ibuf, IMSG_CTL_SHOW_NEIGHBOR, 0, 0, -1, NULL, 0);
@@ -648,7 +649,7 @@ show_neighbor_msg(struct imsg *imsg, enu
if (p-capa.peer.mp[i])
hascapamp = 1;
if (hascapamp || p-capa.peer.refresh ||
-   p-capa.peer.restart || p-capa.peer.as4byte) {
+   p-capa.peer.grestart.restart || p-capa.peer.as4byte) {
printf(  Neighbor capabilities:\n);
if (hascapamp) {
printf(Multiprotocol extensions: );
@@ -657,8 +658,11 @@ show_neighbor_msg(struct imsg *imsg, enu
}
if (p-capa.peer.refresh)
printf(Route Refresh\n);
-   if (p-capa.peer.restart)
-   printf(Graceful Restart\n);
+   if (p-capa.peer.grestart.restart) {
+   printf(Graceful Restart);
+   print_neighbor_capa_restart(p);
+   printf(\n);
+   }
if (p-capa.peer.as4byte)
printf(4-byte AS numbers\n);
}
@@ -726,6 +730,28 @@ print_neighbor_capa_mp(struct peer *p)
 }
 
 void
+print_neighbor_capa_restart(struct peer *p)
+{
+   int comma;
+   u_int8_ti;
+
+   if (p-capa.peer.grestart.timeout)
+   printf(: Timeout: %d, , p-capa.peer.grestart.timeout);
+   for (i = 0, comma = 0; i  AID_MAX; i++)
+   if (p-capa.peer.grestart.flags[i]  CAPA_GR_PRESENT) {
+   if (!comma 
+   p-capa.peer.grestart.flags[i]  CAPA_GR_RESTART)
+   printf(restarted, );
+   if (comma)
+   printf(, );
+   printf(%s, aid2str(i));
+   if (p-capa.peer.grestart.flags[i]  CAPA_GR_FORWARD)
+   printf( (preserved));
+   comma = 1;
+   }
+}
+
+void
 print_neighbor_msgstats(struct peer *p)
 {
printf(  Message statistics:\n);
@@ -753,6 +779,8 @@ print_neighbor_msgstats(struct peer *p)
p-stats.prefix_sent_update, p-stats.prefix_rcvd_update);
printf(  %-15s %10llu %10llu\n, Withdraws,
p-stats.prefix_sent_withdraw, p-stats.prefix_rcvd_withdraw);
+   printf(  %-15s %10llu %10llu\n, End-of-Rib,
+   p-stats.prefix_sent_eor, p-stats.prefix_rcvd_eor);
 }
 
 void
@@ -1107,8 +1135,8 @@ show_interface_msg(struct imsg *imsg)
 void
 show_rib_summary_head(void)
 {

Re: Possible bug in timecounter code

2012-09-03 Thread Stefan Fritsch
On Sunday 02 September 2012, s...@sfritsch.de wrote:
 But it may still be a problem the other way round. If adjtimedelta
 would  go to zero during the lost ticks, there will be some
 over-compensation that is not detected.

After some more hints from Mark (thanks), I think this is very 
unlikely to cause a problem in practice, possibly except if running on 
a virtualization host that is overloaded/swapping.



Sync i386 NMI trap code with amd64

2012-09-03 Thread Alexander Polakov
Include isa.h to avoid confusion while reading the code (code wrapped
into #if NISA  0 is thrown out by cpp atm).
No behaviour change, except for additional printf() before entering
the debugger (which I find helpful).
Ignore second chunk if you don't care about i386 and amd64 being the
same.

Btw, amd64/x86_nmi() reads ports which are called historic garbage by
i386/isa_nmi().

Index: trap.c
===
RCS file: /cvs/src/sys/arch/i386/i386/trap.c,v
retrieving revision 1.103
diff -u -r1.103 trap.c
--- trap.c  7 Aug 2012 05:16:53 -   1.103
+++ trap.c  3 Sep 2012 21:49:26 -
@@ -80,6 +80,7 @@
 #endif
 
 #include npx.h
+#include isa.h
 
 void trap(struct trapframe *);
 void syscall(struct trapframe *);
@@ -509,13 +510,12 @@
if (kdb_trap(type, 0, frame))
return;
 #endif
-   return;
 #endif /* DDB || KGDB */
/* machine/parity/power fail/kitchen sink faults */
-   if (isa_nmi() == 0)
-   return;
-   else
+   if (isa_nmi() != 0)
goto we_re_toast;
+   else
+   return;
 #endif
}



Re: inet6 autoconf spl fix

2012-09-03 Thread David Gwynne
yes.

On 02/09/2012, at 8:20 PM, Stefan Sperling s...@openbsd.org wrote:

 prelist_update() runs at IPL_SOFTNET. Code moved out of it into a
 workq task for adding new addresses from process context should
 run at IPL_SOFTNET, too, shouldn't it?
 
 Index: netinet6/nd6_rtr.c
 ===
 RCS file: /cvs/src/sys/netinet6/nd6_rtr.c,v
 retrieving revision 1.62
 diff -u -p -r1.62 nd6_rtr.c
 --- netinet6/nd6_rtr.c28 Aug 2012 20:32:02 -  1.62
 +++ netinet6/nd6_rtr.c2 Sep 2012 10:01:34 -
 @@ -1298,7 +1298,9 @@ nd6_addr_add(void *prptr, void *arg2)
   struct nd_prefix *pr = (struct nd_prefix *)prptr;
   struct in6_ifaddr *ia6 = NULL;
   struct ifaddr *ifa;
 - int ifa_plen, autoconf, privacy;
 + int ifa_plen, autoconf, privacy, s;
 +
 + s = splsoftnet();
 
   autoconf = 1;
   privacy = (pr-ndpr_ifp-if_xflags  IFXF_INET6_NOPRIVACY) == 0;
 @@ -1362,6 +1364,8 @@ nd6_addr_add(void *prptr, void *arg2)
   pfxlist_onlink_check();
 
   pr-ndpr_refcnt--;
 +
 + splx(s);
 }
 
 /*