Re: main cadd2ca217 doesn't boot

2024-05-25 Thread Ryan Libby
On Sat, May 25, 2024 at 5:47 PM Tomoaki AOKI wrote: > > On Sun, 26 May 2024 00:21:31 +0100 > Nuno Teixeira wrote: > > > Hello, > > > > Just upgraded to latest main at cadd2ca217 > > > > Boot menu shows up and then it stops earlier around: > > .. > > FreeBSD clang version ... > > > > No crash

Re: panic: lock "tmpfsni" 0xfffff80721307090 already initialized

2024-05-25 Thread Ryan Libby
On Sat, May 25, 2024 at 1:32 AM Alexander Leidinger wrote: > > Hi, > > [123095] panic: lock "tmpfsni" 0xf80721307090 already initialized > [123095] cpuid = 8 > [123095] time = 1716597585 > [123095] KDB: stack backtrace: > [123095] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >

Re: Panic: lock "lnxspin" 0xfffff800176c0730 already initialized

2024-05-16 Thread Ryan Libby
On Thu, May 16, 2024 at 9:56 PM Emmanuel Vadot wrote: > > On Thu, 16 May 2024 10:27:40 -0700 > Ryan Libby wrote: > > > On Thu, May 16, 2024 at 6:00?AM David Wolfskill > > wrote: > > > > > > This is running main-n270174-abb1a1340e3f (built in-

Re: Panic: lock "lnxspin" 0xfffff800176c0730 already initialized

2024-05-16 Thread Ryan Libby
On Thu, May 16, 2024 at 6:00 AM David Wolfskill wrote: > > This is running main-n270174-abb1a1340e3f (built in-place from > main-n270163-154ad8e0f88f), with ports at main-n663685-3f732745ab06; > the ports-resident kernel modules were rebuilt with the kernel, > courtesy (e.g.): > >

Re: Graph of the FreeBSD memory fragmentation

2024-05-14 Thread Ryan Libby
On Tue, May 14, 2024 at 9:09 AM Ryan Libby wrote: > > On Tue, May 14, 2024 at 1:14 AM Alexander Leidinger > wrote: > > > > Am 2024-05-14 03:54, schrieb Ryan Libby: > > > That was a long winded way of saying: the "UMA bucket" axis is > > > actually

Re: Graph of the FreeBSD memory fragmentation

2024-05-14 Thread Ryan Libby
On Tue, May 14, 2024 at 1:14 AM Alexander Leidinger wrote: > > Am 2024-05-14 03:54, schrieb Ryan Libby: > > That was a long winded way of saying: the "UMA bucket" axis is > > actually "vm phys free list order". > > > > That said, I find that di

Re: Graph of the FreeBSD memory fragmentation

2024-05-13 Thread Ryan Libby
On Thu, May 9, 2024 at 2:36 AM Alexander Leidinger wrote: > > Am 2024-05-08 18:45, schrieb Bojan Novković: > > Hi, > > > > On 5/7/24 14:02, Alexander Leidinger wrote: > > > >> Hi, > >> > >> I created some graphs of the memory fragmentation. > >>

Re: git non-time-sequential logs

2021-01-04 Thread Ryan Libby
On Mon, Jan 4, 2021 at 11:00 AM Franco Fichtner wrote: > > > > On 4. Jan 2021, at 7:52 PM, Enji Cooper wrote: > > > > The point is to stop looking at git like svn: commits should be done as > > larger bodies of work (merge commits), as opposed to single atomic commits. > > Er, uh, no. ;) > >

Re: git non-time-sequential logs

2021-01-04 Thread Ryan Libby
On Mon, Jan 4, 2021 at 10:08 AM Warner Losh wrote: ... > As for date order, we could also add a commit hook that requires the date > to be properly set, but that creates friction for developers. Is that > friction worth the benefits? I don't think so, but as you say we could also > add notes...

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

2020-06-30 Thread Ryan Libby
much benefit we would see from option 3, but it's more work. Ryan > > > From: owner-freebsd-curr...@freebsd.org > on behalf of Rick Macklem > Sent: Thursday, June 18, 2020 11:42 PM > To: Ryan Libby > Cc: Konstantin Belousov; Jeff Roberso

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

