<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech">
    <title>gmane.os.openbsd.tech</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.tech/28865"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.tech/28864"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.tech/28863"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.tech/28862"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.tech/28861"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.tech/28860"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.tech/28859"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.tech/28858"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.tech/28857"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.tech/28856"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.tech/28855"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.tech/28854"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.tech/28853"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.tech/28852"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.tech/28851"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.tech/28850"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.tech/28849"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.tech/28848"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.tech/28847"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.openbsd.tech/28846"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28865">
    <title>Re: ftp synopsis</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28865</link>
    <description>&lt;pre&gt;
yes, it's a trade off. sacrificing clarity for neatness. but ftp's
synopsis currently looks so bad i thought it was broken when i first
looked at it.

however my diff is not future proof i.e. further additions will
ressurect the problem. for that reason i'm ok with leaving as-is. but i
still prefer my proposal to what's there now.

jmc


&lt;/pre&gt;</description>
    <dc:creator>Jason McIntyre</dc:creator>
    <dc:date>2012-05-26T08:56:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28864">
    <title>No pierdas esta oportunidad de hacerte socio. publicidad   so gid</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28864</link>
    <description>&lt;pre&gt;Deseas hacerte socio de nuestro club y disfrutar de la ciudad, campo y playa?
La Alameda &amp;amp; Hacienda Club te espera...




La Alameda &amp;amp; Hacienda Club
T. 444-9018 / 241-3208

[demime 1.01d removed an attachment of type image/jpeg which had a name of nsubrayada.jpg]

[demime 1.01d removed an attachment of type image/jpeg which had a name of fcruentacion.jpg]

[demime 1.01d removed an attachment of type image/jpeg which had a name of ninexperto.jpg]


&lt;/pre&gt;</description>
    <dc:creator>La Alameda &amp; Hacienda Club</dc:creator>
    <dc:date>2012-05-26T08:21:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28863">
    <title>Re: ftp synopsis</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28863</link>
    <description>&lt;pre&gt;
Hmm, I'd say shortening srcaddr to src makes things less clear.



&lt;/pre&gt;</description>
    <dc:creator>Mark Kettenis</dc:creator>
    <dc:date>2012-05-26T08:10:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28862">
    <title>Re: Memory leak in snmpd(8)</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28862</link>
    <description>&lt;pre&gt;On Thu, May 24, 2012 at 8:16 AM, Kenneth R Westerback
&amp;lt;kwesterback&amp;lt; at &amp;gt;rogers.com&amp;gt; wrote:


Ken,

Your diff looks good to me. I also found a few spots that leak in
pf.c. All combined I've come up with this diff. Ok?


