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
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
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, Maxim Dounin wrote:
Hello!
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, 2010 at 03:17:59PM +0200,
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:
Hello!
On
Hi Christopher,
snip
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
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:
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 pyu...@gmail.com wrote:
On Thu, Nov
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
-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
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
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'
device =
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
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
vendor
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
17 matches
Mail list logo
