Fixed in 333575.
On Sat, May 12, 2018 at 00:35 Peter Holm wrote:
> On Sat, May 12, 2018 at 01:26:34AM +, Matt Macy wrote:
> > Author: mmacy
> > Date: Sat May 12 01:26:34 2018
> > New Revision: 333509
> > URL: https://svnweb.freebsd.org/changeset/base/333509
> >
> > Log:
> > hwpmc(9): Make
See r333631
On Tue, May 15, 2018 at 09:18 Mark Johnston wrote:
> On Tue, May 08, 2018 at 01:39:45AM +, Matt Macy wrote:
> > Author: mmacy
> > Date: Tue May 8 01:39:45 2018
> > New Revision: 45
> > URL: https://svnweb.freebsd.org/changeset/base/45
> >
> > Log:
> > Sleep rather than
How do I avoid problems while allowing timely updates?
-M
On Thu, May 17, 2018 at 11:38 AM, Emmanuel Vadot wrote:
>
> Hi Matt,
>
> On Thu, 17 May 2018 18:14:10 + (UTC)
> Matt Macy wrote:
>
>> Author: mmacy
>> Date: Thu May 17 18:14:10 2018
>> New Revision: 333745
>> URL: https://svnweb.fre
On Thu, May 17, 2018 at 12:32 PM, Pedro Giffuni wrote:
>
>
> On 17/05/2018 14:27, Emmanuel Vadot wrote:
>>
>> On Thu, 17 May 2018 14:20:05 -0500
>> Pedro Giffuni wrote:
>>
>>> On 17/05/2018 14:12, Matthew Macy wrote:
>>>>
>>>> H
It's not breaking the build there, but I'd be fine with removing it
more generally.
-M
On Thu, May 17, 2018 at 2:08 PM, Nathan Whitehorn
wrote:
>
>
> On 05/17/18 14:04, Matt Macy wrote:
>>
>> Author: mmacy
>> Date: Thu May 17 21:04:19 2018
>> New Revision: 333765
>> URL: https://svnweb.freebsd.o
> - epoch_enter_critical() - can be called inside a different epoch,
> starts a section that will acquire any MTX_DEF mutexes or do
> anything that might sleep.
Should read will _not_ acquire ...
> - epoch_exit_critical() - corresponding exit call
> - epoch_wait_critical() - wait va
Sorry, will do
On Fri, May 18, 2018 at 15:29 John Baldwin wrote:
> On Thursday, May 17, 2018 07:30:57 PM Matt Macy wrote:
> > Author: mmacy
> > Date: Thu May 17 19:30:57 2018
> > New Revision: 333757
> > URL: https://svnweb.freebsd.org/changeset/base/333757
> >
> > Log:
> > epoch(9): missed ad
I guess we'll need to allocate more pages at boot. We must have been
on the edge already if that pushed us over.
-M
On Fri, May 18, 2018 at 12:03 PM, Ilya Bakulin wrote:
> Hi Matt,
> seems this commit has broken at least BeagleBone Black booting process. On
> all revisions after it the kernel pan
8 at 9:13 AM, Matthew Macy wrote:
>>
>> I guess we'll need to allocate more pages at boot. We must have been
>> on the edge already if that pushed us over.
>> -M
>>
>> On Fri, May 18, 2018 at 12:03 PM, Ilya Bakulin wrote:
>> > Hi Matt,
>&
r333874
On Sat, May 19, 2018 at 12:16 AM, Matthew Macy wrote:
> I can do that tomorrow. But point is that something else will push it over
> soon.
>
> On Sat, May 19, 2018 at 12:14 AM, Mateusz Guzik wrote:
>> imo all these sysinits can and shoud be collapsed into one, which w
Oops I’ll add a separate define for that
On Sat, May 19, 2018 at 04:27 Ed Maste wrote:
> On 18 May 2018 at 20:04, Matt Macy wrote:
> > Author: mmacy
> > Date: Sat May 19 00:04:01 2018
> > New Revision: 333819
> > URL: https://svnweb.freebsd.org/changeset/base/333819
> >
> > Log:
> > Silence n
uipc_usrreq.c Sat May 19 02:15:40 2018
> (r333822)
> >> @@ -4,7 +4,7 @@
> >> * Copyright (c) 1982, 1986, 1989, 1991, 1993
> >> * The Regents of the University of California.
> >> * Copyright (c) 2004-2009 Robert N. M. Watson
> >> - * A
sys/conf/files: compile-with "${NORMAL_C} ${NO_WSHIFT_COUNT_NEGATIVE}
${NO_WSHIFT_COUNT_OVERFLOW} -I$S/dev/ath"
On Sat, May 19, 2018 at 5:30 AM, Matthew Macy wrote:
> Oops I’ll add a separate define for that
>
> On Sat, May 19, 2018 at 04:27 Ed Maste wrote:
>>
>> On 18 May 2018
On Sat, May 19, 2018 at 8:56 AM, Emmanuel Vadot wrote:
> On 2018-05-19 17:39, Matthew Macy wrote:
>>
>> On Sat, May 19, 2018 at 07:17 Emmanuel Vadot
>> wrote:
>>
>>> On 2018-05-19 15:35, Rodney W. Grimes wrote:
>>>>
>>>> [ Charset
On Sat, May 19, 2018 at 4:49 AM, Ed Maste wrote:
> On 19 May 2018 at 02:31, Matt Macy wrote:
>> Author: mmacy
>> Date: Sat May 19 06:31:17 2018
>> New Revision: 333872
>> URL: https://svnweb.freebsd.org/changeset/base/333872
>>
>> Log:
>> ctfconvert: silence useless enum has too many values war
gcc8
On Sun, May 20, 2018 at 15:14 Rick Macklem wrote:
> Matt Macy wrote:
> >Author: mmacy
> >Date: Sun May 20 06:14:12 2018
> >New Revision: 333924
> >URL: https://svnweb.freebsd.org/changeset/base/333924
> >
> >Log:
> > nfsclient: warnings cleanups
> Just wondering what compiler you are using
c8 make -j buildkernel
and
WITHOUT_FORMAT_EXTENSIONS= XCC=/usr/local/bin/gcc8 make -j
buildkernel KERNCONF=GENERIC-NODEBUG
Thanks.
On Sun, May 20, 2018 at 4:09 PM, Matthew Macy wrote:
> gcc8
>
> On Sun, May 20, 2018 at 15:14 Rick Macklem wrote:
>>
>> Matt Macy wrote:
>
on where I can use gcc, but if you email me the
> list of warnings, I can look at them.
>
> rick
>
> ____
> From: Matthew Macy
> Sent: Sunday, May 20, 2018 7:16:31 PM
> To: Rick Macklem
> Cc: src-committ...@freebsd.org; svn-src-...@freeb
Thanks
On Mon, May 21, 2018 at 00:47 Marko Zec wrote:
> On Mon, 21 May 2018 07:12:06 +
> Matt Macy wrote:
>
> > Author: mmacy
> > Date: Mon May 21 07:12:06 2018
> > New Revision: 333967
> > URL: https://svnweb.freebsd.org/changeset/base/333967
> >
> > Log:
> > ensure that vnet is set when
On Mon, May 21, 2018 at 00:47 Marko Zec wrote:
> On Mon, 21 May 2018 07:12:06 +
> Matt Macy wrote:
>
> > Author: mmacy
> > Date: Mon May 21 07:12:06 2018
> > New Revision: 333967
> > URL: https://svnweb.freebsd.org/changeset/base/333967
> >
> > Log:
> > ensure that vnet is set when doing i
Sorry about that
On Mon, May 21, 2018 at 04:59 Hans Petter Selasky wrote:
> On 05/21/18 13:49, Ed Maste wrote:
> > After r333968 the build is also broken on all archs but amd64 and i386.
>
> It looks like amd64 and i386 build with VIMAGE enabled by default, while
> the others not. 12-current. So
Looking closer I think the ifp should always be set. I'll just add an
assert to that effect and make it non-conditional.
-M
On Mon, May 21, 2018 at 1:55 AM, Marko Zec wrote:
> On Mon, 21 May 2018 08:34:10 +
> Matt Macy wrote:
>
>> Author: mmacy
>> Date: Mon May 21 08:34:10 2018
>> New Revisi
Good point. Will fix.
On Mon, May 21, 2018 at 9:54 AM, Eric van Gyzen wrote:
> On 05/19/2018 00:09, Matt Macy wrote:
>> @@ -1663,16 +1655,18 @@ static int
>> umtxq_sleep_pi(struct umtx_q *uq, struct umtx_pi *pi, uint32_t owner,
>> const char *wmesg, struct abs_timeout *timo, bool shared)
>>
Bear in mind that prior to my change most functions would call it
without ever using it on non-debug builds.
On Mon, May 21, 2018 at 9:54 AM, Eric van Gyzen wrote:
> On 05/19/2018 00:09, Matt Macy wrote:
>> @@ -1663,16 +1655,18 @@ static int
>> umtxq_sleep_pi(struct umtx_q *uq, struct umtx_pi *p
On Mon, May 21, 2018 at 6:15 AM, Jonathan Looney wrote:
> 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?
It a
On Tue, May 22, 2018 at 00:33 Eitan Adler wrote:
> On 21 May 2018 at 01:34, Matt Macy wrote:
> > Author: mmacy
> > Date: Mon May 21 08:34:10 2018
> > New Revision: 333968
> > URL: https://svnweb.freebsd.org/changeset/base/333968
> >
> > Log:
> > in(6)_mcast: Expand out vnet set / restore macro
Track
On Wed, May 23, 2018 at 06:53 Ian Lepore wrote:
> On Wed, 2018-05-23 at 06:15 +, Matt Macy wrote:
> > Author: mmacy
> > Date: Wed May 23 06:15:55 2018
> > New Revision: 334074
> > URL: https://svnweb.freebsd.org/changeset/base/334074
> >
> > Log:
> > Bump FreeBSD_version after r33381
On Wed, May 23, 2018 at 9:43 AM, John Baldwin wrote:
> On Wednesday, May 23, 2018 06:15:55 AM Matt Macy wrote:
>> Author: mmacy
>> Date: Wed May 23 06:15:55 2018
>> New Revision: 334074
>> URL: https://svnweb.freebsd.org/changeset/base/334074
>>
>> Log:
>> Bump FreeBSD_version after r333813
>>
>
Thanks.
On Wed, May 23, 2018 at 11:40 AM, Mark Linimon wrote:
> On Wed, May 23, 2018 at 09:56:00AM -0700, Matthew Macy wrote:
>> Thanks updated for 1200064. Someone(tm) needs to do 1200063.
>
> done.
>
> mcl
___
svn-src-head@fre
Talk to the gcc devs. The warning is useful even if there are false positives.
On Wed, May 23, 2018 at 3:27 PM, Gleb Smirnoff wrote:
> Hi,
>
> On Sat, May 19, 2018 at 05:10:52AM +, Matt Macy wrote:
> M> Author: mmacy
> M> Date: Sat May 19 05:10:51 2018
> M> New Revision: 333860
> M> URL: ht
On Wed, May 23, 2018 at 3:57 PM, Gleb Smirnoff wrote:
> The initialization isn't useful.
It silences a gcc warning. So yes it is. It's this exchange which is not useful.
-M
> On Wed, May 23, 2018 at 03:52:42PM -0700, Matthew Macy wrote:
> M> Talk to the gcc devs. The war
On Wed, May 23, 2018 at 11:52 AM, John Baldwin wrote:
> On Wednesday, May 23, 2018 05:00:05 PM Matt Macy wrote:
>> Author: mmacy
>> Date: Wed May 23 17:00:05 2018
>> New Revision: 334104
>> URL: https://svnweb.freebsd.org/changeset/base/334104
>>
>> Log:
>> epoch: allow for conditionally asserti
09:51:34PM -0700, Matthew Macy wrote:
> M> Warnings find bugs PERIOD. Although most are not useful, I've found
> M> quite a number of real issues from compiling with gcc8.
> M>
> M> If you want to _actually_ be helpful fix these:
> M> https://people.freebsd.org/~mm
On Wed, May 23, 2018 at 10:32 PM, Ravi Pokala wrote:
> -Original Message-
> From: on behalf of Matt Macy
>
> Date: 2018-05-23, Wednesday at 21:31
> To: , ,
>
> Subject: svn commit: r334129 - head/sys/amd64/conf
>
>> Author: mmacy
>> Date: Thu May 24 04:31:53 2018
>> New Revision: 3341
error, and we did carry about
> building with gcc8, in this case the assignment should be added with
> a comment /* pacify gcc */.
>
> On Wed, May 23, 2018 at 03:59:33PM -0700, Matthew Macy wrote:
> M> On Wed, May 23, 2018 at 3:57 PM, Gleb Smirnoff wrote:
> M> > The initializat
On Wed, May 23, 2018 at 10:25 PM, Gleb Smirnoff wrote:
> On Wed, May 23, 2018 at 10:13:25PM -0700, Matthew Macy wrote:
> M> On Wed, May 23, 2018 at 10:07 PM, Gleb Smirnoff
> wrote:
> M> > Can you please explain the bug supposed to be fixed by r333860 QUESTION
> MAR
On Wed, May 23, 2018 at 11:35 PM, Michael Tuexen
wrote:
>> On 24. May 2018, at 06:51, Matthew Macy wrote:
>>
>> Warnings find bugs PERIOD. Although most are not useful, I've found
> Some warnings indicate bugs, some warnings are just wrong. If you
> have a "
On Wed, May 23, 2018 at 11:42 PM, Michael Tuexen
wrote:
>> On 24. May 2018, at 08:36, Matthew Macy wrote:
>>
>> On Wed, May 23, 2018 at 11:35 PM, Michael Tuexen
>> wrote:
>>>> On 24. May 2018, at 06:51, Matthew Macy wrote:
>>>>
>>>> W
Bugs in the code I'd just imported because I imported from the wrong branch :-/
On Wed, May 23, 2018 at 11:50 PM, Cy Schubert wrote:
> In message <201805240647.w4o6lesd071...@repo.freebsd.org>, Matt Macy
> writes:
>> Author: mmacy
>> Date: Thu May 24 06:47:40 2018
>> New Revision: 334134
>> URL:
Ugh. Not intentional
On Thu, May 24, 2018 at 02:35 Sergey Kandaurov wrote:
> On 24 May 2018 at 07:30, Matt Macy wrote:
>
>> Author: mmacy
>> Date: Thu May 24 04:30:06 2018
>> New Revision: 334128
>> URL: https://svnweb.freebsd.org/changeset/base/334128
>>
>> Log:
>> libpmcstat: compile in eve
On Thu, May 24, 2018 at 8:54 AM, Warner Losh wrote:
>
>
> On Thu, May 24, 2018 at 12:36 AM, Matthew Macy wrote:
>>
>> On Wed, May 23, 2018 at 11:35 PM, Michael Tuexen
>> wrote:
>> >> On 24. May 2018, at 06:51, Matthew Macy wrote:
>> >>
>
On Thu, May 24, 2018 at 8:58 AM, Warner Losh wrote:
>
>
> On Thu, May 24, 2018 at 12:53 AM, Matthew Macy wrote:
>>
>> On Wed, May 23, 2018 at 11:42 PM, Michael Tuexen
>> wrote:
>> >> On 24. May 2018, at 08:36, Matthew Macy wrote:
>> >>
>
>
> False positives are compiler bugs.
No they're not. No more than missed optimization opportunities.
They're limitations in the control flow analysis.
>
> It does happen, with GCC more than with clang, that the compiler has too
> many bugs and it's a bad practice to pessimize code to work aroun
On Thu, May 24, 2018 at 8:51 AM, Andrew Gallatin wrote:
> On 05/23/18 20:09, Pedro Giffuni wrote:
>>
>> FWIW;
>>
>> On 23/05/2018 17:18, Cy Schubert wrote:
>>>
>>> In message <20180523202228.gc58...@spindle.one-eyed-alien.net>, Brooks
>>> Davis wr
>>> ites:
--QRj9sO5tAVLaXnSD
C
On Thu, May 24, 2018 at 3:36 PM, John Baldwin wrote:
> On Thursday, May 24, 2018 04:30:06 AM Matt Macy wrote:
>> Author: mmacy
>> Date: Thu May 24 04:30:06 2018
>> New Revision: 334128
>> URL: https://svnweb.freebsd.org/changeset/base/334128
>>
>> Log:
>> libpmcstat: compile in events based on j
I asked for this, so working on a fix. Let me know if you're already
about to commit.
On Thu, May 24, 2018 at 3:14 PM, John Baldwin wrote:
> On Thursday, May 24, 2018 09:38:18 PM Olivier Houchard wrote:
>> Author: cognet
>> Date: Thu May 24 21:38:18 2018
>> New Revision: 334189
>> URL: https://sv
Odd. I tested the same thing as did pho with regular interfaces. Will fix
asap.
On Fri, May 25, 2018 at 09:36 Mark Johnston wrote:
> On Wed, May 23, 2018 at 09:02:15PM +, Matt Macy wrote:
> > Author: mmacy
> > Date: Wed May 23 21:02:14 2018
> > New Revision: 334118
> > URL: https://svnweb.fr
On Fri, May 25, 2018 at 9:24 PM, Kurt Lidl wrote:
> On 5/24/18 3:22 PM, Matthew Macy wrote:
>>
>> i386 is definitely on the wane, but so long as it's used by more than
>> a handful of people it will be supported. All you need to know about
>> sparc64 vitality is th
I've re-edited that code twice by request by others. I will amend it
again at some point to reflect this viewpoint.
On Sat, May 26, 2018 at 12:44 PM, Eric van Gyzen wrote:
> On 05/23/2018 23:47, Gleb Smirnoff wrote:
>>
>> On Thu, May 24, 2018 at 06:44:20AM +0200, Mateusz Guzik wrote:
>> M> I fund
On Mon, Jun 4, 2018 at 5:08 AM, Konstantin Belousov wrote:
> On Mon, Jun 04, 2018 at 01:10:23AM +, Matt Macy wrote:
>> @@ -2214,6 +2236,11 @@ pmc_hook_handler(struct thread *td, int function, void
>>
>> pmc_capture_user_callchain(PCPU_GET(cpuid), PMC_HR,
>> (str
This appears to have broken the NOINET build.
--- ip6_gre.o ---
cc -target i386-unknown-freebsd12.0
--sysroot=/home/mmacy/devel/build/home/mmacy/networking/i386.i386/tmp
-B/home/mmacy/devel/build/home/mmacy/networking/i386.i386/tmp/usr/bin
-O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MO
Which arch? Universe is passing for me (except for pre-existing
breakage of i386-LINT-NOINET).
-M
On Tue, Jun 5, 2018 at 8:53 PM, Cy Schubert wrote:
> In message <201806060248.w562m9tb083...@repo.freebsd.org>, Matt Macy
> writes:
>> Author: mmacy
>> Date: Wed Jun 6 02:48:09 2018
>> New Revision
-DNO_CLEAN doesn't work with the file rename.
On Tue, Jun 5, 2018 at 10:14 PM, Cy Schubert wrote:
> amd64
>
> ~cy
>
> In message il.com>
> , Matthew Macy writes:
>> Which arch? Universe is passing for me (except for pre-existing
>> breakage of i386-LINT
pmu events hasn't been in libpmcstat for a while
On Wed, Jun 6, 2018 at 08:36 Bryan Drewery wrote:
> On 6/5/18 12:32 AM, Kyle Evans wrote:
> > On Mon, Jun 4, 2018 at 10:11 PM, Kyle Evans wrote:
> >> On Fri, May 25, 2018 at 4:46 PM, Bryan Drewery
> wrote:
> >>> Author: bdrewery
> >>> Date: Fri
On Wed, Jun 6, 2018 at 12:03 PM, Peter Holm wrote:
> On Thu, May 17, 2018 at 05:59:35PM +, Matt Macy wrote:
>> Author: mmacy
>> Date: Thu May 17 17:59:35 2018
>> New Revision: 333744
>> URL: https://svnweb.freebsd.org/changeset/base/333744
>>
>> Log:
>> AF_UNIX: make unix socket locking fine
Try r334756 and then send me your scripts for any panics you can produce.
-M
On Wed, Jun 6, 2018 at 7:12 PM, Matthew Macy wrote:
> On Wed, Jun 6, 2018 at 12:03 PM, Peter Holm wrote:
>> On Thu, May 17, 2018 at 05:59:35PM +, Matt Macy wrote:
>>> Author: mmacy
>>>
>
> Okay. I believe there might be situations where we may want to still
> keep the 'default' stack alive. I know Windows doesn't yet use RACK when
> rtt is lesser than 10ms (or something like that), as an example.
>
Is there any reason RACK wouldn't work for tracking 10us RTTs? If we
know we kno
> The main codepath which runs into this (... -> cache_lookup -> vhold) most
> definitely does not need the fence for production operation.
>
> What is unclear without audit is whether there are vhold users which need
> one. I think the patch is fine to go in if the other VI_FREE place gets a
> com
On Fri, Jun 8, 2018 at 07:35 Mark Johnston wrote:
> On Fri, Jun 08, 2018 at 04:58:03AM +, Matt Macy wrote:
> > Author: mmacy
> > Date: Fri Jun 8 04:58:03 2018
> > New Revision: 334827
> > URL: https://svnweb.freebsd.org/changeset/base/334827
> >
> > Log:
> > hwpmc: simplify calling convent
> The fact that our NMI handler isn't re-entrant can lead to subtle
> problems. If while executing the NMI handler we hit a dtrace
> probe or DDB breakpoint, the iret executed upon return to the handler
> will re-enable NMIs. Then, if a second NMI arrives before the handler
> for the first has retu
On Sat, Jun 9, 2018 at 10:51 Mark Johnston wrote:
> On Sat, Jun 09, 2018 at 08:11:15AM -0400, John Baldwin wrote:
> > On 6/8/18 12:34 PM, Matthew Macy wrote:
> > >> The fact that our NMI handler isn't re-entrant can lead to subtle
> > >> problems. If wh
Fair. But it didn't actually work before. It's not clear anyone has
ever used it.
On Mon, Jun 11, 2018 at 9:54 AM, Mark Johnston wrote:
> On Mon, Jun 11, 2018 at 04:31:43PM +, Matt Macy wrote:
>> Author: mmacy
>> Date: Mon Jun 11 16:31:42 2018
>> New Revision: 334960
>> URL: https://svnweb.fr
On Wed, Jun 13, 2018 at 4:47 PM, Ryan Libby wrote:
> On Wed, Jun 13, 2018 at 4:30 PM, Matt Macy wrote:
>> Author: mmacy
>> Date: Wed Jun 13 23:30:54 2018
>> New Revision: 335094
>> URL: https://svnweb.freebsd.org/changeset/base/335094
>>
>> Log:
>> fix OFED build after r335053
>>
>> Modified:
>
diff --git a/sys/kern/uipc_socket.c b/sys/kern/uipc_socket.c
index 2d6dc845938..35bcad41a59 100644
--- a/sys/kern/uipc_socket.c
+++ b/sys/kern/uipc_socket.c
@@ -2175,6 +2175,7 @@ soreceive_stream(struct socket *so, struct
sockaddr **psa, struct uio *uio,
struct sockbuf *sb;
struct m
This breaks universe / tinderbox on AMD64. You appear to have
committed parts of a patch to ixlvc.c. I'm not quite clear on what
happened here and if just removing the '+' will produce something
usable.
void
ixlv_configure_queues(struct ixlv_sc *sc)
{
device_tdev = sc->dev;
stru
OK. I've taken it out of NOTES until such time.
-M
On Mon, Jun 18, 2018 at 7:38 PM, Eric Joyner wrote:
> It probably won't result in anything usable. I need to remove ixlvc.c from
> the build since the VF driver as a whole doesn't work atm.
>
> - Eric
>
> On Mon
pho@ and sbruno@ tested the patch before commit, I can't readily
reproduce even though the detach path should be common enough. Please
tell me if this helps:
https://people.freebsd.org/~mmacy/inpcb.diff
Thanks.
On Sat, May 5, 2018 at 2:01 AM, O. Hartmann wrote:
> -BEGIN PGP SIGNED MESSAGE
_tcbinfo);
}
We're still acquiring a sleepable mutex out of order with a read lock
held with the former version of the patch.
On Sat, May 5, 2018 at 1:31 PM, O. Hartmann wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Am Sat, 5 May 2018 11:21:47 -0700
> Matthe
it's in the same place as before but I'll attach just to be clear.
Gzipped to keep gmail from inserting carriage returns.
-M
On Sat, May 5, 2018 at 1:54 PM, O. Hartmann wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Am Sat, 5 May 2018 13:45:13 -0700
&
Is the e1000 driver compiled in or loaded as a module?
-M
On Tue, May 8, 2018 at 3:10 PM, Mark Johnston wrote:
> On Tue, May 08, 2018 at 01:39:45AM +, Matt Macy wrote:
>> Author: mmacy
>> Date: Tue May 8 01:39:45 2018
>> New Revision: 45
>> URL: https://svnweb.freebsd.org/changeset/bas
Can you please try the attached patch? (Note that gmail may insert
carriage returns)
-M
On Tue, May 8, 2018 at 3:10 PM, Mark Johnston wrote:
> On Tue, May 08, 2018 at 01:39:45AM +, Matt Macy wrote:
>> Author: mmacy
>> Date: Tue May 8 01:39:45 2018
>> New Revision: 45
>> URL: https://svn
Nix that. The panic is incorrect, we simply don't have anything to do
in the default case.
On Tue, May 8, 2018 at 4:31 PM, Matthew Macy wrote:
> Can you please try the attached patch? (Note that gmail may insert
> carriage returns)
>
> -M
>
> On Tue, May 8, 2018 at 3:10 P
Can you tell me anything more about your workload?
On Wed, May 9, 2018 at 5:48 AM, Tom Jones wrote:
> On Sun, May 06, 2018 at 08:34:13PM +, Matt Macy wrote:
>> Author: mmacy
>> Date: Sun May 6 20:34:13 2018
>> New Revision: 09
>> URL: https://svnweb.freebsd.org/changeset/base/09
>>
>
On Wed, May 9, 2018 at 11:03 AM, Tom Jones wrote:
> On Wed, May 09, 2018 at 10:47:17AM -0700, Matthew Macy wrote:
>> Can you tell me anything more about your workload?
>
> Running the VM snapshot based on r333209, with kernels built today. VM
> will panic sitting idle. Network
Yes. Can you give me the line number for epoch_call_task+0x7b
On Fri, May 11, 2018 at 12:18 AM, Peter Holm wrote:
> On Fri, May 11, 2018 at 04:54:13AM +, Matt Macy wrote:
>> Author: mmacy
>> Date: Fri May 11 04:54:12 2018
>> New Revision: 333480
>> URL: https://svnweb.freebsd.org/changeset/b
- How many cores? How many sockets?
- Any special config options other than DIAGNOSTIC?
On Fri, May 11, 2018 at 12:29 AM, Matthew Macy wrote:
> Yes. Can you give me the line number for epoch_call_task+0x7b
>
>
> On Fri, May 11, 2018 at 12:18 AM, Peter Holm wrote:
>> On Fri,
Peter Holm wrote:
> On Fri, May 11, 2018 at 12:36:40AM -0700, Matthew Macy wrote:
>> - How many cores? How many sockets?
>> - Any special config options other than DIAGNOSTIC?
>>
>
> CPU: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz (1995.24-MHz K8-class CPU)
&g
Thanks
On Fri, May 11, 2018 at 11:47 Mark Johnston wrote:
> On Thu, May 10, 2018 at 05:55:25PM +, Matt Macy wrote:
> > Author: mmacy
> > Date: Thu May 10 17:55:24 2018
> > New Revision: 333466
> > URL: https://svnweb.freebsd.org/changeset/base/333466
> >
> > Log:
> > Add simple preempt saf
It fixes something that is completely broken in bmake that everyone in
the know patches on their local systems. It was included by accident.
I immediately backed it out in the subsequent commit.
On Fri, May 11, 2018 at 1:13 PM, Bryan Drewery wrote:
> On 5/10/2018 10:55 AM, Matt Macy wrote:
>> Aut
Are you planning on MFCing this? That’s the main value to MFVs at this
point.
Thanks.
On Mon, Jun 22, 2020 at 23:42 Toomas Soome wrote:
> Author: tsoome
> Date: Tue Jun 23 06:42:39 2020
> New Revision: 362531
> URL: https://svnweb.freebsd.org/changeset/base/362531
>
> Log:
> MFOpenZFS: Add ba
Do not commit directly to sys/contrib. PR, vendor branch update, then merge.
On Wed, Aug 26, 2020 at 12:29 AM Toomas Soome wrote:
>
> Author: tsoome
> Date: Wed Aug 26 07:29:17 2020
> New Revision: 364806
> URL: https://svnweb.freebsd.org/changeset/base/364806
>
> Log:
> remove pragma ident lin
These flags aren't defined by default when building external kernel modules:
gmake[2]: Entering directory '/usr/home/matt/devel/ZoF/module'
env -u MAKEFLAGS make -C /home/matt/devel/ZoF/module -f Makefile.bsd -w
make[3]: Entering directory `/home/matt/devel/ZoF/module'
make[3]: "/usr/home/matt/dev
Just what I put on the review. I’ll put together a man page the week
after next. Sorry for the delay.
-M
On Mon, Nov 30, 2020 at 10:16 Michael Tuexen wrote:
>
>
> > On 29. Nov 2020, at 20:38, Matt Macy wrote:
> >
> > Author: mmacy
> > Date: Sun Nov 29 19:38:03 2020
> > New Revision: 368163
> >
I worry about the incredible mess of header dependencies that the linuxkpi
is prone to introducing. I’m happy to review any proposed changes to that
effect, but do not feel like it’s important enough to make a priority.
Thanks.
-M
On Mon, Nov 30, 2020 at 08:33 Bjoern A. Zeeb
wrote:
> On 30 No
Sorry, I meant to respond.
http://concurrencykit.org/presentations/ebr.pdf
http://scalebsd.org/blog/2018/05/03/Why-is-munmap-single-threaded-and-what-can-we-do-about-it
http://scalebsd.org/blog/2018/06/16/UDP-and-epoch-for-liveness-guarantees
On Sun, Jun 24, 2018 at 13:56 Ed Schouten wrote:
On Mon, Jun 25, 2018 at 01:30 Andriy Gapon wrote:
> On 25/06/2018 10:25, Ed Schouten wrote:
> > Hi Andriy, Matthew,
> >
> > 2018-06-24 23:36 GMT+02:00 Andriy Gapon :
> >> Perhaps a little application of google can help.
> >> [keywords: epoch based reclamation]
> >
> > Based on the man page, it wa
genoffset_test tests that the offsets match up
On Tue, Jul 3, 2018 at 11:02 AM, Bryan Drewery wrote:
> On 7/2/2018 6:55 PM, Matt Macy wrote:
>> Author: mmacy
>> Date: Tue Jul 3 01:55:09 2018
>> New Revision: 335879
>> URL: https://svnweb.freebsd.org/changeset/base/335879
>>
>> Log:
>> make cri
What is the "correct" way to make sure that offset.inc is visible to modules?
On Tue, Jul 3, 2018 at 10:39 AM, Bryan Drewery wrote:
> On 7/2/2018 7:50 PM, Matt Macy wrote:
>> Author: mmacy
>> Date: Tue Jul 3 02:50:07 2018
>> New Revision: 335880
>> URL: https://svnweb.freebsd.org/changeset/base/
I didn't want it to be global. Note that I did _exactly_ what John told me
to. I don't believe the tone or word choice is justified.
-M
On Tue, Jul 3, 2018 at 17:32 Warner Losh wrote:
> And this is why I wanted it to conform to the current build paradigm in my
> review... I'll mop it up once Br
On Thu, Jul 5, 2018 at 8:54 AM, Konstantin Belousov wrote:
> On Thu, Jul 05, 2018 at 07:56:22AM -0700, John Baldwin wrote:
>> On 7/4/18 7:22 AM, Konstantin Belousov wrote:
>> > On Tue, Jul 03, 2018 at 11:05:42PM +, Matt Macy wrote:
>> >> Author: mmacy
>> >> Date: Tue Jul 3 23:05:42 2018
>> >>
this breaks the MIPS builds.
On Thu, Jul 5, 2018 at 9:33 AM, Brooks Davis wrote:
> On Thu, Jul 05, 2018 at 09:10:54AM -0700, Ravi Pokala wrote:
>> Hi Brooks,
>>
>> -Original Message-
>> From: on behalf of Brooks Davis
>>
>> Date: 2018-07-05, Thursday at 06:13
>> To: , ,
>>
>> Subject
On Sun, Jul 8, 2018 at 7:22 AM, Mark Johnston wrote:
> On Tue, Jul 03, 2018 at 01:55:10AM +, Matt Macy wrote:
>> Author: mmacy
>> Date: Tue Jul 3 01:55:09 2018
>> New Revision: 335879
>> URL: https://svnweb.freebsd.org/changeset/base/335879
>>
>> Log:
>> make critical_{enter, exit} inline
>
Build still works, but you're assuming that developers only use svn.
make[1]: "/usr/home/mmacy/devel/freebsd/Makefile.inc1" line 343:
SYSTEM_COMPILER: libclang will be built for bootstrapping a
cross-compiler.
make[1]: "/usr/home/mmacy/devel/freebsd/Makefile.inc1" line 348:
SYSTEM_LINKER: libclang
That would only fix it if svn weren't installed.
On Sun, Jul 22, 2018 at 9:31 AM, Colin Percival wrote:
> On 07/22/18 08:04, Rodney W. Grimes wrote:
>>> Build still works, but you're assuming that developers only use svn.
>>
>> No, he correctly assumed that RELEASE engineering only uses svn/svnli
The entries in the .json files were replicated and mapfile.csv lacked a
newline at the end of the file causing parse failures.
-M
On Mon, Aug 13, 2018 at 4:56 PM Ravi Pokala wrote:
> Hi Matt,
>
> -Original Message-
> From: on behalf of Matt Macy
>
> Date: 2018-08-13, Monday at 16:46
>
Sorry. I'll take a look.
On Fri, Aug 17, 2018 at 05:30 Andrey V. Elsukov wrote:
> On 15.08.2018 23:23, Matt Macy wrote:
> > Author: mmacy
> > Date: Wed Aug 15 20:23:08 2018
> > New Revision: 337866
> > URL: https://svnweb.freebsd.org/changeset/base/337866
> >
> > Log:
> > Fix in6_multi double
Yes. See r338162. Thanks.
-M
On Tue, Aug 21, 2018 at 2:24 PM Gleb Smirnoff wrote:
> On Wed, Aug 15, 2018 at 08:23:09PM +, Matt Macy wrote:
> M> @@ -3772,8 +3775,11 @@ if_delmulti_locked(struct ifnet *ifp, struct
> ifmultiad
> M> ll_ifma->ifma_ifp = NULL; /* XXX */
On Tue, Aug 21, 2018 at 16:52 Mark Johnston wrote:
> On Tue, Aug 21, 2018 at 04:00:10PM -0700, Matthew Macy wrote:
> > Yes. See r338162. Thanks.
>
> You missed instances of the same bug in in_mcast.c and in6_mcast.c.
Thanks
>
>
> > On Tue, Aug 21, 2018 at 2:2
>
> Could you please create a stable/11 deprecation change.
>
What does that entail other than an update to UPDATING in stable/11?
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any
Johannes - do you know off hand?
-M
On Wed, Aug 22, 2018 at 12:06 AM Andriy Gapon wrote:
> On 22/08/2018 04:50, Matt Macy wrote:
> > Author: mmacy
> > Date: Wed Aug 22 01:50:12 2018
> > New Revision: 338172
> > URL: https://svnweb.freebsd.org/changeset/base/338172
> >
> > Log:
> > Remove legac
1 - 100 of 111 matches
Mail list logo