2020-06-15 Thread Ryan Libby
but it is a screen console, so I need to > transcribe the output to email by hand. (ie. If you need something > specific I can do that, but trying to do everything Kostik and Ryan asked > for isn't easy.) > > rick > > > > Konstantin Belousov wrote: > >On Fri, May 22,

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

2020-05-21 Thread Ryan Libby
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 over NFS using my not so big Pentium 4 (single core, > 1.25Gbytes RAM, i386),

Re: -CURRENT fatal trap cause by cxgbe module

2020-03-02 Thread Ryan Libby
On Sun, Mar 1, 2020 at 8:07 PM Dustin Marquess wrote: > > So I've been fighting with any current from the last month or so > instantly crashing when I boot it. I did notice that kernels in the > various snapshot images were working, however, so I was trying to > figure out why. At first I

Re: Panic with latest CURRENT amd64 as Virtualbox guest

2020-01-23 Thread Ryan Libby
On Thu, Jan 23, 2020 at 12:25 AM Rares Aioanei wrote: > > My bad, here's the link : https://imgur.com/45He1iy > > On Wed, Jan 22, 2020 at 8:04 PM Johan Hendriks wrote: > > > > These is no file attached. I think the mailing list stripped it off. > > But i had an kernel panic also with Freebsd

Re: New external GCC toolchain ports/packages

2019-12-20 Thread Ryan Libby
On Fri, Dec 20, 2019 at 10:15 AM Konstantin Belousov wrote: > > 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

Re: New external GCC toolchain ports/packages

2019-12-20 Thread Ryan Libby
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 Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote: > > >> > > >> In the

Re: New external GCC toolchain ports/packages

2019-12-19 Thread Ryan Libby
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 from -gcc > to -gcc6. These are built as flavors of a new devel/freebsd-gcc6 > port. The xtoolchain package is not

Re: SVN r355148/9 breaks build

2019-11-27 Thread Ryan Libby
On Wed, Nov 27, 2019 at 7:23 PM Ryan Libby wrote: > > On Wed, Nov 27, 2019 at 6:44 PM Michael Butler > wrote: > > > > Something missing from a header here? > > > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/uma_core.o > > --- uma_core.o --- > > /

Re: SVN r355148/9 breaks build

2019-11-27 Thread Ryan Libby
On Wed, Nov 27, 2019 at 6:44 PM Michael Butler wrote: > > Something missing from a header here? > > Building /usr/obj/usr/src/amd64.amd64/sys/VM01/uma_core.o > --- uma_core.o --- > /usr/src/sys/vm/uma_core.c:1864:39: error: use of undeclared identifier > 'sysctl___vm_uma' > zone->uz_oid =

Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)

2018-06-29 Thread Ryan Libby
[Re-sending from my subscription address, sorry for the spam] On Fri, Jun 29, 2018 at 1:26 PM, John Baldwin wrote: > On 6/28/18 7:54 PM, Mark Millard wrote: >> On 2018-Jun-28, at 6:04 PM, Mark Millard wrote: >> >>> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote: >>> [ ci.free.bsd.org

Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)

2018-06-29 Thread Ryan Libby
On Fri, Jun 29, 2018 at 1:26 PM, John Baldwin wrote: > On 6/28/18 7:54 PM, Mark Millard wrote: >> On 2018-Jun-28, at 6:04 PM, Mark Millard wrote: >> >>> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote: >>> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed) for

Re: Compiling the kernel using GCC

2017-08-26 Thread Ryan Libby
On Sat, Aug 26, 2017 at 2:41 AM, Aijaz Baig wrote: > Has anyone been able to successfully compile the kernel using GCC as > against CLANG the default compiler on most later versions of FreeBSD? I was > able to successfully buildworld. After which I reboot and now /usr/bin/cc

Re: [322369] buildkernel failure: error: use of undeclared identifier 'mp_ncpus'

2017-08-10 Thread Ryan Libby
On Thu, Aug 10, 2017 at 9:51 AM, O. Hartmann wrote: > r322369 fails to build a kernel due to: > > > --- mptable.o --- > /usr/src/sys/x86/x86/mptable.c:480:39: error: use of undeclared identifier > 'mp_ncpus' > proc->apic_id < MAX_LAPIC_ID && mp_ncpus <