>
> I was using csup to track RELEN_8_0 branch. Currently I'm syncing to
> RELENG_8.
>
> If I understood you right, after getting the sources for RELENG_8, I need to
> apply the patch and then rebuild world?
>
You only need to rebuild the kernel.
-- Qing
__
On 20 Apr 2010, at 01:31, Bobby Walker wrote:
>
> Hey list, I've searched and searched for a solution to this problem and I
> can't find one.
>
>
>
> I've got the wireless nic setup, its a Linksys WUSB54G v2.
>
>
>
> Its picked up by the ural driver, but as far as I can tell that driver
On Tuesday 20 April 2010 2:53:16 am c0re wrote:
> Hello All!
> I've upgraded freebsd from 7.0 to 7.3 and all was good until I tryed to
> configure gre interface and use ipfw fwd.
> I'm actually does not know what was the point of failure in my
> configuration.
>
> [ some details snipped ]
>
> It w
On 20 April 2010 15:48, John Baldwin wrote:
> On Tuesday 20 April 2010 2:53:16 am c0re wrote:
>> Hello All!
>> I've upgraded freebsd from 7.0 to 7.3 and all was good until I tryed to
>> configure gre interface and use ipfw fwd.
>> I'm actually does not know what was the point of failure in my
>> c
On Thu, 15 Apr 2010 10:49:08 -0700, Li, Qing wrote:
>> Doesn't seem to have any effect. Please see
>> http://lists.freebsd.org/pipermail/freebsd-net/2010-March/024728.html
>> on how to reproduce.
>>
LQ>
LQ> Could you please try the patch at:
LQ>
LQ> http://people.freebsd.org/~qingli/ng-
just noticed that sys/kern/uipc_domain.c still sets max_linkhdr=16
as a default.
The value is often used to reserve head space in mbufs for
the MAC header. As such, 16 is too short for systems that make
use of vlans, and the effect might be that we would need
additional mbuf entries or at least mov
On Tue, Apr 20, 2010 at 07:28:45PM +0200, Luigi Rizzo wrote:
> just noticed that sys/kern/uipc_domain.c still sets max_linkhdr=16
> as a default.
> The value is often used to reserve head space in mbufs for
> the MAC header. As such, 16 is too short for systems that make
> use of vlans, and the eff
The following reply was made to PR kern/140597; it has been noted by GNATS.
From: "Scheffenegger, Richard"
To: , "Lawrence Stewart"
Cc: "Biswas, Anumita"
Subject: Re: kern/140597 implement Lost Retransmission Detection
Date: Wed, 21 Apr 2010 02:16:01 +0100
I found a small oversight (bug) in m
Hi,
Accidentally due to misconfiguration of our tools we ran simultaneously
deletion of the same interface alias and crashed the box (FreeBSD-7.1).
So I did some experiments on my 8-STABLE (I have CURRENT in virtualbox only)
to investigate this running concurrently two scripts, which were adding
Hello,
I still need to gather more info when I visit the datacenter to reboot one
of the problematic hosts, but I wanted to verify my basic carp config here
was solid.
I have two hosts that are running a recursing name server on our internal
network for other servers. Since failover from mu
Old Synopsis: multicast packets aren't received when PROMISC mode on fxp.
New Synopsis: [fxp] multicast packets aren't received when PROMISC mode on fxp.
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Apr 21 05:57:31 UTC 2010
Re
11 matches
Mail list logo
