Re: panic shortly after boot when amdgpu.ko is loaded (fpu?)

2020-11-27 Thread Konstantin Belousov
On Thu, Nov 26, 2020 at 10:09:24PM -0700, Rebecca Cran wrote: > I have a Threadripper 2990WX system that I recently installed an AMD Radeon > Pro W5700 into. It runs fine unless I load the amdgpu driver, at which point > it panics several seconds after boot: I have enough time to login and run a >

Re: Samba kernel panics.

2020-11-17 Thread Konstantin Belousov
On Tue, Nov 17, 2020 at 06:20:31PM +0100, Johan Hendriks wrote: > Hello all after updating FreeBSD13 from r367724 to r367755 my samba server > craches the server. > I did rebuild samba 4.11 but that does not help. > > The output on the console is the following. > > Fatal trap 12: page fault

Re: buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71

2020-11-16 Thread Konstantin Belousov
On Mon, Nov 16, 2020 at 10:56:06AM +, Graham Perrin wrote: > On 16/11/2020 09:32, Benjamin Kaduk wrote: > > On Mon, Nov 16, 2020 at 09:27:29AM +, Graham Perrin wrote: > > > Attempting to build r367615 on Friday 13th: > > > > > > … > > > > > > ===> lib/libprocstat/zfs (install) > > >

Re: Possible deadlock on IO / page fault

2020-09-29 Thread Konstantin Belousov
On Tue, Sep 29, 2020 at 02:59:43PM +0300, Michael Zhilin wrote: > Hi, > > I'm using FreeBSD 13-CURRENT (pre-ZoF, r359724) on my laptop with installed > Gnome. Sometimes > (once a week/month) gnome hangs and the system may be still responsible > (may be not). > This week it happened again and I've

Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

2020-09-21 Thread Konstantin Belousov
On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote: > Fatal trap 12: page fault while in kernel mode > cpuid = 31; apic id = 1f > fault virtual address = 0x25407efa This address is very suspicious. I cannot claim it as the fact, but most likely cause for such garbage pointer value

Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

2020-09-20 Thread Konstantin Belousov
On Sun, Sep 20, 2020 at 10:55:26PM +0300, Konstantin Belousov wrote: > On Sun, Sep 20, 2020 at 03:11:26PM +0200, Rainer Hurling wrote: > > Am 20.09.20 um 11:38 schrieb Konstantin Belousov: > > > On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote: > > >>

Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

2020-09-20 Thread Konstantin Belousov
On Sun, Sep 20, 2020 at 03:11:26PM +0200, Rainer Hurling wrote: > Am 20.09.20 um 11:38 schrieb Konstantin Belousov: > > On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote: > >> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky: > >>> On 2020-09-20 10:05, R

Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

2020-09-20 Thread Konstantin Belousov
On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote: > Am 20.09.20 um 10:20 schrieb Hans Petter Selasky: > > On 2020-09-20 10:05, Rainer Hurling wrote: > >> Hi monochrome, > >> > >> back to keyboard, it tried newest CURRENT (r365920) on my box and even > >> with newest sources the error

Re: Last ZFS upgrade (r365347) breaks booting

2020-09-08 Thread Konstantin Belousov
On Tue, Sep 08, 2020 at 09:39:18PM +0200, Piotr Kubaj via freebsd-ppc wrote: > I'm currently on r365449 on powerpc64. I use ZFS on / with zfs.ko compiled in > kernel (because there's no loader on PowerNV systems). > > There seems to be a regression that happened recently, probably in r365347

Process group orphaning fixes

2020-08-18 Thread Konstantin Belousov
I fixed several issues in our handling of the process group job control state, biggest of which was uncovered by the reaping facility. The bugs demostrate itself and underflow (and probably overflow) of pgrp->pg_jobc, that was reported as panics with added and then removed asserts. Feel free to

Re: can buffer cache pages be used in ext_pgs mbufs?

2020-08-11 Thread Konstantin Belousov
On Tue, Aug 11, 2020 at 03:10:39AM +, Rick Macklem wrote: > Konstantin Belousov wrote: > >On Mon, Aug 10, 2020 at 12:46:00AM +, Rick Macklem wrote: > >> Konstantin Belousov wrote: > >> >On Fri, Aug 07, 2020 at 09:43:14PM -0700, Kirk McKusick wrote: > >&

Re: [CFT] Updated devel/valgrind-devel port

2020-07-28 Thread Konstantin Belousov
On Mon, Jul 27, 2020 at 09:49:57PM -0500, Kyle Evans wrote: > On Fri, Jul 24, 2020 at 3:24 PM Kyle Evans wrote: > > > > Hello! > > > > Just a little bit ago, I committed an update[0] to the valgrind-devel > > port that updates it to Paul Floyd's branch, where he has rebased us > > forward to

Re: Building modules gives error: "invalid output constraint '=@cce' in asm"

2020-06-16 Thread Konstantin Belousov
On Tue, Jun 16, 2020 at 12:29:14PM +0530, Rajesh Kumar wrote: > Hi, > > I am trying to build my module with freebsd current branch. But I am > facing compilation issue with header files as below. I have built and > installed the freebsd current branch and booted to that kernel before > building

Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045

