Re: Current amd64 new error or warning from today's current with ruby r320323

On Sun, Jun 25, 2017 at 10:09:07AM -0700, Manfred Antar wrote: > > > On Jun 25, 2017, at 9:41 AM, Konstantin Belousov <kostik...@gmail.com> > > wrote: > > > > On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote: > >> > >>> On

Re: Current amd64 new error or warning from today's current with ruby r320323

On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote: > > https://people.freebsd.org/~kib/misc/vm2.2.patch > > This patch made ruby23 happy on my end. Can't say the same for > emacs-nox11 or temacs while building the former. What exactly do you mean ? Explain the behaviour and show

Re: r320358 panics immediately on boot / AMD64-GENERIC kernel

On Tue, Jun 27, 2017 at 12:09:56PM -0400, Michael Jung wrote: > Screen image with backtrace > > https://pasteboard.co/dZRVG5Uo.jpg > > > After upgrading from 318959 to 320358 I immediately get the attached > panic. > > This is AMD64 / GENERIC kernel. > > /boot/loader.conf is empty. > > The

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On Wed, May 24, 2017 at 04:59:31AM -0700, David Wolfskill wrote: > Yesterday's in-place src update (r318606 -> r318739) was a bit more > "interesting" than usual; as has been noted elsewhere, it really is > necessary to boot the new kernel before the "make installworld" > completes successfully.

Re: ino64: desastrous update - recommendations not working!!!

On Wed, May 24, 2017 at 12:42:19PM +0200, Hartmann, O. wrote: > On almost every CURRENT that has been updated according to UPDATING > entry 2017-05-23 regarding ino64, the recommended update process ends > up in a desaster or, if the old environemnt/kernel is intact, itr > doesn't work. > >

Re: svn commit: r318757 - head

