Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker
On Sat, Feb 20, 2010 at 12:04:35PM +, Bjoern A. Zeeb wrote:
> On Sat, 20 Feb 2010, Bjoern A. Zeeb wrote:
>
> > On Fri, 19 Feb 2010, Mikolaj Golub wrote:
> >
> >> On Thu, 18 Feb 2010 17:32:37 +0200 Nikos Vassiliadis wrote:
> >>
> >>> On 2/17/2010 3:26 PM, Alexander Shikoff wrote:
> Hello
Synopsis: Marvell Yukon NIC not working under FreeBSD
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: remko
Responsible-Changed-When: Mon Feb 22 16:05:20 UTC 2010
Responsible-Changed-Why:
Reassign to network
http://www.freebsd.org/cgi/query-pr.cgi?pr=144206
___
Synopsis: wpa_supplicant(8) drops connection on key renegotiation
State-Changed-From-To: open->closed
State-Changed-By: bschmidt
State-Changed-When: Mon Feb 22 17:13:53 UTC 2010
State-Changed-Why:
A fix has been commited and MFCed as r204215.
http://www.freebsd.org/cgi/query-pr.cgi?pr=142547
___
The following reply was made to PR bin/142547; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: bin/142547: commit references a PR
Date: Mon, 22 Feb 2010 17:11:02 + (UTC)
Author: bschmidt
Date: Mon Feb 22 17:10:47 2010
On Mon, Feb 22, 2010 at 12:52 AM, Pyun YongHyeon wrote:
> On Sun, Feb 21, 2010 at 11:28:54AM +0100, Patrick Ale wrote:
>> Good morning!
>
> After you see the failure DHCP, unplug the UTP cable and wait 2-3
> seconds and replug the UTP cable again. And execute "dhclient ale0",
> does it make any di
On 02/22/10 18:15, bschm...@freebsd.org wrote:
Synopsis: wpa_supplicant(8) drops connection on key renegotiation
State-Changed-From-To: open->closed
State-Changed-By: bschmidt
State-Changed-When: Mon Feb 22 17:13:53 UTC 2010
State-Changed-Why:
A fix has been commited and MFCed as r204215.
http:
On Mon, Feb 22, 2010 at 06:51:19PM +0100, Patrick Ale wrote:
> On Mon, Feb 22, 2010 at 12:52 AM, Pyun YongHyeon wrote:
> > On Sun, Feb 21, 2010 at 11:28:54AM +0100, Patrick Ale wrote:
> >> Good morning!
> >
> > After you see the failure DHCP, unplug the UTP cable and wait 2-3
> > seconds and replu
Hi,
I have a FreeBSD server running Quagga as a BGP router. It has
a number of interfaces in it both bce and em. The most heavily used
interfaces are starting to give me watchdog timeout errors just in the
last week. We normally sustain about 300Mb/s on both of these
interfaces but in th
With the increased load you might be running out of mbufs more easily,
would suggest you increase the mbuf pool.
This is an old old driver now, you might consider going to something a
bit more recent.
Jack
On Mon, Feb 22, 2010 at 10:14 AM, Kirk Davis wrote:
> Hi,
>I have a FreeBSD ser
On Monday 22 February 2010 17:35:24 Backup wrote:
> Silly question here. But will this patch be applied with portsnap fetch
> && update? Or will i have to path the kernel manually?
portsnap? you mean freebsd-update? No, it won't. You have to fetch/build your
kernel manually for now.
--
Bernhard
I have a backup server sitting here that I am going to load 7.3-RC1 onto
and test with it. It is the exact duplicate hardware so that should
help with the upgraded driver. Does it make sence to go to 8.0?
Here is the mbuf usage on this server. I'm nore sure exactly how to
read this but it seem
Try `sysctl dev.em.0.stats=1` and em.2, you're right though, doesn't look
like any
system mbuf failures.
7.2 seems to be a stable base OS and driver, 8 is better in some respects,
but
has not been without its reported problems. I leave the choice to you.
Without more data I am not sure what is ca
On 02/22/10 19:49, Bernhard Schmidt wrote:
On Monday 22 February 2010 17:35:24 Backup wrote:
Silly question here. But will this patch be applied with portsnap fetch
&& update? Or will i have to path the kernel manually?
portsnap? you mean freebsd-update? No, it won't. You have to fet
From: Jack Vogel [mailto:jfvo...@gmail.com]
Try `sysctl dev.em.0.stats=1` and em.2, you're right though,
doesn't look like any
system mbuf failures.
Does this need to be done in loader.conf? It doesn't seem to take from
the command line.
# sysctl dev.em.2.stats
At 03:46 PM 2/22/2010, Kirk Davis wrote:
Does this need to be done in loader.conf? It doesn't seem to take from
the command line.
# sysctl dev.em.2.stats=1
dev.em.2.stats: -1 -> -1
# sysctl dev.em.2.stats
dev.em.2.stats: -1
Hi,
After you issue those commands, the driver will spit out
On Mon, Feb 22, 2010 at 12:46 PM, Kirk Davis wrote:
>
>From: Jack Vogel [mailto:jfvo...@gmail.com]
>
> Try `sysctl dev.em.0.stats=1` and em.2, you're right though,
> doesn't look like any
>system mbuf failures.
>
>
> Does this need to be done in loader.conf? It doesn't se
> -Original Message-
> From: Mike Tancsa [mailto:m...@sentex.net]
> Subject: Re: Intel em0: watchdog timeout
>
> At 03:46 PM 2/22/2010, Kirk Davis wrote:
> >Does this need to be done in loader.conf? It doesn't seem
> to take from
> >the command line.
> ># sysctl dev.em.2.stats=1
> >d
OK, so you are still failing to get mbufs in the RX side, increase the
nmbcluster
value, and then what size is your RX ring (number of rx descriptors)?
If you havent already done so, change that to 1024.
I am developing a change in the RX code right now that will help
this situation, but am doing
OK. I have the following in /boot/loader.conf (and rebooted)
hw.em.rxd=1024
hw.em.txd=1024
Should this be hw.em2.rxd? Is it set per interface or across all
interfaces?
nmbcluster=262144
# sysctl dev.em.2.stats=1
Feb 22 16:29:57 inet-gw kernel: em2: Defer count = 20
Feb 22 16:29:57 inet-gw k
Is your driver static, ie builtin, to the kernel, or do you load/unload it
as a module?
I ask because perhaps we could try a later driver, and being a module makes
that
easier.
Jack
On Mon, Feb 22, 2010 at 3:37 PM, Kirk Davis wrote:
> OK. I have the following in /boot/loader.conf (and reboot
On 2010.02.18 00:31, Christian Ullrich wrote:
> * Steve Bertrand wrote:
>
>> On 2010.02.17 16:42, Christian Ullrich wrote:
>
>>> send the packet. Why doesn't the kernel look up an ARP table entry by
>>> both IP address and interface?
>>
>> That's not how the protocols were designed, and thankfull
Luigi Rizzo wrote:
On Fri, Feb 19, 2010 at 10:48:32PM +0400, rihad wrote:
Hi, all,
Recalling my old posting "dummynet dropping too many packets" dated
October 4, 2009, the problem isn't over just yet. This time, there are
no interface i/o drops (just a reminder: we have 2 bce(4) GigE cards
c
23 matches
Mail list logo
