From owner-freebsd-current Tue Mar 5 10:21:25 2002 Delivered-To: freebsd-current@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id C482037B417; Tue, 5 Mar 2002 10:20:43 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id g25IKgn07447; Tue, 5 Mar 2002 19:20:42 +0100 (CET) (envelope-from wkb) Date: Tue, 5 Mar 2002 19:20:42 +0100 From: Wilko Bulte To: John Baldwin Cc: freebsd-alpha@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: blockable sleep panic on Alpha / current Message-ID: <20020305192042.A7375@freebie.xs4all.nl> References: <20020304191303.A2288@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Tue, Mar 05, 2002 at 10:51:53AM -0500 X-OS: FreeBSD 4.5-STABLE X-PGP: finger wilko@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 Tue, Mar 05, 2002 at 10:51:53AM -0500, John Baldwin wrote: Hi John, > On 04-Mar-02 Wilko Bulte wrote: > > During a make release I just got a panic. The build progressed until: > > > > gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxabs.3 > imaxabs.3.gz > > gzip -cn /usr/src/lib/libc/../libc/stdlib/imaxdiv.3 > imaxdiv.3.gz > > gzip -cn /usr/src/lib/libc/../libc/stdlib/labs.3 > labs.3.gz > > > > The running system is a -current as of today. > > > > The panic: > > > > login: > > FreeBSD/alpha (ds10.wbnet) (ttyd0) > > > > login: panic: blockable sleep lock (sleep mutex) Giant @ > > ../../../alpha/alpha/tr > > ap.c:482 > > cpuid = 0; panic > > Stopped at Debugger+0x34: zapnot v0,#0xf,a0 > > db> > > db> trace > > Debugger() at Debugger+0x34 > > panic() at panic+0x188 > > witness_lock() at witness_lock+0xb4 > > _mtx_lock_flags() at _mtx_lock_flags+0xd8 > > trap() at trap+0x4c8 > > XentMM() at XentMM+0x2c > > --- memory management fault (from ipl 7) --- > > statclock_process() at statclock_process+0x1d4 > > We did something stupid like dereference a NULL pointer here. Can you pull up > gdb on kernel.debug and do 'l *statclock_process+0x1d4'? Thanks to Drew for confirming that -current's gdb is hosed. Using the -stable gdb I get better results. Anyway: (kgdb) l *statclock_process+0x1d4 0xfffffc00003d1ed4 is in statclock_process (../../../kern/kern_clock.c:447). 442 443 /* Update resource usage integrals and maximums. */ 444 if ((pstats = p->p_stats) != NULL && 445 (ru = &pstats->p_ru) != NULL && 446 (vm = p->p_vmspace) != NULL) { 447 ru->ru_ixrss += pgtok(vm->vm_tsize); 448 ru->ru_idrss += pgtok(vm->vm_dsize); 449 ru->ru_isrss += pgtok(vm->vm_ssize); 450 rss = pgtok(vmspace_resident_count(vm)); 451 if (ru->ru_maxrss < rss) (kgdb) > > > XentMM() at XentMM+0x2c > > --- memory management fault --- > > ithread_schedule() at ithread_schedule+0xa4 > > Eww, we have another one here. (kgdb) l *ithread_schedule+0xa4 0xfffffc00003e2924 is in ithread_schedule (../../../kern/kern_intr.c:375). 370 random_harvest(&entropy, sizeof(entropy), 2, 0, 371 RANDOM_INTERRUPT); 372 } 373 374 td = ithread->it_td; 375 p = td->td_proc; 376 KASSERT(p != NULL, ("ithread %s has no process", ithread->it_name)); 377 CTR4(KTR_INTR, "%s: pid %d: (%s) need = %d", __func__, p->p_pid, p->p_comm, 378 ithread->it_need); 379 (kgdb) > > alpha_dispatch_intr() at alpha_dispatch_intr+0x130 > > interrupt() at interrupt+0x138 > > XentInt() at XentInt+0x28 > > --- interrupt (from ipl 0) --- > > critical_exit() at critical_exit+0x1c > > _mtx_unlock_spin_flags() at _mtx_unlock_spin_flags+0xd4 > > vm_fault1() at vm_fault1+0x110c > > vm_fault() at vm_fault+0x64 > > trap() at trap+0x6d8 > > XentMM() at XentMM+0x2c > > --- memory management fault --- > > pmap_enter_quick() at pmap_enter_quick+0x1d4 > > Ugh, this is probably the real bug. :( Can you do a list on this address? (kgdb) l *pmap_enter_quick+0x1d4 0xfffffc000052c314 is in pmap_enter_quick (../../../alpha/alpha/pmap.c:2422). 2417 pmap_insert_entry(pmap, va, mpte, m); 2418 2419 /* 2420 * Increment counters 2421 */ 2422 pmap->pm_stats.resident_count++; 2423 2424 /* 2425 * Now validate mapping with RO protection 2426 */ (kgdb) I hope this makes sense. I still hope to catch a dump. Or alternatively I hope it get's caught by ddb. W/ -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message