2020-06-11 Thread Konstantin Belousov
On Thu, Jun 11, 2020 at 09:33:31AM -0700, David Wolfskill wrote: > On Thu, Jun 11, 2020 at 12:24:17PM -0400, Mark Johnston wrote: > > ... > > > Unfortunately, I ran out of time to do further experiments for now; I'll > > > need to do some work-related things for a while, but thought that this > >

Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045

2020-06-11 Thread Konstantin Belousov
On Thu, Jun 11, 2020 at 12:24:17PM -0400, Mark Johnston wrote: > On Thu, Jun 11, 2020 at 09:11:56AM -0700, David Wolfskill wrote: > > On Thu, Jun 11, 2020 at 06:51:43PM +0300, Konstantin Belousov wrote: > > > ... > > > Can you boot into single-user, without loadin

Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045

2020-06-11 Thread Konstantin Belousov
On Thu, Jun 11, 2020 at 08:44:56AM -0700, David Wolfskill wrote: > On Thu, Jun 11, 2020 at 04:46:58PM +0300, Konstantin Belousov wrote: > > ... > > > I have not used -DNO_CLEAN in years -- I do use META_MODE, though. I > > > can certainly clean out /usr/obj/* & s

Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045

2020-06-11 Thread Konstantin Belousov
On Thu, Jun 11, 2020 at 06:29:24AM -0700, David Wolfskill wrote: > On Thu, Jun 11, 2020 at 04:21:29PM +0300, Konstantin Belousov wrote: > > ... > > The link times out. > > Sigh. Sorry about that; I have copied the images to > freefall:~dhw/head/r362045/ . > >

Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045

2020-06-11 Thread Konstantin Belousov
On Thu, Jun 11, 2020 at 06:05:00AM -0700, David Wolfskill wrote: > Build machine (mini-tower) performed the update (r362008 -> r362045) > without issue, but my laptop panicked quite early on -- before the dump > device was configured. > > I have taken and placed a couple of screen shots in >

Re: acpi timer reads all ones [Was: efirtc + atrtc at the same time]

2020-05-26 Thread Konstantin Belousov
On Tue, May 26, 2020 at 06:22:13PM +0300, Andriy Gapon wrote: > On 25/05/2020 11:37, Andriy Gapon wrote: > > Also, there is another issue related to atrtc. > > When I have both drivers attached, and also when I have only atrtc attached > > (efi.rt.disabled=1), system clock jumps 10 minutes forward

Re: r358252 causes intermittent hangs where processes are stuck sleeping on btalloc

2020-05-23 Thread Konstantin Belousov
On Fri, May 22, 2020 at 11:46:26PM +, Rick Macklem wrote: > Konstantin Belousov wrote: > >On Wed, May 20, 2020 at 11:58:50PM -0700, Ryan Libby wrote: > >> On Wed, May 20, 2020 at 6:04 PM Rick Macklem wrote: > >> > > >> > Hi, > >> > >

Re: r358252 causes intermittent hangs where processes are stuck sleeping on btalloc

2020-05-21 Thread Konstantin Belousov
On Wed, May 20, 2020 at 11:58:50PM -0700, Ryan Libby wrote: > On Wed, May 20, 2020 at 6:04 PM Rick Macklem wrote: > > > > Hi, > > > > Since I hadn't upgraded a kernel through the winter, it took me a while > > to bisect this, but r358252 seems to be the culprit. > > > > If I do a kernel build

Re: CHANGE_PV_LIST_LOCK_TO_PHYS is not correct when !NUMA ?

2020-05-10 Thread Konstantin Belousov
On Sun, May 10, 2020 at 01:02:45PM +0300, Andriy Gapon wrote: > On 09/05/2020 19:50, Konstantin Belousov wrote: > > On Sat, May 09, 2020 at 07:16:27PM +0300, Andriy Gapon wrote: > >> On 09/05/2020 19:13, Konstantin Belousov wrote: > >>> On Sat, May 09, 2020 at 06:52:

Re: CHANGE_PV_LIST_LOCK_TO_PHYS is not correct when !NUMA ?

2020-05-09 Thread Konstantin Belousov
On Sun, May 10, 2020 at 12:02:19AM +0300, Andriy Gapon wrote: > On 09/05/2020 23:47, Konstantin Belousov wrote: > > Might be not, might be it would help due to pmap_delayed_invl_genp(). > > But I would more worry about this 'already started' issue, because > > this must not ha

Re: CHANGE_PV_LIST_LOCK_TO_PHYS is not correct when !NUMA ?

2020-05-09 Thread Konstantin Belousov
On Sat, May 09, 2020 at 11:33:40PM +0300, Andriy Gapon wrote: > On 09/05/2020 19:50, Konstantin Belousov wrote: > > On Sat, May 09, 2020 at 07:16:27PM +0300, Andriy Gapon wrote: > >> On 09/05/2020 19:13, Konstantin Belousov wrote: > >>> On Sat, May 09, 2020 at 06:52:

Re: CHANGE_PV_LIST_LOCK_TO_PHYS is not correct when !NUMA ?

2020-05-09 Thread Konstantin Belousov
On Sat, May 09, 2020 at 07:16:27PM +0300, Andriy Gapon wrote: > On 09/05/2020 19:13, Konstantin Belousov wrote: > > On Sat, May 09, 2020 at 06:52:24PM +0300, Andriy Gapon wrote: > >> On 08/05/2020 19:15, Konstantin Belousov wrote: > >>> On Fri, May 08, 2020 at 06:53:

Re: CHANGE_PV_LIST_LOCK_TO_PHYS is not correct when !NUMA ?

2020-05-09 Thread Konstantin Belousov
On Sat, May 09, 2020 at 06:52:24PM +0300, Andriy Gapon wrote: > On 08/05/2020 19:15, Konstantin Belousov wrote: > > 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 > &g

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

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

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

2020-04-27 Thread Konstantin Belousov
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

Re: nfslockd kernel module fails to load

2020-04-23 Thread Konstantin Belousov
On Thu, Apr 23, 2020 at 11:53:30AM +0200, Alexander Leidinger wrote: > Quoting Konstantin Belousov (from Thu, 23 Apr 2020 > 12:22:48 +0300): > > > On Thu, Apr 23, 2020 at 09:46:02AM +0200, Alexander Leidinger wrote: > > > > > > Quoting Konstantin Belousov (fro

Re: nfslockd kernel module fails to load

2020-04-23 Thread Konstantin Belousov
On Thu, Apr 23, 2020 at 09:46:02AM +0200, Alexander Leidinger wrote: > > Quoting Konstantin Belousov (from Thu, 23 Apr 2020 > 10:04:12 +0300): > > > On Thu, Apr 23, 2020 at 08:30:08AM +0200, Alexander Leidinger wrote: > > > Quoting Konstantin Belousov (from Thu,

Re: nfslockd kernel module fails to load

2020-04-23 Thread Konstantin Belousov
On Thu, Apr 23, 2020 at 08:30:08AM +0200, Alexander Leidinger wrote: > Quoting Konstantin Belousov (from Thu, 23 Apr 2020 > 09:19:08 +0300): > > > On Thu, Apr 23, 2020 at 08:08:09AM +0200, Alexander Leidinger wrote: > > > Hi, > > > > > &g

Re: nfslockd kernel module fails to load

2020-04-23 Thread Konstantin Belousov
On Thu, Apr 23, 2020 at 08:08:09AM +0200, Alexander Leidinger wrote: > Hi, > > link_elf_obj: symbol xdr_free undefined > linker_load_file: /boot/kernel/nfslockd.ko - unsupported file type > KLD nfsd.ko: depends on nfslockd - not available or version mismatch > linker_load_file:

Re: PAE on i386

2020-04-20 Thread Konstantin Belousov
rds, > Hiro > > On Sun, 20 Jan 2019 13:18:54 +0200 > Konstantin Belousov wrote: > > > Hello, > > at https://reviews.freebsd.org/D18894 I put a review which main goal is > > to allow i386 kernels to use NX bits on capable hardware. In essence, > > si

Re: When will the FreeBSD (u)EFI work?

2020-03-30 Thread Konstantin Belousov
On Sun, Mar 29, 2020 at 08:11:16PM -0700, Nathan Whitehorn wrote: > > > On 2020-03-29 20:02, Simon J. Gerraty wrote: > > Nathan Whitehorn wrote: > >> It's basically this that has been the problem: we need a way to manage > >> updates of the EFI loader in this situation, which we don't currently

Re: Any a.out users?

2020-03-13 Thread Konstantin Belousov
On Fri, Mar 13, 2020 at 01:04:42PM -0400, Ed Maste wrote: > While looking at other things we came across ldconfig's a.out support, > which hasn't been used by anything in the FreeBSD base system in ~2 > decades. > > I know there are (or at least recently were) folks using a.out > binaries on

Re: System clock is slow

2020-03-10 Thread Konstantin Belousov
On Tue, Mar 10, 2020 at 12:24:24PM -0400, Theron wrote: > On 2020-03-10 01:38, Peter Jeremy wrote: > > Are you running NTP? If so, is NTP maintaining lock and what is the > > reported PLL frequency (ntpq -c kerni)? > > Didn't show any useful difference, "kernel status: pll unsync" when I tested

Re: option KDTRACE_HOOKS non-optional after r357912?

2020-02-15 Thread Konstantin Belousov
On Sat, Feb 15, 2020 at 03:58:06PM +0100, Stefan Eßer wrote: > Am 15.02.20 um 15:40 schrieb Stefan Eßer: > > Am 15.02.20 um 14:47 schrieb Mateusz Guzik: > >> On 2/15/20, Stefan Eßer wrote: > >>> Hi Mateusz, > >>> > >>> your optimization of systrace checks has made KDTRACE_HOOKS mandatory, > >>>

Re: easy way to work around a lack of a direct map on i386

2020-02-01 Thread Konstantin Belousov
On Sat, Feb 01, 2020 at 01:56:59PM +0100, Hans Petter Selasky wrote: > On 2020-01-31 13:31, Konstantin Belousov wrote: > > On Fri, Jan 31, 2020 at 10:13:58AM +0100, Hans Petter Selasky wrote: > > > On 2020-01-31 00:37, Konstantin Belousov wrote: > > > > On Thu, Ja

Re: easy way to work around a lack of a direct map on i386

2020-01-31 Thread Konstantin Belousov
On Fri, Jan 31, 2020 at 10:13:58AM +0100, Hans Petter Selasky wrote: > On 2020-01-31 00:37, Konstantin Belousov wrote: > > On Thu, Jan 30, 2020 at 11:23:02PM +, Rick Macklem wrote: > > > Hi, > > > > > > The current code for KERN_TLS uses PHYS_TO_DMAP() >

Re: easy way to work around a lack of a direct map on i386

2020-01-30 Thread Konstantin Belousov
On Thu, Jan 30, 2020 at 11:23:02PM +, Rick Macklem wrote: > Hi, > > The current code for KERN_TLS uses PHYS_TO_DMAP() > to access unmapped external pages on m_ext.ext_pgs > mbufs. > I also need to do this to implement RPC-over-TLS. > > The problem is that some arches, like i386, don't >

Fast sigblock

2020-01-13 Thread Konstantin Belousov
https://reviews.freebsd.org/D12773 I intend to commit this in approximately week timeline. The overview of the feature is provided in the review summary above. Short story is, userspace can mask all maskable asynchronous signals with a single memory write, which allows to greatly speed up rtld

Re: AT_EXECPATH aux_info vector contains path of interpreter when directly exec'ing rtld

2019-12-20 Thread Konstantin Belousov
On Fri, Dec 20, 2019 at 04:26:41PM -0500, Ryan Stone wrote: > I've noticed that on head, if I directly execute rtld to run an > executable, AT_EXECPATH contains the path to rtld on head (on > 12.0-RELEASE it will contain nothing). This is causing me a problem > because clang uses AT_EXECPATH to

Re: New external GCC toolchain ports/packages

2019-12-20 Thread Konstantin Belousov
On Fri, Dec 20, 2019 at 09:51:15AM -0800, Ryan Libby wrote: > On Fri, Dec 20, 2019 at 9:31 AM Konstantin Belousov > wrote: > > > > On Fri, Dec 20, 2019 at 09:24:00AM -0800, John Baldwin wrote: > > > On 12/19/19 12:06 PM, Ryan Libby wrote: > > > > On We

Re: New external GCC toolchain ports/packages

2019-12-20 Thread Konstantin Belousov
On Fri, Dec 20, 2019 at 09:24:00AM -0800, John Baldwin wrote: > On 12/19/19 12:06 PM, Ryan Libby wrote: > > On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote: > >> > >> In the interest of supporting newer versions of GCC for a base system > >> toolchain, I've renamed the external GCC packages

Re: ffs_fhtovp: inode overflow?

2019-12-11 Thread Konstantin Belousov
On Wed, Dec 11, 2019 at 10:26:41AM -0600, Eric van Gyzen wrote: > Since ino64 went in, Coverity complains that the two "ino >= foo" > comparisons in ffs_fhtovp() compare a 64-bit value to a 32-bit. Is this > a problem in practice? I do not think that this a problem, and Coverity could be a bit

Re: any scheduler/ipi/wakeup bug fixed in the last year?

2019-12-11 Thread Konstantin Belousov
On Wed, Dec 11, 2019 at 12:48:36PM +0200, Andriy Gapon wrote: > > I am investigating a problem that originally looked like a ZFS I/O hang. > But it quickly became obvious that the GEOM "up" queue was not being > processed. > (kgdb) p g_bio_run_up > $54 = {bio_queue = {tqh_first =

How to regenerate syscall tables ?

2019-12-01 Thread Konstantin Belousov
I am on today stable/12 with src of today HEAD. Trying to add a new syscall, and then regenerating the files, I did 'make buildworld', then orion% make sysent ~/build/bsd/DEV/src make -C /usr/home/kostik/work/build/bsd/DEV/src/sys/kern sysent flua

Re: unkillable process consuming 100% cpu

2019-11-11 Thread Konstantin Belousov
On Mon, Nov 11, 2019 at 01:22:09PM +0100, Hans Petter Selasky wrote: > On 2019-11-11 11:44, Hans Petter Selasky wrote: > > Seems like we can optimise away one more write memory barrier. > > > > If you are building from ports, simply: > > > > cd work/kms-drm* > > cat seqlock.diff | patch -p1 > >

Re: thread on sleepqueue does not wake up after timeout

2019-10-22 Thread Konstantin Belousov
On Tue, Oct 22, 2019 at 02:48:56PM +0300, Andriy Gapon wrote: > On 22/10/2019 13:44, Konstantin Belousov wrote: > > On Tue, Oct 22, 2019 at 01:08:59PM +0300, Andriy Gapon wrote: > >> > >> We observe a problem that happens very rarely (about once a month across &

Re: thread on sleepqueue does not wake up after timeout

2019-10-22 Thread Konstantin Belousov
On Tue, Oct 22, 2019 at 01:08:59PM +0300, Andriy Gapon wrote: > > We observe a problem that happens very rarely (about once a month across many > test machines). The problem is that a thread remain in sleepq_timedwait() > even > after its timeout expires. The thread's td_slpcallout looks like

Re: panic: Unregistered use of FPU in kernel

2019-09-26 Thread Konstantin Belousov
On Thu, Sep 26, 2019 at 02:12:21PM -0600, Alan Somers wrote: > On Thu, Sep 26, 2019 at 11:29 AM Konstantin Belousov > wrote: > > > On Thu, Sep 26, 2019 at 11:20:51AM -0600, Alan Somers wrote: > > > On Thu, Sep 26, 2019 at 11:02 AM Konstantin Belousov < > >

Re: panic: Unregistered use of FPU in kernel

2019-09-26 Thread Konstantin Belousov
On Thu, Sep 26, 2019 at 11:20:51AM -0600, Alan Somers wrote: > On Thu, Sep 26, 2019 at 11:02 AM Konstantin Belousov > wrote: > > > On Thu, Sep 26, 2019 at 09:45:43AM -0600, Alan Somers wrote: > > > The latest VM snapshot > > (FreeBSD-13.0-CURRENT-amd64-20190920-r3

Re: panic: Unregistered use of FPU in kernel

2019-09-26 Thread Konstantin Belousov
On Thu, Sep 26, 2019 at 09:45:43AM -0600, Alan Somers wrote: > The latest VM snapshot (FreeBSD-13.0-CURRENT-amd64-20190920-r352544.qcow2) > instapanics on boot: > > panic: Unregistered use of FPU in kernel > > stack trace: > ... > sse42_crc32c > readsuper > ffs_sbget > g_label_ufs_taste_common >

Re: Direct exec of /usr/bin/ld fails with "mmap of entire address space failed: Cannot allocate memory"

2019-09-21 Thread Konstantin Belousov
On Sat, Sep 21, 2019 at 12:19:19PM -0400, Ryan Stone wrote: > If I try direct exec ld via rtld, I get the following failure: > > # /libexec/ld-elf.so.1 /usr/bin/ld > ld-elf.so.1: /usr/bin/ld: mmap of entire address space failed: Cannot > allocate memory > > Is there some sysctl limit I need to

Re: panic: sleeping thread on r352386

2019-09-17 Thread Konstantin Belousov
On Tue, Sep 17, 2019 at 08:18:26PM +1000, Peter Jeremy wrote: > On 2019-Sep-17 11:06:58 +0300, Konstantin Belousov > wrote: > >Try the following change, which more accurately tries to avoid > >vnode_pager_setsize(). The real cause requires much more extensive > >changes.

Re: panic: sleeping thread on r352386

2019-09-17 Thread Konstantin Belousov
On Tue, Sep 17, 2019 at 02:42:51PM +0900, Masachika ISHIZUKA wrote: > >> This panic happens on 1300047 (both r352239 and r352386) with core > >> i5-7500 as follows. This panic dose not happen on r351728 (1300044). > >> (The following lines were typed by hand so they might have some miss > >>

Re: "Sleeping with non-sleepable lock" in NFS on recent -current

2019-09-16 Thread Konstantin Belousov
On Mon, Sep 16, 2019 at 05:44:28PM +1000, Peter Jeremy wrote: > On 2019-Sep-16 09:32:52 +0300, Konstantin Belousov > wrote: > >On Mon, Sep 16, 2019 at 04:12:05PM +1000, Peter Jeremy wrote: > >> I'm consistently seeing panics in the NFS code on recent -current on > &g

Re: "Sleeping with non-sleepable lock" in NFS on recent -current

2019-09-16 Thread Konstantin Belousov
On Mon, Sep 16, 2019 at 04:12:05PM +1000, Peter Jeremy wrote: > I'm consistently seeing panics in the NFS code on recent -current on aarm64. > The panics are one of the following two: > Sleeping on "vmopar" with the following non-sleepable locks held: > exclusive sleep mutex NEWNFSnode lock

Re: spurious out of swap kills

2019-09-15 Thread Konstantin Belousov
On Sat, Sep 14, 2019 at 06:17:25PM -0700, Don Lewis wrote: > On 13 Sep, Konstantin Belousov wrote: > > On Thu, Sep 12, 2019 at 05:42:00PM -0700, Don Lewis wrote: > >> On 12 Sep, Mark Johnston wrote: > >> > On Thu, Sep 12, 2019 at 04:00:17PM -0700, Don Lewis wrote

Re: spurious out of swap kills

2019-09-12 Thread Konstantin Belousov
On Thu, Sep 12, 2019 at 05:42:00PM -0700, Don Lewis wrote: > On 12 Sep, Mark Johnston wrote: > > On Thu, Sep 12, 2019 at 04:00:17PM -0700, Don Lewis wrote: > >> My poudriere machine is running 13.0-CURRENT and gets updated to the > >> latest version of -CURRENT periodically. At least in the last

Re: ntpd segfaults on start

2019-09-10 Thread Konstantin Belousov
On Mon, Sep 09, 2019 at 03:42:43PM -0600, Warner Losh wrote: > On Mon, Sep 9, 2019 at 3:12 PM Ian Lepore wrote: > > > On Mon, 2019-09-09 at 21:44 +0300, Konstantin Belousov wrote: > > > On Mon, Sep 09, 2019 at 12:13:24PM -0600, Ian Lepore wrote: > > > > On Mon,

Re: TSC-low clock slow on WhiskeyLake i7-8565U (HP Spectre x360 13-ap0043dx)

2019-09-09 Thread Konstantin Belousov
On Mon, Sep 09, 2019 at 04:07:39PM -0400, Neel Chauhan wrote: > Hi, > > I recently got a HP Spectre x360 13-ap0043dx as a gift and by default > the clock runs slower on FreeBSD than Windows or Linux. Yes, I know the > ThinkPad is the best laptop for FreeBSD, but getting an X1 Carbon would >

Re: ntpd segfaults on start

2019-09-09 Thread Konstantin Belousov
On Mon, Sep 09, 2019 at 12:13:24PM -0600, Ian Lepore wrote: > On Mon, 2019-09-09 at 09:30 -0700, Rodney W. Grimes wrote: > > > On Sat, 2019-09-07 at 09:28 -0700, Cy Schubert wrote: > > > > In message <20190907161749.gj2...@kib.kiev.ua>, Konstantin > > > >

Re: ntpd segfaults on start

2019-09-07 Thread Konstantin Belousov
On Sat, Sep 07, 2019 at 08:45:21AM -0700, Cy Schubert wrote: > I've been able to set the memlock rlimit as low as 20 MB. The issue is > letting it default to 0 which allows ntp to mlockall() anything it wants. > ntpd on my sandbox is currently using 18 MB. Default stack size on amd64 is 512M,

Re: ntpd segfaults on start

2019-09-07 Thread Konstantin Belousov
On Sat, Sep 07, 2019 at 06:09:16AM -0700, Cy Schubert wrote: > In message <20190907075619.gg2...@kib.kiev.ua>, Konstantin Belousov writes: > > On Sat, Sep 07, 2019 at 12:53:19AM -0700, Harlan Stenn wrote: > > > Cy, > > > > > &

Re: panic: VOP_UNSET_TEXT returned 22: on r351627

2019-09-07 Thread Konstantin Belousov
On Sat, Sep 07, 2019 at 08:49:10AM -0500, Larry Rosenman wrote: > I got the following panic this AM during a poudriere run. > > r351627 is the revision I'm at. > > Core *IS* available. > > Ideas? It highly suspect that is should be fixed by https://reviews.freebsd.org/D21560. Slightly amused

Re: ntpd segfaults on start

2019-09-07 Thread Konstantin Belousov
On Sat, Sep 07, 2019 at 12:53:19AM -0700, Harlan Stenn wrote: > Cy, > > On 9/6/2019 4:56 PM, Cy Schubert wrote: > > ... > > > > For those who enable ASLR, a better workaround is, to add this to your > > ntp.conf: > > > > rlimit memlock 64 > > > > Until a more precise default is determined. >

Re: ntpd segfaults on start

2019-09-05 Thread Konstantin Belousov
On Thu, Sep 05, 2019 at 06:07:22AM -0700, Cy Schubert wrote: > In message <20190905063354.qxecqjkafikdtdyq@vzakharov>, Vladimir Zakharov > write > s: > > > > --ply3axd74k44nuk3 > > Content-Type: text/plain; charset=utf-8 > > Content-Disposition: inline > > Content-Transfer-Encoding:

Re: Host machines reboots when running bhyve VM

2019-08-28 Thread Konstantin Belousov
On Wed, Aug 28, 2019 at 01:29:24PM -0600, Rebecca Cran wrote: > I recently upgraded to r351575 and now when I run a Bhyve VM, the host > machine instantly reboots. The command-line I'm running is: > > > bhyve -c 2 -m 8G -w -H -s 0,hostbridge -s >

Re: Kernel-Crash when working with ubt0

2019-08-27 Thread Konstantin Belousov
On Tue, Aug 27, 2019 at 06:03:46AM -0700, Maksim Yevmenkin wrote: > > > Hmm... interesting > > > > > > I only took a brief look at it. I suppose I can ensure user space address > > > is wired and then copyout() can be called with mutex held > > > > >No, you cannot do this, at least without

Re: Kernel-Crash when working with ubt0

2019-08-27 Thread Konstantin Belousov
On Mon, Aug 26, 2019 at 02:35:25PM -0700, maksim yevmenkin wrote: > > > > On Aug 26, 2019, at 9:14 AM, Warner Losh wrote: > > > > Is it from read_connection_list? If so I have a 'patch' that I'm using but > > haven't committed because it's just too gross: drop the lock before the > > copyout

Re: Panic on boot with r351461 (AMD ThreadRipper 2990WX)

2019-08-25 Thread Konstantin Belousov
On Sun, Aug 25, 2019 at 07:17:20AM -0600, Rebecca Cran wrote: > On 2019-08-25 00:24, Konstantin Belousov wrote: > > What are the panic messages ? > > Fatal trap 18: integer divide fault while in kernel mode > > instruction pointer = 0x20:0x80f1027c >

Re: Panic on boot with r351461 (AMD ThreadRipper 2990WX)

2019-08-25 Thread Konstantin Belousov
On Sat, Aug 24, 2019 at 05:29:23PM -0600, Rebecca Cran wrote: > On 2019-08-24 17:08, Konstantin Belousov wrote: > > > > Use gdb instead. > > Ah, thanks. > > (gdb) info line *0x8117f67c > Line 405 of "/usr/src/sys/amd64/amd64/mp_machdep.c" starts a

Re: Panic on boot with r351461 (AMD ThreadRipper 2990WX)

2019-08-24 Thread Konstantin Belousov
On Sat, Aug 24, 2019 at 04:54:26PM -0600, Rebecca Cran wrote: > On 2019-08-24 14:33, Konstantin Belousov wrote: > > On Sat, Aug 24, 2019 at 02:22:18PM -0600, Rebecca Cran wrote: > >> instruction pointer = 0x20: 0x811bc664 > > So what is the source line for this a

Re: Panic on boot with r351461 (AMD ThreadRipper 2990WX)

2019-08-24 Thread Konstantin Belousov
On Sat, Aug 24, 2019 at 02:22:18PM -0600, Rebecca Cran wrote: > I updated my kernel to r351461 today and now get a panic on boot. > > > CPU: AMD Ryzen Threadripper 2990WX 32-Core Processor (2994.45-MHz > K8-class CPU) >   Origin="AuthenticAMD"  Id=0x800f82  Family=0x17  Model=0x8  Stepping=2 >  

Re: SVN r351457 breaks drm-current

2019-08-24 Thread Konstantin Belousov
On Sat, Aug 24, 2019 at 11:02:20AM -0600, Warner Losh wrote: > forward declaring struct pcpu; in md_var.h "fixes" this, but I'm not sure > that's the right fix. More correct way to fix it is to include sys/pcpu.h before machine/md_var.h, same as all in-tree consumers of the header do, apparently.

Re: Stop installing /usr/bin/clang

2019-08-16 Thread Konstantin Belousov
oad order they prefer for decades, and if we have some > how broken this.. well that should get fixed asap, not > removing stuff out of base because something is broken by > incorrect path manipulations. > > Regards, > Rod > > > --- Original message --- > > >

Re: Stop installing /usr/bin/clang

2019-08-16 Thread Konstantin Belousov
On Fri, Aug 16, 2019 at 09:47:41AM +0100, David Chisnall wrote: > On 15/08/2019 17:48, Konstantin Belousov wrote: > > Please look at https://reviews.freebsd.org/D21060 > > I propose to stop installing /usr/bin/clang, clang++, clang-cpp. > > > > It probably do

Re: Stop installing /usr/bin/clang

2019-08-16 Thread Konstantin Belousov
y know what she does. I did not see it causing issues practically, while multiple clangs in the path cause real problems. > > --- Original message --- > From: "Konstantin Belousov"  > Date: 15 August 2019, 19:48:37 > > Please look at https://reviews.freebsd.org/D21

Stop installing /usr/bin/clang

2019-08-15 Thread Konstantin Belousov
Please look at https://reviews.freebsd.org/D21060 I propose to stop installing /usr/bin/clang, clang++, clang-cpp. It probably does not matter when all your software comes from ports or packages, but is actually very annoying when developing on FreeBSD. In particular, you never know which `clang'

Re: userret: assert td_lk_slocks == 0

2019-08-12 Thread Konstantin Belousov
On Mon, Aug 12, 2019 at 12:14:25PM +0300, Andriy Gapon wrote: > > I am trying to debug a leak of a shared vnode lock and I noticed that > there is no check for td_lk_slocks in userret. There are checks for > td_rw_rlocks and td_sx_slocks. I wonder if there is any valid scenario > where a thread

Re: rc script: manual stop vs system shutdown

2019-08-12 Thread Konstantin Belousov
On Mon, Aug 12, 2019 at 10:46:29AM +0300, Andriy Gapon wrote: > On 01/08/2019 22:51, Ian Lepore wrote: > > On Thu, 2019-08-01 at 21:14 +0300, Andriy Gapon wrote: > >> On 01/08/2019 19:12, Warner Losh wrote: > >>> > >>> > >>> On Thu, Aug 1, 2019, 10:53 AM Rodney W. Grimes > >>>

Re: r350484 and ASLR enabled - init died (signal 6, exit 0)

2019-08-08 Thread Konstantin Belousov
On Thu, Aug 08, 2019 at 09:35:23AM +0300, Vladimir Zakharov wrote: > On Mon, Aug 05, 2019, Konstantin Belousov wrote: > > On Mon, Aug 05, 2019 at 08:10:43PM +0200, Trond Endrestøl wrote: > > > On Mon, 5 Aug 2019 06:02-0700, David Wolfskill wrote: > > > > > >

NIS maps value length increase to 16m

2019-08-06 Thread Konstantin Belousov
Apparently, NIS is still in use even in large enterprise environments, not everything was consumed by LDAP. And there, Linux added a quirk very long time ago, in 2013 at least, see https://marc.info/?l=fedora-extras-commits=13667504323=2 What they did is the increase of the longest allowed

Re: r350484 and ASLR enabled - init died (signal 6, exit 0)

2019-08-05 Thread Konstantin Belousov
On Mon, Aug 05, 2019 at 08:10:43PM +0200, Trond Endrestøl wrote: > On Mon, 5 Aug 2019 06:02-0700, David Wolfskill wrote: > > > On Mon, Aug 05, 2019 at 02:53:04PM +0200, Trond Endrestøl wrote: > > > Hi, > > > > > > Has anyone else noticed the kernel being unable to spawn init lately? > > > > > >

Re: [package - head-i386-default][sysutils/lsof] Failed for lsof-4.93.2_2,8 in build

2019-07-25 Thread Konstantin Belousov
On Thu, Jul 25, 2019 at 02:10:46PM -0500, Larry Rosenman wrote: > On 07/25/2019 1:40 pm, Justin Hibbits wrote: > > On Thu, 25 Jul 2019 12:35:32 -0600 > > Alan Somers wrote: > > > >> On Thu, Jul 25, 2019 at 12:13 PM Larry Rosenman > >> wrote: > >> > > >> > On 07/25/2019 1:10 pm, Alan Somers

Re: mmap port from 9 not working

2019-07-22 Thread Konstantin Belousov
On Mon, Jul 22, 2019 at 02:03:26PM +0200, Ronald Klop wrote: > > Van: Laurie Jennings > Datum: zondag, 21 juli 2019 16:58 > Aan: Konstantin Belousov > CC: FreeBSD Current > Onderwerp: Re: mmap port from 9 not working > > > > On Sunday, July 21, 2019, 10:44:

Re: mmap port from 9 not working

2019-07-21 Thread Konstantin Belousov
On Sun, Jul 21, 2019 at 03:48:03AM +, Laurie Jennings wrote: > I have some custom stuff I'm porting from Freebsd 9.x using mmap. I get a > pointer from the kernel via an ioctl and I map it into a shared buffer. > char *kptr;   // mem ptr from kernel >

Re: panic: vm_page_free_prep: freeing mapped page

2019-07-14 Thread Konstantin Belousov
On Sun, Jul 14, 2019 at 03:34:20PM -0400, Mark Johnston wrote: > On Sun, Jul 14, 2019 at 01:14:57AM +0300, Konstantin Belousov wrote: > > On Sat, Jul 13, 2019 at 04:50:57PM -0500, Larry Rosenman wrote: > > > I have cores. Ideas? > > > svn rev: r349976 > >

Re: panic: vm_page_free_prep: freeing mapped page

2019-07-13 Thread Konstantin Belousov
On Sat, Jul 13, 2019 at 04:50:57PM -0500, Larry Rosenman wrote: > I have cores. Ideas? > svn rev: r349976 > > [I] ➜ more core.txt.12 > borg.lerctr.org dumped core - see /var/crash/vmcore.12 > > Sat Jul 13 16:47:03 CDT 2019 > > FreeBSD borg.lerctr.org 13.0-CURRENT FreeBSD 13.0-CURRENT r349976

Re: should a copy_file_range(2) syscall be interrupted via a signal

2019-07-05 Thread Konstantin Belousov
On Fri, Jul 05, 2019 at 08:59:23PM +, Rick Macklem wrote: > Konstantin Belousov wrote: > >On Fri, Jul 05, 2019 at 07:30:54PM +0200, Jilles Tjoelker wrote: > >> On Fri, Jul 05, 2019 at 12:28:51AM +, Rick Macklem wrote: > >> > I have been working on a Linu

Re: should a copy_file_range(2) syscall be interrupted via a signal

2019-07-05 Thread Konstantin Belousov
On Fri, Jul 05, 2019 at 07:30:54PM +0200, Jilles Tjoelker wrote: > On Fri, Jul 05, 2019 at 12:28:51AM +, Rick Macklem wrote: > > I have been working on a Linux compatible copy_file_range(2) syscall > > (the current code can be found at https://reviews.freebsd.org/D20584). > > > One

Re: adding a syscall to libc?

2019-06-09 Thread Konstantin Belousov
On Sun, Jun 09, 2019 at 06:12:59AM +, Rick Macklem wrote: > Konstantin Belousov wrote: > >On Sat, Jun 08, 2019 at 02:57:27AM +, Rick Macklem wrote: > >> Hi, > >> > First off, thanks Kostik for the fine explanation. I agree with Oliver that > it should >

Re: adding a syscall to libc?

2019-06-08 Thread Konstantin Belousov
On Sat, Jun 08, 2019 at 02:57:27AM +, Rick Macklem wrote: > Hi, > > I've started working of a copy_file_range() syscall for FreeBSD. I think I > have the > kernel patched and ready for some testing. > However, I'm confused about what I need to do in src/lib/libc/sys? > - Some syscalls have

Re: Crash on very recent CURRENT if using poudriere

2019-06-02 Thread Konstantin Belousov
On Sun, Jun 02, 2019 at 07:45:34PM +0200, Kurt Jaeger wrote: > Hi! > > > > > > [panic] non-zero write count during poudriere run > > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238031 > > > > > > > > > > Ideas on how to proceed ? > > > > > > > > Try this. > > > > > > Unfortunatly,

Re: Crash on very recent CURRENT if using poudriere

2019-06-02 Thread Konstantin Belousov
On Sun, Jun 02, 2019 at 06:48:51PM +0200, Kurt Jaeger wrote: > Hi! > > > > [panic] non-zero write count during poudriere run > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238031 > > > > > > Ideas on how to proceed ? > > > > Try this. > > Unfortunatly, I can no longer reproduce the

Re: Crash on very recent CURRENT if using poudriere

2019-05-31 Thread Konstantin Belousov
On Fri, May 31, 2019 at 12:49:11PM +0200, Kurt Jaeger wrote: > Hi! > > [panic] non-zero write count during poudriere run > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238031 > > Ideas on how to proceed ? Try this. diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c index

Re: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

2019-05-27 Thread Konstantin Belousov
On Mon, May 27, 2019 at 03:55:21PM +0200, voida...@420blaze.it wrote: > Hello, > I wanted to discuss about bug 231768 a bit: it is about keeping > COMPAT_FREEBSD4/5/6/7/9 on by default in the kernel configs. What problem are you trying to solve ? > > The patch attached for the bug is for

Re: Weirdness when writing to pseudofs file

2019-05-22 Thread Konstantin Belousov
On Wed, May 22, 2019 at 10:36:34AM -0700, Johannes Lundberg wrote: > Hi > > I'm fiddling with lindebugfs, which is based on pseudofs. When writing > to a file, > > this works: # echo  1 >> /path/to/file > > but this does not: # echo 1 > /path/to/file > > "Operation not supported." is returned

  1   2   3   4   5   6   7   8   9   10   >