https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235325
Piotr Kubaj changed:
What|Removed |Added
Assignee|n...@freebsd.org |free...@intel.com
Statu
On Wed, Oct 7, 2020 at 11:45 AM Kyle Evans wrote:
>
> Hi,
>
> I have a couple of domain patches in review, if anyone would like to
> comment/review the area:
>
> https://reviews.freebsd.org/D25062 adds a dom_probe callback so that
> domains can indicate whether they shoul
Hi,
I have a couple of domain patches in review, if anyone would like to
comment/review the area:
https://reviews.freebsd.org/D25062 adds a dom_probe callback so that
domains can indicate whether they should be supported at all or not.
This avoids some dirty stuff in domains that may not be
Hi freebsd-hackers@, freebsd-net@,
Could someone please commit these two patches for ipfw/libalias/RFC6598:
URL: https://reviews.freebsd.org/D23356
Title: natd: Add support for RFC 6598/Carrier Grade NAT subnets via
libalias
Description:
Add support for RFC 6598/Carrier Grade NAT address
hi!
On Fri, 3 Jul 2020 at 20:12, Neel Chauhan wrote:
> Hi freebsd-hackers@, freebsd-net@,
>
> These two patches that will be described are a continuation of r357092.
>
> r357092 added support for RFC 6598/Carrier Grade NAT (subnet:
> 100.64.0.0/10) in libalias and IPFW in-ker
Hi freebsd-hackers@, freebsd-net@,
These two patches that will be described are a continuation of r357092.
r357092 added support for RFC 6598/Carrier Grade NAT (subnet:
100.64.0.0/10) in libalias and IPFW in-kernel NAT.
These two patches add support for RFC 6598 to natd and ng_nat
> Hi freebsd-net@,
>
> I'm really sorry if I'm bothering you with emails like this.
>
> If there are any committers here, I have two patches for the ipfw(8)
> subsystem.
>
> The patches (w/ description & URL) are:
>
> ===
> ipfw(8): In fill_ip6()
Hi freebsd-net@,
I'm really sorry if I'm bothering you with emails like this.
If there are any committers here, I have two patches for the ipfw(8)
subsystem.
The patches (w/ description & URL) are:
===
ipfw(8): In fill_ip6(), use a single statement for both "me" a
Hi freebsd-net@,
I'm not sure if this mailing list is the right place to ask for code
review. If not, could you please direct me to the right mailing list?
I have three patches for ipfw(8) below:
* https://reviews.freebsd.org/D24011 (ipfw: Support {w:x:y::z}:port
(bracketed) IPv6 addr
> > > > need to, after it boots up type
> > > >
> > > > kldload tcp_bbr
> > > >
> > > > or
> > > >
> > > > kldload tcp_rack
> > > >
> > > > To get the modules loaded
> > > >
> > kldload tcp_bbr
> > > >
> > > > or
> > > >
> > > > kldload tcp_rack
> > > >
> > > > To get the modules loaded
> > > >
> > > > R
> > > >
> > > >
>
any KERNCONF=MYKERNEL, and that
>>>>> successfully finished.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 19, 2019 at 12:19 PM Randall Stewart wrote:
>>>>> You can look in the config I sent.. but here is what
>>>
RATELIMIT
>>>> **
>>>>
>>>> So you should
>>>> 1) Apply the current patch in phabricator
>>>> 2) edit your config and add the above three lines
>>>> 3) go to the src dir and type
>>>> make buildke
n is: 352483
> > > >
> > > > ===
> > > > awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko.full export_syms |
> > > > xargs -J% objcopy % zlib.ko.full
> > > > objcopy --only-keep-deb
onf/kmod_syms.awk zlib.ko.full export_syms |
> xargs -J% objcopy % zlib.ko.full
> > > > objcopy --only-keep-debug zlib.ko.full zlib.ko.debug
> > > > objcopy --strip-debug --add-gnu-debuglink=zlib.ko.debug
> zlib.ko.full zlib.ko
> > > > ---
9
> > > --
> > > >>> Kernel(s) GENERIC built in 1972 seconds, ncpu: 4
> > > ===
> > >
> > > Thank you
> > > Vishal.
>> > >
>>> > > Build is done successfully. I would appreciate if you could share
>>> config changes needed for BBR.
>>> > >
>>> > > My svn revision is: 352483
>>> > >
>>> > >
opy --strip-debug --add-gnu-debuglink=zlib.ko.debug zlib.ko.full
>> zlib.ko
>> > > --
>> > > >>> Kernel build for GENERIC completed on Wed Sep 18 21:08:31 UTC 2019
>> > > --
s) GENERIC built in 1972 seconds, ncpu: 4
> > > ===
> > >
> > > Thank you
> > > Vishal.
> > >
> > >
> > > On Wed, Sep 18, 2019 at 3:34 PM vm finance
> wrote:
> > > I&
I manually extracted Makefile contents from the patch and added that as
Makefile under ~modules/tcp/bbr...
make cleandepend worked
now trying make dependwould keep you posted.
Thanks!
On Thu, Sep 19, 2019 at 7:39 PM vm finance wrote:
> Since you mentioned Sep17 vs Sep10 patches should
Since you mentioned Sep17 vs Sep10 patches should be slightly different, I
would appreciate if you could please check the one available at:
https://reviews.freebsd.org/D21582?id=62213
Is that the correct one to download/use?
Thank you!
On Thu, Sep 19, 2019 at 7:31 PM vm finance wrote:
>
vm finance
> wrote:
> > > I'm using amd64. I'd get back as soon as base build is complete.
> > >
> > > Thanks!
> > >
> > > On Wed, Sep 18, 2019 at 7:09 AM Randall Stewart
> wrote:
> > > To get bbr running you will need to change
have successfully did
> >
> > 1) buildworld
> > 2) buildkernel
> > 3) installkernel
> >
> > (you can look in UPDATING for instructions .. though the file is long :D)
> >
> > successfully let me know.. and then I will give you the tweaks you need to
;> > On Wed, Sep 18, 2019 at 7:09 AM Randall Stewart
>> wrote:
>> > To get bbr running you will need to change your kernel config.
>> >
>> > Are you building i386 or amd64?
>> >
>> > After you have successfully did
>> >
>
ATING for instructions .. though the file is long :D)
> >
> > successfully let me know.. and then I will give you the tweaks you need
> to add
> > to the kerneconf.
> >
> > It won’t take as long to build because at that point you can add in the
> > NO_CLEAN NO_CLEAN
l give you the tweaks you need to add
> to the kerneconf.
>
> It won’t take as long to build because at that point you can add in the
> NO_CLEAN NO_CLEANDIR options as well since you will have built everything
> the first time
>
> R
>
> > On Sep 18, 2019, at 7:06
;
>> It won’t take as long to build because at that point you can add in the
>> NO_CLEAN NO_CLEANDIR options as well since you will have built everything
>> the first time
>>
>> R
>>
>> > On Sep 18, 2019, at 7:06 AM, vm finance wrote:
>> >
>> > B
to build because at that point you can add in the
> NO_CLEAN NO_CLEANDIR options as well since you will have built everything
> the first time
>
> R
>
> > On Sep 18, 2019, at 7:06 AM, vm finance wrote:
> >
> > BTW, if you think I should be making any changes in config
I should be making any changes in configs, please do let me
> know.
> My goal is to build a freebsd image with BBR patches on x86 VM.
> Nothing fancy.
>
> thanks!
>
> On Wed, Sep 18, 2019 at 7:03 AM vm finance wrote:
> Thanks Randall, Michael,
>
> I did "
BTW, if you think I should be making any changes in configs, please do let
me know.
My goal is to build a freebsd image with BBR patches on x86 VM.
Nothing fancy.
thanks!
On Wed, Sep 18, 2019 at 7:03 AM vm finance wrote:
> Thanks Randall, Michael,
>
> I did "svn svn://svn.freebsd
Stewart wrote:
> >
> > Thats great idea Michael.
> >
> > From the look fo the build log I was sent, his blow-up has nothing to do
> > with the patches.
> >
> > He should probably
> >
> > 1) Check out a fresh version of head.
> > 2)
his blow-up has nothing to do
> with the patches.
>
> He should probably
>
> 1) Check out a fresh version of head.
> 2) Follow the instructions in UPDATING to get a clean build.
> — make buildworld
> — make buildkernel KERNCONF=his-conf
> — make installkernel KERN
Thats great idea Michael.
From the look fo the build log I was sent, his blow-up has nothing to do
with the patches.
He should probably
1) Check out a fresh version of head.
2) Follow the instructions in UPDATING to get a clean build.
— make buildworld
— make buildkernel KERNCONF=his
> On 18. Sep 2019, at 08:19, vm finance wrote:
>
> correcting a typo:
>
> svn co svn://svn.freebsd.org/base/head /usr/src
> current revision: 352434
I suggest to build/install head first without any patches. After that has
worked,
apply the patches you are interested in. That
ead /use/src
>
>
> If you could pls let me know the new patch, I can try that.
>
> Thanks
>
> Sent from my iPhone
>
> On 18-Sep-2019, at 8:56 AM, Randall Stewart wrote:
>
> There have been several patches pre-this one that provide
> the infrastructure to sup
> There have been several patches pre-this one that provide
> the infrastructure to support BBR.
>
> Release 12.0 will *not* have these patches and will *not* compile it.
>
> I have no intention at this point in doing a MFC of this work.. so if you want
> to run BBR you need t
There have been several patches pre-this one that provide
the infrastructure to support BBR.
Release 12.0 will *not* have these patches and will *not* compile it.
I have no intention at this point in doing a MFC of this work.. so if you want
to run BBR you need to run Head
R
> On Sep 17, 2
mesg.
>> >>> I have also attached the entire build log...snippet is below
>> >>>
>> >>> Please let me know what am I missing here?
>> >>>
>> >>> Thanks!
>> >>>
>> >>> #svnlite revision
>> &g
://svn.freebsd.org/base/head
> >>> Relative URL: ^/head
> >>> Repository Root: svn://svn.freebsd.org/base
> >>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> >>> Revision: 352436
> >>> Node Kind: directory
> >>> Schedule: normal
&g
xes:/usr/src #
>>>
>>> -------- snip
>>>
>>>
>>> ad_elf64_obj.llo reloc_elf64.llo disk.llo part.llo vdisk.llo dev_net.llo
>>> bcache.llo interp_simple.llo zfs_cmd.llo
>>> r
eloc_elf64.llo disk.llo part.llo vdisk.llo dev_net.llo
>> bcache.llo interp_simple.llo zfs_cmd.llo
>> rm -f .depend .depend.* GPATH GRTAGS GSYMS GTAGS
>> ===> sys (cleandir)
>> rm -f export_syms machine x86 tcp_bbr.ko tcp_bbr.kld bbr.o sack_filter.o
>> rack_bbr_commo
o sack_filter.o
> rack_bbr_common.o opt_inet.h opt_inet6.h opt_ipsec.h opt_tcpdebug.h
> opt_kern_tls.h
> rm: x86: is a directory
> *** Error code 1
>
> Stop.
> make[3]: stopped in /usr/src/sys
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/src
> *** Er
ped in /usr/src
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/src
> *** Error code 1
>
> Stop.
> make: stopped in /usr/src
>
>
> On Tue, Sep 17, 2019 at 6:27 PM Randall Stewart wrote:
>
>> Pacing is provided by tcp_hpts.c. The current linux patch
Pacing is provided by tcp_hpts.c. The current linux patches do not have
to have fq.. they built an alternate means of doing pacing into bbr.
In either case our testing has shown that our pacing is more accurate than
either fq or the internal pacer :)
R
> On Sep 17, 2019, at 11:05 AM, vm fina
Thanks Randall.
I was able to apply the patch - now rebuilding the kernel. Would update on
how it goes.
BTW, is there any description on how lack of tc_fq under FreeBSD is
compensated here?
The original BBR patches on Linux show that as a must-have? Is that
functionality implemented via
You should be able to compile it against the current head. I re-doing that now
(had an
issue with my machine and had to roll it back to a backup).
When I put the patch up on Sept 10th it complied with and without BBR on
whatever
was that rev..
Looking in the commit logs that would have been aro
Hi Randall,
Thanks for releasing BBR patch:
https://reviews.freebsd.org/D21582#change-xcAWBif3E9Jq
Could you please let me know what SVN/GIT label tag this is based on? I
would like to patch and experiment with it. I couldn't find this info in
the released patch.
Thanks a lot!
On Tue, Sep 10, 2
rrs@ has just posted the BBR patch to phabricator:
https://reviews.freebsd.org/D21582
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Hello Jamie,
Thanks - I see there is a new file added tcp_ratelimit.c (probably to
emulate tc-fq behavior under Linux?). However, don't see this file under
"netinet/"am I missing something?
Is there a way to checkout the entire netinet/ code with BBR changes in
FreeBSD? I would like to build,
> I would like to try BBR under FreeBSD.
>
> I'm willing to try anything experimental as well. Could someone please
> suggest what is the latest patch available for this. The last patch I came
> across is:
> https://reviews.freebsd.org/D15525
>
> Could someone please confirm if there is anything la
Hello everyone,
I would like to try BBR under FreeBSD.
I'm willing to try anything experimental as well. Could someone please
suggest what is the latest patch available for this. The last patch I came
across is:
https://reviews.freebsd.org/D15525
Could someone please confirm if there is anything
On Sun, Nov 25, 2018 at 02:24:47PM -0500, Viktor Dukhovni wrote:
>
> Not sure what's required to get these adopted upstream. My stf0
> interface was still flapping in/out of "tentative" with 11.2, so
> I applied essentially the same patches as for 11.1.
Just a fo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235325
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
Keywords
Not sure what's required to get these adopted upstream. My stf0
interface was still flapping in/out of "tentative" with 11.2, so
I applied essentially the same patches as for 11.1.
--
Viktor.
Inde
,
- Kuankuan
在 2017年7月21日，上午2:54，hiren panchasara 写道：
On 07/19/17 at 12:26P, Kuankuan Yang wrote:
Dear All,
I?m a newbie for FreeBSD development. May I ask a stupid question where could I
find the TCP BBR patches :P
Hi! Thanks for your interest in BBR/FreeBSD. Other than what you listed, nothing
is
gt;
>>> 在 2017年7月21日，上午2:54，hiren panchasara 写道：
>>>
>>> On 07/19/17 at 12:26P, Kuankuan Yang wrote:
>>>> Dear All,
>>>>
>>>> I?m a newbie for FreeBSD development. May I ask a stupid question where
>>>>
m a newbie for FreeBSD development. May I ask a stupid question where
>>> could I find the TCP BBR patches :P
>>
>> Hi! Thanks for your interest in BBR/FreeBSD. Other than what you listed,
>> nothing
>> is public yet.
>>
>> Cheers,
>> Hire
l,
>>
>> I?m a newbie for FreeBSD development. May I ask a stupid question where
>> could I find the TCP BBR patches :P
>
> Hi! Thanks for your interest in BBR/FreeBSD. Other than what you listed,
> nothing
> is public yet.
>
> Cheers,
> Hiren
_
On 07/19/17 at 12:26P, Kuankuan Yang wrote:
> Dear All,
>
> I?m a newbie for FreeBSD development. May I ask a stupid question where could
> I find the TCP BBR patches :P
Hi! Thanks for your interest in BBR/FreeBSD. Other than what you listed, nothing
is public yet.
C
Dear All,
I’m a newbie for FreeBSD development. May I ask a stupid question where could I
find the TCP BBR patches :P
From the FreeBSD Transport DevSubmit page, I knew that Randall Stewart is the
main contributor for TCP BBR task, and found the code changes may be ready to
get in.
> Mich
Dear All,
I’m a newbie for FreeBSD development. May I ask a stupid question where could I
find the TCP BBR patches :P
From the FreeBSD Transport DevSubmit page, I knew that Randall Stewart is the
main contributor for TCP BBR task, and found the code changes may be ready to
get in.
> Mich
Andrey V. Elsukov wrote this message on Tue, Mar 03, 2015 at 15:39 +0300:
> We are using reviews.freebsd.org to publish patches for review for some
> time. And now public mailing lists got spammed by emails from
> phabricator (especially I mean this one). It is hard for me (and I think
&
Hi All,
We are using reviews.freebsd.org to publish patches for review for some
time. And now public mailing lists got spammed by emails from
phabricator (especially I mean this one). It is hard for me (and I think
for many other users) to read this mailing list.
Guys, when your patch doesn&#
Sorry, having problems sending attachments as plain text.
Here's virtio_net_3.10.60.patch:
# The netmap 3.10 patch for the virtio_net driver fails to apply. This
# patch is the whole netmap virtio driver patch for 3.10.60 (from
# kernel.org), and it applies correctly.
#
Index: linux-3.10.60/dri
Sorry, having problems sending attachments as plain text.
Here's virtio_netmap.patch:
# This file is a patch to the netmap virtio_net driver include file.
# There is a problem with the initialization, and during read packet with
# control of the indicies .
#
# This problem is easily seen by bui
ol on
the guest.
The first 255 pings will work fine, when the index hits 255, then the
packet receive will fail, and will continue to fail every time on slot 255.
I've included patches for both problems in the hopes that the source code
will be updated and others won't have to find these
On Wed, Oct 22, 2014 at 3:47 PM, Tony Moseby wrote:
> Hello,
>
> A simple question,if I want to know if there is a patch for my
> problem where should i Look?is there a data base or similar with
> all patches for every source code file ? or how does one goes about.
> Many th
Hello,
A simple question,if I want to know if there is a patch for my
problem where should i Look?is there a data base or similar with
all patches for every source code file ? or how does one goes about.
Many thanks
___
freebsd-net@freebsd.org mailing
stale now with Tom Jones' recent patch
> >>>>>>>> based on
> >>>>>>>> a more up-to-date version of the Internet-Draft, but the PRR patch
> >>>>>>>> should
> >>>>>>>> still be useful
-Draft, but the PRR patch
>>>>>>>> should
>>>>>>>> still be useful?
>>>>>>>
>>>>>>> My newcwv patch is much more up to date than Aris's, but it is slightly
>>>>>>> different in implementation.
; should
>>>>>>> still be useful?
>>>>>>
>>>>>> My newcwv patch is much more up to date than Aris's, but it is slightly
>>>>>> different in implementation. I have had a few suggestions from Adrian,
>>>>>>
hould
>>>>>> still be useful?
>>>>>
>>>>> My newcwv patch is much more up to date than Aris's, but it is slightly
>>>>> different in implementation. I have had a few suggestions from Adrian,
>>>>> but he
>>>>
t;>> he
>>>> couldn't comment on how it relates to the tcp internals.
>>>>
>>>> There is a PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191520
>>>>
>>>> The biggest difference in structure between mine and Aris's patc
d a few suggestions from Adrian, but
>>> he
>>> couldn't comment on how it relates to the tcp internals.
>>>
>>> There is a PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191520
>>>
>>> The biggest difference in structure between mine a
a/show_bug.cgi?id=191520
>>
>> The biggest difference in structure between mine and Aris's patch is the use
>> of
>> tcp timers. It would be good to hear if my approach or Aris's is prefered.
>>
>>> On 2014-6-19, at 23:35, George Neville-Neil wrote:
>&
1520
>
> The biggest difference in structure between mine and Aris's patch is the use
> of
> tcp timers. It would be good to hear if my approach or Aris's is prefered.
>
>> On 2014-6-19, at 23:35, George Neville-Neil wrote:
>>
>> > On 4 Feb
tween mine and Aris's patch is the use of
tcp timers. It would be good to hear if my approach or Aris's is prefered.
> On 2014-6-19, at 23:35, George Neville-Neil wrote:
>
> > On 4 Feb 2014, at 1:38, Eggert, Lars wrote:
> >
> >> Hi,
> >>
> >>
>
>> Hi,
>>
>> below are two patches that implement RFC6937 ("Proportional Rate Reduction
>> for TCP") and draft-ietf-tcpm-newcwv-00 ("Updating TCP to support
>> Rate-Limited Traffic"). They were done by Aris Angelogiannopoulos for his MS
>> the
On Thu, Jun 19, 2014 at 02:35:13PM -0700, George Neville-Neil wrote:
> On 4 Feb 2014, at 1:38, Eggert, Lars wrote:
>
> > Hi,
> >
> > below are two patches that implement RFC6937 ("Proportional Rate Reduction
> > for TCP") and draft-ietf-tcpm-newcwv-00 (&q
On 4 Feb 2014, at 1:38, Eggert, Lars wrote:
> Hi,
>
> below are two patches that implement RFC6937 ("Proportional Rate Reduction
> for TCP") and draft-ietf-tcpm-newcwv-00 ("Updating TCP to support
> Rate-Limited Traffic"). They were done by Aris Angelogiannopo
John Howie wrote:
> Hi Rick,
>
> That is an excellent point and a good debate to have.
>
> I have not looked in detail at how PXEBOOT does it, but I think a
> clean up of the code to somehow pass arguments to the kernel is
> preferable to having a diskless client send a slew of needless
> request
On 6/1/14, 8:01 PM, Rick Macklem wrote:
John Howie wrote:
[...]
Actually, I tend to think that using the code in sys/nfs/bootp_subr.c
is preferable to using the NFS stuff in stand that pxeboot does.
The only reason I know for pxeboot doing the NFS stuff and filling in
the nfsv3_diskless struct
Hi Rick,
That is an excellent point and a good debate to have.
I have not looked in detail at how PXEBOOT does it, but I think a clean up of
the code to somehow pass arguments to the kernel is preferable to having a
diskless client send a slew of needless requests to the DHCP server to request
Hi Steinar,
I could ask you to 'prove it', too, but I can easily check when I get back from
my current travels :-)
It important to note that even if it does (as I think it does) it is NOT in
violation of the RFC. The RFC simply says that if a client wants something it
should ask for it, and no
> In short, no, I have no packet traces. Given that the DHCP code in the
> FreeBSD boot loader and NFS subsystem does not request those options, but
> that ISC-DHCP does provide them, I will go out on a limb and say that it
> must be serving them without being asked if they are configured.
In that
John Howie wrote:
> Hi all,
>
> I apologize for the cross posting of this email, but I believe it
> will be
> of interest to people across all three groups. Please feel free to
> forward
> to additional groups if you feel they would benefit.
>
> I have seen a few posts on and off over the years a
Hi Steinar,
In short, no, I have no packet traces. Given that the DHCP code in the
FreeBSD boot loader and NFS subsystem does not request those options, but
that ISC-DHCP does provide them, I will go out on a limb and say that it
must be serving them without being asked if they are configured.
Re
> Section 3.5 of RFC 2131 (the DHCP RFC) states that "...Second, in its
> initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the
> server with a list of specific parameters the client is interested in"
> and "...The client can inform the server which configuration parameters
> the cl
Hi all,
I apologize for the cross posting of this email, but I believe it will be
of interest to people across all three groups. Please feel free to forward
to additional groups if you feel they would benefit.
I have seen a few posts on and off over the years about Windows Server
DHCP not working
On Fri, Apr 11, 2014 at 4:16 PM, hiren panchasara
wrote:
> On Fri, Apr 11, 2014 at 4:15 AM, Eggert, Lars wrote:
>> Hi,
>>
>> since folks are playing with Midori's DCTCP patch, I wanted to make sure
>> that you were also aware of the patches
On Fri, Apr 11, 2014 at 4:15 AM, Eggert, Lars wrote:
> Hi,
>
> since folks are playing with Midori's DCTCP patch, I wanted to make sure that
> you were also aware of the patches that Aris did for PRR and NewCWV...
>>
>>
Lars,
There are no actual patches attach
Hi,
since folks are playing with Midori's DCTCP patch, I wanted to make sure that
you were also aware of the patches that Aris did for PRR and NewCWV...
Lars
On 2014-2-4, at 10:38, Eggert, Lars wrote:
> Hi,
>
> below are two patches that implement RFC6937 ("Proporti
<
said:
> The patch includes a lot of drc2.patch and drc3.patch, so don't try
> and apply it to a patched kernel. Hopefully it will apply cleanly to
> vanilla sources.
> Tha patch has been minimally tested.
Well, it's taken a long time, but I was finally able to get some
testing. The user whos
Hi Josh,
I'm attaching a .tgz file of the patches (oce0.patch to oce24.patch, Please
make sure that you apply them in the same order) that I told you about for the
Emulex's OCE driver.
I had opened a PR for the same, However .tgz files are not allowed as
attachments to the problem re
On Mar 1, 2013, at 5:36 AM, "Duvvuru,Venkat Kumar"
wrote:
> Hi Josh,
> I have a bunch of patches (~25 in number) to submit. Please let me know the
> process to submit them.
> Do I just attach them in a single email or open pr's for each of them??
> Pls sugges
Hi Josh,
I have a bunch of patches (~25 in number) to submit. Please let me know the
process to submit them.
Do I just attach them in a single email or open pr's for each of them??
Pls suggest.
/Venkat
-Original Message-
From: Josh Paetzel [mailto:j...@tcbug.org]
Sent: Sat
Vencat,
There's been a breakdown in communication. I've been working on oce with Adam
and have a bunch of oce hardware. Please cc me on any patches you have. (pr's
are fine, but they won't get my attention)
Thanks,
Josh Paetzel
On Feb 7, 2013, at 3:57 AM, "Duvv
Hi,
I have submitted this patch http://www.freebsd.org/cgi/query-pr.cgi?pr=171838
some time back. Could you please let me know when this will be pulled in?
I have some more patches to submit. Please let me know if submitting it online
at this link http://www.freebsd.org/send-pr.html is the only
On Jan 18, 2013, at 6:12 AM, Sean Bruno wrote:
> On Fri, 2013-01-18 at 18:10 +0530, Venkat Duvvuru wrote:
>> Hi,
>> I have to submit some patches for Emulex's "oce" driver. Could you please
>> let me know if http://www.freebsd.org/send-pr.html is t
On Fri, 2013-01-18 at 18:10 +0530, Venkat Duvvuru wrote:
> Hi,
> I have to submit some patches for Emulex's "oce" driver. Could you please
> let me know if http://www.freebsd.org/send-pr.html is the correct way of
> submitting them?
>
> /Venkat
Yes please.
1 - 100 of 184 matches
Mail list logo