l: l...@lerctr.org > US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 > > > > On 5/24/17, 4:05 AM, "Konstantin Belousov" <kostik...@gmail.com> wrote: > > On Tue, May 23, 2017 at 04:46:14PM -0500, Larry Rosenman wrote: > > My PostgreSQL bui

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On Wed, May 24, 2017 at 06:59:05AM -0700, David Wolfskill wrote: > On Wed, May 24, 2017 at 04:35:58PM +0300, Konstantin Belousov wrote: > > If build of r318739 succed, can you try, please, to rebuild the current > > latest sources, but now with reverted r318750 ? > > It did

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

) The path to the linker executable that crashes > > 3) Backtrace of the crash > > > > -Dimitry > > > > On Wed, May 24, 2017 at 03:10:33PM +0300, Konstantin Belousov wrote: > > ... > > > > If you perform build of r318739 on r318739 (i.e. build of the same

Re: ino64 package fallout

On Wed, May 24, 2017 at 10:05:22AM -0700, Don Lewis wrote: > I just upgraded by package build box and its poudriere jail to r318776 > and ran into some significant package build fallout. There are several reviews that fix ports with most significant fallouts, lang/llvm39

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On Wed, May 24, 2017 at 08:15:09AM -0700, David Wolfskill wrote: > On Wed, May 24, 2017 at 07:20:01AM -0700, David Wolfskill wrote: > > ... > > > > I have updated /usr/src back to 318781, then started a new build. > > > So are you building stock 318781, or did you reverted r318750 ? > > > > Stock

Re: 64-bit inodes (ino64) Status Update and Call for Testing

On Sun, May 21, 2017 at 02:14:56PM +0200, Jilles Tjoelker wrote: > We have another type in this area which is too small in some situations: > uint8_t for struct dirent.d_namlen. For filesystems that store filenames > as upto 255 UTF-16 code units, the name to be stored in d_name may be > upto 765

Re: 64-bit inodes (ino64) Status Update and Call for Testing

On Sun, May 21, 2017 at 04:03:55PM +0200, Jilles Tjoelker wrote: > On Sun, May 21, 2017 at 03:31:18PM +0300, Konstantin Belousov wrote: > > On Sun, May 21, 2017 at 02:14:56PM +0200, Jilles Tjoelker wrote: > > > We have another type in this area which is too small in some situati

Re: svn commit: r318757 - head

On Tue, May 23, 2017 at 04:46:14PM -0500, Larry Rosenman wrote: > My PostgreSQL buildfarm animal BROKE with this change until I force rebuilt > lang/perl5.24 > and all my p5-* ports. So what was the symptoms and the error, exactly ? A lot of efforts were spent to ensure that _consistent_ set of

kqueue(2) changes

I implemented an option to specify absolute time for kqueue(2) timers, and did required type changes to support larger values in struct kevent. Please see https://reviews.freebsd.org/D11025 for the patch, including man page update, and for some more detailed explanation. Please review.

Re: Time to increase MAXPHYS?

On Sat, Jun 03, 2017 at 11:28:23PM -0600, Warner Losh wrote: > On Sat, Jun 3, 2017 at 9:55 PM, Allan Jude wrote: > > > On 2017-06-03 22:35, Julian Elischer wrote: > > > On 4/6/17 4:59 am, Colin Percival wrote: > > >> On January 24, 1998, in what was later renumbered to SVN

Re: [libltdl] removal from gnu ports

On Wed, Jun 07, 2017 at 11:33:32AM +0100, David Chisnall wrote: > On 7 Jun 2017, at 10:33, blubee blubeeme wrote: > > > > Hi > > > > I'm sure I was reading yesterday on a different machine about the linker > > flag -ld which has something to do with gnu dlopen and how it's

Re: Panic @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305"

On Fri, Jun 09, 2017 at 05:57:15AM -0700, David Wolfskill wrote: > Build machine updated from r319689 to r319733 OK; smoke test was > uneventful. > > Laptop updated similarly, but smoke test was a little more "interesting". > > Turns out that laptop gets to multi-user mode OK... if I disable >

Re: INO64 in head: Does sys/boot/common/ufsread.c need its "typedef uint32_t ufs_ino_t;" replaced?

On Fri, Jun 16, 2017 at 05:01:43PM -0700, Mark Millard wrote: > buildworld via clang for powerpc64 and powerpc fails for lack of > `__udivdi3' referenced in sys/boot/common/ufsread.c fsread_size > code. But this lead to me looking around and I found a conceptually > separate possible issue. . . >

Re: INO64 in head: Does sys/boot/common/ufsread.c need its "typedef uint32_t ufs_ino_t;" replaced?

On Fri, Jun 16, 2017 at 08:54:10PM -0700, Mark Millard wrote: > On 2017-Jun-16, at 7:48 PM, Konstantin Belousov > wrote: > > > On Fri, Jun 16, 2017 at 05:01:43PM -0700, Mark Millard wrote: > >> . . . > > > > UFS uses 32bit inodes, changing to 64bit is both

Re: adding extern maxbcachebuf to param.h

On Sun, Jun 18, 2017 at 12:36:59PM +, Rick Macklem wrote: > My recent commit (r320062) broke the arm build when it added > extern int maxbcachebuf; > to sys/param.h. Although I don't understand the actual failure, I believe > it is caused by arm/arm/elf_note.S including param.h and then using

Re: Compiler optimisation bug

On Tue, May 02, 2017 at 10:26:17AM +0200, Nick Hibma wrote: > There is a bug in sbin/dhclient.c for large expiry values on 32 bit platforms > where time_t is a uint32_t (bug #218980, > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218980). It is caused by a > compiler optimisation that

Re: filemon: weird full-time build although filemon enabled

On Mon, May 08, 2017 at 09:04:08AM -0700, Simon J. Gerraty wrote: > O. Hartmann wrote: > > It is weird! > > > > Today, after yesterday's built, I face the same 90 minutes build horror > > again, this time > > I switched on "-dM" with the make command. > > > > This

Re: ino64 package fallout

On Wed, May 24, 2017 at 05:49:04PM -0700, Don Lewis wrote: > On 24 May, Konstantin Belousov wrote: > > On Wed, May 24, 2017 at 10:05:22AM -0700, Don Lewis wrote: > >> I just upgraded by package build box and its poudriere jail to r318776 > >> and ran into some signif

Re: ino64, java and intellij products problem

On Wed, May 31, 2017 at 11:53:39PM +0300, Boris Samorodov wrote: > Hi All, > > Seems that after ino64 transition some java programs stopped > to fully function. I.e. java/intellij (IntellJ IDEA and Co) > starts but does not show any files. > > I'm not sure if it's a java or IntelliJ problem. Any

Re: @r324591: panic: UNR inconsistency: items 0 found 7 (line 361)

On Fri, Oct 13, 2017 at 04:36:34AM -0700, David Wolfskill wrote: > This occurred after I had booted & smoke-tested my laptop, then > issued "sudo shutdown -r now"; it's *possible* that there was also > a (similar?) problem shutting down yesterday (@r324542), but the > screen had gone dark and

Re: C++ in jemalloc

On Thu, Oct 05, 2017 at 11:59:03AM -0700, David Goldblatt wrote: > Hi all, > > The jemalloc developers have wanted to start using C++ for a while, to > enable some targeted refactorings of code we have trouble maintaining due > to brittleness or complexity (e.g. moving thousand line macro

Re: Dying SD memory? handle_workitem_freefile: got error 5 while accessing filesystem

On Sun, Sep 24, 2017 at 08:32:54AM -0700, Rodney W. Grimes wrote: > Would it be possible to add some robustness to these checksum > failed errors to indicate there source more accurately? Ie > either a /dev entry or a fstab entry, and the fact they are > from the ffs layer? Perhaps this. But

Re: Dying SD memory? handle_workitem_freefile: got error 5 while accessing filesystem

On Sun, Sep 24, 2017 at 02:19:26PM +0200, O. Hartmann wrote: > Am Sun, 24 Sep 2017 10:52:38 +0300 > Konstantin Belousov <kostik...@gmail.com> schrieb: > > > On Sun, Sep 24, 2017 at 09:31:51AM +0200, O. Hartmann wrote: > > > Running a NanoBSD application on a small PC

Re: Build error: 'isa/rtc.h' file not found

On Mon, Oct 02, 2017 at 09:44:36AM +0200, O. Hartmann wrote: > Am Mon, 2 Oct 2017 11:35:22 +0700 > "Alex V. Petrov" schrieb: > > > revision 324186 > > In file included from /usr/obj/usr/src/tmp/usr/include/sys/efi.h:33: > >

Re: Dying SD memory? handle_workitem_freefile: got error 5 while accessing filesystem

On Sun, Sep 24, 2017 at 09:31:51AM +0200, O. Hartmann wrote: > Running a NanoBSD application on a small PCEngine device, feeding the box > with a CURRENT > (FreeBSD 12.0-CURRENT #33 r323958: Sat Sep 23 22:19:57 CEST 2017 amd64), > booting from a > SD memory card. > > Recently, when saving

Re: Segfault in _Unwind_* code called from pthread_exit

On Wed, Aug 23, 2017 at 04:37:07PM +0200, Tijl Coosemans wrote: > Hi, > > The following program segfaults for me on amd64 when linked like this: > > cc -o test test.c -lpthread -L/usr/local/lib/gcc5 -lgcc_s -rpath > /usr/local/lib/gcc5 > > > #include >

Re: SIGSEGV in /bin/sh after r322740 -> r322776 update

On Tue, Aug 22, 2017 at 04:46:27AM -0700, David Wolfskill wrote: > Started with: > FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #445 > r322740M/322745:1200040: Mon Aug 21 04:35:19 PDT 2017 > r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 > >

Re: SIGSEGV in /bin/sh after r322740 -> r322776 update

On Tue, Aug 22, 2017 at 05:28:36AM -0700, David Wolfskill wrote: > On Tue, Aug 22, 2017 at 02:59:23PM +0300, Konstantin Belousov wrote: > > ... > > > lldb's notion of the backtrace was fairly non-useful: > > > g1-252(11.1-S)[7] lldb -c sh.core > > > (lldb) targe

Re: Segfault in _Unwind_* code called from pthread_exit

On Fri, Aug 25, 2017 at 05:38:51PM +0200, Tijl Coosemans wrote: > So both GCC and LLVM unwinding look up the return address in the CFI > table and fail when the return address is garbage, but LLVM treats this > as an end-of-stack condition while GCC further tries to see if the > return address

Re: Segfault in _Unwind_* code called from pthread_exit

On Sat, Aug 26, 2017 at 08:28:13PM +0200, Tijl Coosemans wrote: > On Sat, 26 Aug 2017 02:44:42 +0300 Konstantin Belousov <kostik...@gmail.com> > wrote: > > How does llvm unwinder detects that the return address is a garbage ? > > It just stops unwinding when it can'

Re: SIGSEGV in /bin/sh after r322740 -> r322776 update

On Tue, Aug 22, 2017 at 05:46:17AM -0700, David Wolfskill wrote: > On Tue, Aug 22, 2017 at 03:34:49PM +0300, Konstantin Belousov wrote: > > ... > > $ gdb /bin/sh sh.core > > (gdb) bt > > (gdb) info registers > > (gdb) disassemble > > [New LWP 100182] >

Re: Switch vfs.nfsd.issue_delegations to TUNABLE ?

On Tue, Nov 28, 2017 at 11:41:36AM +0100, Emmanuel Vadot wrote: > > Hello, > > I would like to switch the vfs.nfsd.issue_delegations sysctl to a > tunable. > The reason behind it is recent problem at work on some on our filer > related to NFS. > We use NFSv4 without delegation as we never

Re: CURRENT: core dumped no process name

On Tue, Nov 28, 2017 at 06:09:16PM +0700, Alex V. Petrov wrote: > You were right. > After revert to r325188 worked: > Nov 28 18:05:18 alex kernel: pid 23618 (mc), uid 0: exited on signal 6 > (core dumped) Thank you for confirming. Adding the committer. > > 28.11.2017 17:38, K

Re: CURRENT: core dumped no process name

On Tue, Nov 28, 2017 at 05:13:10PM +0700, Alex V. Petrov wrote: > from /var/log/messages > > # grep core /var/log/messages > Nov 21 06:26:56 alex kernel: 1001: exited on signal 11 (core dumped) > Nov 22 00:46:31 alex kernel: FreeBSD/SMP: 1 package(s) x 8 core(s) > Nov 22 16:01:32 alex kernel:

Re: Switch vfs.nfsd.issue_delegations to TUNABLE ?

On Tue, Nov 28, 2017 at 02:26:10PM +0100, Emmanuel Vadot wrote: > On Tue, 28 Nov 2017 13:04:28 +0200 > Konstantin Belousov <kostik...@gmail.com> wrote: > > > On Tue, Nov 28, 2017 at 11:41:36AM +0100, Emmanuel Vadot wrote: > > > > > > Hell

Re: CURRENT: core dumped no process name

On Tue, Nov 28, 2017 at 08:37:44AM -0800, Gleb Smirnoff wrote: > Hi Alex, > > On Tue, Nov 28, 2017 at 06:09:16PM +0700, Alex V. Petrov wrote: > A> You were right. > A> After revert to r325188 worked: > A> Nov 28 18:05:18 alex kernel: pid 23618 (mc), uid 0: exited on signal 6 > A> (core dumped)

Re: CURRENT: core dumped no process name

On Tue, Nov 28, 2017 at 10:37:45AM +0700, Alex V. Petrov wrote: > SUBJ: > Nov 28 10:28:38 alex kernel: 1001: exited on signal 11 (core dumped) > It was a thunerbird > > > 12.0-CURRENT #0 r326286 > kernel GENERIC-NODEBUG The format strings is following: "pid %d (%s), uid %d: exited on signal

Re: /usr/obj is 11GB huge on FreeBSD 12-current

On Fri, Dec 15, 2017 at 06:38:48PM +0100, Wolfram Schneider wrote: > On 15 December 2017 at 17:51, Wolfram Schneider wrote: > > On 15 December 2017 at 13:02, David Wolfskill wrote: > >> On Fri, Dec 15, 2017 at 10:12:09AM +0100, Wolfram Schneider wrote: >

Re: cannot access pass device from within jail

On Sun, Dec 17, 2017 at 02:52:12PM -0500, Dan Langille wrote: > Hello, > > What suggestions do you have for where I should look next? I'm happy to start > installing various builds of FreeBSD in order to track down which commit > caused this. > > I'm trying to access a tape library from within

Re: cannot access pass device from within jail

On Sun, Dec 17, 2017 at 03:49:15PM -0500, Dan Langille wrote: > > On Dec 17, 2017, at 3:37 PM, Konstantin Belousov <kostik...@gmail.com> > > wrote: > > Does it work to access the pass device from host using host' /dev ? > > Yes, it does. see "Th

Re: XBOX/i386 and xlint removal

On Thu, Nov 09, 2017 at 03:52:21PM +0200, Konstantin Belousov wrote: > Hello, > I created two reviews to axe two features which I personally find of > little use in modern FreeBSD. ... I put the follow up to remove the lint support from the headers. Feel free to review and comment, aft

Re: [HEADS UP] posix_fallocate support removed from ZFS, lld affected

On Mon, Nov 06, 2017 at 11:43:42AM -0700, Ed Maste wrote: > On 6 November 2017 at 10:56, Ian Lepore wrote: > > > > Oh, right. lld != ld. > > Indeed, but this will be a problem for the arm64 package builds if > they use ZFS and an 11.x userland on a new kernel. We probably need

XBOX/i386 and xlint removal

Hello, I created two reviews to axe two features which I personally find of little use in modern FreeBSD. https://reviews.freebsd.org/D13015 xlint https://reviews.freebsd.org/D13016 XBOX/i386 Reviews contain the explanations. For xlint it is just an overdue, IMO. While for XBOX I do not have

Re: Segfault in _Unwind_* code called from pthread_exit

On Sat, Oct 21, 2017 at 10:02:38PM +0200, Andreas Tobler wrote: > On 26.08.17 20:40, Konstantin Belousov wrote: > > On Sat, Aug 26, 2017 at 08:28:13PM +0200, Tijl Coosemans wrote: > >> On Sat, 26 Aug 2017 02:44:42 +0300 Konstantin Belousov > >> <kostik...@gmail.c

Re: Segfault in _Unwind_* code called from pthread_exit

On Tue, Oct 31, 2017 at 08:37:29PM +0100, Andreas Tobler wrote: > On 31.10.17 10:28, Konstantin Belousov wrote: > > On Mon, Oct 30, 2017 at 10:54:05PM +0100, Andreas Tobler wrote: > >> On 30.10.17 15:32, Tijl Coosemans wrote: > >>> On Sun, 29 Oct 2017 20:40:46 +0100 A

Re: Segfault in _Unwind_* code called from pthread_exit

On Sun, Oct 29, 2017 at 06:23:51PM +0100, Tijl Coosemans wrote: > On Sat, 26 Aug 2017 21:40:34 +0300 Konstantin Belousov <kostik...@gmail.com> > wrote: > > On Sat, Aug 26, 2017 at 08:28:13PM +0200, Tijl Coosemans wrote: > >> I did consider using > >> a CFI dire

Re: Segfault in _Unwind_* code called from pthread_exit

On Mon, Oct 30, 2017 at 10:54:05PM +0100, Andreas Tobler wrote: > On 30.10.17 15:32, Tijl Coosemans wrote: > > On Sun, 29 Oct 2017 20:40:46 +0100 Andreas Tobler > > wrote: > >> Attached what I have for libgcc. It can be applied to gcc5-8, should > >> give no issues. The

Re: panic: vtopde on a uva/gpa 0x1030000 @r325228 (amd64)

On Tue, Oct 31, 2017 at 04:37:10AM -0700, David Wolfskill wrote: > Performed the usual src update in head/amd64; today was from r325137 to > r325228. Laptop had no complaints; everything Just Worked (as usual). > > GEOM: new disk da1 > panic: vtopde on a uva/gpa 0x103 > cpuid = 5 > time =

Re: Lag after resume culprit found

On Thu, May 17, 2018 at 11:06:42AM +0300, Andriy Gapon wrote: > On 17/05/2018 10:56, Johannes Lundberg wrote: > > > > > > On Thu, May 17, 2018 at 8:46 AM, Johannes Lundberg > > wrote: > > > > > > > > On Thu, May 17, 2018 at 7:43 AM, Andriy

Re: Floating point in kernel?

On Sat, May 26, 2018 at 10:59:50AM +0100, Johannes Lundberg wrote: > Hi > > The new AMD graphics drivers use floats in kernel space. > Upstream Linux code has something like: > kernel_fpu_begin(); > ... > kernel_fpu_end(); > > Do we have similar functions to save/restore FPU registers? Read

Re: [RFC] Deprecation and removal of the drm2 driver

ote: > > > >> > > > > > >> > > > I propose that we remove the old drm2 driver (sys/dev/drm2) from > > > >> > > > FreeBSD. I suggest the driver is marked as deprecated in 11.x > > and > > > >> > > > removed fro

Re: A head buildworld race visible in the ci.freebsd.org build history

On Mon, Jun 18, 2018 at 12:42:46PM -0700, Bryan Drewery wrote: > On 6/15/2018 10:55 PM, Mark Millard wrote: > > In watching ci.freebsd.org builds I've seen a notable > > number of one time failures, such as (example from > > powerpc64): > > > > --- all_subdir_lib/libufs --- > > ranlib -D libufs.a

Ryzen public erratas

Today I noted that AMD published the public errata document for Ryzens, https://developer.amd.com/wp-content/resources/55449_1.12.pdf Some of the issues listed there looks quite relevant to the potential hangs that some people still experience with the machines. I wrote a script which should

Re: Ryzen public erratas

On Wed, Jun 13, 2018 at 12:06:42PM +0100, Johannes Lundberg wrote: > > Konstantin Belousov writes: > > > Today I noted that AMD published the public errata document for Ryzens, > > https://developer.amd.com/wp-content/resources/55449_1.12.pdf > > > > Some of th

Re: Ryzen public erratas

On Thu, Jun 14, 2018 at 10:24:17AM -0400, Mike Tancsa wrote: > On 6/14/2018 9:36 AM, Eric van Gyzen wrote: > > On 06/13/2018 05:35, Konstantin Belousov wrote: > >> Today I noted that AMD published the public errata document for Ryzens, > >> https://developer.amd.com/wp-c

Re: [RFC] Deprecation and removal of the drm2 driver

On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote: > On Wed, May 30, 2018 at 10:57 PM O. Hartmann wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Am Thu, 24 May 2018 09:10:10 -0700 (PDT) > > "Rodney W. Grimes" schrieb: > > > > > -- Start of PGP signed

Re: ``make buildkernel'' fails when /usr/obj is empty

On Thu, May 31, 2018 at 08:19:20PM +0200, Dimitry Andric wrote: > On 31 May 2018, at 20:11, Warner Losh wrote: > > > > On Thu, May 31, 2018 at 11:47 AM, Dimitry Andric wrote: > > On 31 May 2018, at 18:04, Benjamin Kaduk wrote: > > > On Thu, May 31, 2018 at 09:58:50AM +0200, Gary Jennejohn

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin wrote: > > > On Sun, 3 Jun 2018 16:21:10 +0300 > Konstantin Belousov wrote: > > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin wrote: > > > Hi, > > > > > > After upgrading CU

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin wrote: > Hi, > > After upgrading CURRENT to r333992 (from something at least a year > old, quite some changes in mp_machdep.c since), this machine crashes > on boot: > > Copyright (c) 1992-2018 The FreeBSD Project. > Copyright (c) 1979,

Re: Error build nvidia-driver with r334555

On Sun, Jun 03, 2018 at 05:08:34AM -0700, David Wolfskill wrote: > On Sun, Jun 03, 2018 at 06:48:01PM +0700, Alex V. Petrov wrote: > > > > --- nvidia_subr.o --- > > > > > > nvidia_subr.c:367:26: error: 'memset' call operates on objects of type > > 'struct nv_ioctl_card_info' while the size

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

On Sun, Jun 03, 2018 at 09:50:20PM +0200, Michael Gmelin wrote: > > > On Sun, 3 Jun 2018 18:04:23 +0300 > Konstantin Belousov wrote: > > > On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin wrote: > > > > > > > > > On Sun, 3 Jun 2018

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

On Mon, Jun 04, 2018 at 12:46:32AM +0200, Michael Gmelin wrote: > > > On Sun, 3 Jun 2018 23:53:40 +0300 > Konstantin Belousov wrote: > > > On Sun, Jun 03, 2018 at 09:50:20PM +0200, Michael Gmelin wrote: > > > > > > > > > On Sun, 3 Jun 2018

Re: SVN r334499 breaks i386 kernel build

On Fri, Jun 01, 2018 at 07:42:07PM -0400, Michael Butler wrote: > Building /usr/obj/usr/src/i386.i386/sys/SARAH/vm_mmap.o > --- vm_mmap.o --- > /usr/src/sys/vm/vm_mmap.c:245:6: error: use of undeclared identifier > 'MAP_32BIT' > MAP_32BIT | MAP_ALIGNMENT_MASK)) != 0)) > ^ >

Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)

On Mon, Jun 04, 2018 at 11:17:56PM +0200, Michael Gmelin wrote: > > > On Mon, 4 Jun 2018 14:06:55 +0300 > Konstantin Belousov wrote: > > > On Mon, Jun 04, 2018 at 12:46:32AM +0200, Michael Gmelin wrote: > > > > > > > > > On Sun, 3 Jun 2018

Re: nfsd kernel threads won't die via SIGKILL

On Mon, Jun 25, 2018 at 02:04:32AM +, Rick Macklem wrote: > Konstantin Belousov wrote: > >On Sat, Jun 23, 2018 at 09:03:02PM +, Rick Macklem wrote: > >> During testing of the pNFS server I have been frequently > >> killing/restarting the nfsd. > >&g

Re: nfsd kernel threads won't die via SIGKILL

On Sat, Jun 23, 2018 at 09:03:02PM +, Rick Macklem wrote: > During testing of the pNFS server I have been frequently killing/restarting > the nfsd. > Once in a while, the "slave" nfsd process doesn't terminate and a "ps axHl" > shows: > 0 48889 1 0 20 0 5884 812 svcexit D -

Re: atomic_testandclear_, atomic_testandset_

On Sat, Jun 23, 2018 at 01:38:07PM -0700, Matthew Macy wrote: > It turns out ck already has equivalent primitives. Pardon the noise. Why not to add trivial cmpset-based implementations to the lacking arches ? If maintainers prefer proper ll/cs assembly, they would have the time to do it properly

Re: change of nfsd->kernel interface in head

On Sat, Jun 30, 2018 at 06:39:57PM +, Rick Macklem wrote: > r335012 (the big patch that added the pNFS server support) revised the > nfsd->kernel > nfssvc(2) syscall interface. > It has compatibility code, so that old nfsd binaries still work. > > I now need to revise this interface again to

Re: mlx5(4) jumbo receive

On Wed, Apr 25, 2018 at 04:04:13PM -0400, Ryan Stone wrote: > On Tue, Apr 24, 2018 at 4:55 AM, Konstantin Belousov > <kostik...@gmail.com> wrote: > > +#ifndef MLX5E_MAX_RX_BYTES > > +#defineMLX5E_MAX_RX_BYTES MCLBYTES > > +#endif > > Why do you use a

Re: panic: invalid bcd 194

On Sat, Dec 30, 2017 at 10:07:11PM +0100, Matthias Apitz wrote: > El d??a s??bado, diciembre 30, 2017 a las 10:44:57p. m. +0200, Konstantin > Belousov escribi??: > > > On Sat, Dec 30, 2017 at 09:03:17PM +0100, Matthias Apitz wrote: > > > > > > Hello, > &g

Re: Programmatically cache line

On Sat, Dec 30, 2017 at 07:50:19AM +, blubee blubeeme wrote: > Is there some way to programmatically get the CPU cache line sizes on > FreeBSD? There are, all of them are MD. On x86, the CPUID instruction leaf 0x1 returns the information in %ebx register.

Re: Programmatically cache line

On Thu, Jan 04, 2018 at 10:03:32AM +, David Chisnall wrote: > On 3 Jan 2018, at 22:12, Nathan Whitehorn <nwhiteh...@freebsd.org> wrote: > > > > On 01/03/18 13:37, Ed Schouten wrote: > >> 2018-01-01 11:36 GMT+01:00 Konstantin Belousov <kostik...@gmail

Re: Insta-reset-bootloop with r328166 and vm.pmap.pcid_enabled=1

On Thu, Jan 25, 2018 at 04:58:04PM -0500, Ian FREISLICH wrote: > Hi > > I cannot for the life of me recall why I had vm.pmap.pcid_enabled=1 set > in loader.conf, but I did.  Most likely very historical reasons. > > r328166 and later reset without dropping into the debugger during boot, > no

Re: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832

On Fri, Jan 12, 2018 at 12:12:31PM -0500, Mike Tancsa wrote: > On 1/12/2018 11:58 AM, Sean Bruno wrote: > >> > > > > Probably, update your port of x86info. I pushed an update for this and > > it might work better for you. > > Thanks, I tried it but still generates the error / warning. What does

Re: td_swvoltick

On Fri, Jan 12, 2018 at 01:31:41PM -0600, Eric van Gyzen wrote: > should_yield() compares thread::td_swvoltick to 'ticks' to determine > whether a thread is hogging and should yield. Since td_swvoltick > records 'ticks' /before/ the actual context switch, the calculation in > should_yield()

Re: Panic in prison_alloc() on boot

On Sun, Feb 11, 2018 at 11:50:43PM -0500, Ryan Stone wrote: > I'm getting a persistent panic on boot in prison_allow(). The first > case that I hit is this: > > Fatal trap 12: page fault while in kernel mode > cpuid = 10; apic id = 22 > fault virtual address = 0x30 > fault code =

Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

On Tue, Feb 20, 2018 at 05:50:57PM +0100, Juan Ram?n Molina Menor wrote: > > I committed the fix in > > https://svnweb.freebsd.org/base?view=revision=329542 > > > > i.e. should be stable from this point on. > > Hi! > > It is maybe unrelated, but recent commits have broken my system with a >

Re: pkg does not recognize correct kernel version

On Mon, Feb 19, 2018 at 09:39:37PM +0100, Rainer Hurling wrote: > Am 19.02.2018 um 21:24 schrieb Ronald Klop: > > On Mon, 19 Feb 2018 21:10:48 +0100, Rainer Hurling wrote: > > > >> Hi Ronald, > >> > >> Am 19.02.2018 um 20:27 schrieb Ronald Klop: > >>> I just did this. > >>> >

Re: Problem with C11 _Atomic

On Tue, Jan 02, 2018 at 03:17:14PM +0100, Pierre DAVID wrote: > On Mon, Jan 01, 2018 at 11:09:07PM +0200, Konstantin Belousov wrote: > >clang issues a calls to libatomic, which we do not provide. > >As a workaround, use the following command to compile. The resulting > &g

Re: Programmatically cache line

On Mon, Jan 01, 2018 at 06:52:37AM +, David Chisnall wrote: > On 1 Jan 2018, at 05:09, Adrian Chadd <adrian.ch...@gmail.com> wrote: > > > > On 30 December 2017 at 00:28, Konstantin Belousov <kostik...@gmail.com> > > wrote: > >> On Sat, Dec 30, 2017

Re: Problem with C11 _Atomic

On Mon, Jan 01, 2018 at 09:47:40PM +0100, Pierre DAVID wrote: > Hi, > > I'm on a recent current: > FreeBSD biceps.ma.maison 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r327239: > Wed Dec 27 18:25:46 CET 2017 > p...@biceps.ma.maison:/usr/obj/usr/src/amd64.amd64/sys/BICEPS amd64 > > with clang

Re: Linux process causes kernel panic

On Fri, Aug 03, 2018 at 09:26:08PM +0100, Johannes Lundberg wrote: > Hi > > After install new kernel+world built from today's checkout I keep getting > the same crash over and over. Never had this problem before. The previous > kernel was from 3 weeks ago. > > Looks familiar to anyone? > >

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

On Sat, Aug 04, 2018 at 08:28:25PM +0100, Warner Losh wrote: > When I looked at it, I'd assumed there would be VA range we'd assign to the > PAs in the EFI table that at the loader and kernel would agree on. The DMAP > does this on x64 and aarch64, but that's not an option for armv7 nor i386. It

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

On Sat, Aug 04, 2018 at 08:05:24AM -0500, Kyle Evans wrote: > On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov > wrote: > > On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans wrote: > >> > >> This seems odd- pmap lock is acquired at [1], then asserted shortl

Re: Linux process causes kernel panic

On Sat, Aug 04, 2018 at 01:12:17PM +0100, Johannes Lundberg wrote: > No panic over night with that tunable so it seems you're on the right > track. Please try this, on top of r337316. diff --git a/sys/amd64/linux/linux_machdep.c b/sys/amd64/linux/linux_machdep.c index 6c5b014853f..434ea0eac07

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

On Sat, Aug 04, 2018 at 08:56:58AM -0500, Kyle Evans wrote: > On Sat, Aug 4, 2018 at 8:13 AM, Konstantin Belousov > wrote: > > On Sat, Aug 04, 2018 at 08:05:24AM -0500, Kyle Evans wrote: > >> On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov > >> wrote: > &

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

On Sat, Aug 04, 2018 at 09:58:43AM -0500, Kyle Evans wrote: > On Sat, Aug 4, 2018 at 9:51 AM, Ian Lepore wrote: > > On Sat, 2018-08-04 at 08:56 -0500, Kyle Evans wrote: > >> On Sat, Aug 4, 2018 at 8:13 AM, Konstantin Belousov >> com> wrote: > >> > > >

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

On Sat, Aug 04, 2018 at 09:25:47AM -0600, Ian Lepore wrote: > On Sat, 2018-08-04 at 18:22 +0300, Konstantin Belousov wrote: > > On Sat, Aug 04, 2018 at 09:58:43AM -0500, Kyle Evans wrote: > > > > > > On Sat, Aug 4, 2018 at 9:51 AM, Ian Lepore wrote: > > > &g

Re: IOMMU for GPUs

On Sun, Aug 05, 2018 at 10:34:56AM +0100, Johannes Lundberg wrote: > Hi > > First I have to say I don't know much when it comes to virtual GPUs and > IOMMU. I'm trying to figure out what we have and what is missing in regards > to sharing the GPU to virtual guests on Intel and AMD and things like

Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote: > On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov > wrote: > > On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans wrote: > >> On Fri, Aug 3, 2018 at 10:10 PM, Eitan Adler wrote: > >> > Hi al

Re: ffs_truncate3 panics

On Wed, Aug 08, 2018 at 12:30:54PM +, Rick Macklem wrote: > Konstantin Belousov wrote: > >On Tue, Aug 07, 2018 at 12:28:33PM +, Rick Macklem wrote: > >> Hi, > >> > >> During testing of the pNFS server I get an ffs_truncate3 panic every once > >

Re: ffs_truncate3 panics

On Thu, Aug 09, 2018 at 08:38:50PM +, Rick Macklem wrote: > >BTW, does NFS server use extended attributes ? What for ? Can you, please, > >point out the code which does this ? > For the pNFS service, there are two system namespace extended attributes for > each file stored on the service. >

Re: Early kernel boot log?

On Thu, Aug 09, 2018 at 08:54:31AM +0100, Johannes Lundberg wrote: > Hi > > So I believe the reason I'm not seeing and printf output in dmesg is that > it is too early in some functions. > For example > machdep.s > getmemsize() > add_efi_map_entries() > etc > > However, these functions do

Re: Early kernel boot log?

On Thu, Aug 09, 2018 at 10:26:06AM +0100, Johannes Lundberg wrote: > On Thu, Aug 9, 2018 at 9:29 AM Konstantin Belousov > wrote: > > > On Thu, Aug 09, 2018 at 08:54:31AM +0100, Johannes Lundberg wrote: > > > Hi > > > > > > So I believe the reason

Re: ffs_truncate3 panics

On Thu, Aug 09, 2018 at 01:39:20AM +, Rick Macklem wrote: > Konstantin Belousov wrote: > [stuff snipped] > >> >Can you print the only buffer on the clean queue when the panic occur ? > >> ffst3 vtyp=1 bodirty=0 boclean=1 > >> buf at 0x428a110 > >>

<    4   5   6   7   8   9   10   11   12   13   >