On Sat, May 19, 2018 at 10:27 PM, Matt Macy wrote:
> + il = malloc(sizeof(struct in_pcblist) + n * sizeof(struct inpcb
> *), M_TEMP, M_WAITOK|M_ZERO);
> + inp_list = il->il_inp_list;
>
Why does this need M_ZERO?
Jonathan
___
svn-src-head@f
On Sun, May 13, 2018 at 8:14 PM, Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:
>
> It did take me some time to track down this "crazy concept you all
> think I just invented", but it is infact in the GNU groff info
> documentaton (found on my 5.4 systems in /usr/share/info/groff.info.gz
On Mon, Apr 30, 2018 at 3:16 AM, hiren panchasara <
hi...@strugglingcoder.info> wrote:
>
> In my understanding, default stack currently cannot use this mechanism.
When do
> you think that'll be possible?
I think I can speak to Randall's plans for this.
Randall chose not to include in this commit
On Sat, Apr 21, 2018 at 1:53 PM, Conrad Meyer wrote:
>
> I don't think this should be enabled by default. Can we leave it
> disabled by default and let consumers opt-in?
I'm willing to change the default if there's a good reason or consensus for
that. However, it is not obvious to me that the de
Compilation should be fixed as of r331483. I also made this an
optional feature in r331485. If you find more problems, please let me
know.
Jonathan
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsub
On Thu, Mar 22, 2018 at 9:05 PM, Justin Hibbits
wrote:
> On Thu, Mar 22, 2018 at 3:44 PM, Andriy Gapon wrote:
> > On 22/03/2018 17:39, Jonathan Looney wrote:
> >> A tinderbox build didn't complain about atomic_fetchadd_64, so I assume
> it is OK.
> >>
&
A tinderbox build didn't complain about atomic_fetchadd_64, so I assume it
is OK.
Yes, this can be made optional, if there is a need for that.
Jonathan
On Thu, Mar 22, 2018 at 2:22 PM, Ruslan Bukin
wrote:
> Also can this be pluggable ?
> It looks like it is optional device which means it can f
On Tue, Mar 6, 2018 at 6:31 PM, Oliver Pinter wrote:
> X-MFC-with:
>
> commit 27ac811b7acd31b1bdbf959fe49a957cdeabf780
> Author: bde
> Date: Fri Mar 24 17:34:55 2017 +
>
ACK. Thanks!
Jonathan
___
svn-src-head@freebsd.org mailing list
https://li
It looks like this is causing compilation failures:
/home/jtl/head/sys/dev/iicbus/ds1672.c:147:20: error: use of undeclared
identifier 'sc'
clock_dbgprint_ts(sc->sc_dev, CLOCK_DBG_READ, ts);
^
/home/jtl/head/sys/dev/iicbus/ds1672.c:162:20: error: use of undeclared
On Mon, Feb 12, 2018 at 12:27 PM, Jonathan T. Looney
wrote:
> Author: jtl
> Date: Mon Feb 12 17:27:50 2018
> New Revision: 329171
> URL: https://svnweb.freebsd.org/changeset/base/329171
>
> Log:
> Mark the pages used for the initial page-table entries as wired. This
> makes them consistent wi
Hi Julien,
I apologize for just getting to this, but your code just made it into my
local tree.
The non-INVARIANTS case looks incorrect. Because tw stays on the list, it
can end up stuck at the front of the queue and block everything behind it.
Personally, I would be more comfortable just panic'
On Sat, Sep 23, 2017 at 4:37 AM, Bjoern A. Zeeb <
bzeeb-li...@lists.zabbadoz.net> wrote:
>
> Then this makes no sense as we don’t do LRO if forwarding is enabled on
> the machine;
> https://svnweb.freebsd.org/base/head/sys/netinet/tcp_lro.c?
> annotate=317390#l645
Yes, that is true. However, thi
Hi Konstantin,
On Sat, Jun 10, 2017 at 2:12 AM, Konstantin Belousov
wrote:
> No, acquire is only specified for loads, and release for stores. In other
> words, on some hypothetical ll/sc architecture, the atomic_add_acq()
> could be implemented as follows, in asm-pseudocode
> atomic_add_acq(int
Hi John, Konstantin,
This crash occurs during system startup when we are trying to switch from
having each write to the vt device do an immediate flush to using a
callout-based asynchronous flushing mechanism.
It appears the crash was caused by having the VDF_ASYNC flag set while the
vd_timer_arm
On Fri, Feb 24, 2017 at 3:19 PM, hiren panchasara <
hi...@strugglingcoder.info> wrote:
> On 02/24/17 at 06:56P, Jonathan T. Looney wrote:
> > Author: jtl
> > Date: Fri Feb 24 18:56:00 2017
> > New Revision: 314216
> > URL: https://svnweb.freebsd.org/changeset/base/314216
> >
> > Log:
> > We have
On Wed, Feb 22, 2017 at 8:18 PM, Jonathan T. Looney wrote:
> Author: jtl
> Date: Thu Feb 23 01:18:47 2017
> New Revision: 314116
> URL: https://svnweb.freebsd.org/changeset/base/314116
>
> Log:
> Fix a panic during boot caused by inadequate locking of some vt(4) driver
> data structures.
>
>
Thanks!
Yes, that was clearly an error on my part, and your patch is an obvious
solution. I committed it at r307336.
Thanks again!
Jonathan
On Fri, Oct 14, 2016 at 8:01 PM, Shawn Webb
wrote:
> On Wed, Oct 12, 2016 at 02:16:42AM +, Jonathan T. Looney wrote:
> > Author: jtl
> > Date: Wed Oc
On Wed, Oct 12, 2016 at 5:44 AM, Slawa Olhovchenkov wrote:
> Do you perform estimate of performane impact of this overhead?
>
>
Somewhat, but not precisely. It will depend on (at least) a few factors:
a. The hardware
* How fast is your CPU? Your L1/L2/L3 cache?
* How many CPUs?
* How sm
On Tue, Oct 11, 2016 at 10:30 PM, Jonathan T. Looney
wrote:
> Author: jtl
> Date: Wed Oct 12 02:30:33 2016
> New Revision: 307083
> URL: https://svnweb.freebsd.org/changeset/base/307083
>
> Log:
> Currently, when tcp_input() receives a packet on a session that matches a
> TCPCB, it checks (so
On Fri, Mar 4, 2016 at 12:49 AM, Warner Losh wrote:
> It's trivial so worth having. We should discuss what our "oldest
> supported upgrade" release should be as currently it is 8.1.
>
> We put it to 8.1 based on Juniper wanted it for their operations.
> Normally we'd set this closer to 9.0 or so
On 10/13/15, 10:33 PM, "Hiren Panchasara" wrote:
>>
>> I also replied to the review with style findings just now.
>>
>I'll ask Jonathan to look at it.
Thanks for the comments. I'll prepare a cleanup patch which addresses
this, and other comments which arrived after the commit.
Jonathan
__
On 10/14/15, 7:38 AM, "Gleb Smirnoff" wrote:
>What if we write it down this way (thanks C11):
>
>struct tcpcb {
> ...
> union {
>#ifdef TCPPCAP
> struct {
> struct mbufq t_inpkts;
> struct mbufq t_outpkts;
> };
>#e
22 matches
Mail list logo
