<?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://blog.gmane.org/gmane.os.openbsd.tech">
    <title>gmane.os.openbsd.tech</title>
    <link>http://blog.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://comments.gmane.org/gmane.os.openbsd.tech/32918"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.openbsd.tech/32915"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.openbsd.tech/32914"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.openbsd.tech/32907"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.openbsd.tech/32905"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.openbsd.tech/32904"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.openbsd.tech/32901"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.openbsd.tech/32900"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.openbsd.tech/32899"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.openbsd.tech/32896"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.openbsd.tech/32894"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.openbsd.tech/32888"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.openbsd.tech/32887"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.openbsd.tech/32885"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.openbsd.tech/32884"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.openbsd.tech/32875"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.openbsd.tech/32870"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.openbsd.tech/32869"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.openbsd.tech/32868"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.openbsd.tech/32867"/>
      </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://comments.gmane.org/gmane.os.openbsd.tech/32918">
    <title>THANKS TO ALL</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32918</link>
    <description>&lt;pre&gt;Thank to All.


&lt;/pre&gt;</description>
    <dc:creator>Max Power</dc:creator>
    <dc:date>2013-06-18T19:55:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.openbsd.tech/32915">
    <title>My name in tech mailing list archives.</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32915</link>
    <description>&lt;pre&gt;Hi guys.
I have not figured out how to show my name in the tech mailing list archives.

I want to show: Max Power &amp;lt;laboratory&amp;lt; at &amp;gt;cpnetserver.net&amp;gt;
how can I do?

Thanks, Max Power.


&lt;/pre&gt;</description>
    <dc:creator>laboratory&lt; at &gt;cpnetserver.net</dc:creator>
    <dc:date>2013-06-18T19:46:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.openbsd.tech/32914">
    <title>Thank You very much Matthew, Vijay, Otto, Ryan, etc. etc.</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32914</link>
    <description>&lt;pre&gt;Thank You very much Matthew, Vijay, Otto, Ryan
You are really very very kind, Max Power.





&lt;/pre&gt;</description>
    <dc:creator>laboratory&lt; at &gt;cpnetserver.net</dc:creator>
    <dc:date>2013-06-18T18:18:49</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.openbsd.tech/32907">
    <title>fsck vs fsck_ffs   WHAT'S THE DIFFERENCE?</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32907</link>
    <description>&lt;pre&gt;Hi guys!
Please, What is the difference between 'fsck' and 'fsck_ffs' command?


Thanks, Max Power.


&lt;/pre&gt;</description>
    <dc:creator>laboratory&lt; at &gt;cpnetserver.net</dc:creator>
    <dc:date>2013-06-18T18:04:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.openbsd.tech/32905">
    <title>udp route-to without to clause</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32905</link>
    <description>&lt;pre&gt;Hosting a voip server behind OpenBSD with the following pf.conf file
led to some surprising behaviour:

voice_if = em0
data_if= vr0
ext_if = vr3
PBX = "192.168.234.200"
voip_ports = "10000:40000"
table &amp;lt;remote_phones&amp;gt; persist { .... }
match out on $ext_if from { $voice_if:network, $data_if:network } \
    to any nat-to $ext_if static-port
pass out allow-opts flags S/SA modulate state
pass in proto udp on $ext_if from &amp;lt;remote_phones&amp;gt; \
    port {sip,$voip_ports} rdr-to $PBX

Notice the last rule does NOT include a "to" clause, as seen in the
pools faq http://www.openbsd.org/faq/pf/pools.html.

The surprise was when udp traffic on ports 10000:40000 was not coming
through and tcdump on $ext_if showed "icmp port unreachable" being
sent back. Adding "to $ext_if" to the last rule fixed it immediately:

pass in proto udp on $ext_if from &amp;lt;remote_phones&amp;gt; \
    to $ext_if port {sip,$voip_ports} rdr-to $PBX


If this is by design, please explain!

If the "to" clause is always required with rdr-to, then the man page
sho&lt;/pre&gt;</description>
    <dc:creator>Ryan Slack</dc:creator>
    <dc:date>2013-06-17T21:22:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.openbsd.tech/32904">
    <title>inetd chargen diff</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32904</link>
    <description>&lt;pre&gt;first part removes deadstore.