Index: src/usr.sbin/snmpd/mib.c
===================================================================
RCS file: /cvs/src/usr.sbin/snmpd/mib.c,v
retrieving revision 1.52
diff -p -u -r1.52 mib.c
--- src/usr.sbin/snmpd/mib.c20 Mar 2012 03:01:26 -00001.52
+++ src/usr.sbin/snmpd/mib.c26 May 2012 05:14:36 -0000
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1360,7 +1360,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; int mib_carpstats(struct oid *, struct
 int mib_carpiftable(struct oid *, struct ber_oid *, struct ber_element **);
 int mib_carpifnum(struct oid *, struct ber_oid *, struct ber_element **);
 struct carpif
-*mib_carpifget(struct carpif *, u_int);
+*mib_carpifget(u_int);
 int mib_memiftable(struct oid *, struct ber_oid *, struct ber_element **);

 static struct oid openbsd_mib[] = {
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -2647,9 +2647,10 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; mib_carpifnum(struct oid *oid, struct be
 }

 struct carpif *
-mi&lt;/pre&gt;</description>
    <dc:creator>Joel Knight</dc:creator>
    <dc:date>2012-05-26T05:35:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28861">
    <title>Viva una experiencia exclusiva con Diners Club. publicidad   bi bem</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28861</link>
    <description>&lt;pre&gt;
[demime 1.01d removed an attachment of type image/jpeg which had a name of fprimipara.jpg]

[demime 1.01d removed an attachment of type image/jpeg which had a name of dmultiflora.jpg]

[demime 1.01d removed an attachment of type image/jpeg which had a name of facineroso.jpg]


&lt;/pre&gt;</description>
    <dc:creator>DINERS CLUB</dc:creator>
    <dc:date>2012-05-26T03:49:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28860">
    <title>Re: Intel Atom E600 watchdog(4) support</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28860</link>
    <description>&lt;pre&gt;* Miod Vallat &amp;lt;miod&amp;lt; at &amp;gt;online.fr&amp;gt; [2012-05-24 09:30:37]:

Third time lucky, I've renamed the driver to tcpcib, (as much as I'd
love to call it yapcib ;-).

Theo suggested I add code to handle suspend/resume so I've done that
although I can't test it as my net6501 doesn't suspend, although the
code simply stops the watchdog if it's running at suspend time and
starts it up again come resume time. I presume that's ok?

I also documented the maximum period supported by the watchdog timer
and also made a note of the lack of driver support for any other parts
of the hardware.

Matt

--- /dev/nullThu May 24 22:49:02 2012
+++ /usr/src/sys/dev/pci/tcpcib.cThu May 24 22:48:17 2012
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -0,0 +1,264 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
+/*$OpenBSD$*/
+
+/*
+ * Copyright (c) 2012 Matt Dainty &amp;lt;matt&amp;lt; at &amp;gt;bodgit-n-scarper.com&amp;gt;
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTW&lt;/pre&gt;</description>
    <dc:creator>Matt Dainty</dc:creator>
    <dc:date>2012-05-26T00:23:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28859">
    <title>ftp synopsis</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28859</link>
    <description>&lt;pre&gt;the size of ftp's synopsis is making it very ugly. any objections to
shortening it? i.e. this diff is cosmetic.

jmc

Index: ftp.1
===================================================================
RCS file: /cvs/src/usr.bin/ftp/ftp.1,v
retrieving revision 1.82
diff -u -r1.82 ftp.1
--- ftp.130 Apr 2012 13:41:26 -00001.82
+++ ftp.125 May 2012 20:44:52 -0000
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -39,17 +39,17 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 .Sh SYNOPSIS
 .Nm ftp
 .Op Fl 46AadEegimnptVv
-.Op Fl k Ar seconds
+.Op Fl k Ar sec
 .Op Fl P Ar port
-.Op Fl r Ar seconds
-.Op Fl s Ar srcaddr
+.Op Fl r Ar sec
+.Op Fl s Ar src
 .Op Ar host Op Ar port
 .Nm ftp
 .Op Fl C
-.Op Fl o Ar output
-.Op Fl s Ar srcaddr
+.Op Fl o Ar out
+.Op Fl s Ar src
 .Sm off
-.No ftp:// Oo Ar user : password No &amp;lt; at &amp;gt;
+.No ftp:// Oo Ar user : pass No &amp;lt; at &amp;gt;
 .Oc Ar host Oo : Ar port
 .Oc No / Ar file Oo /
 .Oc
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -58,8 +58,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 .Nm ftp
 .Op Fl C
 .Op Fl c Ar cookie
-.Op Fl o Ar output
-.Op Fl s Ar srcaddr
+.Op Fl o Ar out
+.Op Fl s Ar src
 .Sm off
 .No http:// Ar host Oo : Ar port
 .Oc No / Ar file
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -68,8 +68,&lt;/pre&gt;</description>
    <dc:creator>Jason McIntyre</dc:creator>
    <dc:date>2012-05-25T20:47:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28858">
    <title>mg history and window relocation</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28858</link>
    <description>&lt;pre&gt;Move the windows section in the tutorial to a more sensible place
(next to buffers) and move the mg history into the README file which
seems a more sensible place as well.

ok?

-lum

Index: README
===================================================================
RCS file: /cvs/src/usr.bin/mg/README,v
retrieving revision 1.9
diff -u -p -r1.9 README
--- README11 Apr 2012 17:51:10 -00001.9
+++ README25 May 2012 10:30:31 -0000
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -40,8 +40,16 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; People who have worked on previous versi
 
 rtech!daveb&amp;lt; at &amp;gt;sun.comDave Brower
 
-Currently maintained in the OpenBSD src tree, with contributions from
-many others.
+Early release history:
+
+* Nov 16, 1986: First release to mod.sources
+* Mar 3, 1987: First Release (mg1a) via comp.sources.unix
+* May 26, 1988: Second release: (mg2a) via comp.sources.misc
+* Jan 26, 1992: Linux port released by Charles Hedrick. This version
+  later makes its way onto tsx-11, Infomagic, and various other Linux
+  repositories.
+* Feb 25, 2000: First import into the OpenBSD tree, wh&lt;/pre&gt;</description>
    <dc:creator>Mark Lumsden</dc:creator>
    <dc:date>2012-05-25T10:39:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28857">
    <title>mg end of buffer page down diff</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28857</link>
    <description>&lt;pre&gt;When you page down a document and get to the last page, mg doesn't
stop, it keeps going until the last line is at the top of the window.
This diff makes mg stop paging down when the end of the text is
visible. 

Comments/ok?

-lum
ps some whitespace for readability added. 

Index: basic.c
===================================================================
RCS file: /cvs/src/usr.bin/mg/basic.c,v
retrieving revision 1.30
diff -u -p -r1.30 basic.c
--- basic.c4 Jun 2009 02:23:37 -00001.30
+++ basic.c25 May 2012 07:40:33 -0000
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -266,16 +266,20 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; forwpage(int f, int n)
 n = 1;/* if tiny window. */
 } else if (n &amp;lt; 0)
 return (backpage(f | FFRAND, -n));
