Re: svn commit: r367842 - head/sys/kern
This causes a panic on PowerPC64:
panic: mtx_lock() by idle thread 0xc00806437100 on sleep mutex
kernelpmap @ /usr/home/luporl/git/master/sys/powerpc/aim/mmu_oea64.c:2237
cpuid = 31
time = 1605806644
KDB: stack backtrace:
0xc008014d91e0: at kdb_backtrace+0x60
0xc008014d92f0: at vpanic+0x1e0
0xc008014d93a0: at panic+0x40
0xc008014d93d0: at __mtx_lock_flags+0x23c
0xc008014d9480: at moea64_kextract+0x68
0xc008014d9560: at thread_stash+0x48
0xc008014d95a0: at mi_switch+0x1fc
0xc008014d9620: at critical_exit_preempt+0x88
0xc008014d9650: at cpu_idle+0xd4
0xc008014d96c0: at sched_idletd+0x440
0xc008014d9820: at fork_exit+0xc4
0xc008014d98c0: at fork_trampoline+0x18
0xc008014d98f0: at cpu_reset_handler+0x64
It seems the problem is the vtophys() call in thread_zombie(), as PPC64's
pmap_kextract() will try to acquire a pmap lock for addresses out of DMAP
range.
On Thu, Nov 19, 2020 at 7:01 AM Mateusz Guzik wrote:
> Author: mjg
> Date: Thu Nov 19 10:00:48 2020
> New Revision: 367842
> URL: https://svnweb.freebsd.org/changeset/base/367842
>
> Log:
> thread: numa-aware zombie reaping
>
> The current global list is a significant problem, in particular induces
> a lot
> of cross-domain thread frees. When running poudriere on a 2 domain box
> about
> half of all frees were of that nature.
>
> Patch below introduces per-domain thread data containing zombie lists and
> domain-aware reaping. By default it only reaps from the current domain,
> only
> reaping from others if there is free TID shortage.
>
> A dedicated callout is introduced to reap lingering threads if there
> happens
> to be no activity.
>
> Reviewed by: kib, markj
> Differential Revision:https://reviews.freebsd.org/D27185
>
> Modified:
> head/sys/kern/kern_thread.c
>
> Modified: head/sys/kern/kern_thread.c
>
> ==
> --- head/sys/kern/kern_thread.c Thu Nov 19 09:26:51 2020(r367841)
> +++ head/sys/kern/kern_thread.c Thu Nov 19 10:00:48 2020(r367842)
> @@ -52,6 +52,7 @@ __FBSDID("$FreeBSD$");
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -64,9 +65,11 @@ __FBSDID("$FreeBSD$");
>
> #include
>
> +#include
> #include
> #include
> #include
> +#include
> #include
>
> /*
> @@ -128,9 +131,20 @@ SDT_PROBE_DEFINE(proc, , , lwp__exit);
> */
> static uma_zone_t thread_zone;
>
> -static __exclusive_cache_line struct thread *thread_zombies;
> +struct thread_domain_data {
> + struct thread *tdd_zombies;
> + int tdd_reapticks;
> +} __aligned(CACHE_LINE_SIZE);
>
> +static struct thread_domain_data thread_domain_data[MAXMEMDOM];
> +
> +static struct task thread_reap_task;
> +static struct callout thread_reap_callout;
> +
> static void thread_zombie(struct thread *);
> +static void thread_reap_all(void);
> +static void thread_reap_task_cb(void *, int);
> +static void thread_reap_callout_cb(void *);
> static int thread_unsuspend_one(struct thread *td, struct proc *p,
> bool boundary);
> static void thread_free_batched(struct thread *td);
> @@ -159,30 +173,45 @@ EVENTHANDLER_LIST_DEFINE(thread_init);
> EVENTHANDLER_LIST_DEFINE(thread_fini);
>
> static bool
> -thread_count_inc(void)
> +thread_count_inc_try(void)
> {
> - static struct timeval lastfail;
> - static int curfail;
> int nthreads_new;
>
> - thread_reap();
> -
> nthreads_new = atomic_fetchadd_int(, 1) + 1;
> if (nthreads_new >= maxthread - 100) {
> if (priv_check_cred(curthread->td_ucred, PRIV_MAXPROC) !=
> 0 ||
> nthreads_new >= maxthread) {
> atomic_subtract_int(, 1);
> - if (ppsratecheck(, , 1)) {
> - printf("maxthread limit exceeded by uid %u
> "
> - "(pid %d); consider increasing
> kern.maxthread\n",
> - curthread->td_ucred->cr_ruid,
> curproc->p_pid);
> - }
> return (false);
> }
> }
> return (true);
> }
>
> +static bool
> +thread_count_inc(void)
> +{
> + static struct timeval lastfail;
> + static int curfail;
> +
> + thread_reap();
> + if (thread_count_inc_try()) {
> + return (true);
> + }
> +
> + thread_reap_all();
> + if (thread_count_inc_try())
Re: svn commit: r354239 - head/contrib/gdb/gdb
The kernel parts were fixed by r354213 and r354214. I've used old kgdb to test remote debugging through serial only, not for inspecting crash dumps. On Fri, Nov 1, 2019 at 4:34 PM John Baldwin wrote: > On 11/1/19 12:26 PM, luporl wrote: > > Well, after evaluating remote kernel debugging through serial port, on > > amd64, I've run into several issues while using latest ports gdb/kgdb. > > I don't remember all of them, but were things like step/next not always > > working, connection being lost, and similar things. > > OTOH, /usr/libexec/kgdb worked fine and reliably, although older and more > > limited. > > This is probably due to some incompatibility in GDB Remote Serial > Protocol, > > between the kernel backend and newer GDB from ports. > > > > So, that's why I chose to use /usr/libexec/kgdb while fixing/enabling > > remote debugging on PPC64, because it works reasonably well, and I could > > focus on testing/fixing other parts first. > > With only this change on gdb, it is now possible to use it to test some > > basic functionality, like remote debugger attach, backtrace and data > > inspection. > > > > My goal is not to fix every issue in /usr/libexec/kgdb, but just to get > the > > basics working, to then move on and switch to ports' GDB. > > What's odd about this commit is it only affects userland binaries, not the > kernel, so a bit odd for kgdb, especially since the old kgdb in the tree > doesn't include user support IIRC, only kernel bits (in modern gdb, kgdb > is just a wrapper, and you can use 'target vmcore' from within gdb itself > against a crash dump, etc.) > > -- > John Baldwin > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r354239 - head/contrib/gdb/gdb
Well, after evaluating remote kernel debugging through serial port, on amd64, I've run into several issues while using latest ports gdb/kgdb. I don't remember all of them, but were things like step/next not always working, connection being lost, and similar things. OTOH, /usr/libexec/kgdb worked fine and reliably, although older and more limited. This is probably due to some incompatibility in GDB Remote Serial Protocol, between the kernel backend and newer GDB from ports. So, that's why I chose to use /usr/libexec/kgdb while fixing/enabling remote debugging on PPC64, because it works reasonably well, and I could focus on testing/fixing other parts first. With only this change on gdb, it is now possible to use it to test some basic functionality, like remote debugger attach, backtrace and data inspection. My goal is not to fix every issue in /usr/libexec/kgdb, but just to get the basics working, to then move on and switch to ports' GDB. - Leandro On Fri, Nov 1, 2019 at 1:06 PM John Baldwin wrote: > On 11/1/19 4:28 AM, Leandro Lupori wrote: > > Author: luporl > > Date: Fri Nov 1 11:28:43 2019 > > New Revision: 354239 > > URL: https://svnweb.freebsd.org/changeset/base/354239 > > > > Log: > > [PPC64] Fix GDB sigtramp detection > > > > Current implementation of ppcfbsd_pc_in_sigtramp() seems to take only > 32-bit > > PowerPC in account, as on 64-bit PowerPC most kernel instruction > addresses will > > be wrongly reported as in sigtramp. > > > > This change adds proper sigtramp detection for PPC64. > > It's probably not worth fixing this in /usr/bin/gdb? At this point gdb is > only > installed for the kgdb in /usr/libexec on all platforms but sparc64 to > serve as > a fall-back for the crashinfo script in case the ports gdb isn't > installed. The > ports gdb should handle signal trampolines fine on ppc. It uses > instruction > matching patterns to detect trampolines on all supported platforms instead > of > static sigtramp locations. > > -- > John Baldwin > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344534 - head/cddl/contrib/opensolaris/tools/ctf/cvt
Sorry, I forgot to copy the summary from D19353.
Is there a way to change it now?
On Mon, Feb 25, 2019 at 3:56 PM Ian Lepore wrote:
>
> On Mon, 2019-02-25 at 18:52 +, Leandro Lupori wrote:
> > Author: luporl
> > Date: Mon Feb 25 18:52:47 2019
> > New Revision: 344534
> > URL: https://svnweb.freebsd.org/changeset/base/344534
> >
> > Log:
> > Increase ctfconvert buffer size
> >
> > Reviewed by:markj
> > Differential Revision: https://reviews.freebsd.org/D19353
> >
>
> This is not a very good commit message. To be good, it should say why
> the size is being increased. If the commit had included the summary
> text from D19353 it would have been perfect.
>
> -- Ian
>
> > Modified:
> > head/cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c
> >
> > Modified: head/cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c
> > =
> > =
> > --- head/cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c Mon Feb
> > 25 18:41:16 2019 (r344533)
> > +++ head/cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c Mon Feb
> > 25 18:52:47 2019 (r344534)
> > @@ -1268,7 +1268,7 @@ die_funcptr_create(dwarf_t *dw, Dwarf_Die die,
> > Dwarf_O
> > static intr_t *
> > die_base_name_parse(const char *name, char **newp)
> > {
> > - char buf[100];
> > + char buf[256];
> > char const *base;
> > char *c;
> > int nlong = 0, nshort = 0, nchar = 0, nint = 0;
> >
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
