date:20200508

Re: "make buildworld" fails for r360785?

2020-05-08 Thread Robert Huff



Chris writes:
>  >"make buildowrld" fails with:
>  > 
>  > >  c++  -O2 -pipe -fno-common
>  > >  -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang
>  > >  -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm
>  > >  -I/usr/src/contrib/llvm-project/clang/lib/Basic
>  > >  -I/usr/src/contrib/llvm-project/clang/lib/Driver
>  > >  -I/usr/src/contrib/llvm-project/clang/include 
> -I/usr/src/lib/clang/include
>  ...
>  > >  -DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections
>  > >  -fdata-sectio
>  > ns -MD -MF.depend.Basic_SourceManager.o -MTBasic/SourceManager.o
>  > -Wno-format-zero-length -Qunused-arguments
>  > -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include  -fno-exceptions
>  > -fno-rtti -std=c++14 -stdlib=libc++ -Wno-c++11-extensions   -c
>  > /usr/src/contrib/llvm-project/clang/lib/Basic/SourceManager.cpp -o
>  > Basic/SourceManager.o
>  > >  /usr/src/contrib/llvm-project/clang/lib/Basic/SourceManager.cpp:1228:10:
>  > >  fatal error: 'emmintrin.h' file not found
>  > >  #include 
>  > >   ^
>  > >  1 error generated.
>  > >  *** Error code 1
>
>  I ran ionto this awhile back, and I think the way I was able to solve it 
> with a
>  make kernel-toolchain

I tried both "make toolchain" and "make kernel-toolchain"; both
failed with 

c++  -O2 -pipe -fno-common 
-I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang 
-I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm 
-I/usr/src/contrib/llvm-project/clang/lib/Basic 
-I/usr/src/contrib/llvm-project/clang/lib/Driver 
-I/usr/src/contrib/llvm-project/clang/include -I/usr/src/lib/clang/include 
-I/usr/src/contrib/llvm-project/llvm/include -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\" 
-DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" -DLLVM_TARGET_ENABLE_X86 
-DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser 
-DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter 
-DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler 
-DLLVM_NATIVE_TARGET=LLVMInitializeX86Target 
-DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo 
-DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections 
-fdata-sections 
 -MD -MF.depend.Basic_SanitizerSpecialCaseList.o 
-MTBasic/SanitizerSpecialCaseList.o -Wno-format-zero-length -Qunused-arguments 
-I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include  -fno-exceptions 
-fno-rtti -std=c++14 -stdlib=libc++ -Wno-c++11-extensions   -c 
/usr/src/contrib/llvm-project/clang/lib/Basic/SanitizerSpecialCaseList.cpp -o 
Basic/SanitizerSpecialCaseList.o
c++  -O2 -pipe -fno-common 
-I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang 
-I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm 
-I/usr/src/contrib/llvm-project/clang/lib/Basic 
-I/usr/src/contrib/llvm-project/clang/lib/Driver 
-I/usr/src/contrib/llvm-project/clang/include -I/usr/src/lib/clang/include 
-I/usr/src/contrib/llvm-project/llvm/include -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\" 
-DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" -DLLVM_TARGET_ENABLE_X86 
-DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser 
-DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter 
-DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler 
-DLLVM_NATIVE_TARGET=LLVMInitializeX86Target 
-DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo 
-DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections 
-fdata-sections 
 -MD -MF.depend.Basic_Sanitizers.o -MTBasic/Sanitizers.o 
-Wno-format-zero-length -Qunused-arguments 
-I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include  -fno-exceptions 
-fno-rtti -std=c++14 -stdlib=libc++ -Wno-c++11-extensions   -c 
/usr/src/contrib/llvm-project/clang/lib/Basic/Sanitizers.cpp -o 
Basic/Sanitizers.o
c++  -O2 -pipe -fno-common 
-I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang 
-I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm 
-I/usr/src/contrib/llvm-project/clang/lib/Basic 
-I/usr/src/contrib/llvm-project/clang/lib/Driver 
-I/usr/src/contrib/llvm-project/clang/include -I/usr/src/lib/clang/include 
-I/usr/src/contrib/llvm-project/llvm/include -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.0\" 
-DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" -DLLVM_TARGET_ENABLE_X86 
-DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser 
-DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter 
-DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler 
-DLLVM_NATIVE_TARGET=LLVMInitializeX86Target 
-DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo 
-D

Re: Panic in fusefs(5) on 13.0-CURRENT r359773