+
 lp = curwp-&amp;gt;w_linep;
-while (n-- &amp;amp;&amp;amp; lforw(lp) != curbp-&amp;gt;b_headp) {
-lp = lforw(lp);
-}
+while (n--)
+if ((lp = lforw(lp)) == curbp-&amp;gt;b_headp)
+return(TRUE);
+
 curwp-&amp;gt;w_linep = lp;
 curwp-&amp;gt;w_rflag |= WFFULL;
+
 /* if in current window, don't move dot */
-for (n = curwp-&amp;gt;w_ntrows; n-- &amp;amp;&amp;amp; lp != curbp-&amp;gt;b_headp; lp = lforw(lp))
+for (n =&lt;/pre&gt;</description>
    <dc:creator>Mark Lumsden</dc:creator>
    <dc:date>2012-05-25T08:16:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28856">
    <title>Aromatizador automatico 57% OFF | Pochoclera Automatica 53% OFF | Juego de Cocina 51% OFF  | Cuchillo Deli Pro  60% OFF | Test de Alcoholemia 67% OFF | Cena Gourmet 52% OFF</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28856</link>
    <description>&lt;pre&gt;Para visualizar correctamente este newsletter ingresa a
http://news1.bonuscupon.com.ar/r.html?uid=1.j.295h.9y.2ij1azebm9


&lt;/pre&gt;</description>
    <dc:creator>Bonus Cupon</dc:creator>
    <dc:date>2012-05-24T23:57:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28855">
    <title>Bocaditos y Mini Sándwiches por Delivery. publicidad   mo son</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28855</link>
    <description>&lt;pre&gt;
[demime 1.01d removed an attachment of type image/jpeg which had a name of fcraniano.jpg]

[demime 1.01d removed an attachment of type image/jpeg which had a name of anhelante.jpg]

[demime 1.01d removed an attachment of type image/jpeg which had a name of ndesventajosa.jpg]

[demime 1.01d removed an attachment of type image/jpeg which had a name of tverdeceledon.jpg]

[demime 1.01d removed an attachment of type image/jpeg which had a name of ecuestre.jpg]

[demime 1.01d removed an attachment of type image/jpeg which had a name of cfrancolina.jpg]

[demime 1.01d removed an attachment of type image/jpeg which had a name of flaqueado.jpg]


&lt;/pre&gt;</description>
    <dc:creator>Montecristo Café·Restaurante  </dc:creator>
    <dc:date>2012-05-24T22:20:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28854">
    <title>Re: mg - start up file diffs (2 of 2)</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28854</link>
    <description>&lt;pre&gt;
So its good to test.

Here is an updated diff, which DOES update any set-default-modes.

-lum

Index: main.c
===================================================================
RCS file: /cvs/src/usr.bin/mg/main.c,v
retrieving revision 1.64
diff -u -p -r1.64 main.c
--- main.c12 Apr 2012 04:47:59 -00001.64
+++ main.c24 May 2012 15:15:34 -0000
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -98,19 +98,28 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; main(int argc, char **argv)
  */
 update();
 
-/* user startup file */
-if ((cp = startupfile(NULL)) != NULL)
-(void)load(cp);
-
 /*
  * Create scratch buffer now, killing old *init* buffer.
- * This causes *scratch* to be created and made curbp,
- * ensuring default modes are inherited from the startup
- * file correctly
+ * This causes *scratch* to be created and made curbp.
  */
-
 if ((bp = bfind("*init*", FALSE)) != NULL)
 killbuffer(bp);
+
+/* user startup file. */
+if ((cp = startupfile(NULL)) != NULL)
+(void)load(cp);
+
+/* 
+ * Now ensure any default buffer modes from the startup file are
+ * given to any files open&lt;/pre&gt;</description>
    <dc:creator>Mark Lumsden</dc:creator>
    <dc:date>2012-05-24T15:24:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28853">
    <title>Re: Memory leak in snmpd(8)</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28853</link>
    <description>&lt;pre&gt;On Thu, 24 May 2012 16:16:02 +0200, Kenneth R Westerback
&amp;lt;kwesterback&amp;lt; at &amp;gt;rogers.com&amp;gt; wrote:

Hi Ken,

I like your patch; it's better than mine.

And you are right about the socket fd leak. If an ioctl()
would close the filedes passed in that would be a very
awkward API.

Gerhard

--
GeNUA, Gesellschaft fC&amp;lt;r Netzwerk- und Unix-Administration mbH
Domagkstrasse 7, 85551 Kirchheim bei Muenchen
tel +49 89 991950-0, fax -999, www.genua.de
Geschaeftsfuehrer: Dr. Magnus Harlander, Dr. Michaela Harlander,
Bernhard Schneck. Amtsgericht Muenchen HRB 98238


&lt;/pre&gt;</description>
    <dc:creator>Gerhard Roth</dc:creator>
    <dc:date>2012-05-24T14:33:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28852">
    <title>Re: Memory leak in snmpd(8)</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28852</link>
    <description>&lt;pre&gt;
Calling mib_carpget() seems a tad over complex. Wouldn't the diff
below make it cleaner? Untested except by gcc.

And doesn't the socket 's' leak too, or does SIOCGVH returning -1
mean 's' was closed?

.... Ken

Index: mib.c
===================================================================
RCS file: /cvs/src/usr.sbin/snmpd/mib.c,v
retrieving revision 1.52
diff -u -p -r1.52 mib.c
--- mib.c20 Mar 2012 03:01:26 -00001.52
+++ mib.c24 May 2012 14:11:22 -0000
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1360,7 +1360,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; int mib_carpstats(struct oid *, struct 
 int mib_carpiftable(struct oid *, struct ber_oid *, struct ber_element **);
 int mib_carpifnum(struct oid *, struct ber_oid *, struct ber_element **);
 struct carpif
-*mib_carpifget(struct carpif *, u_int);
+*mib_carpifget(u_int);
 int mib_memiftable(struct oid *, struct ber_oid *, struct ber_element **);
 
 static struct oid openbsd_mib[] = {
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -2647,9 +2647,10 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; mib_carpifnum(struct oid *oid, struct be
 }
 
 struct carpif *
-mib_carpifget(struct carpif *cif, u_int idx)
+mib_carpifg&lt;/pre&gt;</description>
    <dc:creator>Kenneth R Westerback</dc:creator>
    <dc:date>2012-05-24T14:16:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28851">
    <title>Re: Intel Atom E600 watchdog(4) support</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28851</link>
    <description>&lt;pre&gt;
Come on. It obviously has to be "yapcib" since it's yet another pcib.

Miod


&lt;/pre&gt;</description>
    <dc:creator>Miod Vallat</dc:creator>
    <dc:date>2012-05-24T13:30:33</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28850">
    <title>Re: Intel Atom E600 watchdog(4) support</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28850</link>
    <description>&lt;pre&gt; &amp;lt;mitja&amp;lt; at &amp;gt;muzenic.net&amp;gt; [2012-05-24 07:23:22]:

We typically prefer shorter names.  tcpcib might not be such a bad name.


&lt;/pre&gt;</description>
    <dc:creator>Mark Kettenis</dc:creator>
    <dc:date>2012-05-24T13:08:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28849">
    <title>Re: Intel Atom E600 watchdog(4) support</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28849</link>
    <description>&lt;pre&gt;* Mitja MuE&amp;gt;eniD
 &amp;lt;mitja&amp;lt; at &amp;gt;muzenic.net&amp;gt; [2012-05-24 07:23:22]:

Looking at the watchdog code, it looks like the kernel will refresh the
timer every period / 2, so for a 60 second timeout, it could fire
anywhere between 30-60 seconds after the host hangs.


Yes, that makes sense.


Better than esixhundredpcib ;-)

Does anyone have any suggestions? e6xxpcib? atompcib? iatcpcib?

Matt


&lt;/pre&gt;</description>
    <dc:creator>Matt Dainty</dc:creator>
    <dc:date>2012-05-24T12:47:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28848">
    <title>Memory leak in snmpd(8)</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28848</link>
    <description>&lt;pre&gt;Hi,

with the OPENBSD-CARP-MIB a memory leak was introduced to snmpd(8):

RCS file: mib.c,v
retrieving revision 1.52
diff -u -p -r1.52 mib.c
--- mib.c       2012/03/20 03:01:26     1.52
+++ mib.c       2012/05/24 12:53:35
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -2713,7 +2713,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; mib_carpiftable(struct oid *oid, struct ber_oid *o,
st
         /* Get and verify the current row index */
         idx = o-&amp;gt;bo_id[OIDIDX_carpIfEntry];

-       if ((cif = mib_carpifget(cif, idx)) == NULL) {
+       if (mib_carpifget(cif, idx) == NULL) {
                 free(cif);
                 return (1);
         }


Gerhard

--
GeNUA, Gesellschaft fC&amp;lt;r Netzwerk- und Unix-Administration mbH
Domagkstrasse 7, 85551 Kirchheim bei Muenchen
tel +49 89 991950-0, fax -999, www.genua.de
Geschaeftsfuehrer: Dr. Magnus Harlander, Dr. Michaela Harlander,
Bernhard Schneck. Amtsgericht Muenchen HRB 98238


&lt;/pre&gt;</description>
    <dc:creator>Gerhard Roth</dc:creator>
    <dc:date>2012-05-24T11:54:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28847">
    <title>Re: Intel Atom E600 watchdog(4) support</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28847</link>
    <description>&lt;pre&gt;
No, pchpcib is inappropriate.  This device is part of the CPU itself,
not on EG20T Platform Controller Hub companion chip.



&lt;/pre&gt;</description>
    <dc:creator>Mark Kettenis</dc:creator>
    <dc:date>2012-05-24T11:25:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28846">
    <title>Re: Intel Atom E600 watchdog(4) support</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28846</link>
    <description>&lt;pre&gt;Works for me on net6501 on i386 GENERIC and GENERIC.MP

after a succesfull watchdog fire:

e600pcib0 at pci0 dev 31 function 0 "Intel E600 LPC" rev 0x00: watchdog,
reboot on timeout

It did fire a bit too early though, my watchdog period was set to 32 seconds
and the machine did reset after 26 seconds on my stopwatch. Similarly, with
a 60 second period it fired after ~50 seconds. Don't know if it really
matters though....

Finally, can you mention that the valid period range is 1-600 seconds? The
code does it right by silently lowering a too-high period to 600, but it
would be nice to have it mentioned in the manpages too.

[msata] # sysctl kern.watchdog.period=1
kern.watchdog.period: 0 -&amp;gt; 1
[msata] # sysctl kern.watchdog.period
kern.watchdog.period=1
[msata] # sysctl kern.watchdog.period=10000
kern.watchdog.period: 1 -&amp;gt; 10000
[msata] # sysctl kern.watchdog.period
kern.watchdog.period=600

Regards, Mitja

P.S. While I was composing this reply some other mails have come through.
How about esixoopcib ? :)

Add&lt;/pre&gt;</description>
    <dc:creator>Mitja Muženič</dc:creator>
    <dc:date>2012-05-24T11:21:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.openbsd.tech/28845">
    <title>Re: Intel Atom E600 watchdog(4) support</title>
    <link>http://permalink.gmane.org/gmane.os.openbsd.tech/28845</link>
    <description>&lt;pre&gt;
heh, my bad, i had doubts that wdt was actually part of the cpu...


&lt;/pre&gt;</description>
    <dc:creator>Mike Belopuhov</dc:creator>
    <dc:date>2012-05-24T11:16:15</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.os.openbsd.tech">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.os.openbsd.tech</link>
  </textinput>
</rdf:RDF>

