Re: libmap.conf: mapping directories?
The patch attached is implementing a freebsd32 prefix thing like we do for the linux compatibility. It would be nice if you could try it and report me any errors or bugs you may find. The patch is meant to be applied against current and might work on the 6- branch. It won't be enough and some file-moving would be needed to make it work correctly as there is still nothing in the /compat/ia32 directory afaik. I mean that it would be interesting to move the freebsd32 libs and other compatibility files in that folder. Best Regards, Antoine freebsd32prefix-current.patch Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
compiling the kernel faster
> > You can set NOCLEAN in your environment. That will save you from > having to rebuild things that didn't change. Major time saver if > you're only working in a couple of files. It's NO_CLEAN actually, and for the kernel building, it's especially NO_KERNELCLEAN Antoine Pelisse -Glenn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd-5.4-stable panics
On 9/30/05, John Baldwin <[EMAIL PROTECTED]> wrote:
>
> On Friday 30 September 2005 11:25 am, Antoine Pelisse wrote:
> > On 9/30/05, John Baldwin <[EMAIL PROTECTED]> wrote:
> > > On Friday 30 September 2005 05:24 am, Antoine Pelisse wrote:
> > > > Hi Robert,
> > > > I don't think your patch is correct, the total linked list can be
> > > > broken
> > > >
> > > > while the lock is released, thus just passing the link may not be
> > > > enough I have submitted a PR[1] for this a month ago but nobody took
> > > > care of it yet Regards,
> > > > Antoine Pelisse
> > > >
> > > > [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84684
> > >
> > > I think this patch looks ok. Robert, can you get the original panic on
> > > this
> > > thread tested against this patch?
> >
> > I had a small program which could reproduce this panic in 10 seconds, it
> > was basically creating empty threads and calling kvm_getprocs() in the
> same
> > time. Anyway the patch was able to stop the program from panicing.
> > The panic is also reproducible in RELENG_6 and HEAD IIRC.
>
> It turns out that the sysctl buffer is already wired in one of the two
> cases
> that this function is called, so I moved the wiring up to the upper layer
> in
> the other case and cut out a bunch of the locking gymnastics as a result.
> Can you try this patch?
>
> Index: kern_proc.c
> ===
> RCS file: /usr/cvs/src/sys/kern/kern_proc.c,v
> retrieving revision 1.231
> diff -u -r1.231 kern_proc.c
> --- kern_proc.c 27 Sep 2005 18:03:15 - 1.231
> +++ kern_proc.c 30 Sep 2005 17:04:57 -
> @@ -875,22 +875,16 @@
>
> if (flags & KERN_PROC_NOTHREADS) {
> fill_kinfo_proc(p, &kinfo_proc);
> - PROC_UNLOCK(p);
> error = SYSCTL_OUT(req, (caddr_t)&kinfo_proc,
> sizeof(kinfo_proc));
> - PROC_LOCK(p);
> } else {
> - _PHOLD(p);
> FOREACH_THREAD_IN_PROC(p, td) {
> fill_kinfo_thread(td, &kinfo_proc);
> - PROC_UNLOCK(p);
> error = SYSCTL_OUT(req, (caddr_t)&kinfo_proc,
> sizeof(kinfo_proc));
> - PROC_LOCK(p);
> if (error)
> break;
> }
> - _PRELE(p);
> }
> PROC_UNLOCK(p);
> if (error)
> @@ -932,6 +926,9 @@
> if (oid_number == KERN_PROC_PID) {
> if (namelen != 1)
> return (EINVAL);
> + error = sysctl_wire_old_buffer(req, 0);
> + if (error)
> + return (error);
> p = pfind((pid_t)name[0]);
> if (!p)
> return (ESRCH);
>
> --
> John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve" = http://www.FreeBSD.org
>
Hi John,
I'm sorry I can't test it right now, I'm in a foreign country for three
months and can only connect to the internet through the university
connection.
I'll be back home mid-december. Maybe Rob should take care of testing it.
Regards,
Antoine Pelisse
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
freebsd-5.4-stable panics
On 9/30/05, John Baldwin <[EMAIL PROTECTED]> wrote:
> On Friday 30 September 2005 05:24 am, Antoine Pelisse wrote:
> > Hi Robert,
> > I don't think your patch is correct, the total linked list can be broken
>
> > while the lock is released, thus just passing the link may not be enough
> > I have submitted a PR[1] for this a month ago but nobody took care of it
> > yet Regards,
> > Antoine Pelisse
> >
> > [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84684
>
> I think this patch looks ok. Robert, can you get the original panic on
> this
> thread tested against this patch?
I had a small program which could reproduce this panic in 10 seconds, it
was basically creating empty threads and calling kvm_getprocs() in the same
time. Anyway the patch was able to stop the program from panicing.
The panic is also reproducible in RELENG_6 and HEAD IIRC.
> On 9/29/05, Robert Watson <[EMAIL PROTECTED]> wrote:
> > > On Thu, 29 Sep 2005, Rob Watt wrote:
> > > > On Thu, 29 Sep 2005, Robert Watson wrote:
> > > >> Could you dump the contents of *td and *td->td_proc for me? I'm
> quite
> > > >> interested to know what the value in td->td_proc->p_state is, among
>
> > >
> > > other
> > >
> > > >> things. If I could also have you generate a dump of the KSE group
> > > >> structures in td->td_proc->p_ksegrps and the threads in
> > > >> td->td_proc->p_threads.
> > > >
> > > > I've attached a file with many of the values you have asked for. We
> > > > looked at some of the threads referenced by td->td_proc->p_threads,
> but
> > > > we weren't sure we were walking the list correctly. Do you have any
> > > > tips
> > > >
> > > > for walking those thread lists?
> > > >
> > > >> Could you tell me if the program named by p->p_comm is linked
> against
> > > >> a threading library? If it's a custom app, you may already know,
> and
> > > >> if not, you can run ldd on the application to see what it is linked
> > > >> against.
> > > >
> > > > The programs named by p->p_comm is linked against the pthreads
> library.
> > >
> > > This seems to be enough information to at least track this down a bit:
> > > td_ksegrp is NULL, rather than a corrupt value, which suggests that
> the
> > > thread is incompletely initialized. Other hints that this are the case
> > > are that td_critnest is 1 (as is set when it is allocated), and the
> state
> > > is TDS_INACTIVE. Some other fields are set though, such as td_oncpu,
> > > which is normally initialized to NOCPU.
> > >
> > > > (kgdb) p *td
> > > > $1 = {td_proc = 0xff004aa9f000, td_ksegrp = 0x0, td_plist =
> > > > {tqe_next = 0xff 00b4798000,
> > > > tqe_prev = 0xff00a97ae010}, td_kglist = {tqe_next =
> > > > 0xff00b4798000,
> > > > tqe_prev = 0xff00a97ae020}, td_slpq = {tqe_next = 0x0, tqe_prev
> > > > = 0x ff001fac7c10}, td_lockq = {
> > > > tqe_next = 0xff00a97ae000, tqe_prev = 0xb6797a70},
> > > > td_runq = {tq e_next = 0x0,
> > > > tqe_prev = 0x80608180}, td_selq = {tqh_first = 0x0, tqh_last
> > > > = 0xfff fff00633112c0},
> > > > td_sleepqueue = 0xff00382b0400, td_turnstile =
> 0xff00c1712900,
> > > > td_umtx q = 0xff00d1207080,
> > > > td_tid = 100253, td_flags = 16777216, td_inhibitors = 0, td_pflags =
>
> > > > 128, td_d upfd = 0, td_wchan = 0x0,
> > > > td_wmesg = 0x0, td_lastcpu = 2 '\002', td_oncpu = 2 '\002',
> > > > td_owepreempt = 0 '\0', td_locks = 0,
> > > > td_blocked = 0x0, td_ithd = 0x0, td_lockname = 0x0, td_contested =
> > > > {lh_first =
> > > > 0x0}, td_sleeplocks = 0x0,
> > > > td_intr_nesting_level = 0, td_pinned = 0, td_mailbox = 0x0, td_ucred
> =
> > > > 0xf f00ad18f200,
> > > > td_standin = 0x0, td_upcall = 0x0, td_sticks = 0, td_uuticks = 0,
> > > > td_usticks =
> > > > 0, td_intrval = 0,
> > > > td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_sigmask = {__bits =
> > > > {4294967295, 4 294967295, 4294967295,
> > > > 4294967295}}, td_siglist = {__bits = {0, 0, 0, 0}}, td_generation
> > > > = 14, td _sigstk = {ss_sp = 0x0,
> > > > ss_size = 0, ss_flags = 0}, td_kflags = 0, td_xsig = 0,
> >
freebsd-5.4-stable panics
Hi Robert,
I don't think your patch is correct, the total linked list can be broken
while the lock is released, thus just passing the link may not be enough
I have submitted a PR[1] for this a month ago but nobody took care of it yet
Regards,
Antoine Pelisse
[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84684
On 9/29/05, Robert Watson <[EMAIL PROTECTED]> wrote:
>
> On Thu, 29 Sep 2005, Rob Watt wrote:
>
> > On Thu, 29 Sep 2005, Robert Watson wrote:
> >
> >> Could you dump the contents of *td and *td->td_proc for me? I'm quite
> >> interested to know what the value in td->td_proc->p_state is, among
> other
> >> things. If I could also have you generate a dump of the KSE group
> >> structures in td->td_proc->p_ksegrps and the threads in
> >> td->td_proc->p_threads.
> >
> > I've attached a file with many of the values you have asked for. We
> > looked at some of the threads referenced by td->td_proc->p_threads, but
> > we weren't sure we were walking the list correctly. Do you have any tips
>
> > for walking those thread lists?
> >
> >> Could you tell me if the program named by p->p_comm is linked against a
> >> threading library? If it's a custom app, you may already know, and if
> >> not, you can run ldd on the application to see what it is linked
> >> against.
> >
> > The programs named by p->p_comm is linked against the pthreads library.
>
> This seems to be enough information to at least track this down a bit:
> td_ksegrp is NULL, rather than a corrupt value, which suggests that the
> thread is incompletely initialized. Other hints that this are the case
> are that td_critnest is 1 (as is set when it is allocated), and the state
> is TDS_INACTIVE. Some other fields are set though, such as td_oncpu,
> which is normally initialized to NOCPU.
>
> > (kgdb) p *td
> > $1 = {td_proc = 0xff004aa9f000, td_ksegrp = 0x0, td_plist =
> > {tqe_next = 0xff 00b4798000,
> > tqe_prev = 0xff00a97ae010}, td_kglist = {tqe_next =
> > 0xff00b4798000,
> > tqe_prev = 0xff00a97ae020}, td_slpq = {tqe_next = 0x0, tqe_prev
> > = 0x ff001fac7c10}, td_lockq = {
> > tqe_next = 0xff00a97ae000, tqe_prev = 0xb6797a70},
> > td_runq = {tq e_next = 0x0,
> > tqe_prev = 0x80608180}, td_selq = {tqh_first = 0x0, tqh_last
> > = 0xfff fff00633112c0},
> > td_sleepqueue = 0xff00382b0400, td_turnstile = 0xff00c1712900,
> > td_umtx q = 0xff00d1207080,
> > td_tid = 100253, td_flags = 16777216, td_inhibitors = 0, td_pflags =
> > 128, td_d upfd = 0, td_wchan = 0x0,
> > td_wmesg = 0x0, td_lastcpu = 2 '\002', td_oncpu = 2 '\002',
> > td_owepreempt = 0 '\0', td_locks = 0,
> > td_blocked = 0x0, td_ithd = 0x0, td_lockname = 0x0, td_contested =
> > {lh_first =
> > 0x0}, td_sleeplocks = 0x0,
> > td_intr_nesting_level = 0, td_pinned = 0, td_mailbox = 0x0, td_ucred =
> > 0xf f00ad18f200,
> > td_standin = 0x0, td_upcall = 0x0, td_sticks = 0, td_uuticks = 0,
> > td_usticks =
> > 0, td_intrval = 0,
> > td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_sigmask = {__bits =
> > {4294967295, 4 294967295, 4294967295,
> > 4294967295}}, td_siglist = {__bits = {0, 0, 0, 0}}, td_generation
> > = 14, td _sigstk = {ss_sp = 0x0,
> > ss_size = 0, ss_flags = 0}, td_kflags = 0, td_xsig = 0,
> > td_profil_addr = 0, td_profil_ticks = 0,
> > td_base_pri = 182 '\u', td_priority = 182 '\u', td_pcb =
> > 0xb68 dcd10, td_state = TDS_INACTIVE,
> > td_retval = {1, 29309280}, td_slpcallout = {c_links = {sle = {sle_next
> > = 0x0},
> > tqe = {tqe_next = 0x0,
> > tqe_prev = 0xff001fac7d80}}, c_time = 55907602, c_arg =
> > 0xff0063 311260,
> > c_func = 0x802e32a0 , c_mtx = 0x0, c_flags =
> > 16}, td _frame = 0xb68dcc40,
> > td_kstack_obj = 0xff0087f93d20, td_kstack = 18446744072477315072,
> > td_kstac k_pages = 4,
> > td_altkstack_obj = 0x0, td_altkstack = 0, td_altkstack_pages = 0,
> > td_critnest = 1, td_md = {
> > md_spinlock_count = 1, md_saved_flags = 582}, td_sched =
> > 0xff0063311488}
>
> I'm not familiar with the internals of the thread and KSE life cycle here,
>
> so I think we'll need to look to those more familiar with this to
> understand what of two things may be going on:
>
> (1) Is the fact that td_ksegrp != NULL an invariant for a connected
> thread, and that kern_proc is relying on that but the thread code is
> failing to implement it safely?
>
> (2) Is td_k
