On Nov 11, 2010, at 3:00 PM, George Neville-Neil wrote:
> Howdy,
>
> After some excellent comments from Bjoern I've put together the following
> patch:
>
> http://people.freebsd.org/~gnn/head-arpqueue4.diff
>
> Please review and comment.
Looks good to me.
Regards,
--
Rui Paulo
___
On 11/07/10 17:32, Lawrence Stewart wrote:
> On 11/03/10 09:30, Andre Oppermann wrote:
>> On 02.11.2010 01:11, Maxim Dounin wrote:
>>> Hello!
>>>
>>> On Mon, Sep 27, 2010 at 03:17:59PM +0200, Andre Oppermann wrote:
>>>
On 27.09.2010 10:12, Maxim Dounin wrote:
> Hello!
>
> On Mon, S
Hi All,
A quick note that this evening, I made the first in a series of upcoming
commits to head that modify the TCP stack fairly significantly. I have
no reason to believe you'll notice any issues, but TCP is a complex
beast and it's possible things might crop up. The changes are mostly
related t
On 11/12/10 20:44, Lawrence Stewart wrote:
> On 11/07/10 17:32, Lawrence Stewart wrote:
>> On 11/03/10 09:30, Andre Oppermann wrote:
>>> On 02.11.2010 01:11, Maxim Dounin wrote:
Hello!
On Mon, Sep 27, 2010 at 03:17:59PM +0200, Andre Oppermann wrote:
> On 27.09.2010 10:12, Ma
On Fri, Nov 12, 2010 at 09:21:29PM +1100, Lawrence Stewart wrote:
> On 11/12/10 20:44, Lawrence Stewart wrote:
> > On 11/07/10 17:32, Lawrence Stewart wrote:
> >> On 11/03/10 09:30, Andre Oppermann wrote:
> >>> On 02.11.2010 01:11, Maxim Dounin wrote:
> Hello!
>
> On Mon, Sep 27, 201
On 11/12/10 21:41, Kostik Belousov wrote:
> On Fri, Nov 12, 2010 at 09:21:29PM +1100, Lawrence Stewart wrote:
>> On 11/12/10 20:44, Lawrence Stewart wrote:
>>> On 11/07/10 17:32, Lawrence Stewart wrote:
On 11/03/10 09:30, Andre Oppermann wrote:
> On 02.11.2010 01:11, Maxim Dounin wrote:
>>
The problem is the "fwd" can't handle "nextaddr" if "nextaddr" resolves to an
ipv6 address.
It works fine if it resolves to an ipv4 address. Any other ideas ?
Thanks,
Rick
-Original Message-
From: Doug Barton
To: freebsd-net@freebsd.org
Sent: Wed, Nov 10, 2010 10:31 pm
Subject: Re
Hi Christopher,
Before the reboot two Linux clients were mounting the FreeBSD server. They
were both using port 903 locally. On the head node clientA:903 was remapped
to headnode:903 and clientB:903 was remapped to headnode:601. There is no
activity when the reboot occurs. The head node tak
Old Synopsis: vnet_pfil_init() happens too late if pfil_head_register() is
called from if_ethersubr.c
New Synopsis: [pfil] vnet_pfil_init() happens too late if pfil_head_register()
is called from if_ethersubr.c
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimo
Old Synopsis: nd6_ns_input:panic may happen, for RTFREE_LOCKED set rt to 0.
New Synopsis: [patch] nd6_ns_input: panic may happen, for RTFREE_LOCKED set rt
to 0.
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Nov 12 21:16:04 UTC
Hi,
I hope you are interested in inet section it looks like this (will able to
send the exact output only a bit later unfortunately as removed the card) :
inet 0.0.0.0 netmask 255.255.255.255
Thanks,
Gabor
On Thu, Nov 11, 2010 at 10:26 PM, Pyun YongHyeon wrote:
> On Thu, Nov 11, 2010 at 09:56:
Old Synopsis: encapsulate vlan in ng_ether before output to if
New Synopsis: [vlan] encapsulate vlan in ng_ether before output to if
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Nov 12 21:31:41 UTC 2010
Responsible-Changed-Why
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
Since I have seen this issue resolved nowhere within Google results, I
would like to post it here for future reference - its cause, how to work
around it.
Thanks for rwatson@ for his expertise.
This is what I have seen on my own system:
Nov 1
Hello,
We're trying to work with newly purcharsed Intel EXPi9404PF NICs ("Intel
PRO/1000 PF Quad Port Server Adapter") but they do not seem to be
detected (no ports showing with 'ifconfig -l'). We're having no
problems with the 2-port version of the same card -- is there a known
issue with
On Fri, Nov 12, 2010 at 10:18:40PM +0100, Gabor Radnai wrote:
> Hi,
>
> I hope you are interested in inet section it looks like this (will able to
> send the exact output only a bit later unfortunately as removed the card) :
> inet 0.0.0.0 netmask 255.255.255.255
>
This might be caused by dhclie
On Fri, Nov 12, 2010 at 09:07:59AM +0200, Zeus V Panchenko wrote:
> Hi,
>
> Gabor Radnai (gabor.rad...@gmail.com) [10.11.11 23:22] wrote:
> > pciconf:
> > n...@pci0:0:20:0:class=0x068000 card=0x816a1043 chip=0x026910de rev=0xa3
> > hdr=0x00
> > vendor = 'NVIDIA Corporation'
> > dev
On Thu, Nov 11, 2010 at 10:53:38PM +, r...@reckschwardt.de wrote:
> here is the pciconf for the onboard Nic
>
You still didn't post dmesg output. Because there were a lot of
bge(4) changes since 8.1-RELEASE, I think it would be better to try
CURRENT or latest snapshot release and check wheth
Pyun YongHyeon (pyu...@gmail.com) [10.11.13 01:01] wrote:
>
> Please be more specific for the issue. Your description is hard to
> narrow down possible cause.
>
> > i was sure it is the problem of the onboard rt nics ...
> >
>
> pciconf output of all re(4) controllers are useless because the
>
pciconf -l please, I'll betcha these are the new quad ports that are in my
next igb driver
update, it would have gone in already but I've been fighting a bug in the
header split
code.
Show me what the output looks like, and I'll get ya fixed up, dont worry :)
Jack
On Fri, Nov 12, 2010 at 2:08 P
19 matches
Mail list logo