second part fixes using 'rs' as uninitalized.
 
Index: inetd.c
===================================================================
RCS file: /cvs/src/usr.sbin/inetd/inetd.c,v
retrieving revision 1.135
diff -u -p -r1.135 inetd.c
--- inetd.c19 Apr 2013 18:03:16 -00001.135
+++ inetd.c17 Jun 2013 18:46:20 -0000
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1678,10 +1678,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; chargen_stream(int s, struct servtab *se
 
 inetd_setproctitle(sep-&amp;gt;se_service, s);
 
-if (!endring) {
+if (!endring)
 initring();
-rs = ring;
-}
 
 text[LINESIZ] = '\r';
 text[LINESIZ + 1] = '\n';
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1710,10 +1708,9 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; chargen_dg(int s, struct servtab *sep)
 socklen_t size;
 char text[LINESIZ+2];
 
-if (endring == 0) {
+if (endring == 0)
 initring();
-rs = ring;
-}
+rs = ring;
 
 size = sizeof(ss);
 if (recvfrom(s, text, sizeof(text), 0, (struct sockaddr *)&amp;amp;ss,


&lt;/pre&gt;</description>
    <dc:creator>David Hill</dc:creator>
    <dc:date>2013-06-17T18:47:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.openbsd.tech/32901">
    <title>fixed: race in dpb fetch</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32901</link>
    <description>&lt;pre&gt;quite a few people have seen that one, where fetch grabs a file, and
the main engine starts building while the file is not there yet.

What actually happened is that there was some misguided caching optimization
with respect to fetch objects, and the object was marked as okay as soon
as we asserted the checksum was alright... and the main engine would fire
up the build. BUT fetch actually stages the fetch into a file.part temporary
file, and moves it to the actual file name as a last step (*after* the
checksum was verified), so you ended up with the object saying "okay,
I'm cheksummed (the temp file is okay), the build engine starting the build,
re-checksumming the same file (hey, it's not in the cache) and either failing
(okay the file has not been moved yet) or checksumming it for nothing (the
rename and cache move happened too late)...

The diagnostic specifics took longer than the actual fix...

*IF* you still see fetch trouble in dpb, then that would *definitely* be
NFS's fault. :)


&lt;/pre&gt;</description>
    <dc:creator>Marc Espie</dc:creator>
    <dc:date>2013-06-16T19:10:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.openbsd.tech/32900">
    <title>Show multicast groups joined?</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32900</link>
    <description>&lt;pre&gt;Folks,

What would be the appropriate command to show the IPv6 multicast groups
joined by all/each interface?

(FWIW, I'm looking for something similar to FreeBSD's "ifmcstat(8)" or
Linux's "ip -6 maddr show").

Thanks in advance!
&lt;/pre&gt;</description>
    <dc:creator>Fernando Gont</dc:creator>
    <dc:date>2013-06-16T13:23:34</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.openbsd.tech/32899">
    <title>SOFTRAID PROBLEM: SOLVED!!</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32899</link>
    <description>&lt;pre&gt;Ciao Otto, Alexander...

Solved! I attached disks after installation of the operating system and everything was resolved.

Thank You, Max Power.


&lt;/pre&gt;</description>
    <dc:creator>laboratory&lt; at &gt;cpnetserver.net</dc:creator>
    <dc:date>2013-06-16T09:47:19</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.openbsd.tech/32896">
    <title>SOFTRAID PROBLEM</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32896</link>
    <description>&lt;pre&gt;Hi,
after using some hard-drive with softraid in raid5,
I can no longer reset them. All disks the same problem...
When I try to delete raid partition disklabel reports:
With the command:
disklabel -E wd1, after any changes [ after q option ], return:

disklabel: ioctl DIOCWDINFO open partition would move or shrink
disklabel: unable to write label

--------------------------------------------------------------------------------------

The disks works fine with other operating system [ex. linux[ext4], windows[ntfs]].

The problem is only with OpenBSD [5.3 amd64].
Of course I reformatted the disk system and reinstalled everything but nothing.

I tried with:
- fdisk -iy wd1;
- dd if=/dev/zero of=/dev/rwd1c bs=1m count=1

but when I launch the command: disklabel wd1
I always find the [a] RAID partition and
and do not remove it and do not delete!!
---------------------------------------------------------------------------------------

How can I delete this partition?

Help me please. Thanks for the help,
MAXPOWER.&lt;/pre&gt;</description>
    <dc:creator>laboratory&lt; at &gt;cpnetserver.net</dc:creator>
    <dc:date>2013-06-16T05:57:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.openbsd.tech/32894">
    <title>sgi: enable 24-bit audio on mavb(4) devices</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32894</link>
    <description>&lt;pre&gt;This is a small diff to enable mavb(4) 24-bit native format. To
test it, first check that audio works without the diff. Then, apply
the diff, kill sndiod, and run it as:

sndiod -dd -e s24be4lsb

then play any audio file; sndiod should log something like:

snd0: 48000Hz, s24be4lsb, play 0:1, rec 0:1, 9 blocks of 960 frames

does it? if so, does it sound right?

Thanks!

&lt;/pre&gt;</description>
    <dc:creator>Alexandre Ratchov</dc:creator>
    <dc:date>2013-06-15T11:40:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.openbsd.tech/32888">
    <title>variable initialisation for userland program</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32888</link>
    <description>&lt;pre&gt;Hello

Does the chain automatically set a parameter so C var are set to zero by
default ?

curl http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/nc/netcat
.c?rev=1.112;content-type=text%2Fplain &amp;gt; grep Sflag

If I compile this in release Slfag has a random value when tested or the
value 1 if the flag -S is set.

Or is it because the kernel do some kind of calloc instead of malloc while
loading process ? so it is always zero memmory.

Cheers.

&lt;/pre&gt;</description>
    <dc:creator>sven falempin</dc:creator>
    <dc:date>2013-06-14T13:48:19</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.openbsd.tech/32887">
    <title>bge diff needs testing</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32887</link>
    <description>&lt;pre&gt;Hi,

David Imhoff has found that flow control got broken in bge
after some recent changes but also that simple "ifconfig bge0"
call done by any user can change current flow control settings.
We've tested it on a bunch of recent cards (5719, 5720), one
old-ish card (5715) but would like others to make sure their
bge's are running fine with this.  Changes must be visible
under substantial load from multiple clients.

An elaborate explanation from David:

---------8&amp;lt;---------

If auto polling is disabled bge_link_upd() &amp;lt; at &amp;gt;l4546 does a call to
mii_pollstat() followed by a explicit call to bge_miibus_statchg().
However bge_miibus_statchg() is also called implicitly from
mii_pollstat() -&amp;gt; brgphy_service(,, MII_POLLSTAT) -&amp;gt; mii_phy_update().

bge_miibus_statchg() &amp;lt; at &amp;gt;l1056 obtains the flow control state from
mii-&amp;gt;mii_media_active and afterwards removes the flow control information
from mii-&amp;gt;mii_media_active. So the second time bge_miibus_statchg() is
called the flow control flags in mii-&amp;gt;mii_media_active are always zero&lt;/pre&gt;</description>
    <dc:creator>Mike Belopuhov</dc:creator>
    <dc:date>2013-06-13T16:09:15</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.openbsd.tech/32885">
    <title>bge: fixup the random tx backoff seed mask</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32885</link>
    <description>&lt;pre&gt;NetBSD and Broadcom docs (5718-PG106-R.pdf and 57XX-PG105-R.pdf)
and even our bnx(4) driver (and it's spec) agree that the mask
should be 0x3ff.

OK?

diff --git sys/dev/pci/if_bgereg.h sys/dev/pci/if_bgereg.h
index 3685f14..c0a28b9 100644
--- sys/dev/pci/if_bgereg.h
+++ sys/dev/pci/if_bgereg.h
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -720,11 +720,11 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 #defineBGE_LEDCTL_TRADLED_STS0x00000400
 #defineBGE_LEDCTL_BLINKPERIOD0x7FF80000
 #defineBGE_LEDCTL_BLINKPERIOD_OVERRIDE0x80000000
 
 /* TX backoff seed register */
-#defineBGE_TX_BACKOFF_SEED_MASK0x3F
+#defineBGE_TX_BACKOFF_SEED_MASK0x3FF
 
 /* Autopoll status register */
 #defineBGE_AUTOPOLLSTS_ERROR0x00000001
 
 /* Transmit MAC mode register */


&lt;/pre&gt;</description>
    <dc:creator>Mike Belopuhov</dc:creator>
    <dc:date>2013-06-12T12:50:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.openbsd.tech/32884">
    <title>want to subscribe tech&lt; at &gt;openbsd.org</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32884</link>
    <description>&lt;pre&gt;want to subscribe tech&amp;lt; at &amp;gt;openbsd.org

Михаил Швецов.

&lt;/pre&gt;</description>
    <dc:creator>Михаил Швецов</dc:creator>
    <dc:date>2013-06-12T12:23:05</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.openbsd.tech/32875">
    <title>brgphy diff to test on fiber bge(4)</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32875</link>
    <description>&lt;pre&gt;Hi,

Could someone with a fiber bge give the diff below a spin.
The code chunk in question should not be run for fiber PHYs.
There's no change in functionality for non-optical transmitters.

http://svnweb.freebsd.org/base/head/sys/dev/mii/brgphy.c?r1=244480&amp;amp;r2=244481

OK's are welcome as well.


diff --git sys/dev/mii/brgphy.c sys/dev/mii/brgphy.c
index fe39a3e..5e18795 100644
--- sys/dev/mii/brgphy.c
+++ sys/dev/mii/brgphy.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -720,26 +720,25 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; brgphy_mii_phy_auto(struct mii_softc *sc)
 if (sc-&amp;gt;mii_flags &amp;amp; MIIF_DOPAUSE)
 anar |= BRGPHY_SERDES_ANAR_BOTH_PAUSE;
 PHY_WRITE(sc, BRGPHY_SERDES_ANAR, anar);
 } else {
 anar = BMSR_MEDIA_TO_ANAR(sc-&amp;gt;mii_capabilities) | ANAR_CSMA;
 if (sc-&amp;gt;mii_flags &amp;amp; MIIF_DOPAUSE)
 anar |= BRGPHY_ANAR_ASP | BRGPHY_ANAR_PC;
 PHY_WRITE(sc, BRGPHY_MII_ANAR, anar);
+/* Enable speed in the 1000baseT control register */
+ktcr = BRGPHY_1000CTL_AFD | BRGPHY_1000CTL_AHD;
+if (sc-&amp;gt;mii_oui == MII_OUI_xxBROADCOM &amp;amp;&amp;amp;
+    sc-&amp;gt;mii_model == MII_MODEL_xxBROADCOM_BCM5701)
+&lt;/pre&gt;</description>
    <dc:creator>Mike Belopuhov</dc:creator>
    <dc:date>2013-06-10T15:43:44</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.openbsd.tech/32870">
    <title>enable cmp macro for rb-trees in sys/tree.h</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32870</link>
    <description>&lt;pre&gt;Hi,

I've had this patch in my tree for a while.  It's just a consistency
fix so that cmp can be a plain macro for rb-trees, too.


Regards,
Franco

Index: tree.h
===================================================================
RCS file: /OpenBSD/src/sys/sys/tree.h,v
retrieving revision 1.13
diff -u -r1.13 tree.h
--- tree.h9 Jul 2011 00:19:45 -00001.13
+++ tree.h9 Jun 2013 19:02:37 -0000
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -622,7 +622,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 struct type *tmp = RB_ROOT(head);\
 int comp;\
 while (tmp) {\
-comp = cmp(elm, tmp);\
+comp = (cmp)(elm, tmp);\
 if (comp &amp;lt; 0)\
 tmp = RB_LEFT(tmp, field);\
 else if (comp &amp;gt; 0)\
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -641,7 +641,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 struct type *res = NULL;\
 int comp;\
 while (tmp) {\
-comp = cmp(elm, tmp);\
+comp = (cmp)(elm, tmp);\
 if (comp &amp;lt; 0) {\
 res = tmp;\
 tmp = RB_LEFT(tmp, field);\


&lt;/pre&gt;</description>
    <dc:creator>Franco Fichtner</dc:creator>
    <dc:date>2013-06-09T22:22:19</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.openbsd.tech/32869">
    <title>fix guard define</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32869</link>
    <description>&lt;pre&gt;Hi,

found this while reading up on recent changes to -current.
Genuine cvs diff this time.  ;)


Regards,
Franco

Index: octeonreg.h
===================================================================
RCS file: /cvs/src/sys/arch/octeon/include/octeonreg.h,v
retrieving revision 1.1
diff -u -r1.1 octeonreg.h
--- octeonreg.h2 Jun 2013 20:29:36 -00001.1
+++ octeonreg.h9 Jun 2013 18:07:34 -0000
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -27,7 +27,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
  */
 
 #ifndef _MACHINE_OCTEONREG_H_
-#define _MACHINE_OCTEONREG_H
+#define _MACHINE_OCTEONREG_H_
 
 #define OCTEON_CF_BASE0x1D000800ULL
 #define OCTEON_CIU_BASE0x1070000000000ULL


&lt;/pre&gt;</description>
    <dc:creator>Franco Fichtner</dc:creator>
    <dc:date>2013-06-09T20:46:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.openbsd.tech/32868">
    <title>Still More Secrets of Buffer Cache Enlargement.</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32868</link>
    <description>&lt;pre&gt;Greetings all, 

Here's an up to date version of the buffer flipper that installs
on post hackathon -current. 

This diff (~beck/viagra.diff15) contains one important change from
the previous version - In the old cache, as buffers were never freed, 
we would put B_INVAL buffers in the cache at the head of the clean LRU. 
(B_INVAL buffers do not contain cachable data - so for example when a
remove happens and a file's link count drops to 0, all it's buffers 
are marked B_INVAL). 

I noticed after some work with tedu at the end of the hackathon that
we kept a lot of data in cache for removed files - it was because of
this - and moving to the head of the LRU (behaviour that has been
retained since the old static buffer cache) does not make sense with
the modern dynamic one - so this diff has changed it to free the
B_INVAL buffers right away instead of cacheing them. 

I'm running this on multiple arches and on my nfs servers feeding them. 

-Bob


On Mon, Jun 03, 2013 at 09:20:08AM -0600, Bob Beck wrote:

Index&lt;/pre&gt;</description>
    <dc:creator>Bob Beck</dc:creator>
    <dc:date>2013-06-09T18:37:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.openbsd.tech/32867">
    <title>in6_unlink_ifa: interface address has no prefix</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32867</link>
    <description>&lt;pre&gt;Hi,

I have this as /etc/hostname.lo1:

inet 172.26.153.50 0xffffff00 NONE mtu 1398

!route add 172.26.153.0/24 172.26.153.50
!route add default 172.26.153.50 -priority 12

and see the following on boot:

in6_unlink_ifa: interface address 0xffff800000624a00 has no prefix
in6_unlink_ifa: interface address 0xffff800000624a00 has no prefix

by adding -inet6 to the first line I can work around this warning.


Christopher


&lt;/pre&gt;</description>
    <dc:creator>Christopher Zimmermann</dc:creator>
    <dc:date>2013-06-09T16:34:27</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.openbsd.tech/32863">
    <title>axe.4 typo</title>
    <link>http://comments.gmane.org/gmane.os.openbsd.tech/32863</link>
    <description>&lt;pre&gt;According to http://www.asix.com.tw/products.php?PLine=71

--- /usr/src/share/man/man4/axe.4       Mon Jun  3 00:02:33 2013
+++ /tmp/axe.4  Sun Jun  9 12:25:14 2013
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -84,8 +84,8 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 .Pp
 The AX88172, AX88178, and AX88772 are USB 2.0 devices designed to work with
 either Ethernet or HomePNA transceivers.
-The AX8172 and AX88772 contain 10/100 Ethernet MACs with MII interfaces.
-The AX8178 contains a 10/100/1000 Gigabit Ethernet MAC with a GMII/MII
+The AX88172 and AX88772 contain 10/100 Ethernet MACs with MII interfaces.
+The AX88178 contains a 10/100/1000 Gigabit Ethernet MAC with a GMII/MII
 interface.
 All adapters will operate with either USB 1.x or USB 2.0 controllers, however
 performance with 1.x controllers will be limited since the USB 1.x standard


--
Michał Markowski


&lt;/pre&gt;</description>
    <dc:creator>Michał Markowski</dc:creator>
    <dc:date>2013-06-09T10:36:40</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>