2020-05-08 Thread Alan Somers

On Mon, Apr 27, 2020 at 4:51 AM Konstantin Belousov 
wrote:

> On Mon, Apr 27, 2020 at 11:39:41AM +0200, Mateusz Piotrowski wrote:
> > Hi everyone!
> >
> > I'm experiencing panics every day. Apparently, they are caused by a bug
> in
> > our FUSE implementation.
> >
> > The panic occurs when I'm editing files in a folder mounted via SSHFS
> from a
> > bhyve VM running Ubuntu 18.04.
> >
> > I'm sending some parts of the core.txt file. Let me know if I can provide
> > any additional information.
> >
> > Cheers,
> >
> > Mateusz
> >
> > ---
> >
> > t480 dumped core - see /var/crash/vmcore.3
> >
> > Mon Apr 27 11:30:19 CEST 2020
> >
> > FreeBSD t480 13.0-CURRENT FreeBSD 13.0-CURRENT #4 r359773: Sat Apr 11
> > 05:32:31 CEST 2020 root@t480:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64
> >
> > panic: Assertion bp->b_flags & B_VMIO failed at
> > /usr/src/sys/fs/fuse/fuse_node.c:433
> >
> > GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD]
> > Copyright (C) 2020 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later
> > 
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.
> > Type "show copying" and "show warranty" for details.
> > This GDB was configured as "x86_64-portbld-freebsd13.0".
> > Type "show configuration" for configuration details.
> > For bug reporting instructions, please see:
> > .
> > Find the GDB manual and other documentation resources online at:
> > .
> >
> > For help, type "help".
> > Type "apropos word" to search for commands related to "word"...
> > Reading symbols from /boot/kernel/kernel...
> > Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...
> >
> > Unread portion of the kernel message buffer:
> > WARNING !drm_modeset_is_locked(&crtc->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:577
> > WARNING !drm_modeset_is_locked(&crtc->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:577
> > WARNING !drm_modeset_is_locked(&crtc->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:577
> > WARNING !drm_modeset_is_locked(&dev->mode_config.connection_mutex)
> failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:622
> > WARNING !drm_modeset_is_locked(&plane->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821
> > WARNING !drm_modeset_is_locked(&plane->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821
> > WARNING !drm_modeset_is_locked(&plane->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821
> > WARNING !drm_modeset_is_locked(&plane->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821
> > WARNING !drm_modeset_is_locked(&plane->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821
> > WARNING !drm_modeset_is_locked(&plane->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821
> > WARNING !drm_modeset_is_locked(&plane->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821
> > WARNING !drm_modeset_is_locked(&plane->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821
> > WARNING !drm_modeset_is_locked(&plane->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821
> > <4>WARN_ON(!mutex_is_locked(&dev->struct_mutex))
> >
> > <4>WARN_ON(!mutex_is_locked(&fbc->lock))
> >
> >
> <4>WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock))
> > panic: Assertion bp->b_flags & B_VMIO failed at
> > /usr/src/sys/fs/fuse/fuse_node.c:433
> > cpuid = 5
> > time = 1587979693
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> > 0xfe00cc0ef330
> > vpanic() at vpanic+0x182/frame 0xfe00cc0ef380
> > panic() at panic+0x43/frame 0xfe00cc0ef3e0
> > fuse_vnode_setsize() at fuse_vnode_setsize+0x135/frame 0xfe00cc0ef430
> > fuse_internal_cache_attrs() at fuse_internal_cache_attrs+0xc4/frame
> > 0xfe00cc0ef490
> > fuse_vnop_lookup() at fuse_vnop_lookup+0x6bf/frame 0xfe00cc0ef620
> > lookup() at lookup+0x5e1/frame 0xfe00cc0ef6c0
> > namei() at namei+0x524/frame 0xfe00cc0ef7b0
> > kern_statat() at kern_statat+0x7f/frame 0xfe00cc0ef8d0
> > sys_fstatat() at sys_fstatat+0x2f/frame 0xfe00cc0ef9d0
> > amd64_syscall() at amd64_syscall+0x140/frame 0xfe00cc0efaf0
> > fast_syscall_common() at fast_syscall_common+0x101/frame
> 0xfe00cc0efaf0
> > --- syscall (552, FreeBSD ELF64, sys_fstatat), rip =

Next-hop objects and scalable multipath routing project status update [May 8]

2020-05-08 Thread Alexander V . Chernikov

Hi,

I would like to share the current state and the next steps for the 
nhops/multipath project.

To recap: project is about modernising the current routing stack and 
implementing scalable multipath routing. 

Most changes are based on introduction of the concept of nexthops. Nexthops, 
which are separate datastructures, containing all necessary information to 
perform packet forwarding such as gateway, interface and mtu. They are shared 
among the routes, providing more pre-computed cache-efficient data while 
requiring less memory.
Interested reader can find more detailed description in 
https://reviews.freebsd.org/D24141 .

All changes[*] from the stage1 (nexthop objects introduction) has landed.
Currently the focus is on upgrading various route change notification 
mechanisms to allow transparent multipath introduction.
After that the focus will switch on landing the actual multipath implementation.

[*] D24776 is pending commit tomorrow.

More detailed plan:

1 Nexthop objects [In progress]
1.1 Introduction of nexthop objects [DONE: r359823]
1.2 Conversion of old KPI users to the new one [DONE]
1.2.1 Conversion of route caching to nexthop caching [DONE: r360292]
1.3 Conversion of struct `rtentry` field access to nhop field access [DONE]
1.4 Eliminating old lookup KPI and hiding struct rtentry. [95% complete, 
rtentry: rS360824, kpi: D24776 (pending), ]

2 Multipath [In progress]
2.1 Switch control plane customers to use (rtentry, nhop) pair instead of 
rtentry to allow multipath changes happen transparently. [10% complete]
2.2 Introduce nexthop group objects
2.3 Add mutipath support for the rib manipulation functions
2.4 Add flowid generation for outbound traffic to enable load balancing


-- 
[No timeline]

3 Rtsock/netlink nhops support
3.1 Implement index lookup for nhops/nhop groups
3.2 Design rtsock messages for nhop/nhgrp operations& prefix binding
3.3 Implement kernel part
3.4 Implement frr or bird support

4 Modular longest-prefix-match lookup algorithm
4.1 Design control plane framework for attaching algos.
4.2 Implement one (IPv6?) lookup algorithm



/Alexander

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311

2020-05-08 Thread Mark Millard

[More details for a sshd failure. The other
examples are omitted. The sshd failure also shows
a all-zeros-up-to-a-page-boundary issue, just for
a different address range.]

On 2020-May-7, at 12:06, Mark Millard  wrote:
> 
> [mountd failure example: also at sz_size2index_lookup assert
> for the same zero'd memory problem.]
> 
>> On 2020-May-7, at 00:46, Mark Millard  wrote:
>> 
>> [__je_sz_size2index_tab seems messed up in 2 of the
>> asserting contexts: first 384 are zero in both. More
>> before that is also messed up (all zero). I show the
>> details later below.]
>> 
>> On 2020-May-6, at 16:57, Mark Millard  wrote:
>> 
>>> [This explores process crashes that happen during system
>>> shutdown, in a context not having MALLOC_PRODUCTION= .
>>> So assert failures are reported as the stopping points.]
>>> 
>>> It looks like shutdown -p now, shutdown -r now, and the
>>> like can lead some processes to assert during their exit
>>> attempt, including a sshd failure (that I've not seen
>>> before), rpcbind, and nfsd. I show information about the
>>> observed asserts for those below.
>>> 
>>> 
>>> sshd hit an assert, failing slab == extent_slab_get(extent) :
>>> 
>>> (gdb) bt 
>>> #0  thr_kill () at thr_kill.S:4
>>> #1  0x50927170 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
>>> #2  0x50886cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
>>> #3  0x508834b0 in arena_dalloc (tsdn=, ptr=, 
>>> tcache=, alloc_ctx=, slow_path=>> out>)
>>>  at 
>>> /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:315
>>> #4  idalloctm (tsdn=0x500dd040, ptr=0x5008a180, tcache=0x500dd160, 
>>> alloc_ctx=, is_internal=, 
>>> slow_path=)
>>>  at 
>>> /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inlines_c.h:118
>>> #5  0x5087b0a4 in ifree (tsd=0x500dd040, ptr=0x5008a180, tcache=0x500dd160, 
>>> slow_path=) at jemalloc_jemalloc.c:2590
>>> #6  0x5087acac in __je_free_default (ptr=0x5008a180) at 
>>> jemalloc_jemalloc.c:2784
>>> #7  0x5087b294 in __free (ptr=0x5008a180) at jemalloc_jemalloc.c:2852
>>> #8  0x10029464 in server_accept_loop (config_s=, 
>>> sock_in=, sock_out=, newsock=) 
>>> at /usr/src/crypto/openssh/sshd.c:1185
>>> #9  main (ac=, av=0xde3c) at 
>>> /usr/src/crypto/openssh/sshd.c:2009
>>> 
>>> . . .
>>> (gdb) up
>>> #2  0x50886cc0 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
>>> 67  (void)raise(SIGABRT);
>>> (gdb) up
>>> #3  0x508834b0 in arena_dalloc (tsdn=, ptr=, 
>>> tcache=, alloc_ctx=, slow_path=>> out>)
>>>  at 
>>> /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:315
>>> 315 assert(slab == extent_slab_get(extent));
>>> 
>>> (gdb) list
>>> 310 rtree_ctx = tsd_rtree_ctx(tsdn_tsd(tsdn));
>>> 311 extent_t *extent = rtree_extent_read(tsdn, 
>>> &extents_rtree,
>>> 312 rtree_ctx, (uintptr_t)ptr, true);
>>> 313 assert(szind == extent_szind_get(extent));
>>> 314 assert(szind < SC_NSIZES);
>>> 315 assert(slab == extent_slab_get(extent));
>>> 316 }
>>> 317 
>>> 318 if (likely(slab)) {
>>> 319 /* Small allocation. */
>>> 
>>> More fully:
>>> 
>>> 285 JEMALLOC_ALWAYS_INLINE void
>>> 286 arena_dalloc(tsdn_t *tsdn, void *ptr, tcache_t *tcache,
>>> 287 alloc_ctx_t *alloc_ctx, bool slow_path) {
>>> 288 assert(!tsdn_null(tsdn) || tcache == NULL);
>>> 289 assert(ptr != NULL);
>>> 290 
>>> 291 if (unlikely(tcache == NULL)) {
>>> 292 arena_dalloc_no_tcache(tsdn, ptr);
>>> 293 return;
>>> 294 }
>>> 295 
>>> 296 szind_t szind;
>>> 297 bool slab;
>>> 298 rtree_ctx_t *rtree_ctx;
>>> 299 if (alloc_ctx != NULL) {
>>> 300 szind = alloc_ctx->szind;
>>> 301 slab = alloc_ctx->slab;
>>> 302 assert(szind != SC_NSIZES);
>>> 303 } else {
>>> 304 rtree_ctx = tsd_rtree_ctx(tsdn_tsd(tsdn));
>>> 305 rtree_szind_slab_read(tsdn, &extents_rtree, rtree_ctx,
>>> 306 (uintptr_t)ptr, true, &szind, &slab);
>>> 307 }
>>> 308 
>>> 309 if (config_debug) {
>>> 310 rtree_ctx = tsd_rtree_ctx(tsdn_tsd(tsdn));
>>> 311 extent_t *extent = rtree_extent_read(tsdn, 
>>> &extents_rtree,
>>> 312 rtree_ctx, (uintptr_t)ptr, true);
>>> 313 assert(szind == extent_szind_get(extent));
>>> 314 assert(szind < SC_NSIZES);
>>> 315 assert(slab == extent_slab_get(extent));
>>> 316 }
>>> 317 
>>> 318 if (likely(slab)) {
>>> 319 /* Small allocation. */
>>> 320 tcache_dalloc_small(tsdn_tsd(tsdn), tcache, ptr, szind,
>>> 321 slow_path);
>>> 322 } else {
>>> 323 arena_dalloc_large(tsdn, ptr, tcache, szind, slow_path);
>>> 324 }
>>> 325 }
>>

Re: ${COMPILER_VERSION} < 40300

2020-05-08 Thread Konstantin Belousov

On Fri, May 08, 2020 at 11:22:51AM -0700, John Baldwin wrote:
> On 5/7/20 10:17 AM, Warner Losh wrote:
> > On Thu, May 7, 2020 at 10:38 AM Eric van Gyzen  wrote:
> > 
> >> If I were to clean up obsolete ${COMPILER_VERSION} tests in the tree,
> >> which ones should I keep?  I would probably confine it to head, so I
> >> could prune quite a few.
> >>
> > 
> > Anything in the bootstrap path should remain, especially in the install
> > portion of the bootstrap path since we don't require new compilers for
> > that. I doubt there's more than one or two of these and there may be zero.
> > The rest can go away.
> > 
> > We should also look at taking out the fmake workarounds in the tree too.
> > Most of these are in src/Makefile and src/Makefile.inc.
> 
> I think Eric though was asking about  and the like.  Right now
> we still have conditional support for some really old compilers that are
> likely to never be used with FreeBSD 13 (ancient Intel icc, gcc 2.95, etc.).
> 
> Like, do we keep support for pre-ANSI C to delete 'const' etc. via
> macros?   Admittedly there isn't a tremendous amount of cruft in cdefs.h.
> What would seem more invasive would be to do things like require C99 and
> use 'restrict' directly instead of __restrict, but the first step towards
> any of that is probably to remove some of the cruft from cdefs.h and
> possibly some other places.
I think __restrict still needs to be around, due to C++ not supporting
the keyword.

Actually there is more urgent need to add some bits to cdefs.h, like
c17 and newer POSIX_C_SOURCE.

> 
> (BTW, it would be good to know if it's at all useful to keep any of the
> icc bits around.)
> 
> -- 
> John Baldwin
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ${COMPILER_VERSION} < 40300

2020-05-08 Thread Eric van Gyzen


On 5/8/20 1:22 PM, John Baldwin wrote:

I think Eric though was asking about  and the like.


Actually, I was asking about makefile conditions, but this is still a 
good discussion to have.  I'm in a cleanup mood.



(BTW, it would be good to know if it's at all useful to keep any of the
icc bits around.)


Intel made a FreeBSD version of their 2016 compiler.

https://software.intel.com/content/www/us/en/develop/articles/intel-system-studio-2016-for-freebsd.html

That uses Clang as a front-end, so maybe some of the old icc bits can 
still go away.  I still have a copy of that compiler, so I can test 
things as needed.


Eric
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ${COMPILER_VERSION} < 40300

2020-05-08 Thread John Baldwin

On 5/7/20 10:17 AM, Warner Losh wrote:
> On Thu, May 7, 2020 at 10:38 AM Eric van Gyzen  wrote:
> 
>> If I were to clean up obsolete ${COMPILER_VERSION} tests in the tree,
>> which ones should I keep?  I would probably confine it to head, so I
>> could prune quite a few.
>>
> 
> Anything in the bootstrap path should remain, especially in the install
> portion of the bootstrap path since we don't require new compilers for
> that. I doubt there's more than one or two of these and there may be zero.
> The rest can go away.
> 
> We should also look at taking out the fmake workarounds in the tree too.
> Most of these are in src/Makefile and src/Makefile.inc.

I think Eric though was asking about  and the like.  Right now
we still have conditional support for some really old compilers that are
likely to never be used with FreeBSD 13 (ancient Intel icc, gcc 2.95, etc.).

Like, do we keep support for pre-ANSI C to delete 'const' etc. via
macros?   Admittedly there isn't a tremendous amount of cruft in cdefs.h.
What would seem more invasive would be to do things like require C99 and
use 'restrict' directly instead of __restrict, but the first step towards
any of that is probably to remove some of the cruft from cdefs.h and
possibly some other places.

(BTW, it would be good to know if it's at all useful to keep any of the
icc bits around.)

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CHANGE_PV_LIST_LOCK_TO_PHYS is not correct when !NUMA ?

2020-05-08 Thread Konstantin Belousov

On Fri, May 08, 2020 at 06:53:24PM +0300, Andriy Gapon wrote:
> 
> I have a reproducible panic with a custom kernel without option NUMA while 
> using
> amdgpu driver from linuxkpi-based drm:
> 
> panic: address 41ec0 beyond the last segment
> 
> I did some quick debugging and the panic happens when Xorg server tries to
> access a frame buffer (or something like that).  There is a page fault that 
> gets
> satisfied by ttm with a fictitious page.
> 
> The stack trace is:
> #11 0x808031a3 in panic (fmt=0x8119a998 
> "5\003ʀ\377\377\377\377") at /usr/devel/git/motil/sys/kern/kern_shutdown.c:839
> #12 0x80bbc552 in pmap_enter (pmap=, va=34504441856,
> m=, prot=, flags=, 
> psind= out>) at /usr/devel/git/motil/sys/amd64/amd64/pmap.c:6035
> #13 0x80b288be in vm_fault_populate (fs=) at
> /usr/devel/git/motil/sys/vm/vm_fault.c:519
> #14 vm_fault_allocate (fs=) at
> /usr/devel/git/motil/sys/vm/vm_fault.c:1032
> #15 vm_fault (map=, vaddr=, 
> fault_type= out>, fault_flags=, m_hold=) at
> /usr/devel/git/motil/sys/vm/vm_fault.c:1342
> #16 0x80b26e7e in vm_fault_trap (map=0xfe0017cd39e8,
> vaddr=, fault_type=, fault_flags=0,
> signo=0xfe00a810dbc4, ucode=0xfe00a810dbc0) at
> /usr/devel/git/motil/sys/vm/vm_fault.c:589
> #17 0x80bcf89c in trap_pfault (frame=0xfe00a810dc00,
> usermode=, signo=, ucode=0x80853250
> ) at /usr/devel/git/motil/sys/amd64/amd64/trap.c:821
> #18 0x80bceeec in trap (frame=0xfe00a810dc00) at
> /usr/devel/git/motil/sys/amd64/amd64/trap.c:34
> 
> 
> The line number in pmap_enter() is incorrect, I guess because of 
> optimizations.
> The assert seems to be reached via pmap_enter -> CHANGE_PV_LIST_LOCK_TO_PHYS 
> ->
> PHYS_TO_PV_LIST_LOCK -> pa_index().
> 
> The panic in correct in that the page is fictitious and its physical address 
> is
> beyond the end of real physical memory.
> It seems that NUMA PHYS_TO_PV_LIST_LOCK() is aware of such pages, but !NUMA 
> one
> is not.

I think you can remove this assert.  pa_index() is always taken by
% NVP_LIST_LOCKS, because fictitious mappings are not promoted.

Try that and commit if it works for you.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

CHANGE_PV_LIST_LOCK_TO_PHYS is not correct when !NUMA ?

2020-05-08 Thread Andriy Gapon


I have a reproducible panic with a custom kernel without option NUMA while using
amdgpu driver from linuxkpi-based drm:

panic: address 41ec0 beyond the last segment

I did some quick debugging and the panic happens when Xorg server tries to
access a frame buffer (or something like that).  There is a page fault that gets
satisfied by ttm with a fictitious page.

The stack trace is:
#11 0x808031a3 in panic (fmt=0x8119a998 
"5\003ʀ\377\377\377\377") at /usr/devel/git/motil/sys/kern/kern_shutdown.c:839
#12 0x80bbc552 in pmap_enter (pmap=, va=34504441856,
m=, prot=, flags=, psind=) at /usr/devel/git/motil/sys/amd64/amd64/pmap.c:6035
#13 0x80b288be in vm_fault_populate (fs=) at
/usr/devel/git/motil/sys/vm/vm_fault.c:519
#14 vm_fault_allocate (fs=) at
/usr/devel/git/motil/sys/vm/vm_fault.c:1032
#15 vm_fault (map=, vaddr=, fault_type=, fault_flags=, m_hold=) at
/usr/devel/git/motil/sys/vm/vm_fault.c:1342
#16 0x80b26e7e in vm_fault_trap (map=0xfe0017cd39e8,
vaddr=, fault_type=, fault_flags=0,
signo=0xfe00a810dbc4, ucode=0xfe00a810dbc0) at
/usr/devel/git/motil/sys/vm/vm_fault.c:589
#17 0x80bcf89c in trap_pfault (frame=0xfe00a810dc00,
usermode=, signo=, ucode=0x80853250
) at /usr/devel/git/motil/sys/amd64/amd64/trap.c:821
#18 0x80bceeec in trap (frame=0xfe00a810dc00) at
/usr/devel/git/motil/sys/amd64/amd64/trap.c:34


The line number in pmap_enter() is incorrect, I guess because of optimizations.
The assert seems to be reached via pmap_enter -> CHANGE_PV_LIST_LOCK_TO_PHYS ->
PHYS_TO_PV_LIST_LOCK -> pa_index().

The panic in correct in that the page is fictitious and its physical address is
beyond the end of real physical memory.
It seems that NUMA PHYS_TO_PV_LIST_LOCK() is aware of such pages, but !NUMA one
is not.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: "make buildworld" fails for r360785?

Re: Panic in fusefs(5) on 13.0-CURRENT r359773

Next-hop objects and scalable multipath routing project status update [May 8]

Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311

Re: ${COMPILER_VERSION} < 40300

Re: ${COMPILER_VERSION} < 40300

Re: ${COMPILER_VERSION} < 40300

Re: CHANGE_PV_LIST_LOCK_TO_PHYS is not correct when !NUMA ?

CHANGE_PV_LIST_LOCK_TO_PHYS is not correct when !NUMA ?

9 matches

Site Navigation

Mail list logo

Footer information