On Thu, Apr 25, 2024 at 07:49:23PM -0700, Rick Macklem wrote:
> Hi,
>
> This week I have been doing active testing as a part of an IETF
> bakeathon for NFSv4. During the week I had a NFSv4 client
> crash. On the surface, it is straightforward, in that it called
> ncl_doio_directwrite() and the
On Wed, Apr 24, 2024 at 01:12:39PM +0500, BSD USER wrote:
> linking kernel
> ld: error: undefined symbol: ktrcapfail
> >>> referenced by vfs_lookup.c
> >>> vfs_lookup.o:(namei)
> >>> referenced by vfs_lookup.c
> >>> vfs_lookup.o:(namei_setup)
> >>> referenced by
On Wed, Mar 27, 2024 at 03:01:11AM +0100, Bernd Walter wrote:
> Same Problem with current:
> reeBSD 15.0-CURRENT #0 main-n268793-220ee18f1964: Thu Mar 14 02:58:39 UTC 2024
>
> real memory = 1649265344512 (1572862 MB)
> avail memory = 1057118396416 (1008146 MB)
Real memory is really the max
On Wed, Mar 27, 2024 at 01:00:07PM +0100, Mateusz Guzik wrote:
> Top of main, but I reproduced it on stable/14-e64d827d3 as well.
>
> Mere "timeout 2 sleep 10" correctly times out.
>
> Running "truss -f timeout 2 sleep 10" prevents timeout from killing
> sleep and the entire thing refuses to
ccur in some dedicated context,
like per-CPU thread, instead of userret.
>
>
> R
>
>
>
> On 3/18/24 3:42 PM, Drew Gallatin wrote:
> > No. The goal is to run on every return to userspace for every thread.
> >
> > Drew
> >
> > On Mon, Mar 18
it registers the
ast to run on next return to userspace, for the current thread.
Is it enough?
>
> Drew
>
> On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote:
> > On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote:
> > > On 18 Mar 2024, at 7:04, tue...@freebs
On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote:
> On 18 Mar 2024, at 7:04, tue...@freebsd.org wrote:
>
> >> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote:
> >>
> >> Hello all!
> >>
> >> It works just fine!
> >> System performance is OK.
> >> Using patch on
On Mon, Mar 11, 2024 at 09:03:38AM +0100, Alexander Leidinger wrote:
> Am 2024-03-10 22:57, schrieb Konstantin Belousov:
>
> > We are already low on the free bits in the flags, even after expanding
> > them
> > to 64bit. More, there are useful common fs services co
On Sun, Mar 10, 2024 at 09:50:51PM +, Kirk McKusick wrote:
> > Date: Sun, 10 Mar 2024 19:21:54 +0200
> > From: Konstantin Belousov
> > To: Kirk McKusick
> > Cc: curr...@freebsd.org
> > Subject: Re: Reason why "nocache" option is not displayed in &quo
On Sat, Mar 09, 2024 at 04:59:49PM -0800, Rick Macklem wrote:
> Hi,
>
> I would like to compare va_size to va_bytes in vn_generic_copy_file_range(),
> as a heuristic to check for a sparse file (only works for non-compressed
> file systems).
>
> The call to VOP_GETATTR(invp, ..) was replaced by
On Sun, Mar 10, 2024 at 01:53:05AM +, Kirk McKusick wrote:
> The issue has to do with how flags are defined in mount.h.
> Specifically there are the flags that are externally visible
> (prefixed with MNT_) and those that are for internal use
> (prefixed with MNTK_, the K standing for KERNEL).
On Fri, Feb 23, 2024 at 08:34:21PM -0800, Gleb Smirnoff wrote:
> Hi FreeBSD/main users,
>
> the February 2024 stabilization week started with 03cc3489a02d that was tagged
> as main-stabweek-2024-Feb. At the moment of the tag creation we already knew
> about several regression caused by
On Wed, Feb 21, 2024 at 08:20:25PM +, Brooks Davis wrote:
> That's probably worth a shot. Static linking will work anyway because
> libc.a in effect embeds libsys to retain compatability.
Please do not add libsys.so to the ABI. Right now it is an implementation
detail of libthr and libc, and
On Sat, Feb 03, 2024 at 11:10:14AM -0700, Warner Losh wrote:
> On Sat, Feb 3, 2024, 11:02 AM Konstantin Belousov
> wrote:
>
> > On Sat, Feb 03, 2024 at 11:05:10AM -0500, Daniel Eischen wrote:
> > > Will this break binary compatibility with older programs expecting t
On Sat, Feb 03, 2024 at 11:05:10AM -0500, Daniel Eischen wrote:
> Will this break binary compatibility with older programs expecting those
> symbols in libc and not linked to libsys?
As was mentioned, libc filters libsys. This means that libc exports all
the same symbols as before, but forward
On Sat, Feb 03, 2024 at 12:12:35PM +0100, Mateusz Guzik wrote:
> On 2/3/24, David Chisnall wrote:
> > On 3 Feb 2024, at 09:15, Mateusz Guzik wrote:
> >>
> >> Binary startup is very slow, for example execve of a hello world
> >> binary in a Linux-based chroot on FreeBSD is faster by a factor of 2
On Fri, Feb 02, 2024 at 12:07:35PM -0800, Steve Kargl wrote:
> On Sun, Jan 28, 2024 at 12:04:48PM +0200, Konstantin Belousov wrote:
> > On Sat, Jan 27, 2024 at 09:22:59PM -0800, Steve Kargl wrote:
> > > On Sat, Jan 27, 2024 at 10:29:34PM +0100, Dimitry Andric wrote:
> > &
On Sat, Jan 27, 2024 at 09:22:59PM -0800, Steve Kargl wrote:
> On Sat, Jan 27, 2024 at 10:29:34PM +0100, Dimitry Andric wrote:
> > On 27 Jan 2024, at 18:08, Steve Kargl
> > wrote:
> > >
> > > In an attempt to cleanup a bit of src/lib/msun, I ran into
> > > a small issue that I cannot explain at
On Fri, Dec 29, 2023 at 01:50:34PM +0100, Dimitry Andric wrote:
> The problem is really that our kernel headers (those under sys/) require C99.
> The only thing that
> https://cgit.freebsd.org/src/commit/?id=a8b70cf26030d68631200619bd1b0ad35b34b6b8
> did was move two static inline functions
On Fri, Dec 22, 2023 at 11:18:23PM -0800, Xin Li wrote:
> Hi,
>
> Inspired by D42961, I propose that we move forward with disabling the
> compression by default in newsyslog, as implemented in
> https://reviews.freebsd.org/D43169
>
> Historically, newsyslog has compressed rotated log files to
On Fri, Dec 22, 2023 at 02:03:56PM -0700, Warner Losh wrote:
> Yes. I'd prefer to make this more parameterized, maybe with sanity checks.
>
> That is, there'd be a tool that would do the right thing, based on what you
> tell it to do. we'd set the defaults to be a default install. If you want
>
On Fri, Dec 22, 2023 at 11:36:24AM +0200, Toomas Soome wrote:
>
>
> > On 22. Dec 2023, at 11:09, Mark Millard wrote:
> >
> > Tomoaki AOKI wrote on
> > Date: Thu, 21 Dec 2023 23:21:00 UTC :
> >
> >> On Thu, 21 Dec 2023 14:22:14 +0100
> >> Dimitry Andric wrote:
> >>
> >>> Yeah, my procedure
On Tue, Nov 14, 2023 at 01:30:25PM -0800, Rick Macklem wrote:
> On Tue, Nov 14, 2023 at 1:20 PM Konstantin Belousov
> wrote:
> >
> > On Tue, Nov 14, 2023 at 06:47:46PM +0100, Mateusz Guzik wrote:
> > > On 11/14/23, Alexander Motin wrote:
> > > > O
On Tue, Nov 14, 2023 at 07:51:39PM +0100, Mateusz Guzik wrote:
> On 11/14/23, Alexander Motin wrote:
> > On 14.11.2023 12:44, Alexander Motin wrote:
> >> On 14.11.2023 12:39, Mateusz Guzik wrote:
> >>> One of the vnodes is probably not zfs, I suspect this will do it
> >>> (untested):
> >>>
> >>>
On Tue, Nov 14, 2023 at 06:47:46PM +0100, Mateusz Guzik wrote:
> On 11/14/23, Alexander Motin wrote:
> > On 14.11.2023 12:39, Mateusz Guzik wrote:
> >> One of the vnodes is probably not zfs, I suspect this will do it
> >> (untested):
> >>
> >> diff --git
On Sun, Nov 12, 2023 at 11:51:40AM -0500, Alexander Motin wrote:
> Hi Ronald,
>
> As I can see, the clone request to ZFS came through nullfs, and it crashed
> immediately on enter. I've never been a VFS layer expert, but to me it may
> be a nullfs problem, not zfs. Is there chance you was
On Wed, Oct 25, 2023 at 07:58:41AM +, Marcin Cieslak wrote:
> Hello,
>
> is there any documentation for cdevsw methods?
> I am interested in knowing how d_map_single should
> be written.
>
> Most specifically, I want to know if the driver
> has a chance to track mmaped allocations on its own
On Mon, Sep 18, 2023 at 01:27:55PM -0500, Mike Karels wrote:
> On 18 Sep 2023, at 10:38, Michael Butler wrote:
>
> > On 8/8/23 13:50, Michael Butler wrote:
> >> On 8/8/23 10:56, Tomoaki AOKI wrote:
> >>> On Tue, 8 Aug 2023 17:02:32 +0300
> >>> Kons
On Mon, Aug 21, 2023 at 08:19:28AM +0200, Alexander Leidinger wrote:
> Am 2023-08-20 23:17, schrieb Konstantin Belousov:
> > On Sun, Aug 20, 2023 at 11:07:08PM +0200, Mateusz Guzik wrote:
> > > On 8/20/23, Alexander Leidinger wrote:
> > > > Am 2023-08-2
On Sun, Aug 20, 2023 at 11:07:08PM +0200, Mateusz Guzik wrote:
> On 8/20/23, Alexander Leidinger wrote:
> > Am 2023-08-20 22:02, schrieb Mateusz Guzik:
> >> On 8/20/23, Alexander Leidinger wrote:
> >>> Am 2023-08-20 19:10, schrieb Mateusz Guzik:
> On 8/18/23, Alexander Leidinger wrote:
>
On Tue, Aug 08, 2023 at 10:46:12PM +0900, Tomoaki AOKI wrote:
> On Tue, 8 Aug 2023 15:38:46 +0300
> Konstantin Belousov wrote:
>
> > On Tue, Aug 08, 2023 at 06:37:35AM +0900, Tomoaki AOKI wrote:
> > > On Sun, 6 Aug 2023 12:55:07 +0300
> > > Konstantin Belousov
On Tue, Aug 08, 2023 at 06:37:35AM +0900, Tomoaki AOKI wrote:
> On Sun, 6 Aug 2023 12:55:07 +0300
> Konstantin Belousov wrote:
>
> > On Sun, Aug 06, 2023 at 06:12:38PM +0900, Tomoaki AOKI wrote:
> > > On Wed, 23 Feb 2022 01:30:28 +0200
> > > Konstantin Belousov
On Sun, Aug 06, 2023 at 06:12:38PM +0900, Tomoaki AOKI wrote:
> On Wed, 23 Feb 2022 01:30:28 +0200
> Konstantin Belousov wrote:
>
> > On Tue, Feb 22, 2022 at 06:23:17PM -0500, Alexander Motin wrote:
> > > On 22.02.2022 17:46, Konstantin Belousov wrote:
> > > >
On Tue, Aug 01, 2023 at 04:33:16PM -0700, Rick Macklem wrote:
> On Mon, Jul 31, 2023 at 11:33 PM David Chisnall wrote:
> >
> > Hi,
> >
> > This bit of the C spec is a bit of a mess. There was, I believe, a desire
> > to return volatile to its original use and make any use of volatile other
> >
On Mon, Jul 10, 2023 at 09:39:35AM +, John F Carr wrote:
>
>
> > On Jul 9, 2023, at 19:59, Konstantin Belousov wrote:
> >
> > On Sun, Jul 09, 2023 at 11:36:03PM +, John F Carr wrote:
> >>
> >>
> >>> On Jul 9, 2023, at 19:25, K
On Sun, Jul 09, 2023 at 11:36:03PM +, John F Carr wrote:
>
>
> > On Jul 9, 2023, at 19:25, Konstantin Belousov wrote:
> >
> > On Sun, Jul 09, 2023 at 10:41:27PM +, John F Carr wrote:
> >> Kernel and system at a146207d66f320ed239c1059de9df854b66b55b7
On Sun, Jul 09, 2023 at 10:41:27PM +, John F Carr wrote:
> Kernel and system at a146207d66f320ed239c1059de9df854b66b55b7 plus some
> irrelevant local changes, four 64 bit ARM processors, make.conf sets
> CPUTYPE?=cortex-a57.
>
> I typed ^C while /bin/sh was starting a pipeline and my shell
On Sat, May 20, 2023 at 11:38:14AM -0700, Rick Macklem wrote:
> Hi,
>
> So I did an MFC that broke the stable/13 build (it's reverted now).
> I didn't realize that changes inside _KERNEL in mount.h would do
> this, but now I know.
>
> Since it is only an issue for stable/13 (and not main), I'd
On Wed, Apr 26, 2023 at 01:38:32PM +0200, Hans Petter Selasky wrote:
> On 4/26/23 13:12, Konstantin Belousov wrote:
> > No, in-kernel linker does not behave this way.
> > Modules need to contain explicit reference to all modules they depend upon,
> > using the MODULE_DEPEND()
On Wed, Apr 26, 2023 at 12:55:02PM +0200, Hans Petter Selasky wrote:
> On 4/26/23 12:36, Zhenlei Huang wrote:
> > Hi,
> >
> > I'm recently working on https://reviews.freebsd.org/D39638 (sysctl(9):
> > Enable vnet sysctl variables be loader tunable),
> > the changes to `sys/kern/link_elf_obj.c`
On Fri, Mar 31, 2023 at 01:27:54PM -0400, Ed Maste wrote:
> On Fri, 31 Mar 2023 at 12:38, Charlie Li wrote:
> >
> > Konstantin Belousov wrote:
> > > The branch main has been updated by kib:
> > >
> > > URL:
> > > https://cgit.FreeBSD.org/src/
On Mon, Feb 06, 2023 at 06:59:59PM -0700, Alan Somers wrote:
> On Mon, Feb 6, 2023 at 6:23 PM Rick Macklem wrote:
> >
> > PR#269328 reports an issue related to fspacectl() being
> > mixed with mmap'd I/O.
> >
> > When working on a fix for this for the NFS client, I realized that
> > "man
On Tue, Jan 03, 2023 at 11:38:55AM +0100, Floyd, Paul wrote:
>
> On 30/12/2022 01:54, Konstantin Belousov wrote:
> >
> > The backtrace is needed to make a further analysis.
>
>
> Any suggestions for getting a backtrace? I get the panic booting either the
> insta
On Tue, Jan 03, 2023 at 08:20:16AM +, Chen, Alvin W wrote:
> >
> > [EXTERNAL EMAIL]
> >
> > On 2022-11-14 09:09 +0200, Konstantin Belousov wrote:
> > >
> > > You might use this patch meantime
> > > https://urldefense.com/v3/__https://k
On Thu, Dec 29, 2022 at 09:39:44AM +0100, Paul Floyd wrote:
>
>
> On 28-12-22 18:12, Ronald Klop wrote:
>
> >
> > I've had success to capture errors by recording the screen with my phone
> > and playing back on slow speed.
> > Another option might be to enable serial port for the console of
On Fri, Dec 23, 2022 at 03:47:33PM -0800, Mark Millard wrote:
> Jonathan Chen wrote on
> Date: Fri, 23 Dec 2022 18:40:27 UTC :
>
> > On 24/12/22 07:14, Mark Millard wrote:
> > > Jonathan Chen wrote on
> > > Date: Thu, 22 Dec 2022 19:21:37 UTC :
> > >
> > >> I recently updated my package
der Lake/Raptor Lake)
> > support
> >
> >
> > [EXTERNAL EMAIL]
> >
> > On 2022-11-14 09:09 +0200, Konstantin Belousov wrote:
> > >
> > > You might use this patch meantime
> > > https://urldefense.com/v3/__https://kib.kiev.ua/git/gitw
On Mon, Nov 14, 2022 at 06:50:20AM +, Chen, Alvin W wrote:
>
>
> Internal Use - Confidential
>
>
> > -Original Message-
> > From: Mike Karels
> > Sent: 2022年10月27日 23:17
> > To: Chen, Alvin W
> > Cc: freebsd-current
> > Subject: Re: Status of Intel Hybrid CPU support (Alder
On Tue, Sep 06, 2022 at 10:36:52AM -0600, Alan Somers wrote:
> On Tue, Sep 6, 2022 at 9:07 AM Warner Losh wrote:
> >
> >
> >
> > On Tue, Sep 6, 2022 at 7:34 AM Konstantin Belousov
> > wrote:
> >>
> >> On Mon, Sep 05, 2022 at 08:41:58AM -0600,
On Mon, Sep 05, 2022 at 08:41:58AM -0600, Alan Somers wrote:
> On Sat, Sep 3, 2022 at 11:10 PM Konstantin Belousov
> wrote:
> >
> > On Sat, Sep 03, 2022 at 10:19:12AM -0600, Alan Somers wrote:
> > > Our /usr/include headers define a lot of symbols that are used
On Sat, Sep 03, 2022 at 10:19:12AM -0600, Alan Somers wrote:
> Our /usr/include headers define a lot of symbols that are used by
> critical utilities in the base system like ps and ifconfig, but aren't
> stable across major releases. Since they aren't stable, utilities
> built for older releases
On Fri, Sep 02, 2022 at 04:11:40PM +0200, Mateusz Guzik wrote:
> On 9/2/22, Konstantin Belousov wrote:
> > On Fri, Sep 02, 2022 at 02:05:37PM +0200, Mateusz Guzik wrote:
> >> Is this really of practical use today?
> >>
> >> I have a WIP patch which
On Fri, Sep 02, 2022 at 02:05:37PM +0200, Mateusz Guzik wrote:
> Is this really of practical use today?
>
> I have a WIP patch which needs to temporarily store something on the
> stack and should things go wrong enough it will be accessed by UMA,
> which can't handle the fault nor decide to skip
On Mon, Aug 22, 2022 at 02:56:47PM +, Bjoern A. Zeeb wrote:
> Hi,
>
> I am trying to get some arm64 up and running a bit but cannot use
> loader. I have an MD_ROOT embedded in the kernel with /rescue on it.
> I set INIT_PATH=/rescue/sh .
>
> However that doesn't seem to work:
>
>
On Fri, May 13, 2022 at 01:16:39PM +0200, obiwac wrote:
> Wassup,
>
> This may not be strictly speaking a bug with rtld, but it sure is
> weird/awkward behaviour considering the existing information I could
> gather.
>
> In an unversioned shared object which references a symbol which has
>
On Wed, Feb 23, 2022 at 12:25:24PM -0500, Alexander Motin wrote:
> On 22.02.2022 19:00, Konstantin Belousov wrote:
> > On Tue, Feb 22, 2022 at 06:53:09PM -0500, Alexander Motin wrote:
> > > On 22.02.2022 18:41, Konstantin Belousov wrote:
> > > > On Tue, Feb 22, 2022
On Tue, Feb 22, 2022 at 06:23:17PM -0500, Alexander Motin wrote:
> On 22.02.2022 17:46, Konstantin Belousov wrote:
> > Ok, the next step is to get the CPU feature reports from P- vs. E- cores.
> > Patch below should work, with verbose boot.
>
> Not much difference on that
On Sat, Feb 19, 2022 at 07:26:24PM -0500, Alexander Motin wrote:
> On 19.02.2022 13:23, Konstantin Belousov wrote:
> > On Sat, Feb 19, 2022 at 12:14:16PM -0500, Alexander Motin wrote:
> > > On 19.02.2022 12:02, Mike Karels wrote:
> > > > On 18 Feb 2022, at 20:55, Tomo
On Sat, Feb 19, 2022 at 12:14:16PM -0500, Alexander Motin wrote:
> On 19.02.2022 12:02, Mike Karels wrote:
> > On 18 Feb 2022, at 20:55, Tomoaki AOKI wrote:
> > > Just a thought, but can it be the reason with timing (e.g., rendezvous
> > > within (i)threads, hardware controlls without using
On Thu, Feb 03, 2022 at 11:52:48AM +0100, Jesper Schmitz Mouridsen wrote:
> Hi
> d950c5898a2d8733cd6e75e7ef82b08acac79b34 breaks arm64 with options IOMMU.
Which kernel config is it? Or is it your custom config?
If the later, please provide it to me.
>
> grep -nir vm_page.h
On Tue, Jan 04, 2022 at 09:07:47AM +0900, Tomoaki AOKI wrote:
> I myself never used NFS, but I don't think it a POLA violation,
> because...
> *Keeping latest-stable (formerly, v3?) to oldest (v2) order.
>
> *Usually, once new version is considered stable, security fixes
>are first done
On Thu, Dec 30, 2021 at 08:33:09PM +0100, tue...@freebsd.org wrote:
> > On 30. Dec 2021, at 20:26, Michael Gmelin wrote:
> >
> > This should have been resolved today in
> > https://cgit.freebsd.org/src/commit/?id=5e6a2d6eb220d780c9128c81b58f133114061415
> I do have that commit locally in the
On Mon, Dec 27, 2021 at 10:58:02AM -0800, Gleb Smirnoff wrote:
> On Mon, Dec 27, 2021 at 01:43:01PM -0500, Alexander Motin wrote:
> A> > This allows us to deduct that the callout belongs to proc subsystem and
> A> > we can retrieve the proc it points to: c_lock - 0x128 =
> 0xf8030521e548
> A>
On Mon, Dec 13, 2021 at 04:26:42PM +, Rick Macklem wrote:
> Hi,
>
> There are two problems with Allocate in the NFSv4.2 server in FreeBSD13:
> 1 - It uses the thread credentials instead of the ones for the RPC.
> 2 - It does not ensure that file changes are committed to stable storage.
>
On Thu, Nov 25, 2021 at 06:34:19AM +0100, Kurt Jaeger wrote:
> Hi!
>
> > I have mostly finished implementation of "proper" vdso for amd64
> > native binaries, both 64bit and 32bit. Vdso wraps signal trampolines
> > into real dynamic shared object, which is prelinked into dynamically
> > linked
s (it can do system calls and it can restore the
> entire register state from the contents of an on-stack buffer if you can
> jump into it).
Not now. Randomizing shared page location is not too hard, but there are
some ABI issues to sort out. We live with fixed-mapped shared page for
more tha
I have mostly finished implementation of "proper" vdso for amd64
native binaries, both 64bit and 32bit. Vdso wraps signal trampolines
into real dynamic shared object, which is prelinked into dynamically
linked image.
The main (and in fact, now the only) reason for wrapping trampolines
into vdso
On Sat, Nov 13, 2021 at 09:54:47AM +0100, Gerald Pfeifer wrote:
> On Sat, 13 Nov 2021, Konstantin Belousov wrote:
> >> --
> >> commit 160b4b922b6
> >> Author: Konstantin Belousov
> &g
_UNSAFE=yes and rebuild before reporting the failure to
> the maintainer.
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/lang/gcc11
> --
>
> Full build logs:
> https://www.utahime.org/FreeBS
On Wed, Nov 10, 2021 at 03:45:06PM +0200, Andriy Gapon wrote:
> On 10/11/2021 11:30, Andriy Gapon wrote:
> > On 09/11/2021 17:56, Andriy Gapon wrote:
> > > So, as I was saying, when the delta is large the calculations in
> > > tc_windup and bintime_off give slightly different results and that
> >
On Tue, Nov 09, 2021 at 11:58:30AM +0200, Andriy Gapon wrote:
>
> Two years have passed since my original report, some things have changed,
> but we are still seeing the problem.
>
> To recap, the problem is that sometimes a callout for a sleepq timeout would
> fire to early. The code in
On Fri, Nov 05, 2021 at 06:27:33PM +0100, obiwac wrote:
> Let me preface this by saying that I am in no way knowledgeable enough
> regarding the FreeBSD dynamic linker to know whether or not this is
> infact a bug or intended behaviour.
>
> This program I'm working on, when compiled for FreeBSD,
; /usr/src/sys/amd64/amd64/trap.c:1191
> #17
> #18 0x00080315a71a in ?? ()
> Backtrace stopped: Cannot access memory at address 0x7fffc778
> (kgdb)
>
Try this
commit 2d3f95bd1fd4f71769f60b8037c1ff27c75d8258
Author: Konstantin Belousov
Date: Wed Nov 3 17:11:33 2021 +0200
proc_get_binpath(): return empty
On Fri, Oct 22, 2021 at 01:07:47AM -0700, Julian Elischer wrote:
> Several years ago (OK, maybe 12 years ago) I did an experiment where I
> unpacked a
> freebsd 1.1 (or maybe 2.0?) image into a subdirectory, and after installing
> various
> compat packagesand options and a.out support and changing
On Fri, Oct 15, 2021 at 10:20:55PM +0200, Jan Beich wrote:
> FreeBSD User writes:
>
> > After updating 13-STABLE to 13.0-STABLE #3 stable/13-n247671-70db230dcbd:
> > Thu Oct 14
> > 20:48:53 CEST 2021 amd64 on a Lenovo E540 notebook with Intel iGPU and also
> > updating port
> >
On Sat, Oct 09, 2021 at 05:29:39PM -0600, Warner Losh wrote:
> On Sat, Oct 9, 2021, 5:15 PM Konstantin Belousov
> wrote:
>
> > On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote:
> > > On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric wrote:
> > >
> &
On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote:
> On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric wrote:
>
> > On 9 Oct 2021, at 15:40, Warner Losh wrote:
> > >
> > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric wrote:
> > > On 9 Oct 2021, at 13:37, Dimitry Andric wrote:
> > > >
>
On Fri, Oct 08, 2021 at 03:36:18PM -0400, Michael Butler wrote:
> On 10/7/21 20:19, Konstantin Belousov wrote:
> > On Thu, Oct 07, 2021 at 05:43:14PM -0400, Michael Butler wrote:
> > > On 10/7/21 16:52, Mark Johnston wrote:
> > > > On Thu, Oct 07, 2021 at 04:18:
On Thu, Oct 07, 2021 at 05:43:14PM -0400, Michael Butler wrote:
> On 10/7/21 16:52, Mark Johnston wrote:
> > On Thu, Oct 07, 2021 at 04:18:28PM -0400, Michael Butler via
> > freebsd-current wrote:
> > > On 10/7/21 15:39, Konstantin Belousov wrote:
> > > > On T
On Thu, Oct 07, 2021 at 04:52:52PM -0400, Mark Johnston wrote:
> On Thu, Oct 07, 2021 at 04:18:28PM -0400, Michael Butler via freebsd-current
> wrote:
> > On 10/7/21 15:39, Konstantin Belousov wrote:
> > > On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via
> &
On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via freebsd-current
wrote:
> While building a local release bundle, I sometimes get bsdtar failing (and
> dumping core) as follows below. Worse, as can be seen below, it doesn't stop
> the build unless I happen to notice and it yields an
On Sun, Sep 26, 2021 at 10:23:47AM +0900, Tomoaki AOKI wrote:
> On Sat, 25 Sep 2021 23:46:48 +0300
> Andriy Gapon wrote:
>
> > On 25/09/2021 19:10, Johan Hendriks wrote:
> > > For me i had kern.sched.steal_thresh=1 in my sysctl as i use this machine
> > > mainly
> > > for tests and so on.
> >
On Sat, Sep 25, 2021 at 11:00:50AM +0900, Tomoaki AOKI wrote:
> On Fri, 24 Sep 2021 01:33:33 +0300
> Konstantin Belousov wrote:
>
> > On Thu, Sep 23, 2021 at 09:20:51PM +0200, Johan Hendriks wrote:
> > >
> > > On 23/09/2021 19:52, Konstantin Belousov wrote:
>
On Thu, Sep 23, 2021 at 09:20:51PM +0200, Johan Hendriks wrote:
>
> On 23/09/2021 19:52, Konstantin Belousov wrote:
> > On Fri, Sep 24, 2021 at 12:43:01AM +0900, Tomoaki AOKI wrote:
> > > On Wed, 22 Sep 2021 23:09:05 +0900
> > > Tomoaki AOKI wrote:
> > >
On Fri, Sep 24, 2021 at 12:43:01AM +0900, Tomoaki AOKI wrote:
> On Wed, 22 Sep 2021 23:09:05 +0900
> Tomoaki AOKI wrote:
>
> > On Wed, 22 Sep 2021 05:47:46 -0700
> > David Wolfskill wrote:
> >
> > > On Wed, Sep 22, 2021 at 02:39:37PM +0200, Johan Hendriks wrote:
> > > > I did a git pull this
On Wed, Sep 22, 2021 at 06:27:09AM +0200, Damjan Jovanovic wrote:
> On Wed, Sep 22, 2021 at 6:08 AM Alan Somers wrote:
>
> > tldr; should the Rust ecosystem ditch FreeBSD 10 compat for new code?
> >
> > Rust uses FFI to talk to the OS's C library. That makes cross-compiling a
> > breeze.
On Wed, Sep 22, 2021 at 02:39:37PM +0200, Johan Hendriks wrote:
> I did a git pull this morning and it fails to boot.
> I hangs at Setting hostid : 0x917bf354
>
> This is a vm running on vmware.
> If i boot the old kernel from yesterday it boots normally.
>
> uname -a
> FreeBSD
On Tue, Sep 14, 2021 at 12:25:55AM +0200, Guido Falsi wrote:
> On 14/09/21 00:12, Konstantin Belousov wrote:
> > On Mon, Sep 13, 2021 at 10:07:46PM +0200, Guido Falsi wrote:
> > > On 13/09/21 19:08, Konstantin Belousov wrote:
> > > > On Mon, Sep 13, 2021 at 02:
On Mon, Sep 13, 2021 at 10:07:46PM +0200, Guido Falsi wrote:
> On 13/09/21 19:08, Konstantin Belousov wrote:
> > On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via freebsd-current
> > wrote:
> > > Hi,
> > >
> > > I updated head recently an
On Mon, Sep 13, 2021 at 02:59:25PM +0200, Guido Falsi via freebsd-current wrote:
> Hi,
>
> I updated head recently and today I noticed a difference which looks wrong.
>
> At boodt the new head shows signifcantly less avail memory than before,
> around 3 GiB less.
>
> I moved from commit
On Mon, Sep 06, 2021 at 04:01:37PM +0200, Steffen Nurpmeso wrote:
> Eric McCorkle wrote in
> :
> |Interesting, I wasn't aware of the upstream module. I'd say that's
>
> It's existence was the reason i have readded (now optional, and
> a tad different) session support for my pam_xdg PAM module,
On Tue, Aug 31, 2021 at 01:29:27AM -0500, Dustin Marquess wrote:
> On Mon, Aug 30, 2021 at 4:33 AM Konstantin Belousov wrote:
>
> > On Sun, Aug 29, 2021 at 08:27:02PM -0500, Dustin Marquess wrote:
> > > I am upgrading a -CURRENT box from a build that's exactly 2 weeks old
On Mon, Aug 30, 2021 at 11:48:56AM +0100, Graham Perrin wrote:
> On 30/08/2021 10:33, Konstantin Belousov wrote:
> > Try to add
> > exec="copy_staging enable"
> > line to it, does it hide the problem?
>
> When I last tested (19th August), I got the impres
On Sun, Aug 29, 2021 at 08:27:02PM -0500, Dustin Marquess wrote:
> I am upgrading a -CURRENT box from a build that's exactly 2 weeks old to
> one I built about 2 hours ago. After installkernel I updated the bootloader
> the same way I normally do:
>
> # mount_msdosfs /dev/da8p1 /mnt
> # cp
On Fri, Aug 27, 2021 at 03:41:30PM +0200, Tijl Coosemans wrote:
> Hi,
>
> I use devel/llvm* to build base and just switched to llvm12. It seems
> that on i386 clang12 uses R_386_PLT32 relocations for some calls to at
> least memset, memcpy and __stack_chk_fail (clang11 uses R_386_PC32).
> These
On Sun, Aug 01, 2021 at 10:32:10AM -0700, David Wolfskill wrote:
> On Sun, Aug 01, 2021 at 05:03:32PM +0300, Konstantin Belousov wrote:
> > On Sun, Aug 01, 2021 at 06:01:56AM -0700, David Wolfskill wrote:
> > > Once I was able to complete the "make installworld" af
On Sun, Aug 01, 2021 at 06:01:56AM -0700, David Wolfskill wrote:
> Once I was able to complete the "make installworld" after updating
> from main-n248391-f7f76c200a8c to main-n248404-60fb9e10c74c, the
> subsequent reboot yielded a panic with the keyboard inoperable.
>
> I needed to power-cycle
On Fri, May 28, 2021 at 01:11:06PM +0200, Jakob Alvermark wrote:
> Hi,
>
>
> Building -current fails like this:
>
> --- kerberos5/lib/libasn1__L ---
> Building
> /usr/obj/usr/src/amd64.amd64/kerberos5/lib/libasn1/asn1_kx509_asn1.x
> Building
>
On Mon, Apr 19, 2021 at 10:06:28AM +0100, Alexander Richardson wrote:
> On Sun, 18 Apr 2021 at 20:58, Александр Недоцуков wrote:
> >
> > Hi All,
> >
> > After supposed locking fixes done in this commit:
> > 5245bf7b92b74e556527b4916a8deba386fe5772
> > we have a broken nsdispatch(3) when system
On Sun, Apr 04, 2021 at 07:01:44PM +, Poul-Henning Kamp wrote:
>
> Konstantin Belousov writes:
>
> > But what would you provide as the input for PID controller, and what would
> > be the targets?
>
> Viewing this purely as a vnode related issue is
1 - 100 of 1225 matches
Mail list logo
