From owner-freebsd-current Wed May 30 7:39:52 2001 Delivered-To: freebsd-current@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id DBEEF37B424 for ; Wed, 30 May 2001 07:39:45 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f4UEdVG96944; Wed, 30 May 2001 07:39:32 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3B14BEAE.FDC43C2A@DougBarton.net> Date: Wed, 30 May 2001 07:39:33 -0700 (PDT) From: John Baldwin To: Doug Barton Subject: Re: -current is _definitely_ not stable right now Cc: freebsd-current@FreeBSD.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 30-May-01 Doug Barton wrote: > John Baldwin wrote: >> >> On 28-May-01 Doug Barton wrote: >> > Gang, >> > >> > On the avi front, typing 'aviplay' with or without an argument is >> > guaranteed to instantly wedge the box. I attached a lot of running aviplay >> > through truss, but I have no way to know if it stopped at or before the >> > offending instruction. As for the general wonkiness of the system, I have >> > finally gotten a dump. The backtrace is below, let me know if there is >> > anything else I can do to help debug. >> >> Please try http://www.FreeBSD.org/~jhb/patches/ldt.patch. > > This worked excellently for me! I patched the kernel and rebuilt, then > tested aviplay... success. Then I cvsup'ed, built/installed world and > kernel, and started stress testing. I'm currently running two builds of X > 4, one over NFS and one local, 'make cleandir' in /usr/src, AND avifile > (ok, it's a little choppy, but still runs). I'd say it's probably safe to > go back in the water again. Next stop, re-enabling softupdates. :) Sounds good, I'll commit it in a second. > BTW, I'm probably wrong about this but looking at the patch it seems odd > to me that one of these is ifndef and the other is ifdef: > > @@ -422,15 +433,21 @@ > kmem_free(kernel_map, (vm_offset_t)old_ldt_base, > old_ldt_len * sizeof(union descriptor)); > FREE(new_ldt, M_SUBPROC); > +#ifndef SMP > + mtx_lock_spin(&sched_lock); > +#endif > } else { > pcb->pcb_ldt = pcb_ldt = new_ldt; > +#ifdef SMP > mtx_unlock_spin(&sched_lock); > +#endif > } > > Just curious, We won't to continue to hold the sched_lock before calling set_user_ldt in the !SMP case, but we want to release it in the SMP case before calling the smp rendezvous. We have to release the sched_lock in the then clause before calling kmem_free, so each clause finishes with the sched_lock in a different state. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message