On Mon, Sep 19, 2005 at 02:27:11PM -0600, David Vos wrote:
D> The version of ng_split.c packaged with 5.4 Release has a bug in it
D> that causes items to get lost (not freed) if there are no nodes
D> connected on the other end.
D>
D> This has been fixed in the CVS, Revision 1.7
D>
D> Would it be
On Wed, Sep 14, 2005 at 04:23:30PM +0200, ComteZero _ wrote:
C> Hello,
C>
C> I already posted this thread in freebsd-stable but seems that this list is
C> more appropriate.
C>
C> it's been two weeks I try to find out what's wrong. Clean install from cvsup
C> STABLE (5).
C> my ADSL account works
On Sun, Sep 18, 2005 at 01:39:46AM +0100, n0g0013 wrote:
n> could anybody enlighten me as to the purpose of the "opt_netgraph.h"
n> dependancy in a netgraph module?
n>
n> got some errors, added it to SRCS and it gets generated as an empty
n> file. think there is a minimal one in "sr" driver but c
On Fri, Sep 16, 2005 at 04:33:03PM +0100, Dominic Marks wrote:
D> I'm trying to use two gigabit links together using ng_one2many.
D>
D> I haven't done this before, so here is the environment:
D>
D> FreeBSD 6 system with four gigabit interfaces, two of the four are going
D> to be used a single int
Greetings,
M> The problem is:
M>
M> After the system run about 3 hours, there will be large "Ierrs"
M> The system is not heavy loaded, incoming rates of em0 is less
M> than 150Mbits/s. em1 and em2 are not connected.
M>
M> After 3 hours, the ierrs raise quickly every
On Mon, Aug 15, 2005 at 01:12:31AM +0300, noname wrote:
n> freebsd 5.4 stable. xl0 is connected via ng_bridge to ngeth0 in this way:
n>
n> [EMAIL PROTECTED]:~]# ifconfig xl0 up
n> [EMAIL PROTECTED]:~]# ngctl mkpeer . eiface hook ether
n> [EMAIL PROTECTED]:~]# ifconfig ngeth0 up
n> [EMAIL PROTECTE
On Fri, Aug 12, 2005 at 01:48:59PM +0800, Mao Shou Yan wrote:
M> I have a machine running 5.4 stable, with 3 em cards:
M>
M> (1) Two 82543GC with fiber
M>
M> (2) One 82544
M>
M> All of them are shared irq 11( from vmstat -i)
M>
M>
M>
M> The problem is:
M>
M> After the system run a
Hi,
I am working, very slowly, through this bug, but in the hopes that
others might know something and chime in the packet that caused this
is an ICMPv6 packet for neighbor solicitation (type 135, code 0),
directed at the machine which paniced, i.e. not broadcast or
multicast and is attempting to
