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
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
> >
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
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
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
This represents a misunderstanding of how defines are used. This left
the option open to the user to enable the use of larger than page size
buffers as it does enable better performance. Over the course of a
long uptime memory can get too fragmented. However, this left it open
to the end consumer.
World? It looks like there's a version mismatch between the kernel and modules.
-M
On Thu, Feb 28, 2019 at 7:11 PM Alan Somers wrote:
>
> On Thu, Feb 28, 2019 at 6:40 PM Matthew Macy wrote:
> >
> > to config add:
> > options LINDEBUGFS
> > options G
to config add:
options LINDEBUGFS
options GCOV
compile kernel with gcc (otherwise it will be a no-op)
sysctl debug.gcov.enable=1
mount -t debugfs debugfs /sys/kernel/debug
(or wherever) and the output artifacts will appear under gcov/ - you need to be root to see the artifacts
gcov can then ge
On Tue, Feb 26, 2019 at 09:20 Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:
> > This has zero impact on the licensing disposition of the kernel as
> > distributed as it is only used for test kernels. Tests compiled with
> > coverage instrumentation run much slower than even debug, one
This has zero impact on the licensing disposition of the kernel as
distributed as it is only used for test kernels. Tests compiled with
coverage instrumentation run much slower than even debug, one would never
ship this.
You are very much in the minority being more concerned with ideological
purit
>
>
> > PowerPC barrier instructions are needed to prevent reordering.
> >
> > Correct. The current lkpi implementation also assumes that device
> > endian == host endian. The Linux generic accessors will do use endian
> > macros to byte swap where necessary.
>
> Yes, these functions are used to ac
Correct. This is just the generic case. We just need to define the __io
macros as __compiler_membar in x86/io.h
Cheers.
-M
On Sun, Nov 18, 2018 at 13:08 Tijl Coosemans wrote:
> On Sun, 18 Nov 2018 12:10:25 -0800 Matthew Macy
> wrote:
> >> Note that these functions are n
> Note that these functions are normally used on uncacheable memory which
> is strongly ordered on x86. There should be no reordering at all. On
> PowerPC barrier instructions are needed to prevent reordering.
Correct. The current lkpi implementation also assumes that device
endian == host endia
ov 17, 2018 at 2:01 PM Matthew Macy wrote:
>
> You should probably revert this. The implied understanding of the _relaxed
> version is incorrect. compiler_membar is there to prevent instruction
> reordering which is possible on FreeBSD because the accesses are done in C.
> The relax
You should probably revert this. The implied understanding of the _relaxed
version is incorrect. compiler_membar is there to prevent instruction
reordering which is possible on FreeBSD because the accesses are done in C.
The relaxed variants still do not permit instruction reordering. On Linux
__co
Rodney - we appreciate your emotional investment in the project. And as
convenient as it would be for me to take all the blame the imminent removal
of drm2 was communicated on public lists. Your soul contribution to the
discussion was to bemoan the fact that i386 would no longer have special
advant
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
>
> Could you please create a stable/11 deprecation change.
>
What does that entail other than an update to UPDATING in stable/11?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any ma
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
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 */
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
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
>
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
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
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
>
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 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
>> >>
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
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/
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
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
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:
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
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
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
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:
>
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 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
> 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 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 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
>
> 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
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
>>>
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
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
-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
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
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
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
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 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
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
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
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
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
>
> 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: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:
>> >>
>
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:
>> >>
>
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
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:
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
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 "
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: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
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
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 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
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
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
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-all@fre
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
>>
>
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 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
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
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
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)
>>
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
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
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
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 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-all@freeb
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:
>
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
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
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
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
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
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
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
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,
>&
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
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
> - 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
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
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
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
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
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
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
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
1 - 100 of 109 matches
Mail list logo
