data on #1 as soon as I get debug logs on..pls share some
> pointers on how to turn TCP logging on.
>
> Many thanks!
>
> On Wed, Sep 25, 2019 at 1:41 PM Randall Stewart wrote:
>
>
> > On Sep 25, 2019, at 10:22 AM, vm finance wrote:
> >
> > Hi Randall, Mic
t 2:23 PM, Michael Tuexen
> wrote:
>
>> On 25. Sep 2019, at 22:41, Randall Stewart wrote:
>>
>>
>>
>>> On Sep 25, 2019, at 10:22 AM, vm finance wrote:
>>>
>>> Hi Randall, Michael,
>>>
>>> I'm trying to run some t
st regards
> Michael
>
> >
> > Please let me know.
> >
> > Thanks for all your help.
> >
> > On Fri, Sep 20, 2019 at 4:26 AM vm finance wrote:
> > finally ;) I was able to build it after manually extracting Makefile
> > contents from
s/tcp # ls -R
MakefileMakefile.orig bbr racktcpmd5
./bbr:
./rack:
Makefile
./tcpmd5:
Makefile
Please let me know.
Thanks for your help!
On Thu, Sep 19, 2019 at 11:05 AM Randall Stewart wrote:
> Ahh.. Look in your directory.
>
> You did not create
"/usr/src/sys/modules/tcp/bbr"
>
> STEP 3:
> cd /usr/src/
> make buildkernel KERNCONF=MYKERNEL
> This also fails due to prior errors in Step 2.
>
> Please find MYKERNEL config file + error logs.
>
> Many many thanks for taking time to help me through
Vishal.
>
>
> On Wed, Sep 18, 2019 at 3:34 PM 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 your kern
svn svn://svn.freebsd.org/base/head /usr/src"
> and now doing "make buildworld buildkernel"
> [I didn't change anything in configs - just whatever are the defaults]
>
> I would update as soon as its done.
>
> Thanks again!
>
> On Wed, Sep 18, 2019 at 6:53
suggest to build with his current config first and once he has
that in place and building
a) apply the patch
b) add the extra kernel options
R
> On Sep 18, 2019, at 6:50 AM, Randall Stewart wrote:
>
> Thats great idea Michael.
>
> From the look fo the build log I was sent,
t; Actually I am on head already as mentioned previously. Pulled it using
>>> yesterday:
>>>
>>> svn co svn://svn.freebsd.org/base/head /use/src
>>>
>>>
>>> If you could pls let me know the new patch, I can try that.
>>>
>>> Thanks
&g
please send me a pointer.
>
> Thanks for your help!
>
>
> On Tue, Sep 17, 2019 at 1:33 PM Randall Stewart wrote:
> Looking at your make file log I can’t really tell what you are doing.
>
> Its not the BBR or Rack code that is blowing up…
>
> Are you cross compiling
17, 2019, at 1:11 PM, Randall Stewart wrote:
>
> looking
>
> I was at 352408.. let me update and try it
>
> R
>
>> On Sep 17, 2019, at 1:10 PM, Randall Stewart wrote:
>>
>> Hmm
>>
>> Did you get the patch I updated too this am?
>>
>&
looking
I was at 352408.. let me update and try it
R
> On Sep 17, 2019, at 1:10 PM, Randall Stewart wrote:
>
> Hmm
>
> Did you get the patch I updated too this am?
>
> I have built it both with and without the bbr stack and had no issue.. there
> was
> an issue
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
hat as a must-have? Is that
> functionality implemented via tcp_ratelimit.[ch]?
>
> Any pointers to existing presentations/discussions highly appreciated?
>
> Thanks a lot.
>
> On Tue, Sep 17, 2019 at 5:39 AM Randall Stewart wrote:
> You should be able to compile it against the curren
uld
> like to patch and experiment with it. I couldn't find this info in the
> released patch.
>
> Thanks a lot!
>
> On Tue, Sep 10, 2019 at 10:26 AM Ryan Stone wrote:
> rrs@ has just posted the BBR patch to phabricator:
>
> https://reviews.fre
rrs accepted this revision.
rrs added a comment.
These look fine and familiar ;-)
I think a hash table as an option to sorting is probably a good thing :D
REVISION DETAIL
https://reviews.freebsd.org/D6689
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
propose a patch to make _callout_stop_safe() returns 0 (fail)
>>> J> when the callout is currently running:
>>> J>
>>> J> callout_stop() should return 0 when the callout is currently being
>>> J> serviced and indeed unst
should return 0 when the callout is currently being
>> J> serviced and indeed unstoppable
>> J>
>> https://reviews.freebsd.org/differential/changeset/?ref=62513&whitespace=ignore-most
>> J>
>> J> But this change impacted too many old code paths and w
rrs added a comment.
It would be worth checking the assembly output.. if it truly inlines it then
it should probably only do one compare.. but worth checking...
REVISION DETAIL
https://reviews.freebsd.org/D6137
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreference
to start looking at the cleanup
if you
want to pursue this.
R
On Dec 11, 2015, at 11:13 AM, Randall Stewart wrote:
> Hans:
>
> I don’t think you are getting a 1 back from the callout_reset()..
>
> If the pending bit is set, you get a 1 back. But if you have a race where
>
eturn 0. We should also drop one ref at
>> POINT1, or rewrite the code a bit, which might need Randall's help in
>> the callout subsystem area.
>>
>
> Hi,
>
> Looking at the version history, I see Gleb Smirnoff and Randall, heavily
> involved with these cod
Selasky wrote:
> On 12/10/15 16:25, Randall Stewart wrote:
>> For callout_stop/drain you get
>>
>> -1 == Callout as already gone off or is not running (usually the latter)
>> else the caller iks
>> not using locking properly or did not lock and check the act
gt; fork_trampoline() at fork_trampoline+0xe/frame 0xfe03e4e8cab0
>>> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
>>
>> Looks like callout_reset() must be examined too, and was missed by:
>>
>> https://svnweb.freebsd.org/changeset/base/290805
>>
>
:
>>>> .
----
Randall Stewart
r...@netflix.com
803-317-4952
___
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"
rrs added a comment.
The socket buffer with SCTP is just not something thats workable. There are
all sorts of pre-defined notions that closely align a socket buffer to
stream-of-bytes
semantics of TCP. With UDP its never an issue, since you have all un-ordered
who
cares up come the mess
OCK(last);
>inp_lost:
>return (IPPROTO_DONE);
> freebeast(11.0-C)[5]
>
> Thanks! :-)
>
> Peace,
> david
> --
> David H. Wolfskillda...@catwhisker.org
> Those who murder in the name of God or prophet are blasphe
rrs closed this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1711
To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, imp, adrian, hselasky, sbruno
Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net
___
freebsd-net@freeb
rrs added a comment.
Ok after much discussion with Hans, we *could* have an issue where the
user sends in an invalid CPU. This is *not* what I think is happening with Hiren
since the cc_cpu and lock is all sane (it would be a invalid index to cc_cpu
which
would not have an init'd lock). But I hav
rrs added a comment.
I have thought long and hard about this. I don't think its a bug.
But to know for sure I will need to add some instrumentation.
I suspect what is happening is a tremendous number of callouts
all come due at the same time. The three back traces trying to stop or reset
a callou
rrs added a comment.
Hans:
I think your wrong here. The caller of callout_cpu_switch() is holding
the CC_LOCK(). Now there are only two callers of this function.
Either the actual callout code itself (softclock_call_cc()) or
the callout_reset_sbt_on(). In the case of callout_reset_sbt_on().
So
rrs added a comment.
Hans:
Let me explain to you how I think you are wrong, you are missing a
small subtle thing here
When we do the callout_stop we set
cc_migration_cpu() = CPUBLOCK
*NOT*
c->c_cpu = CPUBLOCK;
You are confusing the two things. The CPUBLOCK is used
in two different places
rrs added a comment.
Hiren:
You have the wrong structure type.
In the printf before panic it is giving you the lock that was spinning.. that
would be in the callout_cpu structure I bet.. I mis-told you in email.
So if you did
print *(struct callout_cpu *)0x81364180
It should show you
rrs added a comment.
Wow, but look at the flags here. They are cc_flags == 0.
That means its *not* on the wheel and yet the thing it points to
(our victim) *thinks* its on the wheel.
This is not good.. We are stuck in a lock
trying to reschedule the timeout (a lock that is
not locked by the way
rrs added a comment.
Hiren:
There also should have been a printf before the panic string
printf( "spin lock %p (%s) held by %p (tid %d) too long\n",
m, m->lock_object.lo_name, td, td->td_tid);
Can we see what that lovely printf has displayed?
In theory the lo_name should be "callou
rrs added a comment.
Hiren:
Thats helpful.. as I said this is strange. The callout you posted shows its
associated with CPU 0, (c_cpu == 0), and yet
the mtx on that (which is what we are spinning on) is free (its owned == 4). So
why would we have crashed
holding the spin lock too long? Unless j
rrs added a comment.
Hans:
I don't get your call sequence, I sent you an email on it..
Hiren:
Can you go up the call chain and dump the callout structure
c in
0x80760064 in callout_lock (c=0xf8000d81dc98) at
/usr/src/sys/kern/kern_timeout.c:530
There is something funny here, becau
rrs added a comment.
Jhb/Others
So lets go through your scenario with code in arp:
a) softclock dequeues callout to run
-- Which calls softclock_call_cc
We make it to line:676 and see that "yes" the user (arp) init'd with a
rw_mtx
and run the next line 677 (to get the lock).
b) othe
rrs added a comment.
Adrian:
I know he said callout_drain, but just like in TCP that is *not* always
possible. In
the case of the arp/nd6 code lock are held (same as TCP) so you can't do a
callout_drain. Thats
why the original author put ref-counting in with the idea that the timer would
kill
rrs added a comment.
Hmm thinking about your comment jhb, we could easily add the
callout_drain_async to the
current callout code. If you think its worth while maybe we should add that to
D1711
Jhb, if you think its worth doing add that to D1711 and I will work on it ;-)
REVISION DETAIL
http
rrs added a comment.
JHB:
The scenario you outline is *exactly* the panic that was seen by sbruno. I
guess my description
was unclear.
The existing code in that other thread right now does a callout_stop and
tests the return code. If its one its one (which says I canceled a callout)
then it
l
rrs added a comment.
I don't think this is a refcnt issue bz, the base of this is a hole in the way
the callout code works. Basically there is a window when
a) The callout_wheel is executing, it sees that a "lock" has been configured,
so it goes to
release the callout wheel lock and then lo
rrs created this revision.
rrs added reviewers: jhb, imp, sbruno, gnn, rwatson, lstewart, kostikbel,
adrian.
rrs added subscribers: hselasky, julian, hiren, emaste, freebsd-net.
REVISION SUMMARY
There is a hole in the timer code that when you give it
a lock, it will lock that lock and then ch
rrs added a comment.
I have created D1777 to address the nd6/arp crash separately. I am currently in
the midst
of testing these.
REVISION DETAIL
https://reviews.freebsd.org/D1711
To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, sbruno, imp, adrian, hselasky
Cc: julian, hiren, jhb, kostikbel,
rrs added a comment.
Imp:
Ok I have spent a bit of time puzzling this out. First I was mistaken, the
callouts being run
are either arptimer or nd6timer(function name not right). These are not using
giant but
the passed in lle structure rw_lock.
We need to adjust these so that they check they:
rrs added a comment.
Julian:
The simple fix is to change the callout_init_rw -> callout_init(c, 1);
That makes it so the callout_stop() in this instance would return 0, not 1.
Since the
callout could not be stopped.
This would then cause the reference count to drop to 1 (it was 2 the original
rrs updated this revision to Diff 3631.
rrs added a comment.
This revision now requires review to proceed.
This fixes the comment as imp suggested and the indent...
CHANGES SINCE LAST UPDATE
https://reviews.freebsd.org/D1711?vs=3603&id=3631
REVISION DETAIL
https://reviews.freebsd.org/D1711
rrs added a comment.
Julian:
The point is *exactly* that, the callout *has* a reference.. and now that the
table is being
flushed if the callout_stop returns 1 it thinks the callout has been stopped,
which it has, which
means it will not run and release its reference. Thus the lowering of the
rrs added a comment.
Ok guys, I have puzzled out what that crash *may* be that was posted by Hiren.
The same
issue exists in the timeout code rewrite that Han's has up on the board as
well. Though
the callout_drain_async() may solve it if the user called that instead. Here is
what is happening.
rrs added a comment.
Hiren:
Ok looking at kern_timeout.c thats a call to
class->lc_lock(c_lock, lock_status);
If my 10.x matches yours.
And the call inside that kern_rwlock.c:757
is
v = rw->rw_lock;
owner = (struct thread *)RW_OWNER(v);
I would imagine v is probably a freed lock or some suc
rrs added a comment.
Sbruno: I have a hard time connecting the dots between the kernel panic's you
are seeing
and the callout system (especially the changes I made above). You were getting
a spin-lock held
too long right?
hiren:
This looks interesting to me, it is definitely something I would
rrs updated this revision to Diff 3603.
rrs added a comment.
Lets try this one more time to get line 789 right ;-)
CHANGES SINCE LAST UPDATE
https://reviews.freebsd.org/D1711?vs=3602&id=3603
REVISION DETAIL
https://reviews.freebsd.org/D1711
AFFECTED FILES
kern/kern_timeout.c
sys/callout
rrs updated this revision to Diff 3602.
rrs added a comment.
This revision now requires review to proceed.
Ed:
See if this comment clarification does not help a bit.
Hans:
I have no intention of *not* leaving the macro changes in here, this was a
comment suggested by
imp and I think its a go
rrs added inline comments.
INLINE COMMENTS
sys/kern/kern_timeout.c:789 Opps I will fix that thanks Ed!
sys/kern/kern_timeout.c:1067-1069 Let me see if I can edit this comment a bit
and make it more clear.
REVISION DETAIL
https://reviews.freebsd.org/D1711
To: rrs, gnn, rwatson, sbruno, lst
rrs added reviewers: jhb, kostikbel.
REVISION DETAIL
https://reviews.freebsd.org/D1711
To: rrs, gnn, rwatson, sbruno, lstewart, imp, hselasky, adrian, jhb, kostikbel
Cc: jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net
___
freebsd-net@freebsd.o
rrs updated this revision to Diff 3591.
rrs added a comment.
This revision now requires review to proceed.
Ok I have stripped out the kernel test framework and moved this
to D1755.. jhb, you are a reviewer there as well ;-)
This boils things down to *just* the fixes to the callout.
CHANGES SINCE
rrs added a comment.
jhb
The only reason I put the test stuff in this patch is its the only way to
validate the patch, and
that is something we really need in the callout system is a way to validate
that its working
correctly since this stuff tends to be very subtle and a bit of a head banger
rrs added a comment.
Imp:
I can see how we can easily move callout_test.h out of sys. That really
should be in the module/tests/callout_test/ dir.
But where would you suggest the global framework file go if not sys?
REVISION DETAIL
https://reviews.freebsd.org/D1711
To: rrs, gnn, rwatson, adr
rrs added a comment.
To answer jhb and kostikbel
1) Yes this does address the two issues that Hans re-write of the callout
system did without changing the KPI.
There may be other bugs as well, but with the test framework and the old
code I could reproduce both issues
(spin lock held to
rrs added a comment.
Hans:
We have discussed that, and *no* it will *not* return the incorrect thing once
it can't be stopped. There is code in the callout_reset_sbt_on() that makes sure
zero is returned. The only way that zero will *not* be returned is if the
PENDING
flag is set. That won't hap
rrs updated this revision to Diff 3503.
rrs added a comment.
This addresses all of the concerns of Hans.
I still need help with getting MK_TESTKERN to properly be
placed in the /mk infrastructure, I have pending queries to GNN and JHB on
this...
CHANGES SINCE LAST UPDATE
https://reviews.freebs
rrs added a comment.
Moving the tests to a sub-dir sounds like a good idea as well.. Thanks Hans..
INLINE COMMENTS
sys/kern/kern_timeout.c:674 Hans, no *you must* set it to false here in the
soft clock so you can recognize if
it is requested to be stopped (if possible). The return codes are
rrs created this revision.
rrs added reviewers: gnn, rwatson, imp, hselasky, adrian, sbruno, lstewart.
rrs added a subscriber: freebsd-net.
REVISION SUMMARY
The callout code had two specific bugs within it after the new CPU migration
feature was added.
1) The callout_active() call at times c
All
Ok I fixed it ;-)
Its in SVN r249848.
I will see about getting it to 9 stable, 8 stable and maybe even
8.4 if RE will let me ;-)
R
On Apr 23, 2013, at 9:40 AM, Tom Evans wrote:
> On Tue, Apr 23, 2013 at 1:08 PM, Randall Stewart wrote:
>> Ok
>>
>> I too have been str
ery-pr.cgi?pr=kern/174749
>>>
>>> Another PR for the same problem but specific to IPFW and 8.2-RELEASE
>>>
>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=157796
>>>
>>> I am hoping someone reading this can give the problem the attention it
>>&g
utting this in is not a good idea IMO.
>
>> Besides that bursting into unknown network conditions is very likely to
>> result in burst losses as well. TCP isn't good at recovering from it.
>> In the end you most likely come out ahead if you decay the resta
>> default?
>
> Please don't. The correct fix is either a) to use the initial window as the
> restart
> window (up to 10 MSS nowadays); b) to use a decay mechanism based on the time
> since
> the last network condition probe. Even the latter must decay to initCWN
bsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
--
Randall Stewart
803-317-4952 (cell)
___
freebsd-net@freebsd.org
Good idea…
I will commit this late today.. just in case there are any trailing comments ;-)
R
On Feb 5, 2013, at 3:52 PM, John Baldwin wrote:
> On Tuesday, February 05, 2013 2:30:36 pm Randall Stewart wrote:
>> Ok
>>
>> Here it is one last time (I hope) with the upda
}
break;
}
+ drbr_advance(ifp, ring->br);
enqueued++;
dev->if_obytes += next->m_pkthdr.len;
if (next->m_flags & M_MCAST)
@@ -955,7 +954,6 @@ mlx4_en_transmit_
Hmm
wait, I could probably do the compare to whats in the ring buffer ;-D
R
On Feb 5, 2013, at 2:04 PM, Randall Stewart wrote:
> Hmm
>
> That would trade off a stack pointer + a compare
> vs always doing the move.
>
> Thats fine until I have to add the _mc() version, then th
pm Randall Stewart wrote:
>> Actually, no it is used.
>>
>> If you look in if_var.h int he drbr_putback() function, it does
>> a buf_ring_swap when the old mbuf pointer does not equal the
>> new mbuf pointer. This *does* happen, I crashed at least once
>> yesterd
gt;br);
+ } else {
+ drbr_putback(ifp, txr->br, next, snext);
+ }
break;
}
+ drbr_advance(ifp, txr->br);
enqueued++;
dev->if_obytes +
drbr_putback(ifp, txr->br, next, snext);
+ }
break;
}
+ drbr_advance(ifp, txr->br);
enqueued++;
dev->if_obytes += next->m_pkthdr.len;
if (next->
have
> to track what comes back from the !foo_encap() call and compare it to
> see if you must swap it out.
>
>
>> I guess the sticky widget is the case of ATLQ as you need to dequeue the
>> packet always in the ALTQ case and put it back if the encap fails.
ling list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
--
Randall Stewart
803-317-4952 (cell)
___
freebsd-net@freebsd.org mailing lis
ags));
#else
===
why after `to'?
-netch-
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
nd():
===
#ifdef SYS_sctp_generic_sendmsg
struct sockaddr *to = NULL;
return (syscall(SYS_sctp_generic_sendmsg, sd,
data, len, to, 0, sinfo, flags));
#else
===
why after `to'?
-netch-
--
Randall Stewart
803-317-4952 (cell)
On Jun 24, 2010, at 6:10 AM, Luigi Rizzo wrote:
On Thu, Jun 24, 2010 at 05:43:36AM -0700, Randall Stewart wrote:
Lugi:
One other comment I want to make about your numbers... well maybe
three ;-)
...
Randall,
my numbers may well be affected by large errors, but the point was
just to show
On Jun 24, 2010, at 5:29 AM, Erik Trulsson wrote:
On Thu, Jun 24, 2010 at 05:19:29AM -0700, Randall Stewart wrote:
Bob:
Thats strange... when I do
man byteorder
(on my FreeBSD 8.0 system upgraded to head .. buildworld/
installworld/
et.al)
I get the same man age showing for both
man
Lugi:
One other comment I want to make about your numbers... well maybe
three ;-)
On Jun 23, 2010, at 10:12 AM, Luigi Rizzo wrote:
On Wed, Jun 23, 2010 at 09:50:26AM -0700, Randall Stewart wrote:
...
strong objection!
We should instead use names with exact sizes (16,32,64).
So please
work when I get in this AM.
I think what's needed here is some hint inside the man ntohl
that for 64 bit quantities should use be64toh/htobe64 and a
reference to that man page..
R
On Jun 23, 2010, at 8:36 PM, Bob Johnson wrote:
On 6/23/10, Randall Stewart wrote:
Then I would strongly su
On Jun 23, 2010, at 12:41 PM, Julian Elischer wrote:
On 6/23/10 10:12 AM, Luigi Rizzo wrote:
On Wed, Jun 23, 2010 at 09:50:26AM -0700, Randall Stewart wrote:
...
strong objection!
We should instead use names with exact sizes (16,32,64).
So please tell me why you object so strongly? We have
Bruce:
Comments (and questions in-line)... (you too Luigi)
On Jun 23, 2010, at 6:33 AM, Bruce Evans wrote:
On Wed, 23 Jun 2010, Luigi Rizzo wrote:
On Tue, Jun 22, 2010 at 05:46:02PM -0400, Randall Stewart wrote:
Hi all:
I have had some fun in my day job playing with exchanging 64bit
On Jun 22, 2010, at 6:12 PM, Luigi Rizzo wrote:
On Tue, Jun 22, 2010 at 05:46:02PM -0400, Randall Stewart wrote:
Hi all:
I have had some fun in my day job playing with exchanging 64bit
numbers. Unfortunately
there is no ntohll() OR htonll() which would be the logical thing
(for
us old
On Jun 22, 2010, at 6:01 PM, Max Laier wrote:
On Tuesday 22 June 2010 23:46:02 Randall Stewart wrote:
Hi all:
I have had some fun in my day job playing with exchanging 64bit
numbers. Unfortunately
there is no ntohll() OR htonll() which would be the logical thing
(for
us old farts) to use
we should have the ntohll() and htonll().. for
consistency if nothing
else.
Any objections to this showing up in a head near you soon (speak soon
or I will commit
the patches to add these ;-D)
R
--
Randall Stewart
803-317-4952 (cell
The following reply was made to PR bin/131365; it has been noted by GNATS.
From: Randall Stewart
To: Mykola Dzham
Cc: bug-follo...@freebsd.org, r...@freebsd.org
Subject: Re: bin/131365: r190758 break using 0 , 0/0, 0.0.0.0/0 as alias for
'default'
Date: Sat, 11 Apr 2009 06:04:37 -0
.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
------
Randall Stewart
803-317-4952 (cell)
803-345-0
ot;freebsd-net-
unsubscr...@freebsd.org"
--
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
t;
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
--
Randall Stewart
803-317-4952 (cell)
On Tue, 23 Dec 2008, Randall Stewart wrote:
4) revamped my s9indent use.. I ran it and then patched back
in just its complaints about me... that way the other s9 issues
can stay in the file untouched by me :-D
Thanks, but it still has many of the style bugs already pointed out
and a few new on
+
+ tunnel_func = (udp_tunnel_func_t) inp->inp_ppcb;
+ tunnel_func(m, off, inp);
+ INP_RUNLOCK(inp);
+ return (IPPROTO_DONE);
+ }
udp6_append(inp, m, off, &fromsa);
INP_RUNLOCK(inp);
return (IPPROTO_DONE);
--
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
N and don't see anything that looks
promising..
Pointers to the right approach would be appreciated.. I am not sure
what the monitor stuff is used for.. but I would like to get this
toolkit fully functional if possible :-)
R
----------
Randall Stewart
803-317-4952 (cell)
mail to "freebsd-net-unsubscr...@freebsd.org"
--
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
many years writing code :-)
5) I ran s9indent.. and of course it found a lot of other things you
missed.. but that
is the way of s9indent I have found :-D
R
diff_with_s9
Description: Binary data
On Dec 12, 2008, at 11:47 AM, Bruce Evans wrote:
On Fri, 12 Dec 2008, Randall Stewart
On Dec 12, 2008, at 12:19 PM, Max Laier wrote:
On Friday 12 December 2008 13:56:38 Randall Stewart wrote:
On Dec 11, 2008, at 8:12 AM, Max Laier wrote:
On Thursday 11 December 2008 13:50:39 Randall Stewart wrote:
...
Another thing... kinda weird.. when I have this thing working with
SCTP
On Fri, 12 Dec 2008, Randall Stewart wrote:
Here is an updated patch it:
1) Fixes style9 issues (I hope.. I went back to vi and tried
tabs :-0.. sigh one of
these doys I will figure out why my .emacs settings just never cut
it :-()
Fraid not.
% Index: netinet/ud
stems)
Have you looked at m_apply() ? It already exists for stuff like this
i.e. functions which act on an mbuf chain, although it doesn't
necessarily expect chain heads.
cheers
BMS
--
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)
e you looked at m_apply() ? It already exists for stuff like this
i.e. functions which act on an mbuf chain, although it doesn't
necessarily expect chain heads.
cheers
BMS
----------
Randall Stewart
803-317-4952 (cell)
On Dec 11, 2008, at 8:12 AM, Max Laier wrote:
On Thursday 11 December 2008 13:50:39 Randall Stewart wrote:
All:
Ok here is what I have come up with.. going along the
lines of Max's suggestion.. its pretty clean I think.
Comments would be most welcome..
The only thing possibly a bit
1 - 100 of 210 matches
Mail list logo
