--- On Tue, 9/8/09, Mike Tancsa wrote:
> From: Mike Tancsa
> Subject: Re: em driver input errors
> To: "Barney Cordoba"
> Cc: freebsd-net@freebsd.org
> Date: Tuesday, September 8, 2009, 6:21 PM
> At 05:42 PM 9/8/2009, Barney Cordoba
> wrote:
> > Manish What specific kinds of input errors are
--- On Wed, 9/9/09, Barney Cordoba wrote:
> From: Barney Cordoba
> Subject: Re: em driver input errors
> To: "Mike Tancsa"
> Cc: freebsd-net@freebsd.org
> Date: Wednesday, September 9, 2009, 7:40 AM
>
>
> --- On Tue, 9/8/09, Mike Tancsa
> wrote:
>
> > From: Mike Tancsa
> > Subject: Re: e
In 8.0-B4 for amd64, bge does not recognize that there is an active
ethernet connection on bge0. Switching the cable to bge1 works correctly.
This seems to be the same issue as reported on July 21 by Oyvind Rakvag,
but I saw no response to that report.
Attached are the dmesg.boot, /var/log/m
At 07:47 AM 9/9/2009, Barney Cordoba wrote:
www.sentex.net/mike > > > > > > The 8241GI may not be able to
handle full gigabit flows if > its only > wired at 32-bit 33Mhz,
which is only capable of bursting to > 1Gb/s. With > a single NIC
it likely just fine, but it a bridged or > firewall typ
--- On Wed, 9/9/09, Mike Tancsa wrote:
> From: Mike Tancsa
> Subject: Re: em driver input errors
> To: "Barney Cordoba"
> Cc: freebsd-net@freebsd.org
> Date: Wednesday, September 9, 2009, 9:55 AM
> At 07:47 AM 9/9/2009, Barney Cordoba
> wrote:
> > www.sentex.net/mike > > > >
> > > The 8241
Old Synopsis: TCP window scaling value
New Synopsis: TCP window scaling value calculated incorrectly?
State-Changed-From-To: feedback->open
State-Changed-By: gavin
State-Changed-When: Wed Sep 9 14:24:24 UTC 2009
State-Changed-Why:
Over to maintainer(s) for investigation
Responsible-Changed-From
Old Synopsis: igb driver troubles in 8.0-BETA4
New Synopsis: [igb] igb driver troubles in 8.0-BETA4
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Sep 9 14:29:34 UTC 2009
Responsible-Changed-Why:
Over to maintainer(s).
http://
The following reply was made to PR kern/138652; it has been noted by GNATS.
From: Gaurav Goel
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/138652: TCP window scaling value
Date: Wed, 9 Sep 2009 19:19:58 +0530
--000feaef6808cf00280473255b4d
Content-Type: text/plain; charset=UTF-8
Dea
At 10:19 AM 9/9/2009, Barney Cordoba wrote:
test would be to force it to 100Mb/s to see if the problem goes
away. I see you are using em1 which implies another NIC...if you
have traffic on the other lan its not much different than Also,
realize that most pciX busses are shared. So your disk an
At 11:17 AM 9/9/2009, Mike Tancsa wrote:
The board is an intel
http://www.intel.com/support/motherboards/server/s3000ah/
Not sure if its wired as PCI-X or just a 32bit bus. I am just
popping in an em pcie nic to see if that makes a difference. I have
an igb as well as bge I can try later.
Number: 138676
Category: misc
Synopsis: after buildworld not work local routes
Confidential: no
Severity: serious
Priority: medium
Responsible:freebsd-bugs
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-
Thanks for the report. I will work you off list for now.
-- Qing
> -Original Message-
> From: Vladislav V. Prodan [mailto:univers...@ukr.net]
> Sent: Wednesday, September 09, 2009 12:05 PM
> To: freebsd-curr...@freebsd.org; freebsd-net@freebsd.org
> Cc: Li, Qing
> Subject: misc/138676: a
Old Synopsis: Do not working multicast through igmpproxy
New Synopsis: [multicast] [panic] not working multicast through igmpproxy
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Sep 9 19:19:45 UTC 2009
Responsible-Changed-Why:
Old Synopsis: after buildworld not work local routes
New Synopsis: [route] after buildworld not work local routes [regression]
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Sep 9 19:23:00 UTC 2009
Responsible-Changed-Why:
Over
r196714 breaks NFSROOT in -CURRENT. When nfsclient tries to
initialize interface calling ifioctl at nfsclient/nfs_vfsops.c:466
it fails with EEXIST (because route is already present I guess).
I fixed it in my tree by checking for error code in mount_nfsroot,
but may be it's ifioctl(SIOCAIFADDR) t
Do you know what IP address nfsclient/nfs_vfsops.c:466 is trying to
insert and do you have an output of the "ifconfig" and route
table you can send to me privately?
At the moment I am suspecting r196714 uncovered an issue that has
always been there. But that's an assumption at the moment.
Thank
Old Synopsis: FreeBSD does not assign linklocal address to loopbacks >0
New Synopsis: [lo] FreeBSD does not assign linklocal address to loopbacks >0
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Sep 9 20:05:49 UTC 2009
Responsi
The following reply was made to PR kern/138676; it has been noted by GNATS.
From: "Vladislav V. Prodan"
To: "Li, Qing" , freebsd-curr...@freebsd.org
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: misc/138676: after buildworld not work local routes
Date: Wed, 09 Sep 2009 23:18:34 +0300
Li, Qi
If a multicast caller does an IP_DROP_MEMBERSHIP followed by a
IP_ADD_MEMBERSHIP, often an uninitialized filter is used for the
in_mfilter passed to in_joingroup_locked() in netinet/in_mcast.c.
The IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP have simple in_mreq input,
and are not using SSM or any of
Stef Walter wrote:
...
Patch is attached which fixes the problem. Is this the right approach?
If not, I hope it helps highlight the problem area.
Good catch; thanks for the fix. I used to depend on imf being
initialized to NULL in this function, however, I opted to keep the old
vector-styl
Bruce Simpson wrote:
> I think this can probably go right in as-is. I'm supposed to be looking
> at other stuff now, so hopefully syrinx@ can check this in if I don't
> get around to it.
Great news. Should I just make a PR for this? Or is there somewhere I
should put it for the 8.0 BETA?
After th
The following reply was made to PR kern/64556; it has been noted by GNATS.
From: Bruce Cran
To: bug-follo...@freebsd.org, t...@hur.st
Cc:
Subject: Re: kern/64556: [sis] if_sis short cable fix problems with NetGear
FA311's
Date: Thu, 10 Sep 2009 02:24:17 +0100
I'm still seeing this problem on
Stef Walter wrote:
> The packets from 172.27.2.2 are not being delivered to the ospfd process
> socket (verified via userland debugging and logging). Even though, as
> you can see above the em0 interface is part of the group.
I've done more research on this.
Each time a packet is not delivered, I
say i run routed and receive rip default from two routers, on the same
local ether. what is the forwarding? i presume it's not smart enough
to balance flows. i hope not alternating packets. clue, please?
fwiw, the routers each have full bgp exits. vrrp would force all
traffic to one. so i am
Randy Bush wrote:
say i run routed and receive rip default from two routers, on the same
local ether. what is the forwarding? i presume it's not smart enough
to balance flows. i hope not alternating packets. clue, please?
fwiw, the routers each have full bgp exits. vrrp would force all
traf
>> say i run routed and receive rip default from two routers, on the same
>> local ether. what is the forwarding? i presume it's not smart enough
>> to balance flows. i hope not alternating packets. clue, please?
> I can't speak for routed
routed is just the routing protocol used to garner the
When removing multicast membership from a socket (ie:
IP_DROP_MEMBERSHIP) that has multiple multicast memberships, the
internal list of memberships and filters are not kept in sync.
This results in dropped packets that are not delivered to the socket
that has the multicast membership. This was exp
What release are you running ?
-- Qing
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Randy Bush
> Sent: Wednesday, September 09, 2009 10:22 PM
> To: freebsd-net
> Subject: forwarding when two rip defaults
>
> say i run
28 matches
Mail list logo